[PATCH 6/6] [v6] phylib: Add of_phy_attach
From: Andy Fleming
10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
drivers/of/of_mdio.c| 20
include/linux/of_mdio.h | 10 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index a43b852..875b7b6 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -254,3 +254,23 @@ struct phy_device *of_phy_connect_fixed_link(struct
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface)
+{
+ struct phy_device *phy = of_phy_find_device(phy_np);
+
+ if (!phy)
+ return NULL;
+
+ return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..6fe8464 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device
*dev,
struct device_node *phy_np,
void (*hndlr)(struct net_device *),
u32 flags, phy_interface_t iface);
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface);
extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface);
@@ -44,6 +47,13 @@ static inline struct phy_device *of_phy_connect(struct
net_device *dev,
return NULL;
}
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np,
+ u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
static inline struct phy_device *of_phy_connect_fixed_link(struct net_device
*dev,
void (*hndlr)(struct
net_device *),
phy_interface_t
iface)
--
1.8.4.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/
[PATCH 3/6] [v6] phylib: turn genphy_driver to an array
From: Shaohui Xie
Then other generic phy driver such as generic 10g phy driver can join it.
Signed-off-by: Shaohui Xie
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
drivers/net/phy/phy_device.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 5d81c89..1cde2b2 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -50,7 +50,12 @@ static void phy_device_release(struct device *dev)
kfree(to_phy_device(dev));
}
-static struct phy_driver genphy_driver;
+enum genphy_driver {
+ GENPHY_DRV_1G,
+ GENPHY_DRV_MAX
+};
+
+static struct phy_driver genphy_driver[GENPHY_DRV_MAX];
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
@@ -580,7 +585,7 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
return -ENODEV;
}
- d->driver = _driver.driver;
+ d->driver = _driver[GENPHY_DRV_1G].driver;
err = d->driver->probe(d);
if (err >= 0)
@@ -658,6 +663,7 @@ EXPORT_SYMBOL(phy_attach);
*/
void phy_detach(struct phy_device *phydev)
{
+ int i;
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
phy_suspend(phydev);
@@ -667,8 +673,12 @@ void phy_detach(struct phy_device *phydev)
* from the generic driver so that there's a chance a
* real driver could be loaded
*/
- if (phydev->dev.driver == _driver.driver)
- device_release_driver(>dev);
+ for (i = 0; i < ARRAY_SIZE(genphy_driver); i++) {
+ if (phydev->dev.driver == _driver[i].driver) {
+ device_release_driver(>dev);
+ break;
+ }
+ }
}
EXPORT_SYMBOL(phy_detach);
@@ -1173,7 +1183,8 @@ void phy_drivers_unregister(struct phy_driver *drv, int n)
}
EXPORT_SYMBOL(phy_drivers_unregister);
-static struct phy_driver genphy_driver = {
+static struct phy_driver genphy_driver[] = {
+{
.phy_id = 0x,
.phy_id_mask= 0x,
.name = "Generic PHY",
@@ -1184,7 +1195,7 @@ static struct phy_driver genphy_driver = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE, },
-};
+} };
static int __init phy_init(void)
{
@@ -1194,7 +1205,8 @@ static int __init phy_init(void)
if (rc)
return rc;
- rc = phy_driver_register(_driver);
+ rc = phy_drivers_register(genphy_driver,
+ ARRAY_SIZE(genphy_driver));
if (rc)
mdio_bus_exit();
@@ -1203,7 +1215,8 @@ static int __init phy_init(void)
static void __exit phy_exit(void)
{
- phy_driver_unregister(_driver);
+ phy_drivers_unregister(genphy_driver,
+ ARRAY_SIZE(genphy_driver));
mdio_bus_exit();
}
--
1.8.4.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/
[PATCH 2/6] [v6] phylib: introduce PHY_INTERFACE_MODE_XGMII for 10G PHY
From: Andy Fleming
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
drivers/of/of_net.c | 1 +
include/linux/phy.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..a208a45 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -30,6 +30,7 @@ static const char *phy_modes[] = {
[PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
[PHY_INTERFACE_MODE_RTBI] = "rtbi",
[PHY_INTERFACE_MODE_SMII] = "smii",
+ [PHY_INTERFACE_MODE_XGMII] = "xgmii",
};
/**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3eda43c..a9685b1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -73,6 +73,7 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
+ PHY_INTERFACE_MODE_XGMII,
} phy_interface_t;
--
1.8.4.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/
[PATCH 5/6] [v6] phylib: Support attaching to generic 10g driver
From: Andy Fleming
phy_attach_direct() may now attach to a generic 10G driver. It can
also be used exactly as phy_connect_direct(), which will be useful
when using of_mdio, as phy_connect (and therefore of_phy_connect)
start the PHY state machine, which is currently irrelevant for 10G
PHYs.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Acked-by: Florian Fainelli
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
drivers/net/phy/phy_device.c | 22 +-
include/linux/phy.h | 2 ++
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 18714fe..39794c4 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -62,9 +62,6 @@ static struct phy_driver genphy_driver[GENPHY_DRV_MAX];
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface);
-
/**
* phy_register_fixup - creates a new phy_fixup and adds it to the list
* @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID)
@@ -567,13 +564,13 @@ EXPORT_SYMBOL(phy_init_hw);
*
* Description: Called by drivers to attach to a particular PHY
* device. The phy_device is found, and properly hooked up
- * to the phy_driver. If no driver is attached, then the
- * genphy_driver is used. The phy_device is given a ptr to
+ * to the phy_driver. If no driver is attached, then a
+ * generic driver is used. The phy_device is given a ptr to
* the attaching device, and given a callback for link status
* change. The phy_device is returned to the attaching driver.
*/
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface)
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+ u32 flags, phy_interface_t interface)
{
struct device *d = >dev;
int err;
@@ -582,12 +579,10 @@ static int phy_attach_direct(struct net_device *dev,
struct phy_device *phydev,
* exist, and we should use the genphy driver.
*/
if (NULL == d->driver) {
- if (phydev->is_c45) {
- pr_err("No driver for phy %x\n", phydev->phy_id);
- return -ENODEV;
- }
-
- d->driver = _driver[GENPHY_DRV_1G].driver;
+ if (phydev->is_c45)
+ d->driver = _driver[GENPHY_DRV_10G].driver;
+ else
+ d->driver = _driver[GENPHY_DRV_1G].driver;
err = d->driver->probe(d);
if (err >= 0)
@@ -623,6 +618,7 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
return err;
}
+EXPORT_SYMBOL(phy_attach_direct);
/**
* phy_attach - attach a network device to a particular PHY device
diff --git a/include/linux/phy.h b/include/linux/phy.h
index a9685b1..565188c 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -588,6 +588,8 @@ int phy_resume(struct phy_device *phydev);
struct phy_device *phy_attach(struct net_device *dev, const char *bus_id,
phy_interface_t interface);
struct phy_device *phy_find_first(struct mii_bus *bus);
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+ u32 flags, phy_interface_t interface);
int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *),
phy_interface_t interface);
--
1.8.4.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/
[PATCH 4/6] [v6] phylib: Add generic 10G driver
From: Andy Fleming
Very incomplete, but will allow for binding an ethernet controller
to it.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
drivers/net/phy/phy_device.c | 81
1 file changed, 81 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1cde2b2..18714fe 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -52,6 +53,7 @@ static void phy_device_release(struct device *dev)
enum genphy_driver {
GENPHY_DRV_1G,
+ GENPHY_DRV_10G,
GENPHY_DRV_MAX
};
@@ -769,6 +771,12 @@ static int genphy_config_advert(struct phy_device *phydev)
return changed;
}
+int gen10g_config_advert(struct phy_device *dev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_advert);
+
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
@@ -816,6 +824,12 @@ int genphy_restart_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_restart_aneg);
+int gen10g_restart_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_restart_aneg);
+
/**
* genphy_config_aneg - restart auto-negotiation or write BMCR
* @phydev: target phy_device struct
@@ -857,6 +871,12 @@ int genphy_config_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_config_aneg);
+int gen10g_config_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_aneg);
+
/**
* genphy_update_link - update link status in @phydev
* @phydev: target phy_device struct
@@ -988,6 +1008,34 @@ int genphy_read_status(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_read_status);
+int gen10g_read_status(struct phy_device *phydev)
+{
+ int devad, reg;
+ u32 mmd_mask = phydev->c45_ids.devices_in_package;
+
+ phydev->link = 1;
+
+ /* For now just lie and say it's 10G all the time */
+ phydev->speed = SPEED_1;
+ phydev->duplex = DUPLEX_FULL;
+
+ for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
+ if (!(mmd_mask & 1))
+ continue;
+
+ /* Read twice because link state is latched and a
+* read moves the current state into the register
+*/
+ phy_read_mmd(phydev, devad, MDIO_STAT1);
+ reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
+ if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
+ phydev->link = 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_read_status);
+
static int genphy_config_init(struct phy_device *phydev)
{
int val;
@@ -1033,6 +1081,16 @@ static int genphy_config_init(struct phy_device *phydev)
return 0;
}
+
+static int gen10g_config_init(struct phy_device *phydev)
+{
+ /* Temporarily just say we support everything */
+ phydev->supported = SUPPORTED_1baseT_Full;
+ phydev->advertising = SUPPORTED_1baseT_Full;
+
+ return 0;
+}
+
int genphy_suspend(struct phy_device *phydev)
{
int value;
@@ -1048,6 +1106,12 @@ int genphy_suspend(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_suspend);
+int gen10g_suspend(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_suspend);
+
int genphy_resume(struct phy_device *phydev)
{
int value;
@@ -1063,6 +1127,12 @@ int genphy_resume(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_resume);
+int gen10g_resume(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_resume);
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -1195,6 +1265,17 @@ static struct phy_driver genphy_driver[] = {
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE, },
+}, {
+ .phy_id = 0x,
+ .phy_id_mask= 0x,
+ .name = "Generic 10G PHY",
+ .config_init= gen10g_config_init,
+ .features = 0,
+ .config_aneg= gen10g_config_aneg,
+ .read_status= gen10g_read_status,
+ .suspend= gen10g_suspend,
+ .resume = gen10g_resume,
+ .driver = {.owner = THIS_MODULE, },
} };
static int __init phy_init(void)
--
1.8.4.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/
[PATCH 1/6] [v6] phylib: Add Clause 45 read/write functions
From: Andy Fleming
Need an extra parameter to read or write Clause 45 PHYs, so
need a different API with the extra parameter.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
---
changes for v6:
rebased on top of 'net-next' tree. commit id 11b57f90257c1.
include/linux/phy.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 7c81dd8..3eda43c 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -488,6 +488,24 @@ struct phy_fixup {
};
/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32
regnum)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ return mdiobus_read(phydev->bus, phydev->addr,
+ MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+}
+
+/**
* phy_read - Convenience function for reading a given PHY register
* @phydev: the phy_device struct
* @regnum: register number to read
@@ -537,6 +555,27 @@ static inline bool phy_is_internal(struct phy_device
*phydev)
return phydev->is_internal;
}
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
+
+ return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
+}
+
struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45,
struct phy_c45_device_ids *c45_ids);
--
1.8.4.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/
[PATCH 1/4] Input: synaptics-rmi4 - split of transport ops into a separate structure
Split off transport operations from rmi_transport_dev into a separate
structure that will be shared between all devices using the same transport
and use const pointer to access it.
Change signature on transport methods so that length is using the proper
tyep - size_t.
Also rename rmi_transport_info to rmi_transport_stats and move protocol
name (which is the only immutable piece of data there) into the transport
device itself.
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_bus.h| 64 -
drivers/input/rmi4/rmi_driver.c | 8 +++---
drivers/input/rmi4/rmi_i2c.c| 49 ---
3 files changed, 67 insertions(+), 54 deletions(-)
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 3e8b57a..ccf26dc 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -135,26 +135,25 @@ struct rmi_driver {
#define to_rmi_driver(d) \
container_of(d, struct rmi_driver, driver);
-/** struct rmi_transport_info - diagnostic information about the RMI transport
+/**
+ * struct rmi_transport_stats - diagnostic information about the RMI transport
* device, used in the xport_info debugfs file.
*
* @proto String indicating the protocol being used.
* @tx_count Number of transmit operations.
- * @tx_bytes Number of bytes transmitted.
* @tx_errs Number of errors encountered during transmit operations.
+ * @tx_bytes Number of bytes transmitted.
* @rx_count Number of receive operations.
- * @rx_bytes Number of bytes received.
* @rx_errs Number of errors encountered during receive operations.
- * @att_count Number of times ATTN assertions have been handled.
+ * @rx_bytes Number of bytes received.
*/
-struct rmi_transport_info {
- const char *proto;
- long tx_count;
- long tx_bytes;
- long tx_errs;
- long rx_count;
- long rx_bytes;
- long rx_errs;
+struct rmi_transport_stats {
+ unsigned long tx_count;
+ unsigned long tx_errs;
+ size_t tx_bytes;
+ unsigned long rx_count;
+ unsigned long rx_errs;
+ size_t rx_bytes;
};
/**
@@ -162,13 +161,14 @@ struct rmi_transport_info {
*
* @dev: Pointer to the communication device, e.g. i2c or spi
* @rmi_dev: Pointer to the RMI device
- * @write_block: Writing a block of data to the specified address
- * @read_block: Read a block of data from the specified address.
* @irq_thread: if not NULL, the sensor driver will use this instead of the
* default irq_thread implementation.
* @hard_irq: if not NULL, the sensor driver will use this for the hard IRQ
* handling
* @data: Private data pointer
+ * @proto_name: name of the transport protocol (SPI, i2c, etc)
+ * @ops: pointer to transport operations implementation
+ * @stats: transport statistics
*
* The RMI transport device implements the glue between different communication
* buses such as I2C and SPI.
@@ -178,20 +178,30 @@ struct rmi_transport_dev {
struct device *dev;
struct rmi_device *rmi_dev;
- int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
- const void *buf, const int len);
- int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
- void *buf, const int len);
-
- int (*enable_device) (struct rmi_transport_dev *xport);
- void (*disable_device) (struct rmi_transport_dev *xport);
-
irqreturn_t (*irq_thread)(int irq, void *p);
irqreturn_t (*hard_irq)(int irq, void *p);
void *data;
- struct rmi_transport_info info;
+ const char *proto_name;
+ const struct rmi_transport_ops *ops;
+ struct rmi_transport_stats stats;
+};
+
+/**
+ * struct rmi_transport_ops - defines transport protocol operations.
+ *
+ * @write_block: Writing a block of data to the specified address
+ * @read_block: Read a block of data from the specified address.
+ */
+struct rmi_transport_ops {
+ int (*write_block)(struct rmi_transport_dev *xport, u16 addr,
+ const void *buf, size_t len);
+ int (*read_block)(struct rmi_transport_dev *xport, u16 addr,
+ void *buf, size_t len);
+
+ int (*enable_device) (struct rmi_transport_dev *xport);
+ void (*disable_device) (struct rmi_transport_dev *xport);
};
/**
@@ -232,7 +242,7 @@ bool rmi_is_physical_device(struct device *dev);
*/
static inline int rmi_read(struct rmi_device *d, u16 addr, void *buf)
{
- return d->xport->read_block(d->xport, addr, buf, 1);
+ return d->xport->ops->read_block(d->xport, addr, buf, 1);
}
/**
@@ -248,7 +258,7 @@ static inline int rmi_read(struct rmi_device *d, u16 addr,
void *buf)
static inline int rmi_read_block(struct rmi_device *d, u16 addr, void *buf,
const int len)
{
- return d->xport->read_block(d->xport, addr, buf, len);
+ return
[PATCH 4/4] Input: synaptics-rmi4 - switch to using i2c_transfer()
Instead of using 2 separate transactions when reading from the device let's
use i2c_transfer. Because we now have single point of failure I had to
change how we collect statistics. I elected to drop control data from the
stats and only track number of bytes read/written for the device data.
Also, since we are not prepared to deal with short reads and writes change
read_block_data and write_block_data to indicate error if we detect short
transfers.
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_i2c.c | 71
1 file changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index c176218..51f5bc8 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -57,22 +57,17 @@ struct rmi_i2c_xport {
*/
static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
{
- struct rmi_transport_dev *xport = _i2c->xport;
struct i2c_client *client = rmi_i2c->client;
u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
int retval;
- dev_dbg(>dev, "writes 3 bytes: %02x %02x\n",
- txbuf[0], txbuf[1]);
- xport->stats.tx_count++;
- xport->stats.tx_bytes += sizeof(txbuf);
retval = i2c_master_send(client, txbuf, sizeof(txbuf));
if (retval != sizeof(txbuf)) {
- xport->stats.tx_errs++;
dev_err(>dev,
"%s: set page failed: %d.", __func__, retval);
return (retval < 0) ? retval : -EIO;
}
+
rmi_i2c->page = page;
return 0;
}
@@ -107,22 +102,27 @@ static int rmi_i2c_write_block(struct rmi_transport_dev
*xport, u16 addr,
if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
- if (retval < 0)
+ if (retval)
goto exit;
}
+ retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
+ if (retval == tx_size)
+ retval = 0;
+ else if (retval >= 0)
+ retval = -EIO;
+
+exit:
dev_dbg(>dev,
- "writes %zd bytes at %#06x: %*ph\n", len, addr, (int)len, buf);
+ "write %zd bytes at %#06x: %d (%*ph)\n",
+ len, addr, retval, (int)len, buf);
xport->stats.tx_count++;
- xport->stats.tx_bytes += tx_size;
- retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
- if (retval < 0)
+ if (retval)
xport->stats.tx_errs++;
else
- retval--; /* don't count the address byte */
+ xport->stats.tx_bytes += len;
-exit:
mutex_unlock(_i2c->page_mutex);
return retval;
}
@@ -133,40 +133,47 @@ static int rmi_i2c_read_block(struct rmi_transport_dev
*xport, u16 addr,
struct rmi_i2c_xport *rmi_i2c =
container_of(xport, struct rmi_i2c_xport, xport);
struct i2c_client *client = rmi_i2c->client;
- u8 txbuf[1] = {addr & 0xff};
+ u8 addr_offset = addr & 0xff;
int retval;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client->addr,
+ .len= sizeof(addr_offset),
+ .buf= _offset,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len= len,
+ .buf= buf,
+ },
+ };
mutex_lock(_i2c->page_mutex);
if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
- if (retval < 0)
+ if (retval)
goto exit;
}
- dev_dbg(>dev, "writes 1 bytes: %02x\n", txbuf[0]);
+ retval = i2c_transfer(client->adapter, msgs, sizeof(msgs));
+ if (retval == sizeof(msgs))
+ retval = 0; /* success */
+ else if (retval >= 0)
+ retval = -EIO;
- xport->stats.tx_count++;
- xport->stats.tx_bytes += sizeof(txbuf);
- retval = i2c_master_send(client, txbuf, sizeof(txbuf));
- if (retval != sizeof(txbuf)) {
- xport->stats.tx_errs++;
- retval = (retval < 0) ? retval : -EIO;
- goto exit;
- }
+exit:
+ dev_dbg(>dev,
+ "read %zd bytes at %#06x: %d (%*ph)\n",
+ len, addr, retval, (int)len, buf);
xport->stats.rx_count++;
- xport->stats.rx_bytes += len;
-
- retval = i2c_master_recv(client, buf, len);
- if (retval < 0)
+ if (retval)
xport->stats.rx_errs++;
else
- dev_dbg(>dev,
- "read %zd bytes at %#06x: %*ph\n",
- len, addr, (int)len, buf);
+ xport->stats.rx_bytes += len;
-exit:
[PATCH 3/4] Input: synaptics-rmi4 - fix I2C functionality check
When adapter does not support required functionality (I2C_FUNC_I2C) we were
returning 0 to the upper layers, making them believe that device bound
successfully.
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_i2c.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index cdc8527..c176218 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -193,11 +193,10 @@ static int rmi_i2c_probe(struct i2c_client *client,
pdata->sensor_name ? pdata->sensor_name : "-no name-",
client->addr, pdata->attn_gpio);
- retval = i2c_check_functionality(client->adapter, I2C_FUNC_I2C);
- if (!retval) {
- dev_err(>dev, "i2c_check_functionality error %d.\n",
- retval);
- return retval;
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_err(>dev,
+ "adapter does not support required functionality.\n");
+ return -ENODEV;
}
if (pdata->gpio_config) {
--
1.8.4.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 2/4] Input: synaptics-rmi4 - rework transport device allocation
Instead of allocating common and private part of transport device
separately make private wrap common part and get rid of private data
pointer in the transport device.
Also rename rmi_i2c_data -> rmi_i2c_xport and data -> rmi_i2c.
Signed-off-by: Dmitry Torokhov
---
drivers/input/rmi4/rmi_bus.h | 3 --
drivers/input/rmi4/rmi_i2c.c | 112 +--
2 files changed, 56 insertions(+), 59 deletions(-)
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index ccf26dc..decb479 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -165,7 +165,6 @@ struct rmi_transport_stats {
* default irq_thread implementation.
* @hard_irq: if not NULL, the sensor driver will use this for the hard IRQ
* handling
- * @data: Private data pointer
* @proto_name: name of the transport protocol (SPI, i2c, etc)
* @ops: pointer to transport operations implementation
* @stats: transport statistics
@@ -181,8 +180,6 @@ struct rmi_transport_dev {
irqreturn_t (*irq_thread)(int irq, void *p);
irqreturn_t (*hard_irq)(int irq, void *p);
- void *data;
-
const char *proto_name;
const struct rmi_transport_ops *ops;
struct rmi_transport_stats stats;
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index 40badf3..cdc8527 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -17,22 +17,25 @@
#define BUFFER_SIZE_INCREMENT 32
/**
- * struct rmi_i2c_data - stores information for i2c communication
+ * struct rmi_i2c_xport - stores information for i2c communication
+ *
+ * @xport: The transport interface structure
*
* @page_mutex: Locks current page to avoid changing pages in unexpected ways.
* @page: Keeps track of the current virtual page
- * @xport: Pointer to the transport interface
*
* @tx_buf: Buffer used for transmitting data to the sensor over i2c.
* @tx_buf_size: Size of the buffer
*/
-struct rmi_i2c_data {
+struct rmi_i2c_xport {
+ struct rmi_transport_dev xport;
+ struct i2c_client *client;
+
struct mutex page_mutex;
int page;
- struct rmi_transport_dev *xport;
u8 *tx_buf;
- int tx_buf_size;
+ size_t tx_buf_size;
};
#define RMI_PAGE_SELECT_REGISTER 0xff
@@ -52,10 +55,10 @@ struct rmi_i2c_data {
*
* Returns zero on success, non-zero on failure.
*/
-static int rmi_set_page(struct rmi_transport_dev *xport, u8 page)
+static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
{
- struct i2c_client *client = to_i2c_client(xport->dev);
- struct rmi_i2c_data *data = xport->data;
+ struct rmi_transport_dev *xport = _i2c->xport;
+ struct i2c_client *client = rmi_i2c->client;
u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
int retval;
@@ -70,37 +73,40 @@ static int rmi_set_page(struct rmi_transport_dev *xport, u8
page)
"%s: set page failed: %d.", __func__, retval);
return (retval < 0) ? retval : -EIO;
}
- data->page = page;
+ rmi_i2c->page = page;
return 0;
}
static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
const void *buf, size_t len)
{
- struct i2c_client *client = to_i2c_client(xport->dev);
- struct rmi_i2c_data *data = xport->data;
+ struct rmi_i2c_xport *rmi_i2c =
+ container_of(xport, struct rmi_i2c_xport, xport);
+ struct i2c_client *client = rmi_i2c->client;
size_t tx_size = len + 1;
int retval;
- mutex_lock(>page_mutex);
-
- if (!data->tx_buf || data->tx_buf_size < tx_size) {
- if (data->tx_buf)
- devm_kfree(>dev, data->tx_buf);
- data->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
- data->tx_buf = devm_kzalloc(>dev, data->tx_buf_size,
- GFP_KERNEL);
- if (!data->tx_buf) {
- data->tx_buf_size = 0;
+ mutex_lock(_i2c->page_mutex);
+
+ if (!rmi_i2c->tx_buf || rmi_i2c->tx_buf_size < tx_size) {
+ if (rmi_i2c->tx_buf)
+ devm_kfree(>dev, rmi_i2c->tx_buf);
+ rmi_i2c->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
+ rmi_i2c->tx_buf = devm_kzalloc(>dev,
+ rmi_i2c->tx_buf_size,
+ GFP_KERNEL);
+ if (!rmi_i2c->tx_buf) {
+ rmi_i2c->tx_buf_size = 0;
retval = -ENOMEM;
goto exit;
}
}
- data->tx_buf[0] = addr & 0xff;
- memcpy(data->tx_buf + 1, buf, len);
- if (RMI_I2C_PAGE(addr) != data->page) {
- retval = rmi_set_page(xport, RMI_I2C_PAGE(addr));
+ rmi_i2c->tx_buf[0] = addr & 0xff;
+
[PATCH v3 5/7] vfio: Use new interfaces for MSI/MSI-X enablement
Signed-off-by: Alexander Gordeev
---
drivers/vfio/pci/vfio_pci_intrs.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 641bc87..4a9db1d 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -482,15 +482,19 @@ static int vfio_msi_enable(struct vfio_pci_device *vdev,
int nvec, bool msix)
for (i = 0; i < nvec; i++)
vdev->msix[i].entry = i;
- ret = pci_enable_msix(pdev, vdev->msix, nvec);
- if (ret) {
+ ret = pci_enable_msix_range(pdev, vdev->msix, 1, nvec);
+ if (ret < nvec) {
+ if (ret > 0)
+ pci_disable_msix(pdev);
kfree(vdev->msix);
kfree(vdev->ctx);
return ret;
}
} else {
- ret = pci_enable_msi_block(pdev, nvec);
- if (ret) {
+ ret = pci_enable_msi_range(pdev, 1, nvec);
+ if (ret < nvec) {
+ if (ret > 0)
+ pci_disable_msi(pdev);
kfree(vdev->ctx);
return ret;
}
--
1.7.7.6
--
Regards,
Alexander Gordeev
agord...@redhat.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 1/1] x86/iommu: use bit structures for context_entry
I have noticed the same issue too. But after second check, seems it's safe with current implementation, but obviously it's not future safe. On 2014/1/10 15:29, Li, ZhenHua wrote: > I have not seen such a bug yet . but obviously a '=' should be used when > you want to set a value. > > for example, if x != 0, > x=10 > and > x|=10 > will cause different result. > > ZhenHua > > On 01/07/2014 10:41 PM, Joerg Roedel wrote: >> On Fri, Dec 20, 2013 at 04:45:01PM +0800, Li, Zhen-Hua wrote: >>> There is a structure named context_entry used by intel iommu, and there >>> are some bit operations on it. Use bit structure may make these >>> operations >>> easy. >>> Also the function context_set_address_root may cause problem because >>> it uses >>> |= operation, not set the new value. And this patch can fix it. >> >> What is the problem you are trying to fix here? Is it an actual bug? >> >> >> Joerg >> >> > > -- > 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/ -- 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] zram: do not pass rw argument to __zram_make_request()
On Thu, Jan 09, 2014 at 04:23:43PM +0300, Sergey Senozhatsky wrote:
> Do not pass rw argument down the __zram_make_request() -> zram_bvec_rw()
> chain, decode it in zram_bvec_rw() instead. Besides, this is the place
> where we distinguish READ and WRITE bio data directions, so account zram
> RW stats here, instead of __zram_make_request(). This also allows to
> account a real number of zram READ/WRITE operations, not just requests
> (RW request may end up in a number of zram RW ops with separate
> locking, compression/decompression, slot free handling, etc).
Looks sane to me because other statistic variable accounts per bio, not
request. But it changes current statistic's semantic so they could be
regressed. Let's wait a bit for other's opinion.
Thanks.
>
> Signed-off-by: Sergey Senozhatsky
>
> ---
>
> drivers/block/zram/zram_drv.c | 29 -
> 1 file changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 833d24f..798793f 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -534,22 +534,27 @@ static void handle_pending_slot_free(struct zram *zram)
> }
>
> static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
> - int offset, struct bio *bio, int rw)
> + int offset, struct bio *bio)
> {
> int ret;
> + int rw = bio_data_dir(bio);
> +
> + if (rw == READA)
> + rw = READ;
>
> if (rw == READ) {
> + atomic64_inc(>stats.num_reads);
> down_read(>lock);
> handle_pending_slot_free(zram);
> ret = zram_bvec_read(zram, bvec, index, offset, bio);
> up_read(>lock);
> } else {
> + atomic64_inc(>stats.num_writes);
> down_write(>lock);
> handle_pending_slot_free(zram);
> ret = zram_bvec_write(zram, bvec, index, offset);
> up_write(>lock);
> }
> -
> return ret;
> }
>
> @@ -680,22 +685,13 @@ out:
> return ret;
> }
>
> -static void __zram_make_request(struct zram *zram, struct bio *bio, int rw)
> +static void __zram_make_request(struct zram *zram, struct bio *bio)
> {
> int offset;
> u32 index;
> struct bio_vec bvec;
> struct bvec_iter iter;
>
> - switch (rw) {
> - case READ:
> - atomic64_inc(>stats.num_reads);
> - break;
> - case WRITE:
> - atomic64_inc(>stats.num_writes);
> - break;
> - }
> -
> index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
> offset = (bio->bi_iter.bi_sector &
> (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
> @@ -714,16 +710,15 @@ static void __zram_make_request(struct zram *zram,
> struct bio *bio, int rw)
> bv.bv_len = max_transfer_size;
> bv.bv_offset = bvec.bv_offset;
>
> - if (zram_bvec_rw(zram, , index, offset, bio, rw) < 0)
> + if (zram_bvec_rw(zram, , index, offset, bio) < 0)
> goto out;
>
> bv.bv_len = bvec.bv_len - max_transfer_size;
> bv.bv_offset += max_transfer_size;
> - if (zram_bvec_rw(zram, , index+1, 0, bio, rw) < 0)
> + if (zram_bvec_rw(zram, , index + 1, 0, bio) < 0)
> goto out;
> } else
> - if (zram_bvec_rw(zram, , index, offset, bio, rw)
> - < 0)
> + if (zram_bvec_rw(zram, , index, offset, bio) < 0)
> goto out;
>
> update_position(, , );
> @@ -753,7 +748,7 @@ static void zram_make_request(struct request_queue
> *queue, struct bio *bio)
> goto error;
> }
>
> - __zram_make_request(zram, bio, bio_data_dir(bio));
> + __zram_make_request(zram, bio);
> up_read(>init_lock);
>
> 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/
--
Kind regards,
Minchan Kim
--
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/1] x86/iommu: use bit structures for context_entry
I have not seen such a bug yet . but obviously a '=' should be used when you want to set a value. for example, if x != 0, x=10 and x|=10 will cause different result. ZhenHua On 01/07/2014 10:41 PM, Joerg Roedel wrote: On Fri, Dec 20, 2013 at 04:45:01PM +0800, Li, Zhen-Hua wrote: There is a structure named context_entry used by intel iommu, and there are some bit operations on it. Use bit structure may make these operations easy. Also the function context_set_address_root may cause problem because it uses |= operation, not set the new value. And this patch can fix it. What is the problem you are trying to fix here? Is it an actual bug? Joerg -- 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/
[f2fs-dev] [PATCH] f2fs: remove the needless parameter of f2fs_wait_on_page_writeback
"boo sync" parameter is never referenced in f2fs_wait_on_page_writeback.
We should remove this parameter.
Signed-off-by: Yuan Zhong
---
fs/f2fs/data.c|2 +-
fs/f2fs/f2fs.h|2 +-
fs/f2fs/gc.c |4 ++--
fs/f2fs/inline.c |2 +-
fs/f2fs/inode.c |2 +-
fs/f2fs/segment.c |2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 63d1902..19ad066 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -226,7 +226,7 @@ static void __set_data_blkaddr(struct dnode_of_data *dn,
block_t new_addr)
struct page *node_page = dn->node_page;
unsigned int ofs_in_node = dn->ofs_in_node;
- f2fs_wait_on_page_writeback(node_page, NODE, false);
+ f2fs_wait_on_page_writeback(node_page, NODE);
rn = F2FS_NODE(node_page);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5f7dc4f..8466b5e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1132,7 +1132,7 @@ void rewrite_node_page(struct f2fs_sb_info *, struct page
*,
struct f2fs_summary *, block_t, block_t);
void allocate_data_block(struct f2fs_sb_info *, struct page *,
block_t, block_t *, struct f2fs_summary *, int);
-void f2fs_wait_on_page_writeback(struct page *, enum page_type, bool);
+void f2fs_wait_on_page_writeback(struct page *, enum page_type);
void write_data_summaries(struct f2fs_sb_info *, block_t);
void write_node_summaries(struct f2fs_sb_info *, block_t);
int lookup_journal_in_cursum(struct f2fs_summary_block *,
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 9117cca..ea0371e 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -428,7 +428,7 @@ next_step:
/* set page dirty and write it */
if (gc_type == FG_GC) {
- f2fs_wait_on_page_writeback(node_page, NODE, true);
+ f2fs_wait_on_page_writeback(node_page, NODE);
set_page_dirty(node_page);
} else {
if (!PageWriteback(node_page))
@@ -533,7 +533,7 @@ static void move_data_page(struct inode *inode, struct page
*page, int gc_type)
} else {
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
- f2fs_wait_on_page_writeback(page, DATA, true);
+ f2fs_wait_on_page_writeback(page, DATA);
if (clear_page_dirty_for_io(page) &&
S_ISDIR(inode->i_mode)) {
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index e0d800a..31ee5b1 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -106,7 +106,7 @@ static int __f2fs_convert_inline_data(struct inode *inode,
struct page *page)
set_page_writeback(page);
write_data_page(page, , _blk_addr, );
update_extent_cache(new_blk_addr, );
- f2fs_wait_on_page_writeback(page, DATA, true);
+ f2fs_wait_on_page_writeback(page, DATA);
/* clear inline data and flag after data writeback */
zero_user_segment(ipage, INLINE_DATA_OFFSET,
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 915f9a8..ffa4c6d 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -175,7 +175,7 @@ void update_inode(struct inode *inode, struct page
*node_page)
{
struct f2fs_inode *ri;
- f2fs_wait_on_page_writeback(node_page, NODE, false);
+ f2fs_wait_on_page_writeback(node_page, NODE);
ri = F2FS_INODE(node_page);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 5f84639..a934e6f 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1053,7 +1053,7 @@ void rewrite_node_page(struct f2fs_sb_info *sbi,
}
void f2fs_wait_on_page_writeback(struct page *page,
- enum page_type type, bool sync)
+ enum page_type type)
{
struct f2fs_sb_info *sbi = F2FS_SB(page->mapping->host->i_sb);
if (PageWriteback(page)) {
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚ:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)
Hi. On 12/10/2013 09:29 AM, Samuel Ortiz wrote: > Hi Micky, > > On Tue, Dec 10, 2013 at 09:56:48AM +0800, micky wrote: >> Hi Francis: >> On 12/10/2013 09:39 AM, wwang wrote: >>> which is based on Thomas' patch. >> >> Can you help us test this patch, we disable irq while suspend here. > I already pushed a patch from Thomas to mfd-fixes that seems to fix the > resume breakage: > > https://git.kernel.org/cgit/linux/kernel/git/sameo/mfd-fixes.git/commit/?id=19e49e445e198197c5e243f92d333d076e23d032 > I still can see any traces of this fix in Linus' tree. Shouldn't this get merged before 3.13 is out ? Thanks -- 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] PPC: KVM: fix VCPU run for HV KVM
When write to MMIO happens and there is an ioeventfd for that and is handled successfully, ioeventfd_write() returns 0 (success) and kvmppc_handle_store() returns EMULATE_DONE. Then kvmppc_emulate_mmio() converts EMULATE_DONE to RESUME_GUEST_NV and this broke from the loop. This adds handling of RESUME_GUEST_NV in kvmppc_vcpu_run_hv(). Cc: Michael S. Tsirkin Suggested-by: Paul Mackerras Signed-off-by: Alexey Kardashevskiy --- This definitely needs a better commit message. Please, help. ps. it seems like ioeventfd never worked on ppc64. hm. --- arch/powerpc/kvm/book3s_hv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 072287f..24f363f 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -1569,7 +1569,7 @@ static int kvmppc_vcpu_run_hv(struct kvm_run *run, struct kvm_vcpu *vcpu) vcpu->arch.fault_dar, vcpu->arch.fault_dsisr); srcu_read_unlock(>kvm->srcu, srcu_idx); } - } while (r == RESUME_GUEST); + } while ((r == RESUME_GUEST_NV) || (r == RESUME_GUEST)); out: vcpu->arch.state = KVMPPC_VCPU_NOTREADY; -- 1.8.4.rc4 -- 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] qlcnic: fix compiler warning
Adding netdev.
> -Original Message-
> From: Martin Kaiser,,, [mailto:mar...@reykholt.kaiser.cx] On Behalf Of
> Martin Kaiser
> Sent: Thursday, January 09, 2014 9:29 PM
> To: Himanshu Madhani; Rajesh Borundia
> Cc: linux-kernel; triv...@kernel.org
> Subject: [PATCH -next] qlcnic: fix compiler warning
>
> Add an explicit cast to fix the following warning (seen on Debian Wheezy, gcc
> 4.7.2)
>
> CC [M] drivers/net/wireless/rtlwifi/rtl8192ce/trx.o
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c: In function
> ‘qlcnic_send_filter’:
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:349:3: warning:
> passing argument 2 of ‘ether_addr_equal’ from incompatible pointer type
> [enabled by default]
> In file included from include/linux/if_vlan.h:16:0,
> from drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:9:
> include/linux/etherdevice.h:244:20: note: expected ‘const u8 *’ but
> argument is of type ‘u64 *’
>
If I am not wrong, this patch should go to David's net-next tree.
> Signed-off-by: Martin Kaiser
Acked-by: Shahed Shaikh
Thanks,
Shahed
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> index 6373f60..3557154 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> @@ -346,7 +346,7 @@ static void qlcnic_send_filter(struct qlcnic_adapter
> *adapter,
> head = &(adapter->fhash.fhead[hindex]);
>
> hlist_for_each_entry_safe(tmp_fil, n, head, fnode) {
> - if (ether_addr_equal(tmp_fil->faddr, _addr) &&
> + if (ether_addr_equal(tmp_fil->faddr, (const u8 *)_addr)
> &&
> tmp_fil->vlan_id == vlan_id) {
> if (jiffies > (QLCNIC_READD_AGE * HZ + tmp_fil-
> >ftime))
> qlcnic_change_filter(adapter, _addr,
> --
> 1.7.10.4
Re: [alsa-devel] [PATCH] ASoC: simple-card: fix one bug to writing to the platform data
Xiubo Li wrote:
> It's a bug that writing to the platform data directly, for it should
> be constant. So just copy it before writing.
>
> Signed-off-by: Xiubo Li
> ---
> sound/soc/generic/simple-card.c | 40 +---
> 1 file changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
> index 406e4ea..5b65324 100644
> --- a/sound/soc/generic/simple-card.c
> +++ b/sound/soc/generic/simple-card.c
[snip]
> @@ -204,36 +205,37 @@ static int asoc_simple_card_probe(struct
> platform_device *pdev)
> struct device_node *np = pdev->dev.of_node;
> struct device_node *of_cpu, *of_codec, *of_platform;
> struct device *dev = >dev;
> + int ret;
>
> cinfo = NULL;
> of_cpu = NULL;
> of_codec= NULL;
> of_platform = NULL;
> +
> + cinfo = devm_kzalloc(dev, sizeof(*cinfo), GFP_KERNEL);
> + if (!cinfo)
> + return -ENOMEM;
> +
> if (np && of_device_is_available(np)) {
> - cinfo = devm_kzalloc(dev, sizeof(*cinfo), GFP_KERNEL);
> - if (cinfo) {
> - int ret;
> - cinfo->snd_card.dev = >dev;
> - ret = asoc_simple_card_parse_of(np, cinfo, dev,
> - _cpu,
> - _codec,
> - _platform);
> - if (ret < 0) {
> - if (ret != -EPROBE_DEFER)
> - dev_err(dev, "parse error %d\n", ret);
> - return ret;
> - }
> - } else {
> - return -ENOMEM;
> + cinfo->snd_card.dev = dev;
> +
> + ret = asoc_simple_card_parse_of(np, cinfo, dev,
> + _cpu,
> + _codec,
> + _platform);
> + if (ret < 0) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "parse error %d\n", ret);
> + return ret;
> }
> } else {
> - cinfo = pdev->dev.platform_data;
> - if (!cinfo) {
> + if (!pdev->dev.platform_data) {
> dev_err(dev, "no info for asoc-simple-card\n");
> return -EINVAL;
> }
>
> - cinfo->snd_card.dev = >dev;
> + memcpy(cinfo, pdev->dev.platform_data, sizeof(cinfo));
> + cinfo->snd_card.dev = dev;
> }
>
> if (!cinfo->name||
If the original cinfo is not used anymore, the use of its structure to
handle the card information is not a good idea:
- almost all cinfo information are in the struct snd_soc_card,
- this cinfo structure cannot be extended to handle many DAI links,
- it contains simple-card information which are of no use for the
platform caller.
So, I'd rather have seen:
- the removal of 'snd_link' and 'snd_card' from the platform interface
(struct asoc_simple_card_info),
- the definition of a local struct simple_card_data containing the
struct snd_soc_card and a pointer to an array of fmt/sysclk values
(one per DAI link).
--
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] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
On Thursday 09 January 2014 10:03 PM, Brian Norris wrote: > On Thu, Jan 09, 2014 at 04:09:00PM +0530, Sekhar Nori wrote: >> On Thursday 26 December 2013 05:36 PM, ivan.khoronzhuk wrote: >>> On 12/18/2013 02:13 PM, Sekhar Nori wrote: On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote: > Hi, Sekhar > > This patch is based on "Reuse davinci-nand driver for Keystone arch" > series. > The series has passed review at https://lkml.org/lkml/2013/12/17/241 > and can be found at http://git.infradead.org/l2-mtd.git > > This patch can be still applied on top of the series without conflicts. > > Can you please pick up the $subject patch if you are OK with it? I have no problems with the patch and can pick it too, but need ack from MTD maintainer (David) as it touches drivers/mtd/ too. David, If you do not have the patch, we can resend it. Thanks, Sekhar >>> >>> Hi Brian, >>> >>> Do you agree if this patch will go through Davinci tree? >>> >>> This is the last one we need to reuse Davinci Nand driver for Keystone. >> >> Since we never got an ack from MTD folks, I am going and go ahead and >> try pushing this through ARM-SoC regardless. I will CC the MTD >> maintainers on the pull request so any objections could even be posted >> there. > > Sorry, I've been a little busy / out for vacation. The MTD parts look OK > to me. Feel free to take it in your tree. > > Acked-by: Brian Norris Actually the NAND portion conflicts with some of the changes from Ivan you took recently. I think it will be better if you take this patch too with my ack. For me to take it through ARM-SoC, I need an immutable branch from you - with commits same as what you will eventually be sending to Linus, based on which I can send a pull request. In any case, there is a v4 needed to fix a build and checkpatch error I just noticed. I will send it out soon. Thanks, Sekhar -- 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: kdump failed because of hotplug memory adding in kdump kernel
On 01/09/14 at 02:56pm, Toshi Kani wrote: > On Thu, 2014-01-09 at 16:27 -0500, Vivek Goyal wrote: > > On Thu, Jan 09, 2014 at 11:34:30AM -0700, Toshi Kani wrote: > > > On Thu, 2014-01-09 at 13:23 -0500, Vivek Goyal wrote: > > > > On Thu, Jan 09, 2014 at 10:24:25AM -0700, Toshi Kani wrote: > > > > > > > > [..] > > > > > > I think creating a new command line option is simpler as compared to > > > > > > creating a new flag in bootparam which in turn disables memory > > > > > > hotplug. > > > > > > More users can use that option. For example, if for some reason > > > > > > hotplug > > > > > > code is crashing, one can just disable it on command line as work > > > > > > around > > > > > > and move on. > > > > > > > > > > I do not have a strong opinion about having such option. However, I > > > > > think it is more user friendly to keep the exactmap option works alone > > > > > on any platforms. > > > > > > > > I think we should create internally a variable which will disable memory > > > > hotplug. And set that variable based on memmap=exactmap, mem=X and also > > > > provide a way to disable memory hotplug directly using command line > > > > option. > > > > > > > > Current kexec-tools can use memmap=exactmap and be happy. I am writing > > > > a new kexec syscall and will not be using memmap=exactmap and would need > > > > to use that command line option to disable memory hotplug behavior. > > > > > > Sounds good to me. > > > > Nobody responded to my other question, so I would ask it again. > > > > Assume we have disabled hotplug memory in second kernel. First kernel > > saw hotplug memory and assume crash kernel reserved region came from > > there. We will pass this memory in bootparams to second kernel and it > > will show up in E820 map. It should still be accessible in second kernel, > > is that right? > > Yes. > > > Or there is some dependency on ACPI doing some magic before this memory > > range is available in second kernel? > > No. The 1st kernel reserves the crash kernel region, which cannot be > hot-deleted. So, this region continues to be accessible by the 2nd > kernel without any operation. Now what I understand is if a several memsection is reserved for crashkernel, then in 2nd kernel, they are just like normal memory. In ns object tree, they are not treated as hotplug memory. Otherwise, any hotplug memory which is not reserved for 2nd kernel can be parsed and need be added as hotplug memory, and add them into movable zone. Am I right? The other question, e820 reserve is done earlier than acpi initialization, because acpi_early_init() invocation is very late in start_kernel(). Does that means at the very beginning all memorys are in e820, later when acpi_early_init is called, hotplug memory is detected, they will be moved to different place or need be marked with a specific flag? > > I am more curious to know how makedumpfile decides what memory ranges to > dump. The 1st kernel may have performed memory hot-add / delete > operations before a crash, so it needs to know the valid physical > address range at the time of crash, and may not rely on the E820 map > from BIOS (which is stale). Am I right to assume that makedumpfile gets > it from the page tables of the 1st kernel? makedumpfile just do the dump, what memory ranges to dump is decided in 1st kernel by kexec-tools. In 1st kernel, if kexec-tools executed, it will find all System Ram memorys which exclude the reserved regions for kdump kernel, then build a logical elf file, each load segment is one of these System Ram memory regions, its addr and length is written into the program header. Then makedumpfile just read this elf file, and read all of them and dump. If after kexec-tools execution and before crash, a hotplug memory is removed, udev will check this and trigger a kdump restart, kexec-tools is executed again, System Ram region information are stored. The logical file header will be passed to 2nd kernel. > > Thanks, > -Toshi > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- 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: hfsplus: kernel panic in hfsplus_brec_lenoff
On Thu, 2014-01-09 at 18:12 -0500, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next > kernel > I've stumbled on the following spew: > > [ 5835.181300] BUG: unable to handle kernel paging request at 880055a3cffa Thank you for report about the issue. But could you share a reproducing path? Or, maybe, is it possible to repeat your steps? It will be great to have reproducing path. Thanks, Vyacheslav Dubeyko. -- 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] zram: drop `init_done' zram member
Hello Sergey,
On Thu, Jan 09, 2014 at 03:57:46PM +0300, Sergey Senozhatsky wrote:
> Introduce init_done() helper function which allows us to drop
> `init_done' struct zram member. init_done() uses the fact that
> ->init_done == 1 equals to ->meta != NULL.
>
> Signed-off-by: Sergey Senozhatsky
It would be good without any harm but I'm just considering to
change the lock with rcu with atomic variable.
Please give me a time and feedback to you in next week.
Thanks.
>
> ---
>
> drivers/block/zram/zram_drv.c | 21 +++--
> drivers/block/zram/zram_drv.h | 12 +---
> 2 files changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 108f273..833d24f 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -42,6 +42,11 @@ static struct zram *zram_devices;
> /* Module params (documentation at end) */
> static unsigned int num_devices = 1;
>
> +static inline int init_done(struct zram *zram)
> +{
> + return zram->meta != NULL;
> +}
> +
> static inline struct zram *dev_to_zram(struct device *dev)
> {
> return (struct zram *)dev_to_disk(dev)->private_data;
> @@ -60,7 +65,7 @@ static ssize_t initstate_show(struct device *dev,
> {
> struct zram *zram = dev_to_zram(dev);
>
> - return sprintf(buf, "%u\n", zram->init_done);
> + return sprintf(buf, "%u\n", init_done(zram));
> }
>
> static ssize_t num_reads_show(struct device *dev,
> @@ -133,7 +138,7 @@ static ssize_t mem_used_total_show(struct device *dev,
> struct zram_meta *meta = zram->meta;
>
> down_read(>init_lock);
> - if (zram->init_done)
> + if (init_done(zram))
> val = zs_get_total_size_bytes(meta->mem_pool);
> up_read(>init_lock);
>
> @@ -556,14 +561,12 @@ static void zram_reset_device(struct zram *zram, bool
> reset_capacity)
> flush_work(>free_work);
>
> down_write(>init_lock);
> - if (!zram->init_done) {
> + if (!init_done(zram)) {
> up_write(>init_lock);
> return;
> }
>
> meta = zram->meta;
> - zram->init_done = 0;
> -
> /* Free all pages that are still in this zram device */
> for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
> unsigned long handle = meta->table[index].handle;
> @@ -604,8 +607,6 @@ static void zram_init_device(struct zram *zram, struct
> zram_meta *meta)
> queue_flag_set_unlocked(QUEUE_FLAG_NONROT, zram->disk->queue);
>
> zram->meta = meta;
> - zram->init_done = 1;
> -
> pr_debug("Initialization done!\n");
> }
>
> @@ -623,7 +624,7 @@ static ssize_t disksize_store(struct device *dev,
> disksize = PAGE_ALIGN(disksize);
> meta = zram_meta_alloc(disksize);
> down_write(>init_lock);
> - if (zram->init_done) {
> + if (init_done(zram)) {
> up_write(>init_lock);
> zram_meta_free(meta);
> pr_info("Cannot change disksize for initialized device\n");
> @@ -744,7 +745,7 @@ static void zram_make_request(struct request_queue
> *queue, struct bio *bio)
> struct zram *zram = queue->queuedata;
>
> down_read(>init_lock);
> - if (unlikely(!zram->init_done))
> + if (unlikely(!init_done(zram)))
> goto error;
>
> if (!valid_io_request(zram, bio)) {
> @@ -893,7 +894,7 @@ static int create_device(struct zram *zram, int device_id)
> goto out_free_disk;
> }
>
> - zram->init_done = 0;
> + zram->meta = NULL;
> return 0;
>
> out_free_disk:
> diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> index d8f6596..1388bad 100644
> --- a/drivers/block/zram/zram_drv.h
> +++ b/drivers/block/zram/zram_drv.h
> @@ -99,26 +99,24 @@ struct zram_slot_free {
> };
>
> struct zram {
> + /* Prevent concurrent execution of device init, reset and R/W request */
> + struct rw_semaphore init_lock;
> struct zram_meta *meta;
> +
> struct rw_semaphore lock; /* protect compression buffers, table,
> * 32bit stat counters against concurrent
> * notifications, reads and writes */
> -
> - struct work_struct free_work; /* handle pending free request */
> struct zram_slot_free *slot_free_rq; /* list head of free request */
> + spinlock_t slot_free_lock;
> + struct work_struct free_work; /* handle pending free request */
>
> struct request_queue *queue;
> struct gendisk *disk;
> - int init_done;
> - /* Prevent concurrent execution of device init, reset and R/W request */
> - struct rw_semaphore init_lock;
> /*
>* This is the limit on amount of *uncompressed* worth of data
>* we can store in a disk.
>*/
> u64 disksize; /* bytes */
> - spinlock_t slot_free_lock;
> -
> struct zram_stats stats;
> };
>
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On 01/10/2014 05:39 AM, Stephen Hemminger wrote: > On Thu, 09 Jan 2014 16:55:07 +0800 > Jason Wang wrote: > >> What if use do want a qdisc and want to change the its queue length for >> tun/macvlan? And the the name tx_queue_length is misleading. For tun it >> may make sense since it was used in transmission path. For macvtap it >> was not. So maybe what we need is just a new ioctl for both tun/macvtap >> and a new feature flag. If user create the device with new feature flag, >> the socket receive queue length could be changed by ioctl instead of >> dev->tx_queue_length. If not, the old behaviour could be kept. > The overloading of tx_queue_len in macvtap was the original design mistake. > Can't this just be undone and expose rx_queue_len as sysfs attribute? That works. But we current allow user to change the socket sndbuf through TUNSNDBUF. Maybe we need a similar one for receive. -- 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 00/16] net: stmmac: Add Allwinner A20 GMAC ethernet controller glue layer
Hi, This is v2 of the Allwinner A20 GMAC glue layer for stmmac. The clock and DT patches should be applied after my clock rename[1] series. [1] ARM: sunxi: rename DT clock node names to clk@N The Allwinner A20 SoC integrates an early version of dwmac IP from Synopsys. On top of that is a hardware glue layer. This layer needs to be configured before the dwmac can be used. Part of the glue layer is a clock mux, which controls the source and direction of the TX clock used by GMAC. The clock module driver is added in patch #9. The remaining glue layer code is in patch #10. The glue layer is implemented with existing feature flags and callbacks found in stmmac driver core. A new stmmac_of_data structure, which is a subset of the original platform data, has been added to tie these values with compatible strings. The purpose of this is to avoid future glue layers assuming they can pass other data or directly modify values used by the driver core. This is found in patch #7. The callbacks have also been extended to pass board specific data. This is found in patch #4. This version of dwmac IP requires store and forward DMA mode. The relevant device tree property was documented, but not implemented. Patch #6 adds this to stmmac platform driver. Changes since v1: * Added optional reset control to stmmac driver core * Added non CONFIG_RESET_CONROLLER routines for the above change * Extended callback API, as discussed with Srinivas * Used new stmmac_of_data to pass features and callbacks, instead of platform data, as discussed * Seperated clock module glue layer into clock driver Comments? Thanks, ChenYu Chen-Yu Tsai (16): reset: add non CONFIG_RESET_CONTROLLER routines net: stmmac: Enable stmmac main clock when probing hardware net: stmmac: Add support for optional reset control net: stmmac: Allocate and pass soc/board specific data to callbacks blackfin: Update stmmac callback signatures net: stmmac: Honor DT parameter to force DMA store and forward mode net: stmmac: Use driver data and callbacks tied with compatible strings net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's clk: sunxi: Add Allwinner A20/A31 GMAC clock unit ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI ARM: dts: sun7i: Add pin muxing options for the GMAC ARM: dts: sun7i: cubietruck: Enable the GMAC ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC ARM: dts: sun7i: olinuxino-micro: Enable GMAC instead of EMAC ARM: dts: sun7i: Add ethernet alias for GMAC Documentation/devicetree/bindings/clock/sunxi.txt | 26 .../bindings/net/allwinner,sun7i-a20-gmac.txt | 27 + Documentation/devicetree/bindings/net/stmmac.txt | 3 + Documentation/networking/stmmac.txt| 12 +- arch/arm/boot/dts/sun7i-a20-cubieboard2.dts| 27 ++--- arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 ++ arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts| 27 ++--- arch/arm/boot/dts/sun7i-a20.dtsi | 71 ++- arch/blackfin/mach-bf609/boards/ezkit.c| 2 +- drivers/clk/sunxi/clk-sunxi.c | 74 drivers/net/ethernet/stmicro/stmmac/Kconfig| 12 ++ drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 133 + drivers/net/ethernet/stmicro/stmmac/stmmac.h | 5 + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 45 --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 73 --- include/linux/reset.h | 39 ++ include/linux/stmmac.h | 24 +++- 19 files changed, 547 insertions(+), 70 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c -- 1.8.5.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 v2 05/16] blackfin: Update stmmac callback signatures
stmmac callbacks have been extended for better seperation.
Update them to avoid breakage.
Signed-off-by: Chen-Yu Tsai
---
arch/blackfin/mach-bf609/boards/ezkit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/blackfin/mach-bf609/boards/ezkit.c
b/arch/blackfin/mach-bf609/boards/ezkit.c
index 82beedd..05194e9 100644
--- a/arch/blackfin/mach-bf609/boards/ezkit.c
+++ b/arch/blackfin/mach-bf609/boards/ezkit.c
@@ -117,7 +117,7 @@ static struct stmmac_dma_cfg eth_dma_cfg = {
.pbl= 2,
};
-int stmmac_ptp_clk_init(struct platform_device *pdev)
+int stmmac_ptp_clk_init(struct platform_device *pdev, void *priv)
{
bfin_write32(PADS0_EMAC_PTP_CLKSEL, 0);
return 0;
--
1.8.5.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 v2 08/16] net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's
The Allwinner A20 has an ethernet controller that seems to be
an early version of Synopsys DesignWare MAC 10/100/1000 Universal,
which is supported by the stmmac driver.
Allwinner's GMAC requires setting additional registers in the SoC's
clock control unit.
The exact version of the DWMAC IP that Allwinner uses is unknown,
thus the exact feature set is unknown.
Signed-off-by: Chen-Yu Tsai
---
.../bindings/net/allwinner,sun7i-a20-gmac.txt | 27 +
drivers/net/ethernet/stmicro/stmmac/Kconfig| 12 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 133 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
6 files changed, 179 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
new file mode 100644
index 000..ea4d752
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
@@ -0,0 +1,27 @@
+* Allwinner GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+ - compatible: Should be "allwinner,sun7i-a20-gmac"
+ - clocks: Should contain the GMAC main clock, and tx clock
+ The tx clock type should be "allwinner,sun7i-a20-gmac-clk"
+ - clock-names: Should contain the clock names "stmmaceth",
+ and "allwinner_gmac_tx"
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Examples:
+
+ gmac: ethernet@01c5 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c5 0x1>,
+ <0x01c20164 0x4>;
+ interrupts = <0 85 1>;
+ interrupt-names = "macirq";
+ clocks = <_gates 49>, <_tx>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ phy-mode = "mii";
+ };
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 6e52c0f..e076411 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -25,6 +25,18 @@ config STMMAC_PLATFORM
If unsure, say N.
+config DWMAC_SUNXI
+ bool "Allwinner GMAC support"
+ depends on STMMAC_PLATFORM
+ depends on ARCH_SUNXI
+ default y
+ ---help---
+ Support for Allwinner A20/A31 GMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for A20/A31
+ GMACethernet controller.
+
config STMMAC_PCI
bool "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 356a9dd..ecadece 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
+stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
new file mode 100644
index 000..ea62bd1
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -0,0 +1,133 @@
+/**
+ * dwmac-sunxi.c - Allwinner sunxi DWMAC specific glue layer
+ *
+ * Copyright (C) 2013 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+
+struct sunxi_priv_data {
+ int interface;
+ int clk_enabled;
+ struct clk *tx_clk;
+ struct regulator *regulator;
+};
+
+static void *sun7i_gmac_setup(struct platform_device *pdev)
+{
+ struct sunxi_priv_data *gmac;
+ struct device *dev = >dev;
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if
[PATCH v2 03/16] net: stmmac: Add support for optional reset control
The DWMAC has a reset assert line, which is used on some SoCs. Add an
optional reset control to stmmac driver core.
To support reset control deferred probing, this patch changes the driver
probe function to return the actual error, instead of just -EINVAL.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/net/stmmac.txt | 3 +++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 ++--
5 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e..d132513 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -30,6 +30,9 @@ Required properties:
Optional properties:
- mac-address: 6 bytes, mac address
+- resets: Should contain a phandle to the STMMAC reset signal, if any
+- reset-names: Should contain the reset signal name "stmmaceth", if a
+ reset phandle is given
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 22f89ff..f19a040 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -32,6 +32,7 @@
#include
#include "common.h"
#include
+#include
struct stmmac_priv {
/* Frequently used values are kept adjacent for cache effect */
@@ -91,6 +92,7 @@ struct stmmac_priv {
int wolopts;
int wol_irq;
struct clk *stmmac_clk;
+ struct reset_control *stmmac_rst;
int clk_csr;
struct timer_list eee_ctrl_timer;
int lpi_irq;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 786b51c..af2a313 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -50,6 +50,7 @@
#include
#include "stmmac_ptp.h"
#include "stmmac.h"
+#include
#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x)
#define JUMBO_LEN 9000
@@ -2683,10 +2684,24 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
if (IS_ERR(priv->stmmac_clk)) {
dev_warn(priv->device, "%s: warning: cannot get CSR clock\n",
__func__);
+ ret = PTR_ERR(priv->stmmac_clk);
goto error_clk_get;
}
clk_prepare_enable(priv->stmmac_clk);
+ priv->stmmac_rst = devm_reset_control_get(priv->device,
+ STMMAC_RESOURCE_NAME);
+ if (IS_ERR(priv->stmmac_rst)) {
+ if (PTR_ERR(priv->stmmac_rst) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto error_hw_init;
+ }
+ dev_info(priv->device, "no reset control found\n");
+ priv->stmmac_rst = NULL;
+ }
+ if (priv->stmmac_rst)
+ reset_control_deassert(priv->stmmac_rst);
+
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
@@ -2763,7 +2778,7 @@ error_hw_init:
error_clk_get:
free_netdev(ndev);
- return NULL;
+ return ERR_PTR(ret);
}
/**
@@ -2787,6 +2802,8 @@ int stmmac_dvr_remove(struct net_device *ndev)
stmmac_mdio_unregister(ndev);
netif_carrier_off(ndev);
unregister_netdev(ndev);
+ if (priv->stmmac_rst)
+ reset_control_assert(priv->stmmac_rst);
clk_disable_unprepare(priv->stmmac_clk);
free_netdev(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 644d80e..f3f6218 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -100,9 +100,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
stmmac_default_data();
priv = stmmac_dvr_probe(&(pdev->dev), _dat, addr);
- if (!priv) {
+ if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
- ret = -ENODEV;
+ ret = PTR_ERR(priv);
goto err_out;
}
priv->dev->irq = pdev->irq;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 51c9069..3974586 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -148,9 +148,9 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
}
priv = stmmac_dvr_probe(&(pdev->dev), plat_dat, addr);
- if (!priv) {
+ if (IS_ERR(priv)) {
[PATCH v2 06/16] net: stmmac: Honor DT parameter to force DMA store and forward mode
"snps,force_sf_dma_mode" is documented in stmmac device tree bindings, but is never handled by the driver. Signed-off-by: Chen-Yu Tsai --- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 86ee903..92627e0 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -52,6 +52,8 @@ static int stmmac_probe_config_dt(struct platform_device *pdev, sizeof(struct stmmac_mdio_bus_data), GFP_KERNEL); + plat->force_sf_dma_mode = of_property_read_bool(np, "snps,force_sf_dma_mode"); + /* * Currently only the properties needed on SPEAr600 * are provided. All other properties should be added -- 1.8.5.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 v2 01/16] reset: add non CONFIG_RESET_CONTROLLER routines
Some drivers are shared between platforms that may or may not
have RESET_CONTROLLER selected for them. Add dummy functions
when RESET_CONTROLLER is not selected, thereby eliminating the
need for drivers to enclose reset_control_*() calls within
#ifdef CONFIG_RESET_CONTROLLER, #endif
Signed-off-by: Chen-Yu Tsai
---
include/linux/reset.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 6082247..38aa616 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -4,6 +4,8 @@
struct device;
struct reset_control;
+#ifdef CONFIG_RESET_CONTROLLER
+
int reset_control_reset(struct reset_control *rstc);
int reset_control_assert(struct reset_control *rstc);
int reset_control_deassert(struct reset_control *rstc);
@@ -14,4 +16,41 @@ struct reset_control *devm_reset_control_get(struct device
*dev, const char *id)
int device_reset(struct device *dev);
+#else /* !CONFIG_RESET_CONTROLLER */
+
+static inline int reset_control_reset(struct reset_control *rstc)
+{
+ return 0;
+}
+
+static inline int reset_control_assert(struct reset_control *rstc)
+{
+ return 0;
+}
+
+static inline int reset_control_deassert(struct reset_control *rstc)
+{
+ return 0;
+}
+
+static inline struct reset_control *reset_control_get(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
+static inline void reset_control_put(struct reset_control *rstc) {}
+
+static inline struct reset_control *devm_reset_control_get(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
+
+static inline int device_reset(struct device *dev)
+{
+ return 0;
+}
+
+#endif
+
#endif
--
1.8.5.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 v2 07/16] net: stmmac: Use driver data and callbacks tied with compatible strings
The stmmac driver core allows passing feature flags and callbacks via
platform data. Add a similar stmmac_of_data to pass flags and callbacks
tied to compatible strings. This allows us to extend stmmac with glue
layers for different SoCs.
Also deprecate device tree "snps,phy-addr" property, and default to PHY
address auto-detection.
Signed-off-by: Chen-Yu Tsai
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 46 +-
include/linux/stmmac.h | 18 +
2 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 92627e0..2e554e3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -26,8 +26,20 @@
#include
#include
#include
+#include
#include "stmmac.h"
+static const struct of_device_id stmmac_dt_ids[] = {
+ /* SoC specific glue layers should come before generic bindings */
+ { .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.610"},
+ { .compatible = "snps,dwmac-3.70a"},
+ { .compatible = "snps,dwmac-3.710"},
+ { .compatible = "snps,dwmac"},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
+
#ifdef CONFIG_OF
static int stmmac_probe_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat,
@@ -35,10 +47,32 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
{
struct device_node *np = pdev->dev.of_node;
struct stmmac_dma_cfg *dma_cfg;
+ const struct of_device_id *device;
if (!np)
return -ENODEV;
+ device = of_match_device(stmmac_dt_ids, >dev);
+ if (!device)
+ return -ENODEV;
+
+ if (device->data) {
+ const struct stmmac_of_data *data = device->data;
+ plat->has_gmac = data->has_gmac;
+ plat->enh_desc = data->enh_desc;
+ plat->tx_coe = data->tx_coe;
+ plat->rx_coe = data->rx_coe;
+ plat->bugged_jumbo = data->bugged_jumbo;
+ plat->pmt = data->pmt;
+ plat->riwt_off = data->riwt_off;
+ plat->fix_mac_speed = data->fix_mac_speed;
+ plat->bus_setup = data->bus_setup;
+ plat->setup = data->setup;
+ plat->free = data->free;
+ plat->init = data->init;
+ plat->exit = data->exit;
+ }
+
*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
@@ -46,6 +80,8 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
if (plat->bus_id < 0)
plat->bus_id = 0;
+ /* Default to phy auto-detection */
+ plat->phy_addr = -1;
of_property_read_u32(np, "snps,phy-addr", >phy_addr);
plat->mdio_bus_data = devm_kzalloc(>dev,
@@ -268,16 +304,6 @@ static const struct dev_pm_ops stmmac_pltfr_pm_ops = {
static const struct dev_pm_ops stmmac_pltfr_pm_ops;
#endif /* CONFIG_PM */
-static const struct of_device_id stmmac_dt_ids[] = {
- { .compatible = "st,spear600-gmac"},
- { .compatible = "snps,dwmac-3.610"},
- { .compatible = "snps,dwmac-3.70a"},
- { .compatible = "snps,dwmac-3.710"},
- { .compatible = "snps,dwmac"},
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
-
struct platform_driver stmmac_pltfr_driver = {
.probe = stmmac_pltfr_probe,
.remove = stmmac_pltfr_remove,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index c407791..10a9e2a 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -120,4 +120,22 @@ struct plat_stmmacenet_data {
void *custom_data;
void *bsp_priv;
};
+
+/* of_data for SoC glue layer device tree bindings */
+
+struct stmmac_of_data {
+ int has_gmac;
+ int enh_desc;
+ int tx_coe;
+ int rx_coe;
+ int bugged_jumbo;
+ int pmt;
+ int riwt_off;
+ void (*fix_mac_speed)(void *priv, unsigned int speed);
+ void (*bus_setup)(void __iomem *ioaddr);
+ void *(*setup)(struct platform_device *pdev);
+ void (*free)(struct platform_device *pdev, void *priv);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
+};
#endif
--
1.8.5.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 v4 02/15] clk: Allow drivers to pass in a regmap
On 01/09, Mike Turquette wrote:
> If we're going to use these wrappers, why make it regmap specific? The
> struct clk_desc patches[1][2] can achieve this, but in a more generic
> way.
>
I think you're suggesting a way to avoid adding a
clk_register_regmap() function? But won't we need to write the
same code:
if (dev && dev_get_regmap(dev, NULL))
[clk_type]->regmap = dev_get_regmap(dev, NULL);
else if (dev && dev->parent)
[clk_type]->regmap = dev_get_regmap(dev->parent, NULL);
everytime we want to assign the regmap pointer to a different clock type?
A macro might work for this little snippet, but it wouldn't have
any type safety.
> >
> >
> > 2) Interfaces: Add a void *data in struct clk_hw that can point to
> > whatever I want and still have the same clk_regmap_register() and
> > devm_clk_regmap_register()
> >
> > Example:
> >
> > struct clk_hw {
> > struct clk *clk;
> > const struct clk_init_data *init;
> > void *data;
> > };
> >
> > struct clk_regmap {
> > struct regmap *regmap;
> > unsigned int enable_reg;
> > unsigned int enable_mask;
> > bool enable_is_inverted;
> > };
> >
> > struct clk_branch {
> > u32 hwcg_reg;
> > u32 halt_reg;
> > u8 hwcg_bit;
> > u8 halt_bit;
> > u8 halt_check;
> >
> > struct clk_hw;
> > };
> >
> > static struct clk_branch gsbi1_uart_clk = {
> > .halt_reg = 0x2fcc,
> > .halt_bit = 10,
> > .hw = {
> > .data = &(struct clk_regmap){
> > .enable_reg = 0x29d4,
> > .enable_mask = BIT(9),
> > };
> > .init = &(struct clk_init_data){
> > .name = "gsbi1_uart_clk",
> > .parent_names = (const char *[]){
> > "gsbi1_uart_src",
> > },
> > .num_parents = 1,
> > .ops = _branch_ops,
> > .flags = CLK_SET_RATE_PARENT,
> > },
> > },
> > };
> >
> > I guess option 2 is less likely given your comment about clk_hw being
> > nothing more than a traversal mechanism.
>
> Instead of private data, how about a .register() callback function that
> can point to anything you like? The clk_desc patches implement this and
> it would suffice for registering regmap ops or anything else, without
> polluting struct clk_hw.
>
> [1] http://www.spinics.net/lists/linux-omap/msg101822.html
> [2] http://www.spinics.net/lists/linux-omap/msg101698.html
>
> So you could statically define gsbi1_uart_clk with:
>
> static struct clk_branch_desc gsbi1_uart_clk_desc = {
> .halt_reg = 0x2fcc,
> .halt_bit = 10,
> .enable_reg = 0x29d4,
> .enable_mask = BIT(9),
> .desc = {
> .name = "gsbi1_uart_clk",
> .parent_names = (const char *[]){
> "gsbi1_uart_src",
> },
> .num_parents = 1,
> .ops = _branch_ops,
> .flags = CLK_SET_RATE_PARENT,
> },
> };
>
> And then register it with:
>
> clk_register_desc(NULL, _uart_clk_desc.desc);
>
> This is very analogous to the way that you use use _uart_clk.hw
> but it is more generic and also doesn't pollute clk_hw any further. I
> also think your static data is quite a bit prettier using this method.
>
> Thoughts?
Is the plan to allocate a struct clk_branch at runtime and then
copy all the fields over one by one? I'm trying to avoid that
because it takes more time and more runtime memory. If I had to
go the descriptor route I would probably avoid copying any fields
and just point to the descriptor from struct clk_branch, i.e.
struct clk_branch {
struct clk_branch_desc *desc;
struct clk_hw;
};
but that still seems wasteful to allocate a bunch of little
pointer wrappers when I could have just embedded the clk_hw
struct inside the clk_branch struct from the start.
It feels another key point is being missed though. The regmap
pointer and the enable_reg/enable_mask is embedded in clk_hw to
allow the same code to be used by different types of surrounding
structs. Each struct: clk_pll, clk_rcg, and clk_branch in this
series use the regmap interface to enable/disable the clock and
they can easily do so by passing something that's always
available from struct clk_hw (be it via a wrapper struct, private
data member, or addition of new fields to clk_hw). If the regmap
members move into each specific type of clock we can't just pass
a single pointer to the enable/disable regmap functions anymore.
This is the reason why I suggested a driver data pointer or
container struct so that everything regmap related is contained
within one type.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To
[PATCH v2 16/16] ARM: dts: sun7i: Add ethernet alias for GMAC
U-Boot will insert MAC address into the device tree image.
It looks up ethernet[0-5] aliases to find the ethernet nodes.
Alias GMAC as ethernet0, as it is the only ethernet controller used.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index b18f18f..897dbfc 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -17,7 +17,7 @@
interrupt-parent = <>;
aliases {
- ethernet0 =
+ ethernet0 =
};
cpus {
--
1.8.5.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 v2 14/16] ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..7bf4935 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -19,21 +19,6 @@
compatible = "cubietech,cubieboard2", "allwinner,sun7i-a20";
soc@01c0 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins_a>;
- phy = <>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_cubieboard2: led_pins@0 {
allwinner,pins = "PH20", "PH21";
@@ -60,6 +45,18 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_mii_a>;
+ phy = <>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.8.5.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 v2 13/16] ARM: dts: sun7i: cubietruck: Enable the GMAC
The CubieTruck uses the GMAC with an RGMII phy.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index f9dcb61..025ce52 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -51,6 +51,18 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_rgmii_a>;
+ phy = <>;
+ phy-mode = "rgmii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.8.5.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 net V2 2/2] net: core: explicitly select a txq before doing l2 forwarding
On 01/09/2014 08:31 PM, Neil Horman wrote:
> On Thu, Jan 09, 2014 at 05:37:32PM +0800, Jason Wang wrote:
>> Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit().
>> The
>> will cause several issues:
>>
>> - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
>> instead of lower device which misses the necessary txq synchronization for
>> lower device such as txq stopping or frozen required by dev watchdog or
>> control path.
>> - dev_hard_start_xmit() was called with NULL txq which bypasses the net
>> device
>> watchdog.
>> - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
>> when tso is disabled for lower device.
>>
>> Fix this by explicitly introducing a new param for .ndo_select_queue() for
>> just
>> selecting queues in the case of l2 forwarding offload. And also introducing
>> dfwd_direct_xmit() to do the queue selecting, txq holding and transmitting
>> for
>> l2 forwarding.
>>
>> With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no
>> need
>> to check txq against NULL in dev_hard_start_xmit(). Also there's no need to
>> keep
>> a dedicated ndo_dfwd_start_xmit().
>>
>> In the future, it was also required for macvtap l2 forwarding support since
>> it
>> provides a necessary synchronization method.
>>
>> Cc: John Fastabend
>> Cc: Neil Horman
>> Cc: e1000-de...@lists.sourceforge.net
>> Signed-off-by: Jason Wang
>>
>> ---
>> Changes from V1:
>> - Adding a new parameter to ndo_select_queue instead of a new method to
>> select
>> queue for l2 forwarding.
>> - Remove the unnecessary ndo_dfwd_start_xmit() since txq was selected
>> explicitly.
>> - Keep NETIF_F_LLTX when netdev feature is changed.
>> - Shape the commit log
> A few minor nits inline.
>>
>> }
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index 5360f73..7eb4c82 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -299,7 +299,7 @@ netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
>>
>> if (vlan->fwd_priv) {
>> skb->dev = vlan->lowerdev;
>> -ret = dev_hard_start_xmit(skb, skb->dev, NULL, vlan->fwd_priv);
>> +ret = dfwd_direct_xmit(skb, skb->dev, vlan->fwd_priv);
>> } else {
>> ret = macvlan_queue_xmit(skb, dev);
>> }
>> @@ -366,7 +366,6 @@ static int macvlan_open(struct net_device *dev)
>> if (IS_ERR_OR_NULL(vlan->fwd_priv)) {
>> vlan->fwd_priv = NULL;
>> } else {
>> -dev->features &= ~NETIF_F_LLTX;
>> return 0;
>> }
> After removing the features flag operation here, you don't need the braces
> around the else statement either.
Ok.
>>
>> +int dfwd_direct_xmit(struct sk_buff *skb, struct net_device *dev,
>> + void *accel_priv)
>> +{
>> +struct netdev_queue *txq;
>> +int ret = NETDEV_TX_BUSY;
>> +int index;
>> +
>> +BUG_ON(!dev->netdev_ops->ndo_select_queue);
>> +index = dev->netdev_ops->ndo_select_queue(dev, skb, accel_priv);
>> +
>> +local_bh_disable();
>> +
>> +skb_set_queue_mapping(skb, index);
>> +txq = netdev_get_tx_queue(dev, index);
>> +
>> +HARD_TX_LOCK(dev, txq, smp_processor_id());
>> +if (!netif_xmit_frozen_or_stopped(txq))
>> +ret = dev_hard_start_xmit(skb, dev, txq);
>> +HARD_TX_UNLOCK(dev, txq);
>> +
>> +local_bh_enable();
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(dfwd_direct_xmit);
>> +
> Now that we're using the common path to select a queue, can we just use
> dev_queue_xmit here instead of creating our own transmit function? The txq we
> select from the ixgbe card will just have a pfifo_fast queue on it (if not a
> noop queue), so dev_queue_xmit should just fall into the dev_hard_start_xmit
> path, and save us this extra coding.
>
> Neil
Ture, and this will make no difference with the case without l2
forwarding. To not trouble other parts too much, I will keep the current
dev_queue_xmit() API and rename the current dev_queue_xmit() to
__dev_queue_xmit() can make it can accept a accel_priv parameter. So
dev_queue_xmit() will call this will NULL accel_priv and introduce a
dev_queue_xmit_accel() that can accept a accel_priv parameter.
Thanks
>
> --
> 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/
--
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/2] Exynos5250 SATA Support
This patch series enable the SATA support on Exynos5250 based boards. It incorporates the generic phy framework to deal with sata phy. This patch depends on the below patches [1]. drivers: phy: add generic PHY framework by Kishon Vijay Abraham I [2]. ata: ahci_platform: Manage SATA PHY by Roger Quadros [3].ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files by Leela Krishna Amudala [4]. i2c: s3c2410 : Add polling mode support by Vasanth Ananthan Changes from V5: 1.Rebased on latest generic PHY framework for-next tree. 2.Minor nits such as indentations. Changes from V4: 1.Made Exynos5250 SATA PHY driver by default selects CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver depends on I2C. 2.Used the new phandle "sata_phy_i2c" in the DT entry. 3.struct i2c_driver sataphy_i2c_driver made static which was earlier global type. Changes from V3: 1.Moved the devicetree binding documentation from /bindings/ata/ to bindings/phy/ . 2.Moved devm_phy_create call before to the devm_phy_provider_register. Changes from V2: 1.Removed of_match_table 2.Moved to syscon interface for PMU handling. Changes from V1: 1. Dropped the patch ahci: exynos: add ahci sata support on Exynos platform 2.Adapt to latest generic PHY framework available in git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git next Yuvaraj Kumar C D (2): PHY: Exynos: Add Exynos5250 SATA PHY driver ARM: dts: Enable ahci sata and sata phy .../devicetree/bindings/ata/exynos-sata-phy.txt| 14 -- .../devicetree/bindings/ata/exynos-sata.txt| 25 +- .../devicetree/bindings/phy/samsung-phy.txt| 36 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 11 + arch/arm/boot/dts/exynos5250-smdk5250.dts |8 +- arch/arm/boot/dts/exynos5250.dtsi | 17 +- drivers/phy/Kconfig| 13 ++ drivers/phy/Makefile |1 + drivers/phy/phy-exynos5250-sata-i2c.c | 40 drivers/phy/phy-exynos5250-sata.c | 238 10 files changed, 370 insertions(+), 33 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt create mode 100644 drivers/phy/phy-exynos5250-sata-i2c.c create mode 100644 drivers/phy/phy-exynos5250-sata.c -- 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 v2 10/16] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
The GMAC uses 1 of 2 sources for its transmit clock, depending on the
PHY interface mode. Add both sources as dummy clocks, and as parents
to the GMAC clock node.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 2a78de4..4019c55 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -308,6 +308,34 @@
};
/*
+* The following two are dummy clocks, placeholders used
+* on gmac_tx clock. The actual frequency and availability
+* depends on the external PHY, operation mode and link
+* speed.
+*/
+ mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ clock-output-names = "mii_phy_tx";
+ };
+
+ gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_int_tx";
+ };
+
+ gmac_tx_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ clocks = <_phy_tx_clk>, <_int_tx_clk>;
+ clock-output-names = "gmac_tx";
+ };
+
+ /*
* Dummy clock used by output clocks
*/
osc24M_32k: clk@1 {
--
1.8.5.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 03/14] target/sbc: Add sbc_check_prot + update sbc_parse_cdb for DIF
On Thu, 2014-01-09 at 16:58 +0200, Sagi Grimberg wrote:
> On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds sbc_check_prot() for performing various DIF
> > related CDB sanity checks, along with setting SCF_PROT once
> > sanity checks have passed.
> >
> > Also, add calls in sbc_parse_cdb() for READ_[10,12,16] +
> > WRITE_[10,12,16] to perform DIF sanity checking.
> >
> > Cc: Martin K. Petersen
> > Cc: Christoph Hellwig
> > Cc: Hannes Reinecke
> > Cc: Sagi Grimberg
> > Cc: Or Gerlitz
> > Signed-off-by: Nicholas Bellinger
> > ---
> > drivers/target/target_core_sbc.c | 39
> > ++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/target/target_core_sbc.c
> > b/drivers/target/target_core_sbc.c
> > index 52ae54e..600ffcb 100644
> > --- a/drivers/target/target_core_sbc.c
> > +++ b/drivers/target/target_core_sbc.c
> > @@ -563,6 +563,27 @@ sbc_compare_and_write(struct se_cmd *cmd)
> > return TCM_NO_SENSE;
> > }
> >
> > +bool
> > +sbc_check_prot(struct se_device *dev, struct se_cmd *cmd, unsigned char
> > *cdb)
> > +{
> > + if (!dev->dev_attrib.pi_prot_type)
> > + return true;
> > +
> > + if (dev->dev_attrib.pi_prot_type == TARGET_DIF_TYPE2_PROT &&
> > + (cdb[1] & 0xe0))
> > + return false;
> > +
> > + if (!(cdb[1] & 0xe0)) {
> > + pr_warn("Target: Unprotected READ/WRITE to DIF device\n");
> > + return true;
> > + }
> > + if (!cmd->t_prot_sg || !cmd->t_prot_nents)
> > + return true;
> > +
> > + cmd->se_cmd_flags |= SCF_PROT;
>
> Isn't this the place to fill the se_cmd DIF execution parameters?
> prot_op, prot_type, guard_type, initial_reftag, apptag etc...
> Next, all parties interested in DIF execution should look in se_cmd
> (backstore, transport).
Yes, working on this for -v2 as well. :)
--nab
--
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 04/16] net: stmmac: Allocate and pass soc/board specific data to callbacks
The current .init and .exit callbacks requires access to driver
private data structures. This is not a good seperation and abstraction.
Instead, we add a new .setup callback for allocating private data, and
pass the returned pointer to the other callbacks.
Signed-off-by: Chen-Yu Tsai
---
Documentation/networking/stmmac.txt | 12
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 18 ++
include/linux/stmmac.h| 6 --
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/stmmac.txt
b/Documentation/networking/stmmac.txt
index cdd916d..2090895 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -127,8 +127,9 @@ struct plat_stmmacenet_data {
int riwt_off;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
- int (*init)(struct platform_device *pdev);
- void (*exit)(struct platform_device *pdev);
+ void *(*setup)(struct platform_device *pdev);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
void *custom_cfg;
void *custom_data;
void *bsp_priv;
@@ -169,10 +170,13 @@ Where:
o bus_setup: perform HW setup of the bus. For example, on some ST platforms
this field is used to configure the AMBA bridge to generate more
efficient STBus traffic.
- o init/exit: callbacks used for calling a custom initialization;
+ o setup/init/exit: callbacks used for calling a custom initialization;
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
-registers.
+registers. setup should return a pointer to private data,
+which will be stored in bsp_priv, and then passed to init and
+exit callbacks. init/exit callbacks should not use or modify
+platform data.
o custom_cfg/custom_data: this is a custom configuration that can be passed
while initializing the resources.
o bsp_priv: another private pointer.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3974586..86ee903 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -140,9 +140,16 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
}
}
+ /* Custom setup (if needed) */
+ if (plat_dat->setup) {
+ plat_dat->bsp_priv = plat_dat->setup(pdev);
+ if (IS_ERR(plat_dat->bsp_priv))
+ return PTR_ERR(plat_dat->bsp_priv);
+ }
+
/* Custom initialisation (if needed)*/
if (plat_dat->init) {
- ret = plat_dat->init(pdev);
+ ret = plat_dat->init(pdev, plat_dat->bsp_priv);
if (unlikely(ret))
return ret;
}
@@ -199,7 +206,10 @@ static int stmmac_pltfr_remove(struct platform_device
*pdev)
int ret = stmmac_dvr_remove(ndev);
if (priv->plat->exit)
- priv->plat->exit(pdev);
+ priv->plat->exit(pdev, priv->plat->bsp_priv);
+
+ if (priv->plat->free)
+ priv->plat->free(pdev, priv->plat->bsp_priv);
return ret;
}
@@ -228,7 +238,7 @@ int stmmac_pltfr_freeze(struct device *dev)
ret = stmmac_freeze(ndev);
if (plat_dat->exit)
- plat_dat->exit(pdev);
+ plat_dat->exit(pdev, plat_dat->bsp_priv);
return ret;
}
@@ -240,7 +250,7 @@ int stmmac_pltfr_restore(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
if (plat_dat->init)
- plat_dat->init(pdev);
+ plat_dat->init(pdev, plat_dat->bsp_priv);
return stmmac_restore(ndev);
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index bb5deb0..c407791 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -112,8 +112,10 @@ struct plat_stmmacenet_data {
int riwt_off;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
- int (*init)(struct platform_device *pdev);
- void (*exit)(struct platform_device *pdev);
+ void *(*setup)(struct platform_device *pdev);
+ void (*free)(struct platform_device *pdev, void *priv);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
void *custom_cfg;
void *custom_data;
void *bsp_priv;
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH v2 09/16] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
The Allwinner A20/A31 clock module controls the transmit clock source
and interface type of the GMAC ethernet controller. Model this as
a single clock for GMAC drivers to use.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/clock/sunxi.txt | 26
drivers/clk/sunxi/clk-sunxi.c | 74 +++
2 files changed, 100 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 8a9147d..a1fbf53 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -37,6 +37,7 @@ Required properties:
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks on A20
+ "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -57,6 +58,9 @@ Additionally, most clocks require "clock-output-names":
do not need "clock-output-names"
- all others clocks : the corresponding module name of that clock
+For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
@@ -102,3 +106,25 @@ mmc0_clk: clk@01c20088 {
clocks = <>, < 1>, < 1>;
clock-output-names = "mmc0";
};
+
+mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ clock-output-names = "mii_phy_tx";
+};
+
+gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac_int_tx";
+};
+
+gmac_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ clocks = <_phy_tx_clk>, <_int_tx_clk>;
+ clock-output-names = "gmac";
+};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index a741683..2ae2300 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -373,6 +373,80 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32
parent_rate,
/**
+ * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
+ *
+ * This clock looks something like this
+ *
+ * MII TX clock from PHY >-|____|> to GMAC core
+ * GMAC Int. RGMII TX clk >|___\__/__gate---|> to PHY
+ * Ext. 125MHz RGMII TX clk >--|__divider__/|
+ * ||
+ *
+ * The external 125 MHz reference is optional, i.e. GMAC can use its
+ * internal TX clock just fine. The A31 GMAC clock module does not have
+ * the divider controls for the external reference.
+ *
+ * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
+ * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
+ * select the appropriate source and gate/ungate the output to the PHY.
+ */
+
+#define SUN7I_A20_GMAC_GPIT2
+#define SUN7I_A20_GMAC_MASK0x3
+
+static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_mux *mux;
+ struct clk_gate *gate;
+ const char *clk_name = node->name;
+ const char *parents[2];
+ void *reg;
+ int i = 0;
+
+ /* allocate mux and gate clock structs */
+ mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+ if (!mux)
+ return;
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ if (!gate) {
+ kfree(mux);
+ return;
+ }
+
+ reg = of_iomap(node, 0);
+
+ of_property_read_string(node, "clock-output-names", _name);
+
+ while (i < 2 && (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
+ i++;
+
+ /* set up gate and fixed rate properties */
+ gate->reg = reg;
+ gate->bit_idx = SUN7I_A20_GMAC_GPIT;
+ gate->lock = _lock;
+ mux->reg = reg;
+ mux->mask = SUN7I_A20_GMAC_MASK;
+ mux->flags = CLK_MUX_INDEX_BIT;
+ mux->lock = _lock;
+
+ clk = clk_register_composite(NULL, clk_name,
+ parents, i,
+ >hw, _mux_ops,
+ NULL, NULL,
+ >hw, _gate_ops,
+ CLK_SET_PARENT_GATE);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
[PATCH v2 15/16] ARM: dts: sun7i: olinuxino-micro: Enable GMAC instead of EMAC
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +++--
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index ead3013..b02a796 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -19,21 +19,6 @@
compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
soc@01c0 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins_a>;
- phy = <>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_olinuxino: led_pins@0 {
allwinner,pins = "PH2";
@@ -78,6 +63,18 @@
pinctrl-0 = <_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_mii_a>;
+ phy = <>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.8.5.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 V6 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA
PHY comprises of CMU and TRSV blocks which are of I2C register Map.
So this patch also adds a i2c client driver, which is used configure
the CMU and TRSV block of exynos5250 SATA PHY.
This patch incorporates the generic PHY framework to deal with SATA
PHY.
This patch depends on the below patches
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham I
[2].ata: ahci_platform: Manage SATA PHY
by Roger Quadros
Signed-off-by: Yuvaraj Kumar C D
Signed-off-by: Girish K S
Signed-off-by: Vasanth Ananthan
---
Changes from V5:
1.Rebased on latest generic PHY framework for-next tree.
2.Minor nits such as indentations.
Changes from V4:
1.Made Exynos5250 SATA PHY driver by default selects
CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver
depends on I2C.
2.struct i2c_driver sataphy_i2c_driver made static which
was earlier global type.
3.Renamed the files to phy-exynos5250-sata.c and
phy-exynos5250-sata-i2c.c and CONFIG_EXYNOS5250_SATA_PHY
to CONFIG_PHY_EXYNOS5250_SATA.
Changes from V3:
1.Moved devm_phy_create before to devm_phy_provider_register.
Changes from V2:
1.Removed of_match_table
2.Moved to syscon interface for PMU handling.
Changes from V1:
1.Adapted to latest version of Generic PHY framework
2.Removed exynos_sata_i2c_remove function.
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5250-sata-i2c.c | 40 ++
drivers/phy/phy-exynos5250-sata.c | 238 +
4 files changed, 292 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-sata-i2c.c
create mode 100644 drivers/phy/phy-exynos5250-sata.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index d0611b8..df79150 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -57,4 +57,17 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_EXYNOS5250_SATA
+ tristate "Exynos5250 Sata SerDes/PHY driver"
+ depends on SOC_EXYNOS5250
+ select GENERIC_PHY
+ select I2C
+ select I2C_S3C2410
+ select MFD_SYSCON
+ help
+ Enable this to support SATA SerDes/Phy found on Samsung's
+ Exynos5250 based SoCs.This SerDes/Phy supports SATA 1.5 Gb/s,
+ SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds. It supports one SATA host
+ port to accept one SATA device.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 4e4adc9..8ccf8c3 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) +=
phy-exynos-mipi-video.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
phy-exynos5250-sata-i2c.o
diff --git a/drivers/phy/phy-exynos5250-sata-i2c.c
b/drivers/phy/phy-exynos5250-sata-i2c.c
new file mode 100644
index 000..206e337
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-sata-i2c.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Author:
+ * Yuvaraj C D
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+
+static int exynos_sata_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
+{
+ return 0;
+}
+
+static const struct i2c_device_id sataphy_i2c_device_match[] = {
+ { "exynos-sataphy-i2c", 0 },
+};
+
+static struct i2c_driver sataphy_i2c_driver = {
+ .probe = exynos_sata_i2c_probe,
+ .id_table = sataphy_i2c_device_match,
+ .driver = {
+ .name = "exynos-sataphy-i2c",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init exynos5250_phy_i2c_init(void)
+{
+ return i2c_add_driver(_i2c_driver);
+}
+module_init(exynos5250_phy_i2c_init);
diff --git a/drivers/phy/phy-exynos5250-sata.c
b/drivers/phy/phy-exynos5250-sata.c
new file mode 100644
index 000..6e5ff8d
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-sata.c
@@ -0,0 +1,238 @@
+/*
+ * Samsung SATA SerDes(PHY) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Authors: Girish K S
+ * Yuvaraj Kumar C D
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
[PATCH v2 11/16] ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4019c55..18d211e 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -618,6 +618,21 @@
status = "disabled";
};
+ gmac: ethernet@01c5 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c5 0x1>;
+ interrupts = <0 85 4>;
+ interrupt-names = "macirq";
+ clocks = <_gates 49>, <_tx_clk>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ snps,pbl = <2>;
+ snps,fixed-burst;
+ snps,force_sf_dma_mode;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
hstimer@01c6 {
compatible = "allwinner,sun7i-a20-hstimer";
reg = <0x01c6 0x1000>;
--
1.8.5.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 v2 02/16] net: stmmac: Enable stmmac main clock when probing hardware
Guiseppe previously stated that the "stmmaceth" clock is the main clock
that drives the IP. The stmmac driver does not enable this clock during
the probe phase. If the clock was not enabled by the boot loader or
disabled by the kernel, hardware features and the MDIO bus would not be
probed properly.
Signed-off-by: Chen-Yu Tsai
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 26 +++
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8a7a23a..786b51c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1604,8 +1604,6 @@ static int stmmac_open(struct net_device *dev)
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
- clk_prepare_enable(priv->stmmac_clk);
-
stmmac_check_ether_addr(priv);
if (priv->pcs != STMMAC_PCS_RGMII && priv->pcs != STMMAC_PCS_TBI &&
@@ -1796,7 +1794,6 @@ static int stmmac_release(struct net_device *dev)
#ifdef CONFIG_STMMAC_DEBUG_FS
stmmac_exit_fs();
#endif
- clk_disable_unprepare(priv->stmmac_clk);
stmmac_release_ptp(priv);
@@ -2682,10 +2679,18 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
+ priv->stmmac_clk = devm_clk_get(priv->device, STMMAC_RESOURCE_NAME);
+ if (IS_ERR(priv->stmmac_clk)) {
+ dev_warn(priv->device, "%s: warning: cannot get CSR clock\n",
+__func__);
+ goto error_clk_get;
+ }
+ clk_prepare_enable(priv->stmmac_clk);
+
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
- goto error_free_netdev;
+ goto error_hw_init;
ndev->netdev_ops = _netdev_ops;
@@ -2723,12 +2728,6 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
goto error_netdev_register;
}
- priv->stmmac_clk = clk_get(priv->device, STMMAC_RESOURCE_NAME);
- if (IS_ERR(priv->stmmac_clk)) {
- pr_warn("%s: warning: cannot get CSR clock\n", __func__);
- goto error_clk_get;
- }
-
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
* changed at run-time and it is fixed. Viceversa the driver'll try to
@@ -2756,12 +2755,12 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
return priv;
error_mdio_register:
- clk_put(priv->stmmac_clk);
-error_clk_get:
unregister_netdev(ndev);
error_netdev_register:
netif_napi_del(>napi);
-error_free_netdev:
+error_hw_init:
+ clk_disable_unprepare(priv->stmmac_clk);
+error_clk_get:
free_netdev(ndev);
return NULL;
@@ -2788,6 +2787,7 @@ int stmmac_dvr_remove(struct net_device *ndev)
stmmac_mdio_unregister(ndev);
netif_carrier_off(ndev);
unregister_netdev(ndev);
+ clk_disable_unprepare(priv->stmmac_clk);
free_netdev(ndev);
return 0;
--
1.8.5.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 v2 12/16] ARM: dts: sun7i: Add pin muxing options for the GMAC
The A20 has EMAC and GMAC muxed on the same pins.
Add pin sets with gmac function for MII and RGMII mode to the DTSI.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 18d211e..b18f18f 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -463,6 +463,32 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ gmac_pins_mii_a: gmac_mii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ gmac_pins_rgmii_a: gmac_rgmii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA10",
+ "PA11", "PA12", "PA13",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ /*
+* data lines in RGMII mode use DDR mode
+* and need a higher signal drive strength
+*/
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.8.5.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 V6 2/2] ARM: dts: Enable ahci sata and sata phy
This patch adds dt entry for ahci sata controller and its
corresponding phy controller.phy node has been added w.r.t
new generic phy framework.
Signed-off-by: Yuvaraj Kumar C D
---
Changes since V4:
1.Used the new phandle "sata_phy_i2c" in the DT entry.
2.Updated binding document.
Changes since V3:
1.Moved the binding info to the /bindings/phy/
Changes since V2:
1.Used syscon interface to PMU handling.
2.Changed "sata-phy-i2c" to "exynos-sataphy-i2c".
Changes since V1:
1.Minor changes to node name convention.
2.Updated binding document.
.../devicetree/bindings/ata/exynos-sata-phy.txt| 14
.../devicetree/bindings/ata/exynos-sata.txt| 25 +-
.../devicetree/bindings/phy/samsung-phy.txt| 36
arch/arm/boot/dts/exynos5250-arndale.dts | 11 ++
arch/arm/boot/dts/exynos5250-smdk5250.dts |8 ++---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
6 files changed, 78 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
deleted file mode 100644
index 37824fa..000
--- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* Samsung SATA PHY Controller
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible: compatible list, contains "samsung,exynos5-sata-phy"
-- reg :
-
-Example:
-sata@ffe07000 {
-compatible = "samsung,exynos5-sata-phy";
-reg = <0xffe07000 0x1000>;
-};
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt
b/Documentation/devicetree/bindings/ata/exynos-sata.txt
index 0849f10..b2adb1f 100644
--- a/Documentation/devicetree/bindings/ata/exynos-sata.txt
+++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt
@@ -4,14 +4,21 @@ SATA nodes are defined to describe on-chip Serial ATA
controllers.
Each SATA controller should have its own node.
Required properties:
-- compatible: compatible list, contains "samsung,exynos5-sata"
-- interrupts:
-- reg :
-- samsung,sata-freq :
+- compatible : compatible list, contains "samsung,exynos5-sata"
+- interrupts :
+- reg :
+- samsung,sata-freq:
+- phys : as mentioned in phy-bindings.txt
+- phy-names: as mentioned in phy-bindings.txt
Example:
-sata@ffe08000 {
-compatible = "samsung,exynos5-sata";
-reg = <0xffe08000 0x1000>;
-interrupts = <115>;
-};
+ sata@122f {
+ compatible = "snps,dwc-ahci";
+ samsung,sata-freq = <66>;
+ reg = <0x122f 0x1ff>;
+ interrupts = <0 115 0>;
+ clocks = < 277>, < 143>;
+ clock-names = "sata", "sclk_sata";
+ phys = <_phy>;
+ phy-names = "sata-phy";
+ };
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..a937f75 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,39 @@ Required properties:
- compatible : should be "samsung,exynos5250-dp-video-phy";
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung SATA PHY Controller
+---
+
+SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
+Each SATA PHY controller should have its own node.
+
+Required properties:
+- compatible: compatible list, contains "samsung,exynos5250-sata-phy"
+- reg : offset and length of the SATA PHY register set;
+- #phy-cells : from the generic phy bindings;
+
+Example:
+ sata_phy: sata-phy@1217 {
+ compatible = "samsung,exynos5250-sata-phy";
+ reg = <0x1217 0x1ff>;
+ clocks = < 287>;
+ clock-names = "sata_phyctrl";
+ #phy-cells = <0>;
+ samsung,exynos-sataphy-i2c-phandle = <_phy_i2c>;
+ samsung,syscon-phandle = <_syscon>;
+ };
+
+Device-Tree bindings for sataphy i2c client driver
+--
+
+Required properties:
+compatible: Should be "samsung,exynos-sataphy-i2c"
+- reg: I2C address of the sataphy i2c device.
+
+Example:
+
+ sata_phy_i2c:sata-phy@38 {
+ compatible = "samsung,exynos-sataphy-i2c";
+ reg = <0x38>;
+ };
diff --git
Re: [PATCH 09/14] target/configfs: Expose protection device attributes
On Thu, 2014-01-09 at 13:01 +0200, Sagi Grimberg wrote: > On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger > > > > This patch adds support for exposing DIF protection device > > attributes via configfs. This includes: > > > > pi_prot_type: Protection Type (0, 1, 3 currently support) > > pi_prot_version: Protection Version (DIF v1 currently supported) > > pi_guard_type: Guard Type (1=DIF CRC, 2=IP CRC) > > > > Within se_dev_set_pi_prot_type() it also adds the se_subsystem_api > > device callbacks to setup per device protection information. > > Suggestion, expose pi_prot_format and call transport->init_prot() there. > It is more explicit > and this routine should be called upon getting FORMAT_UNIT as well. , working on this next for FILEIO following your original example code. Thanks Sagi! --nab -- 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.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi, On Fri, Jan 10, 2014 at 6:25 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 09 January 2014 10:54 AM, Roger Quadros wrote: >> Hi Marek, >> >> I have no idea what is happening there. Have you tried using device tree >> boot? >> Board file boot support would be dropped eventually. >> >> Did you try if I2C read write to the twl4030 device works and all necessary >> clocks/supplies are >> present? >> >> Kishon, do you know what is causing the USB DPLL failure there? Issue was fixed. There was in 3.13-rc7 issue with unable to find phy (phy was twl4030_usb). After that issue is gone. > > Not sure what's causing those failures :-s > > -Kishon > >> >> cheers, >> -roger >> >> On 01/09/2014 02:31 AM, Belisko Marek wrote: >>> Any pointers? Still present in 3.13-rc7. >>> >>> On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros wrote: +Kishon On 12/03/2013 11:33 PM, Belisko Marek wrote: > Hi, > > current 3.13-rcX break usb support on gta04 board (similar to > beagleboard) when booting via board file. > > In console we can see messages: > [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY > DPLL clock > [ 5232.936096] omap_musb_mailbox: musb core is not yet ready > [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL > clock > [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL > clock > > Any pointer what could cause that? (in 3.12 usb works fine) > > BR, > > marek > >>> >>> BR, >>> >>> marek >>> >> > BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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 02/14] target: Add DIF CHECK_CONDITION ASC/ASCQ exception cases
On Thu, 2014-01-09 at 12:43 +0200, Sagi Grimberg wrote: > On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger > > > > This patch adds support for DIF related CHECK_CONDITION ASC/ASCQ > > exception cases into transport_send_check_condition_and_sense(). > > > > This includes: > > > >LOGICAL BLOCK GUARD CHECK FAILED > >LOGICAL BLOCK APPLICATION TAG CHECK FAILED > >LOGICAL BLOCK REFERENCE TAG CHECK FAILED > > > > that used by DIF TYPE1 and TYPE3 failure cases. > > > > Cc: Martin K. Petersen > > Cc: Christoph Hellwig > > Cc: Hannes Reinecke > > Cc: Sagi Grimberg > > Cc: Or Gerlitz > > Signed-off-by: Nicholas Bellinger > > --- > > drivers/target/target_core_transport.c | 30 > > ++ > > include/target/target_core_base.h |3 +++ > > 2 files changed, 33 insertions(+) > > > > diff --git a/drivers/target/target_core_transport.c > > b/drivers/target/target_core_transport.c > > index 91953da..707ee17 100644 > > --- a/drivers/target/target_core_transport.c > > +++ b/drivers/target/target_core_transport.c > > @@ -2648,6 +2648,36 @@ transport_send_check_condition_and_sense(struct > > se_cmd *cmd, > > buffer[SPC_ASC_KEY_OFFSET] = 0x1d; > > buffer[SPC_ASCQ_KEY_OFFSET] = 0x00; > > break; > > + case TCM_LOGICAL_BLOCK_GUARD_CHECK_FAILED: > > + /* CURRENT ERROR */ > > + buffer[0] = 0x70; > > + buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10; > > + /* ILLEGAL REQUEST */ > > + buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST; > > + /* LOGICAL BLOCK GUARD CHECK FAILED */ > > + buffer[SPC_ASC_KEY_OFFSET] = 0x10; > > + buffer[SPC_ASCQ_KEY_OFFSET] = 0x01; > > You have Enums for ASCQs (TARGET_GUARD_CHECK_FAILED, > TARGET_APPTAG_CHECK_FAILED, TARGET_REFTAG_CHECK_FAILED). either use them > or loose them. , dropping these extra definitions. --nab -- 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 13/14] target/rd: Add DIF protection into rd_execute_rw
On Thu, 2014-01-09 at 12:32 +0200, Sagi Grimberg wrote:
> On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds support for DIF protection into rd_execute_rw() code
> > for WRITE/READ I/O using sbc_dif_verify_[write,read]() logic.
> >
> > It also adds rd_get_prot_table() for locating protection SGLs
> > assoicated with the ramdisk backend device.
> >
> > Cc: Martin K. Petersen
> > Cc: Christoph Hellwig
> > Cc: Hannes Reinecke
> > Cc: Sagi Grimberg
> > Cc: Or Gerlitz
> > Signed-off-by: Nicholas Bellinger
> > ---
> > drivers/target/target_core_rd.c | 67
> > +++
> > 1 file changed, 67 insertions(+)
> >
> > diff --git a/drivers/target/target_core_rd.c
> > b/drivers/target/target_core_rd.c
> > index dd99844..3fd51eb 100644
> > --- a/drivers/target/target_core_rd.c
> > +++ b/drivers/target/target_core_rd.c
> > @@ -363,6 +363,26 @@ static struct rd_dev_sg_table *rd_get_sg_table(struct
> > rd_dev *rd_dev, u32 page)
> > return NULL;
> > }
> >
> > +static struct rd_dev_sg_table *rd_get_prot_table(struct rd_dev *rd_dev,
> > u32 page)
> > +{
> > + struct rd_dev_sg_table *sg_table;
> > + u32 i, sg_per_table = (RD_MAX_ALLOCATION_SIZE /
> > + sizeof(struct scatterlist));
> > +
> > + i = page / sg_per_table;
> > + if (i < rd_dev->sg_prot_count) {
> > + sg_table = _dev->sg_prot_array[i];
> > + if ((sg_table->page_start_offset <= page) &&
> > +(sg_table->page_end_offset >= page))
> > + return sg_table;
> > + }
> > +
> > + pr_err("Unable to locate struct prot rd_dev_sg_table for page: %u\n",
> > + page);
> > +
> > + return NULL;
> > +}
> > +
> > static sense_reason_t
> > rd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
> > enum dma_data_direction data_direction)
> > @@ -377,6 +397,7 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist
> > *sgl, u32 sgl_nents,
> > u32 rd_page;
> > u32 src_len;
> > u64 tmp;
> > + sense_reason_t rc;
> >
> > if (dev->rd_flags & RDF_NULLIO) {
> > target_complete_cmd(cmd, SAM_STAT_GOOD);
> > @@ -399,6 +420,29 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist
> > *sgl, u32 sgl_nents,
> > data_direction == DMA_FROM_DEVICE ? "Read" : "Write",
> > cmd->t_task_lba, rd_size, rd_page, rd_offset);
> >
> > + if ((cmd->se_cmd_flags & SCF_PROT) && se_dev->dev_attrib.pi_prot_type &&
> > + data_direction == DMA_TO_DEVICE) {
> > + sector_t sector = cmd->data_length /
> > se_dev->dev_attrib.block_size;
> > + struct rd_dev_sg_table *prot_table;
> > + struct scatterlist *prot_sg;
> > + u32 prot_offset, prot_page;
> > +
> > + tmp = cmd->t_task_lba * se_dev->prot_length;
> > + prot_offset = do_div(tmp, PAGE_SIZE);
> > + prot_page = tmp;
> > +
> > + prot_table = rd_get_prot_table(dev, prot_page);
> > + if (!prot_table)
> > + return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
> > +
> > + prot_sg = _table->sg_table[prot_page -
> > prot_table->page_start_offset];
> > +
> > + rc = sbc_dif_verify_write(cmd, cmd->t_task_lba, sector, 0,
> > + prot_sg, prot_offset);
> > + if (rc)
> > + return rc;
> > + }
> > +
> > src_len = PAGE_SIZE - rd_offset;
> > sg_miter_start(, sgl, sgl_nents,
> > data_direction == DMA_FROM_DEVICE ?
> > @@ -460,6 +504,29 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist
> > *sgl, u32 sgl_nents,
> > }
> > sg_miter_stop();
> >
> > + if ((cmd->se_cmd_flags & SCF_PROT) && se_dev->dev_attrib.pi_prot_type &&
> > + data_direction == DMA_FROM_DEVICE) {
> > + sector_t sector = cmd->data_length /
> > se_dev->dev_attrib.block_size;
> > + struct rd_dev_sg_table *prot_table;
> > + struct scatterlist *prot_sg;
> > + u32 prot_offset, prot_page;
> > +
> > + tmp = cmd->t_task_lba * se_dev->prot_length;
> > + prot_offset = do_div(tmp, PAGE_SIZE);
> > + prot_page = tmp;
> > +
> > + prot_table = rd_get_prot_table(dev, prot_page);
> > + if (!prot_table)
> > + return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
> > +
> > + prot_sg = _table->sg_table[prot_page -
> > prot_table->page_start_offset];
> > +
> > + rc = sbc_dif_verify_read(cmd, cmd->t_task_lba, sector, 0,
> > +prot_sg, prot_offset);
> > + if (rc)
> > + return rc;
> > + }
> > +
> > target_complete_cmd(cmd, SAM_STAT_GOOD);
> > return 0;
> > }
>
> I wander how we can skip sbc_dif_verify_ if the transport already
> offloaded DIF verify.
> I think that the transport
Re: [PATCH v8 0/4] qrwlock: Introducing a queue read/write lock implementation
On Wed, Jan 08, 2014 at 11:59:32AM -0500, Waiman Long wrote: > v7->v8: > - Use atomic_t functions (which are implemented in all arch's) to >modify reader counts. > - Use smp_load_acquire() & smp_store_release() for barriers. > - Further tuning in slowpath performance. This version looks good to me. You now have my Reviewed-by on all the patches. Thanx, Paul > v6->v7: > - Remove support for unfair lock, so only fair qrwlock will be provided. > - Move qrwlock.c to the kernel/locking directory. > > v5->v6: > - Modify queue_read_can_lock() to avoid false positive result. > - Move the two slowpath functions' performance tuning change from >patch 4 to patch 1. > - Add a new optional patch to use the new smp_store_release() function >if that is merged. > > v4->v5: > - Fix wrong definitions for QW_MASK_FAIR & QW_MASK_UNFAIR macros. > - Add an optional patch 4 which should only be applied after the >mcs_spinlock.h header file is merged. > > v3->v4: > - Optimize the fast path with better cold cache behavior and >performance. > - Removing some testing code. > - Make x86 use queue rwlock with no user configuration. > > v2->v3: > - Make read lock stealing the default and fair rwlock an option with >a different initializer. > - In queue_read_lock_slowpath(), check irq_count() and force spinning >and lock stealing in interrupt context. > - Unify the fair and classic read-side code path, and make write-side >to use cmpxchg with 2 different writer states. This slows down the >write lock fastpath to make the read side more efficient, but is >still slightly faster than a spinlock. > > v1->v2: > - Improve lock fastpath performance. > - Optionally provide classic read/write lock behavior for backward >compatibility. > - Use xadd instead of cmpxchg for fair reader code path to make it >immute to reader contention. > - Run more performance testing. > > As mentioned in the LWN article http://lwn.net/Articles/364583/, > the read/write lock suffer from an unfairness problem that it is > possible for a stream of incoming readers to block a waiting writer > from getting the lock for a long time. Also, a waiting reader/writer > contending a rwlock in local memory will have a higher chance of > acquiring the lock than a reader/writer in remote node. > > This patch set introduces a queue-based read/write lock implementation > that can largely solve this unfairness problem. > > The read lock slowpath will check if the reader is in an interrupt > context. If so, it will force lock spinning and stealing without > waiting in a queue. This is to ensure the read lock will be granted > as soon as possible. > > The queue write lock can also be used as a replacement for ticket > spinlocks that are highly contended if lock size increase is not > an issue. > > This patch set currently provides queue read/write lock support on > x86 architecture only. Support for other architectures can be added > later on once architecture specific support infrastructure is added > and proper testing is done. > > The optional patch 3 has a dependency on the the mcs_spinlock.h > header file which has not been merged yet. So this patch should only > be applied after the mcs_spinlock.h header file is merged. > > The optional patch 4 use the new smp_store_release() and > smp_load_acquire() functions which are being reviewed & not merged yet. > > Waiman Long (4): > qrwlock: A queue read/write lock implementation > qrwlock x86: Enable x86 to use queue read/write lock > qrwlock: Use the mcs_spinlock helper functions for MCS queuing > qrwlock: Use smp_store_release() in write_unlock() > > arch/x86/Kconfig |1 + > arch/x86/include/asm/spinlock.h |2 + > arch/x86/include/asm/spinlock_types.h |4 + > include/asm-generic/qrwlock.h | 203 > + > kernel/Kconfig.locks |7 + > kernel/locking/Makefile |1 + > kernel/locking/qrwlock.c | 191 +++ > 7 files changed, 409 insertions(+), 0 deletions(-) > create mode 100644 include/asm-generic/qrwlock.h > create mode 100644 kernel/locking/qrwlock.c > -- 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 v8 1/4] qrwlock: A queue read/write lock implementation
On Wed, Jan 08, 2014 at 11:59:33AM -0500, Waiman Long wrote: > This patch introduces a new read/write lock implementation that put > waiting readers and writers into a queue instead of actively contending > the lock like the current read/write lock implementation. This will > improve performance in highly contended situation by reducing the > cache line bouncing effect. Reviewed-by: Paul E. McKenney > The queue read/write lock (qrwlock) is a fair lock even though there > is still a slight chance of lock stealing if a reader or writer comes > at the right moment. Other than that, lock granting is done in a > FIFO manner. As a result, it is possible to determine a maximum time > period after which the waiting is over and the lock can be acquired. > > Internally, however, there is a second type of readers which try to > steal lock aggressively. They simply increments the reader count and > wait until the writer releases the lock. The transition to aggressive > reader happens in the read lock slowpath when > > 1. In an interrupt context. > 2. When a reader comes to the head of the wait queue and sees > the release of a write lock. > > The queue read lock is safe to use in an interrupt context (softirq > or hardirq) as it will switch to become an aggressive reader in such > environment allowing recursive read lock. > > The only downside of queue rwlock is the size increase in the lock > structure by 4 bytes for 32-bit systems and by 12 bytes for 64-bit > systems. > > In term of single-thread performance (no contention), a 256K > lock/unlock loop was run on a 2.4GHz and 2.93Ghz Westmere x86-64 > CPUs. The following table shows the average time (in ns) for a single > lock/unlock sequence (including the looping and timing overhead): > > Lock Type 2.4GHz 2.93GHz > - -- --- > Ticket spinlock14.912.3 > Read lock 17.013.5 > Write lock 17.013.5 > Queue read lock16.013.4 > Queue write lock9.2 7.8 > > The queue read lock is slightly slower than the spinlock, but is > slightly faster than the read lock. The queue write lock, however, > is the fastest of all. It is almost twice as fast as the write lock > and about 1.5X of the spinlock. > > With lock contention, the speed of each individual lock/unlock function > is less important than the amount of contention-induced delays. > > To investigate the performance characteristics of the queue rwlock > compared with the regular rwlock, Ingo's anon_vmas patch that converts > rwsem to rwlock was applied to a 3.12 kernel. This kernel was then > tested under the following 3 conditions: > > 1) Plain 3.12 > 2) Ingo's patch > 3) Ingo's patch + qrwlock > > Each of the 3 kernels were booted up twice with and without the > "idle=poll" kernel parameter which keeps the CPUs in C0 state while > idling instead of a more energy-saving sleep state. The jobs per > minutes (JPM) results of the AIM7's high_systime workload at 1500 > users on a 8-socket 80-core DL980 (HT off) were: > > Kernel JPMs%Change from (1) > -- >1 145704/227295 - >2 229750/236066 +58%/+3.8% >4 240062/248606 +65%/+9.4% > > The first JPM number is without the "idle=poll" kernel parameter, > the second number is with that parameter. It can be seen that most > of the performance benefit of converting rwsem to rwlock actually > come from the latency improvement of not needing to wake up a CPU > from deep sleep state when work is available. > > The use of non-sleeping locks did improve performance by eliminating > the context switching cost. Using queue rwlock gave almost tripling > of performance gain. The performance gain was reduced somewhat with > a fair lock which was to be expected. > > Looking at the perf profiles (with idle=poll) below, we can clearly see > that other bottlenecks were constraining the performance improvement. > > Perf profile of kernel (2): > > 18.65%reaim [kernel.kallsyms] [k] __write_lock_failed > 9.00%reaim [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 5.21% swapper [kernel.kallsyms] [k] cpu_idle_loop > 3.08%reaim [kernel.kallsyms] [k] mspin_lock > 2.50%reaim [kernel.kallsyms] [k] anon_vma_interval_tree_insert > 2.00% ls [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 1.29%reaim [kernel.kallsyms] [k] update_cfs_rq_blocked_load > 1.21%reaim [kernel.kallsyms] [k] __read_lock_failed > 1.12%reaim [kernel.kallsyms] [k] _raw_spin_lock > 1.10%reaim [kernel.kallsyms] [k] perf_event_aux > 1.09% true [kernel.kallsyms] [k] _raw_spin_lock_irqsave > > Perf profile of kernel (3): > > 20.14% swapper [kernel.kallsyms] [k] cpu_idle_loop > 7.94%reaim [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 5.41%
[PATCH] genalloc: spinlock_t needs spinlock_types.h
Compiling a C file which includes genalloc.h but without spinlock_types.h being included before, we will see the compile error below. include/linux/genalloc.h:54:2: error: unknown type name ‘spinlock_t’ Include spinlock_types.h from genalloc.h to fix the problem. Signed-off-by: Shawn Guo --- include/linux/genalloc.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index 1eda33d..1c2fdaa 100644 --- a/include/linux/genalloc.h +++ b/include/linux/genalloc.h @@ -30,6 +30,8 @@ #ifndef __GENALLOC_H__ #define __GENALLOC_H__ +#include + struct device; struct device_node; -- 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 v12 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)
On Fri, 2013-12-20 at 15:24 +0100, Lukasz Majewski wrote:
> This patch provides auto disable/enable operation for boost. It uses already
> present thermal infrastructure to provide BOOST hysteresis.
> The TMU data has been modified to work properly with or without BOOST.
> Hence, the two first trip points with corresponding clip frequencies were
> adjusted.
>
> The first one was reduced from 85 to 70 degrees and clip frequency was
> increased to 1.4 GHz from 800 MHz. This trip point is in fact responsible
> for providing BOOST hysteresis. When temperature exceeds 70 deg, the maximal
> non BOOST frequency for Exynos4412 is imposed.
>
> Since the first trigger level has been "stolen" for BOOST, the second one
> needs to be a compromise for the previously used two for non BOOST
> configuration. The 95 deg with modified clip freq (to 400 MHz) shall provide
> a good balance between cooling down the overheated device and throughput on
> an acceptable level.
>
> Two last trigger levels were not modified since, they cause platform shutdown
> on emergency overheat situation.
> Third trip point passage results in SW managed shut down of the system.
> If the last trip point is crossed, the PMU HW generates the power off
> signal.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Myungjoo Ham
> Acked-by: Eduardo Valentin
Reviewed-by: Zhang Rui
thanks,
rui
>
> ---
> Changes for v12:
> - More verbose patch description to explain new TMU temperature assignment
> for Exynos4412
>
> Changes for v11:
> - Use only one thermal data set
> - Adjust Exynos4412 thermal data to work with or without BOOST
>
> Changes for v10:
> - Remove boost related code from thermal_core.c
> - Use already present thermal infrastructure to provide thermal hysteresis
> - Introduce special set of TMU data for BOOST
>
> Changes for v9:
> - None
>
> Changes for v8:
> - Move cpufreq_boost_* stub functions definition (needed when cpufreq
> is not compiled in) to cpufreq.h at cpufreq core support commit
>
> Changes for v7:
> - None
>
> Changes for v6:
> - Disable boost only when supported and enabled
> - Protect boost related thermal_zone_device struct fields with mutex
> - Evaluate temperature trend during boost enable decision
> - Create separate methods to handle boost enable/disable
> (thermal_boost_{enable|disable}) operations
> - Boost is disabled at any trip point passage (not only the non critical
> one)
> - Add stub definitions for cpufreq boost functions used when
> CONFIG_CPU_FREQ is NOT defined.
>
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
> (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's
> predefined
> pool delay or has woken up thermal workqueue only to wait until device
> cools down.
>
> Changes for v4:
> - New patch
>
> drivers/thermal/samsung/exynos_tmu_data.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index 073c292..476b768 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -131,8 +131,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
>
> #define EXYNOS4412_TMU_DATA \
> .threshold_falling = 10, \
> - .trigger_levels[0] = 85, \
> - .trigger_levels[1] = 103, \
> + .trigger_levels[0] = 70, \
> + .trigger_levels[1] = 95, \
> .trigger_levels[2] = 110, \
> .trigger_levels[3] = 120, \
> .trigger_enable[0] = true, \
> @@ -155,12 +155,12 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .second_point_trim = 85, \
> .default_temp_offset = 50, \
> .freq_tab[0] = { \
> - .freq_clip_max = 800 * 1000, \
> - .temp_level = 85, \
> + .freq_clip_max = 1400 * 1000, \
> + .temp_level = 70, \
> }, \
> .freq_tab[1] = { \
> - .freq_clip_max = 200 * 1000, \
> - .temp_level = 103, \
> + .freq_clip_max = 400 * 1000, \
> + .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> .registers = _tmu_registers, \
--
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 v12 0/7] cpufreq:boost: CPU Boost mode support
On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > Hi Rafael, > > Hi, > > > > This patch series introduces support for CPU overclocking technique > > > called Boost. > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > component: > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > software oriented one (like the one done at Exynos). > > > For this reason cpufreq/freq_table code has been reorganized to > > > include common code. > > > > > > Important design decisions: > > > - Boost related code is compiled-in unconditionally to cpufreq core > > > and disabled by default. The cpufreq_driver is responsibile for > > > setting boost_supported flag and providing set_boost callback(if HW > > > support is needed). For software managed boost, special Kconfig flag - > > > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only > > > when a target platform has thermal framework properly configured. > > > > > > - struct cpufreq_driver has been extended with boost related fields: > > > -- boost_supported - when driver supports boosting > > > -- boost_enabled - boost state > > > -- set_boost - callback to function, which is necessary to > > >enable/disable boost > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > > > visible _only_ when cpufreq driver supports Boost. > > > > > > - No special spin_lock for Boost was created. The one from cpufreq > > > core was reused. > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > changed, then the policy list is iterated and proper adjustements are > > > done. > > > > > > - To improve safety level, the thermal framework is also extended to > > > disable software boosting, when thermal trip point is reached. After > > > cooling down the boost can be enabled again. This emulates behaviour > > > similar to HW managed boost (like x86) > > > > > > Tested at HW: > > >Exynos 4412 3.13-rc4 Linux > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > Lukasz Majewski (7): > > > cpufreq: Add boost frequency support in core > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > > > boost solution > > > cpufreq:boost:Kconfig: Provide support for software managed BOOST > > > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > > > framework > > > Documentation:cpufreq:boost: Update BOOST documentation > > > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > > > thermal:exynos:boost: Automatic enable/disable of BOOST feature (at > > > Exynos4412) > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > drivers/cpufreq/Kconfig |4 + > > > drivers/cpufreq/Kconfig.arm | 15 > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > +++-- drivers/cpufreq/cpufreq.c | > > > 118 - > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > drivers/cpufreq/freq_table.c | 56 -- > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > include/linux/cpufreq.h | 24 ++ 10 files > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > A gentle ping about BOOST patches. > > > > Its been already acked by Viresh and Eduardo. > > > > It applies on kernel_pm/bleeding_edge SHA1: > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > It looks like Rui is still looking into this. > > Rui, are you fine with this series? > Yes, I'm okay with the thermal related parts of this patch set. thanks, rui > Rafael > -- 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/
[GIT PULL] clk: fixes for 3.13
The following changes since commit d6e0a2dd12f4067a5bcefb8bbd8ddbeff800afbc:
Linux 3.13-rc7 (2014-01-04 15:12:14 -0800)
are available in the git repository at:
git://git.linaro.org/people/mike.turquette/linux.git tags/clk-fixes-for-linus
for you to fetch changes up to 778037e1ccb75609846deca9e419449c1dc137fa:
clk: clk-divider: fix divisor > 255 bug (2014-01-08 08:33:12 -0800)
Late fixes for clock drivers. All of these fixes are for user-visible
regressions, typically boot failures or other unsafe system
configuration that causes badness.
Abhilash Kesavan (4):
clk: samsung: exynos5250: Fix ACP gate register offset
clk: samsung: exynos5250: Add MDMA0 clocks
ARM: dts: exynos5250: Fix MDMA0 clock number
clk: samsung: exynos5250: Add CLK_IGNORE_UNUSED flag for the sysreg clock
Andrew Bresticker (1):
clk: exynos5250: fix sysmmu_mfc{l,r} gate clocks
James Hogan (1):
clk: clk-divider: fix divisor > 255 bug
Krzysztof Kozlowski (1):
clk: exynos: File scope reg_save array should depend on PM_SLEEP
Mike Turquette (1):
Merge tag 'samsung-clk-fixes' of
git://git.kernel.org/.../tfiga/samsung-clk into clk-fixes
Seung-Woo Kim (1):
clk: samsung: exynos4: Correct SRC_MFC register
.../devicetree/bindings/clock/exynos5250-clock.txt | 2 ++
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
drivers/clk/clk-divider.c | 2 +-
drivers/clk/samsung/clk-exynos-audss.c | 10 +-
drivers/clk/samsung/clk-exynos4.c | 2 +-
drivers/clk/samsung/clk-exynos5250.c | 14 +-
6 files changed, 19 insertions(+), 13 deletions(-)
--
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/6 v2] crypto:s5p-sss: Add device tree support
Hi Naveen,
On 10 January 2014 11:37, Naveen Krishna Ch wrote:
> Hello Tomasz,
>
[snip]
>>> *pdev)
>>> static struct platform_driver s5p_aes_crypto = {
>>> .probe = s5p_aes_probe,
>>> .remove = s5p_aes_remove,
>>> + .id_table = s5p_sss_ids,
>>> .driver = {
>>> .owner = THIS_MODULE,
>>> .name = "s5p-secss",
>>> + .of_match_table = s5p_sss_dt_match,
>>
>>
>> .of_match_table = of_match_ptr(s5p_sss_dt_match),
> I dint use it, Some time back there was a patchset from Sachin
> https://lkml.org/lkml/2013/9/28/61
> Please suggest me on this.
In those cases the structure was always compiled in. i.e., it was not protected
by #ifdef CONFIG_OF. Hence use of of_match_ptr was not required. of_match_ptr
abstracts this check depending on OF is enabled or not. In the case of
this (sss) driver,
since you are using CONFIG_OF to selectively compile out the code (and esp.
s5p_sss_dt_match structure), use of of_match_ptr will make the code
simpler as it
avoids the use of a dummy structure definition (the #else part of the
struct definition) when OF is
disabled. Hope this clarifies.
--
With warm regards,
Sachin
--
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 07/14] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16
On Thu, 2014-01-09 at 12:24 +0200, Sagi Grimberg wrote: > On 1/8/2014 10:36 PM, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger > > > > This patch updates sbc_emulate_readcapacity_16() to set > > P_TYPE and PROT_EN bits when DIF emulation is enabled by > > the backend device. > > > > Cc: Martin K. Petersen > > Cc: Christoph Hellwig > > Cc: Hannes Reinecke > > Cc: Sagi Grimberg > > Cc: Or Gerlitz > > Signed-off-by: Nicholas Bellinger > > --- > > drivers/target/target_core_sbc.c |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/target/target_core_sbc.c > > b/drivers/target/target_core_sbc.c > > index 366b9bb..22599e8 100644 > > --- a/drivers/target/target_core_sbc.c > > +++ b/drivers/target/target_core_sbc.c > > @@ -106,6 +106,11 @@ sbc_emulate_readcapacity_16(struct se_cmd *cmd) > > buf[9] = (dev->dev_attrib.block_size >> 16) & 0xff; > > buf[10] = (dev->dev_attrib.block_size >> 8) & 0xff; > > buf[11] = dev->dev_attrib.block_size & 0xff; > > + /* > > +* Set P_TYPE and PROT_EN bits for DIF support > > +*/ > > + if (dev->dev_attrib.pi_prot_type) > > + buf[12] = (dev->dev_attrib.pi_prot_type - 1) << 1 | 0x1; > > > > if (dev->transport->get_lbppbe) > > buf[13] = dev->transport->get_lbppbe(dev) & 0x0f; > > Hey Nic, > > What about FORMAT_UNIT emulation? Would certainly be useful to have.. > The backstore protection configuration is done at the target side via > configfs/targetcli, if you publish DIF support in > INQUERY_EVPD/READ_CAPACITY you need to accept protection information format? Mmmm, these two bits bits are following what scsi_debug is currently exposing minus FORMAT_UNIT support..? MKP..? --nab -- 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: [PATCHv8 2/2] dma: Add Freescale eDMA engine driver support
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, January 09, 2014 8:19 PM
> To: Lu Jingchang-B35083
> Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; shawn@linaro.org;
> pawel.m...@arm.com; mark.rutl...@arm.com; swar...@wwwdotorg.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCHv8 2/2] dma: Add Freescale eDMA engine driver support
>
> On Thursday 09 January 2014 11:44:46 Jingchang Lu wrote:
> > >
> > > On Thursday 09 January 2014, Jingchang Lu wrote:
> > > > > > > +sai2: sai@40031000 {
> > > > > > > + compatible = "fsl,vf610-sai";
> > > > > > > + reg = <0x40031000 0x1000>;
> > > > > > > + interrupts = <0 86 0x04>;
> > > > > > > + clocks = < VF610_CLK_SAI2>;
> > > > > > > + clock-names = "sai";
> > > > > > > + dma-names = "tx", "rx";
> > > > > > > + dmas = < VF610_EDMA_DMAMUX0
> VF610_EDMA0_MUX0_SAI2_TX>,
> > > > > > > + < VF610_EDMA_DMAMUX0
> VF610_EDMA0_MUX0_SAI2_RX>;
> > > > > > > + status = "disabled";
> > > > > > > +};
> > > > >
> > > > > It seems wrong to have macros defined like
> VF610_EDMA0_MUX0_SAI2_TX,
> > > > > in particular in the example. These should just be literal
> numbers.
> > > > [Lu Jingchang-b35083]
> > > > This eDMA engineer requires two specifiers, one is a mux group id,
> the
> > > other is a request source id.
> > > > The VF610_EDMA0_MUX0_SAI2_TX is sai's tx dma request source id, it
> is
> > > defined as a literal number.
> > > > There are totally more than 100 request source id, I have them
> macros
> > > defined to make it referenced
> > > > easily and clearly, just like some clock binding done.
> > > > The macros are defined in include/dt-bindings/dma/vf610-edma.h.
> > >
> > > The clock bindings are special because the macros there tend to be
> made
> > > up for controllers that just have a bunch of clocks at random
> register
> > > locations.
> > >
> > > This is not the case for DMA bindings (or some of the more regular
> clock
> > > controllers), so there is absolutely no reason to define those macros
> > > in a header file, it just adds artificial dependencies between the
> > > driver, SoC support and the binding.
> > >
> > > If the numbers are the same as the ones provided in the data sheet,
> > > just use the numbers and remove the macros.
> >
> > Yes, the request source id is defined in the data sheet.
> > each eDMA controller has two muxes, some SoCs have two eDMA controllers
> > while others have only one. The 1st eDMA's muxes are named mux0 and
> mux1,
> > while the 2nd eDMA controller's muxes are named MUX2 and MUX3 in the
> datasheet,
> > and I index them in each eDMA controller from 0 in the driver to handle
> them commonly.
>
> Right. I don't object to the use of the macros for the muxes, that seems
> fine and appropriate given your description.
>
> > I defines the macro tending to give the info from the macro name, such
> as
> > for the VF610_EDMA0_MUX0_SAI2_TX request source, implying the eDMA
> engine id 0,
> > and the mux id should be 0. While VF610_EDMA1_MUX1_FTM0_CH0 implying
> eDMA engine id 1,
> > mux 1. The request sources are shared between the two eDMA controller
> but need the user
> > to select one manually when reference.
>
> Note that the dma binding allows you to actually specify both engines
> in this case. A slave device can have
>
> dma-names = "rx", "rx", "tx", "tx";
> dmas = < 0 12> < 0 12> < 0 13> < 0 13>;
>
> and the requesting a channel from the slave driver will find
> the first available one. In theory we could have some load-balancing
> as well, but that has not been implemented.
[Lu Jingchang-b35083]
Yes, the slave can specify mixed dma channel and the eDMA driver can allocate
channels to it properly. But just as you said, the driver doesn't implement
load-balanceing between eDMA controller, this need the user to balance them
in dts and slave driver manually. And on our LS-1 SoC, there is only one eDMA
controller.
For the slave request id macros definitions, I think their reservation could
direct ease the combination of the controller, the mux, and the request in dts.
Thanks.
>
> > > You are right, your code is actually correct on all combinations
> > > of big-endian and little-endian ARM CPUs. However, I would argue that
> > > it's unusual style, and not portable to other architectures (e.g.
> arm64)
> > > because the definition of readl() is highly architecture dependent.
> > > It would also be problematic if the arm definition has to change
> > > in some form and this driver is overlooked.
> > [Lu Jingchang-b35083]
> > Yes, these definitions are highly depending on the arm32 arch. This
> device is only
> > integrated in our arm32 SoCs currently, so I have only considered arm32.
> > In arm32, it seems that the ioread32 and readl are the same in arm32,
> > I will try your recommendation below to simplify the caller.
>
> Ok, thanks. I generally insist on writing drivers in a
[PATCH] ASoC: simple-card: fix simple card widgets routing property name usage
Fix the usage of simple card widgets routing property, and make it the
same with simple card routing property name.
Signed-off-by: Xiubo Li
---
Documentation/devicetree/bindings/sound/simple-card.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt
b/Documentation/devicetree/bindings/sound/simple-card.txt
index e9e20ec..19c84df 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -43,7 +43,7 @@ Example:
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "left_j";
- simple-audio-routing =
+ simple-audio-card,routing =
"MIC_IN", "Mic Jack",
"Headphone Jack", "HP_OUT",
"Ext Spk", "LINE_OUT";
--
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/
Re: [PATCH 2/6 v2] crypto:s5p-sss: Add device tree support
Hello Tomasz,
Thanks for time and review comments they are really helping me a lot
in getting the patches merged.
Secondly, accept my apologies for not giving proper writeup of why i
din't address
few of your comments on v1 of this patchset.
On 9 January 2014 19:44, Tomasz Figa wrote:
> Hi Naveen,
>
>
> On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds device tree support to the s5p-sss.c crypto driver.
>> Implements a varient struct to address the changes in SSS hardware
>> on various SoCs from Samsung.
>>
>> Also, Documentation under devicetree/bindings added.
>>
>> Signed-off-by: Naveen Krishna Ch
>> CC: Herbert Xu
>> CC: David S. Miller
>> CC: Vladimir Zapolskiy
>> TO:
>> CC:
>> ---
>> Changes since v1:
>> 1. Added description of the SSS module in Documentation
>> 2. Corrected the interrupts description
>> 3. Added varient struct instead of the version variable
>>
>> .../devicetree/bindings/crypto/samsung-sss.txt | 20 +
>> drivers/crypto/s5p-sss.c | 81
>> ++--
>> 2 files changed, 95 insertions(+), 6 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> new file mode 100644
>> index 000..0e45b0d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> @@ -0,0 +1,20 @@
>> +Samsung SoC SSS (Security SubSystem) module
>> +
>> +The SSS module in S5PV210 SoC supports the following:
>> +-- Feeder (FeedCtrl)
>> +-- Advanced Encryption Standard (AES)
>> +-- Data Encryption Standard (DES)/3DES
>> +-- Public Key Accelerator (PKA)
>> +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
>> +-- PRNG: Pseudo Random Number Generator
>> +
>> +Required properties:
>> +
>> +- compatible : Should contain entries for this and backward compatible
>> + SSS versions:
>> + - "samsung,s5p-secss" for S5PV210 SoC.
>
>
> As I wrote in my previous reply, please use specific compatible string
> containing name of SoC on which the block described by it appeared first.
> Let me say it again, for security block that showed up first on S5PV210 the
> string will be "samsung,s5pv210-secss".
1. .name = "s5p-secss", is the name used in the present driver.
So, i dint modify that.
2. I'm not sure which one is the first soc to have the new varient.
May be Exynos4210. Will modify in the next version.
>
>
>> +- reg : Offset and length of the register set for the module
>> +- interrupts : the interrupt-specifier for the SSS module.
>> + Two interrupts "feed control and hash" in case of S5PV210
>> +- clocks : the required gating clock for the SSS module.
>> +- clock-names : the gating clock name to be requested in the SSS driver.
>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>> index 93cddeb..78e0c37 100644
>> --- a/drivers/crypto/s5p-sss.c
>> +++ b/drivers/crypto/s5p-sss.c
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -145,6 +146,20 @@
>> #define AES_KEY_LEN 16
>> #define CRYPTO_QUEUE_LEN1
>>
>> +/**
>> + * struct samsung_aes_varient - platform specific SSS driver data
>
>
> typo: s/varient/variant/g
>
> Anyway, I think this should be moved to the patch adding support for
> Exynos5, as before it there is no use for this struct and it's not directly
> related to DT support.
>
>
>> + * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
>> + * @aes_offset: AES register offset from SSS module's base.
>> + *
>> + * Specifies platform specific configuration of SSS module.
>> + * Note: A structure for driver specific platform data is used for future
>> + * expansion of its usage.
>> + */
>> +struct samsung_aes_varient {
>> + boolhas_hash_irq;
>> + unsigned intaes_offset;
>> +};
>> +
>> struct s5p_aes_reqctx {
>> unsigned long mode;
>> };
>> @@ -173,10 +188,56 @@ struct s5p_aes_dev {
>> struct crypto_queue queue;
>> boolbusy;
>> spinlock_t lock;
>> +
>> + struct samsung_aes_varient *varient;
>> };
>>
>> static struct s5p_aes_dev *s5p_dev;
>>
>> +static struct samsung_aes_varient s5p_aes_data = {
>
>
> Remember to mark constant data as const.
>
>
>> + .has_hash_irq = true,
>> + .aes_offset = 0x4000,
>> +};
>> +
>> +static const struct platform_device_id s5p_sss_ids[] = {
>> + {
>> + .name = "s5p-secss",
>> + .driver_data= (kernel_ulong_t)_aes_data,
>> + },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
>> +
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id s5p_sss_dt_match[] = {
>> + {
>> + .compatible =
[PATCH] gpio: pxa: normalize the return value for gpio_get
It would be convenient to normalize the return value for gpio_get.
I have checked mach-mmp / mach-pxa / plat-pxa / plat-orion / mach-orion5x.
It's OK for all of them to change this function to return 0 and 1.
Signed-off-by: Neil Zhang
---
drivers/gpio/gpio-pxa.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index cc13d1b..42e6e64 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -263,7 +263,8 @@ static int pxa_gpio_direction_output(struct gpio_chip *chip,
static int pxa_gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return readl_relaxed(gpio_chip_base(chip) + GPLR_OFFSET) & (1 <<
offset);
+ u32 gplr = readl_relaxed(gpio_chip_base(chip) + GPLR_OFFSET);
+ return !!(gplr & (1 << offset));
}
static void pxa_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
--
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 00/14] target: Initial support for DIF Type1+Type3 emulation
On Thu, 2014-01-09 at 21:00 -0500, Martin K. Petersen wrote: > > "Nic" == Nicholas A Bellinger writes: > > Nic> This series contains initial support for target mode DIF > Nic> Type1+Type3 emulation within target core, RAMDISK_MCP device > Nic> backend, and tcm_loop fabric driver. > > Super cool! Do you have a git tree so I can start tinkering with this? Most certainly, it's been pushed to target-pending/auto-next. > > I'll start reviewing the pieces tomorrow. Excellent. Thanks MKP! --nab -- 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 0/2] ION dummy driver
On 01/09/2014 08:23 PM, Greg KH wrote: > On Thu, Jan 09, 2014 at 07:40:53PM -0800, John Stultz wrote: >> Greg: I realize this is after the usual -rc6 cutoff for staging, >> so no pressure if you want to defer this for 3.15, but I saw you've >> picked up a few things recently, so I figured I'd send it out so >> I'm not just sitting on it while we wait for LCA to finish. > I would have merged it, but I just tried and got a ton of errors when > building: > > ERROR: "ion_device_destroy" [drivers/staging/android/ion/ion_dummy_driver.ko] > undefined! > ERROR: "ion_heap_destroy" [drivers/staging/android/ion/ion_dummy_driver.ko] > undefined! > ERROR: "ion_device_add_heap" > [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! > ERROR: "ion_heap_create" [drivers/staging/android/ion/ion_dummy_driver.ko] > undefined! > ERROR: "ion_device_create" [drivers/staging/android/ion/ion_dummy_driver.ko] > undefined! > > So, I'll just drop these patches and forget you ever sent them to me :) Gah. Modules bite me every time! Should have been a bool and not tristate in the Kconfig. Sorry! I appreciate the heads up and the build related amnesia. :) thanks -john -- 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/
Intel MIC host driver: possible signed underflow (undefined behavior) in userspace API
Hi,
Looking at this commit:
commit f69bcbf3b4c4b333dcd7a48eaf868bf0c88edab5
Author: Ashutosh Dixit
Date: Thu Sep 5 16:42:18 2013 -0700
Intel MIC Host Driver Changes for Virtio Devices.
Especially at:
+struct mic_copy_desc {
+#ifdef __KERNEL__
+ struct iovec __user *iov;
+#else
+ struct iovec *iov;
+#endif
+ int iovcnt;
+ __u8 vr_idx;
+ __u8 update_used;
+ __u32 out_len;
+};
Seeing iovcnt being declared as a signed integer seems strange. The
first question would be: why is it signed rather than unsigned ?
Then, looking further into
drivers/misc/mic/host/mic_virtio.c:_mic_virtio_copy()
We can see that the while() loop iterates until the local variable
iovcnt reaches the value 0 (and iovcnt is also a signed integer). If
user-space passes e.g. INT_MIN as iovcnt field, this loop then appears
to depend on an undefined behavior (signed underflow) to complete.
Wouldn't it be better to use an unsigned integers both in the
userspace API and for the local variable ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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] drivers: target: target_core_mod: use div64_u64_rem() instead of operator '%' for u64
On Thu, 2014-01-09 at 11:17 +0100, Hannes Reinecke wrote:
> On 01/09/2014 12:18 AM, Nicholas A. Bellinger wrote:
> > On Wed, 2014-01-08 at 08:32 +0100, Hannes Reinecke wrote:
> >> Other than that the sector_div() patch is correct.
> >>
> >
> > Thanks for confirming that sector_div() is correct here vs. the
> > original code using modulo that Chen had pointed out.
> >
> Ah, _that_ was the issue.
> I was wondering why you kept on poking me ...
>
> Well.
> No, that's actually _not_ correct.
> The correct fix would be
>
> diff --git a/drivers/target/target_core_alua.c
> b/drivers/target/target_core_alua.c
> index 54b1e52..12da9b3 100644
> --- a/drivers/target/target_core_alua.c
> +++ b/drivers/target/target_core_alua.c
> @@ -500,8 +500,7 @@ static inline int core_alua_state_lba_dependent(
>
> if (segment_mult) {
> u64 tmp = lba;
> - sector_div(tmp, segment_size * segment_mult);
> - start_lba = tmp;
> + start_lba = sector_div(tmp, segment_size *
> segment_mult);
>
> last_lba = first_lba + segment_size - 1;
> if (start_lba >= first_lba &&
> (beware of line breaks ...)
> Thing is, we need to calculate the offset into the segment to figure out
> which map entry to use.
> The actual number of the segment (as had been calculated with the
> original fix) is immaterial here.
>
> Sorry for this. The email thread just flew past me during Xmas
> with me not paying real attention.
>
Applied + squashed. Apologies for the initial pre-holiday BUG..
Thanks Hannes!
--nab
--
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 0/2] ION dummy driver v2
The ION subsystem requires something register it along with the various heaps that may be available on a system in order to work (Otherwise no /dev/ion is created). This can make it difficult to play with. Thus I've created this simple dummy driver which allocates and registers some basic heaps. I've been using this dummy driver, along with Colin's unit tests and test driver, to be able to validate basic functionality on a number of architectures and it was handy to chase down a few issues before ION was submitted to staging. If you want to play with all of this, Colin's unit tests can be found in AOSP under the system/core/libion directory, but if you want to try to use them in a non-Android environment, I've mirrored that directory and added some changes to get it building under Ubuntu here: https://github.com/johnstultz-work/ion-test Greg: I realize this is after the usual -rc6 cutoff for staging, and I've already made a fool of myself with v1 (but mybe you don't remember!) so no pressure if you want to defer this for 3.15. thanks -john Changes in v2: * Fix module build issue (should have been bool instead of tristate) Cc: Colin Cross Cc: Greg KH Cc: Jesse Barker Cc: Android Kernel Team John Stultz (2): ion: Add dummy driver for testing ion: Add carveout and chunk heaps to dummy driver drivers/staging/android/ion/Kconfig| 10 ++ drivers/staging/android/ion/Makefile | 3 + drivers/staging/android/ion/ion_dummy_driver.c | 158 + 3 files changed, 171 insertions(+) create mode 100644 drivers/staging/android/ion/ion_dummy_driver.c -- 1.8.3.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 1/2] ion: Add dummy driver for testing
Provide a basic dummy driver to register the ion device
and to install basic SYSTEM and SYSTEM_CONTIG heaps.
This allows for basic testing with ION without having
access to drivers or systems that have been enabled to use
ION.
Cc: Colin Cross
Cc: Greg KH
Cc: Jesse Barker
Cc: Android Kernel Team
Signed-off-by: John Stultz
---
drivers/staging/android/ion/Kconfig| 10 +++
drivers/staging/android/ion/Makefile | 3 +
drivers/staging/android/ion/ion_dummy_driver.c | 93 ++
3 files changed, 106 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index a9a64ea..0f8fec1 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,6 +17,16 @@ config ION_TEST
Choose this option to create a device that can be used to test the
kernel and device side ION functions.
+config ION_DUMMY
+ bool "Dummy Ion driver"
+ depends on ION
+ help
+ Provides a dummy ION driver that registers the
+ /dev/ion device and some basic heaps. This can
+ be used for testing the ION infrastructure if
+ one doesn't have access to hardware drivers that
+ use ION.
+
config ION_TEGRA
tristate "Ion for Tegra"
depends on ARCH_TEGRA && ION
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 75039b9..b56fd2b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,4 +4,7 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
ifdef CONFIG_COMPAT
obj-$(CONFIG_ION) += compat_ion.o
endif
+
+obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
obj-$(CONFIG_ION_TEGRA) += tegra/
+
diff --git a/drivers/staging/android/ion/ion_dummy_driver.c
b/drivers/staging/android/ion/ion_dummy_driver.c
new file mode 100644
index 000..6749d29
--- /dev/null
+++ b/drivers/staging/android/ion/ion_dummy_driver.c
@@ -0,0 +1,93 @@
+/*
+ * drivers/gpu/ion/ion_dummy_driver.c
+ *
+ * Copyright (C) 2013 Linaro, 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 "ion.h"
+#include "ion_priv.h"
+
+struct ion_device *idev;
+struct ion_heap **heaps;
+
+struct ion_platform_heap dummy_heaps[] = {
+ {
+ .id = ION_HEAP_TYPE_SYSTEM,
+ .type = ION_HEAP_TYPE_SYSTEM,
+ .name = "system",
+ },
+ {
+ .id = ION_HEAP_TYPE_SYSTEM_CONTIG,
+ .type = ION_HEAP_TYPE_SYSTEM_CONTIG,
+ .name = "system contig",
+ },
+};
+
+struct ion_platform_data dummy_ion_pdata = {
+ .nr = 2,
+ .heaps = dummy_heaps,
+};
+
+static int __init ion_dummy_init(void)
+{
+ int i, err;
+
+ idev = ion_device_create(NULL);
+ heaps = kzalloc(sizeof(struct ion_heap *) * dummy_ion_pdata.nr,
+ GFP_KERNEL);
+ if (!heaps)
+ return PTR_ERR(heaps);
+
+ for (i = 0; i < dummy_ion_pdata.nr; i++) {
+ struct ion_platform_heap *heap_data = _ion_pdata.heaps[i];
+
+ heaps[i] = ion_heap_create(heap_data);
+ if (IS_ERR_OR_NULL(heaps[i])) {
+ err = PTR_ERR(heaps[i]);
+ goto err;
+ }
+ ion_device_add_heap(idev, heaps[i]);
+ }
+ return 0;
+err:
+ for (i = 0; i < dummy_ion_pdata.nr; i++) {
+ if (heaps[i])
+ ion_heap_destroy(heaps[i]);
+ }
+ kfree(heaps);
+
+ return err;
+}
+
+static void __exit ion_dummy_exit(void)
+{
+ int i;
+
+ ion_device_destroy(idev);
+
+ for (i = 0; i < dummy_ion_pdata.nr; i++)
+ ion_heap_destroy(heaps[i]);
+ kfree(heaps);
+
+ return;
+}
+
+module_init(ion_dummy_init);
+module_exit(ion_dummy_exit);
+
--
1.8.3.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 2/2] ion: Add carveout and chunk heaps to dummy driver
Add support to the dummy driver for basic carveout and chunk heaps.
Since we're generating these heaps at module_init, and we want
this driver to be generic enough to be tested on any arch, we
don't have the ability to alloc bootmem, so both of these heaps
are conventionally allocated using alloc_pages(), which limits us
to 4M in size.
Should look into using CMA for heap allocation eventually, but
this provides enough to test the basic functionality of the
heaps.
Cc: Colin Cross
Cc: Greg KH
Cc: Jesse Barker
Cc: Android Kernel Team
Signed-off-by: John Stultz
---
drivers/staging/android/ion/ion_dummy_driver.c | 67 +-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_dummy_driver.c
b/drivers/staging/android/ion/ion_dummy_driver.c
index 6749d29..55b2002 100644
--- a/drivers/staging/android/ion/ion_dummy_driver.c
+++ b/drivers/staging/android/ion/ion_dummy_driver.c
@@ -26,6 +26,9 @@
struct ion_device *idev;
struct ion_heap **heaps;
+void *carveout_ptr;
+void *chunk_ptr;
+
struct ion_platform_heap dummy_heaps[] = {
{
.id = ION_HEAP_TYPE_SYSTEM,
@@ -37,10 +40,24 @@ struct ion_platform_heap dummy_heaps[] = {
.type = ION_HEAP_TYPE_SYSTEM_CONTIG,
.name = "system contig",
},
+ {
+ .id = ION_HEAP_TYPE_CARVEOUT,
+ .type = ION_HEAP_TYPE_CARVEOUT,
+ .name = "carveout",
+ .size = SZ_4M,
+ },
+ {
+ .id = ION_HEAP_TYPE_CHUNK,
+ .type = ION_HEAP_TYPE_CHUNK,
+ .name = "chunk",
+ .size = SZ_4M,
+ .align = SZ_16K,
+ .priv = (void *)(SZ_16K),
+ },
};
struct ion_platform_data dummy_ion_pdata = {
- .nr = 2,
+ .nr = 4,
.heaps = dummy_heaps,
};
@@ -54,9 +71,36 @@ static int __init ion_dummy_init(void)
if (!heaps)
return PTR_ERR(heaps);
+
+ /* Allocate a dummy carveout heap */
+ carveout_ptr = alloc_pages_exact(
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size,
+ GFP_KERNEL);
+ if (carveout_ptr)
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].base =
+ virt_to_phys(carveout_ptr);
+ else
+ pr_err("ion_dummy: Could not allocate carveout\n");
+
+ /* Allocate a dummy chunk heap */
+ chunk_ptr = alloc_pages_exact(
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size,
+ GFP_KERNEL);
+ if (chunk_ptr)
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].base = virt_to_phys(chunk_ptr);
+ else
+ pr_err("ion_dummy: Could not allocate chunk\n");
+
for (i = 0; i < dummy_ion_pdata.nr; i++) {
struct ion_platform_heap *heap_data = _ion_pdata.heaps[i];
+ if (heap_data->type == ION_HEAP_TYPE_CARVEOUT &&
+ !heap_data->base)
+ continue;
+
+ if (heap_data->type == ION_HEAP_TYPE_CHUNK && !heap_data->base)
+ continue;
+
heaps[i] = ion_heap_create(heap_data);
if (IS_ERR_OR_NULL(heaps[i])) {
err = PTR_ERR(heaps[i]);
@@ -72,6 +116,16 @@ err:
}
kfree(heaps);
+ if (carveout_ptr) {
+ free_pages_exact(carveout_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
+ carveout_ptr = NULL;
+ }
+ if (chunk_ptr) {
+ free_pages_exact(chunk_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
+ chunk_ptr = NULL;
+ }
return err;
}
@@ -85,6 +139,17 @@ static void __exit ion_dummy_exit(void)
ion_heap_destroy(heaps[i]);
kfree(heaps);
+ if (carveout_ptr) {
+ free_pages_exact(carveout_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
+ carveout_ptr = NULL;
+ }
+ if (chunk_ptr) {
+ free_pages_exact(chunk_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
+ chunk_ptr = NULL;
+ }
+
return;
}
--
1.8.3.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/
oops in rds_iw_laddr_check
Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 0 PID: 5036 Comm: trinity-main Not tainted 3.13.0-rc7+ #15 task: 88008fc6b7b0 ti: 880090796000 task.ti: 880090796000 RIP: 0010:[] [] rds_iw_laddr_check+0x73/0xc0 [rds_rdma] RSP: 0018:880090797e10 EFLAGS: 00010246 RAX: RBX: 8802147a2520 RCX: 0004 RDX: RSI: 0001 RDI: a1673220 RBP: 880090797e38 R08: R09: R10: 0001800d0004 R11: 7fc1fa61 R12: R13: ac178800 R14: d6ff R15: d6ff FS: 7faf4a474740() GS:88024d00() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 07bc CR3: 90789000 CR4: 001407f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Stack: ac178802 1d88df67 0008 a168e6c0 880090797e60 a161c7ca 880090797ec0 8802146bb480 ac178800 880090797ea8 a1616fb9 Call Trace: [] rds_trans_get_preferred+0x5a/0xa0 [rds] [] rds_bind+0xf9/0x190 [rds] [] SYSC_bind+0xe0/0x120 [] ? vtime_account_user+0x91/0xa0 [] ? context_tracking_user_exit+0x9b/0x100 [] ? syscall_trace_enter+0x145/0x270 [] SyS_bind+0xe/0x10 [] tracesys+0xdd/0xe2 Code: 48 c7 45 d8 00 00 00 00 48 8d 75 d8 44 89 65 dc 48 c7 45 e0 00 00 00 00 66 89 45 d8 e8 47 ae fe ff 85 c0 41 89 c4 75 40 48 8b 03 <80> b8 bc 07 00 00 04 b8 9d ff ff ff 44 0f 45 e0 48 89 df e8 75 /* due to this, we will claim to support IB devices unless we check node_type. */ if (ret || cm_id->device->node_type != RDMA_NODE_RNIC) 1ce: 75 40 jne210 1d0: 48 8b 03mov(%rbx),%rax ret = -EADDRNOTAVAIL; 1d3: 80 b8 bc 07 00 00 04cmpb $0x4,0x7bc(%rax) 1da: b8 9d ff ff ff mov$0xff9d,%eax 1df: 44 0f 45 e0 cmovne %eax,%r12d Looks like cm_id->device was NULL. Dave -- 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/
linux-next: Tree for Jan 10
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140109: Removed tree: ubi (at maintainers request) Dropped tree: sh (complex merge conflicts against very old commits) The powerpc tree still had its build failure. The kvm tree gained a build failure so I used the version from next-20140109. The akpm-current tree gained a conflict against the char-misc tree. Non-merge commits (relative to Linus' tree): 7799 7424 files changed, 367590 insertions(+), 189373 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (7d1c153ab373 Merge branch 'parisc-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (1e01c7eb7c43 ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h) Merging arm-current/fixes (6bcac805bacb Revert "ARM: 7908/1: mm: Fix the arm_dma_limit calculation") Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (f991db1cf1bd Merge remote-tracking branch 'agust/merge' into merge) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (732256b9335f tipc: correctly unlink packets from deferred packet queue) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (150116bcfbd9 ALSA: hiface: Fix typo in 352800 rate definition) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL dereference in unflatten_and_copy()) Merging rr
[PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param
From: Nenghua Cao It fixes the following case: Two FEs connects the same BE; FE1 & BE path has been opened and hw_paramed. At this momment, FE2 & BE path is being opened and hw_paramed. The BE dai will do hw_param again even if it has done hw_param. It is not reasonable. FE1>BE FE2-^ Signed-off-by: Nenghua Cao --- sound/soc/soc-pcm.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 891b9a9..ec07e37 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream) continue; if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) && - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE)) continue; -- 1.7.0.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: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi, On Thursday 09 January 2014 10:54 AM, Roger Quadros wrote: > Hi Marek, > > I have no idea what is happening there. Have you tried using device tree boot? > Board file boot support would be dropped eventually. > > Did you try if I2C read write to the twl4030 device works and all necessary > clocks/supplies are > present? > > Kishon, do you know what is causing the USB DPLL failure there? Not sure what's causing those failures :-s -Kishon > > cheers, > -roger > > On 01/09/2014 02:31 AM, Belisko Marek wrote: >> Any pointers? Still present in 3.13-rc7. >> >> On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros wrote: >>> +Kishon >>> >>> On 12/03/2013 11:33 PM, Belisko Marek wrote: Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek >>> >> >> BR, >> >> marek >> > -- 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/
warning: (PPC_PSERIES && ..) selects HOTPLUG_CPU which has unmet direct dependencies (SMP && ..))
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7d1c153ab373a5c07feb97eaf4e4bcad5bfc262e commit: bb07b00be77fb33274cb44a03bdbf2471e556189 Merge 3.10-rc6 into driver-core-next date: 7 months ago config: make ARCH=powerpc mpc86xx_defconfig All warnings: warning: (PPC_PSERIES && PM_SLEEP_SMP) selects HOTPLUG_CPU which has unmet direct dependencies (SMP && (PPC_PSERIES || PPC_PMAC || PPC_POWERNV || PPC_85xx && !PPC_E500MC)) --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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/
linux-next: manual merge of the akpm-current tree with the char-misc tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
drivers/misc/mei/hbm.c between commit 544f94601409 ("mei: do not run
reset flow from the interrupt thread") from the char-misc tree and commit
dd045dab2999 ("drivers/misc/mei: ratelimit several error messages") from
the akpm-current tree.
I am not sure if the akpm-current tree fix is still needed, but I fixed
it up anyway (see below) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/misc/mei/hbm.c
index 8520cdfa2f05,2ab8b1dab39c..
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@@ -626,31 -597,25 +626,31 @@@ int mei_hbm_dispatch(struct mei_device
}
if (!mei_hbm_version_is_supported(dev)) {
- dev_warn(>pdev->dev, "hbm version mismatch:
stopping the driver.\n");
+ dev_warn(>pdev->dev, "hbm: start: version mismatch
- stopping the driver.\n");
- dev->hbm_state = MEI_HBM_STOP;
+ dev->hbm_state = MEI_HBM_STOPPED;
mei_hbm_stop_req_prepare(dev, >wr_msg.hdr,
dev->wr_msg.data);
- mei_write_message(dev, >wr_msg.hdr,
- dev->wr_msg.data);
+ if (mei_write_message(dev, >wr_msg.hdr,
+ dev->wr_msg.data)) {
+ dev_err(>pdev->dev, "hbm: start: failed to
send stop request\n");
+ return -EIO;
+ }
+ break;
+ }
- return;
+ if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
+ dev->hbm_state != MEI_HBM_START) {
- dev_err(>pdev->dev, "hbm: start: state mismatch,
[%d, %d]\n",
++ dev_err_ratelimited(>pdev->dev, "hbm: start: state
mismatch, [%d, %d]\n",
+ dev->dev_state, dev->hbm_state);
+ return -EPROTO;
}
- if (dev->dev_state == MEI_DEV_INIT_CLIENTS &&
- dev->hbm_state == MEI_HBM_START) {
- dev->init_clients_timer = 0;
- mei_hbm_enum_clients_req(dev);
- } else {
- dev_err_ratelimited(>pdev->dev, "reset: wrong host
start response\n");
- mei_reset(dev, 1);
- return;
+ dev->hbm_state = MEI_HBM_STARTED;
+
+ if (mei_hbm_enum_clients_req(dev)) {
+ dev_err(>pdev->dev, "hbm: start: failed to send
enumeration request\n");
+ return -EIO;
}
wake_up_interruptible(>wait_recvd_msg);
@@@ -731,25 -681,19 +731,25 @@@
< sizeof(enum_res->valid_addresses));
memcpy(dev->me_clients_map, enum_res->valid_addresses,
sizeof(enum_res->valid_addresses));
- if (dev->dev_state == MEI_DEV_INIT_CLIENTS &&
- dev->hbm_state == MEI_HBM_ENUM_CLIENTS) {
- dev->init_clients_timer = 0;
- mei_hbm_me_cl_allocate(dev);
- dev->hbm_state = MEI_HBM_CLIENT_PROPERTIES;
-
- /* first property reqeust */
- mei_hbm_prop_req(dev);
- } else {
- dev_err_ratelimited(>pdev->dev, "reset: unexpected
enumeration response hbm.\n");
- mei_reset(dev, 1);
- return;
+
+ if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
+ dev->hbm_state != MEI_HBM_ENUM_CLIENTS) {
- dev_err(>pdev->dev, "hbm: enumeration response:
state mismatch, [%d, %d]\n",
++ dev_err_ratelimited(>pdev->dev, "hbm: enumeration
response: state mismatch, [%d, %d]\n",
+ dev->dev_state, dev->hbm_state);
+ return -EPROTO;
+ }
+
+ if (mei_hbm_me_cl_allocate(dev)) {
+ dev_err(>pdev->dev, "hbm: enumeration response:
cannot allocate clients array\n");
+ return -ENOMEM;
}
+
+ dev->hbm_state = MEI_HBM_CLIENT_PROPERTIES;
+
+ /* first property request */
+ if (mei_hbm_prop_req(dev))
+ return -EIO;
+
break;
case HOST_STOP_RES_CMD:
pgpTarxs3wjUc.pgp
Description: PGP signature
powerpc: possible access beyond TASK_SIZE in start_thread
Hi Rusty,
I was looking at the diff between kernel v3.12 and recent master (after
3.13-rc7),
and noticed that in the following commit:
commit 94af3abf995b17f6a008b00152c94841242ec6c7
Author: Rusty Russell
Date: Wed Nov 20 22:15:02 2013 +1100
powerpc: ELF2 binaries launched directly.
on powerpc, those lines appear in start_thread():
+ /* start is a relocated pointer to the function
+* descriptor for the elf _start routine. The first
+* entry in the function descriptor is the entry
+* address of _start and the second entry is the TOC
+* value we need to use.
+*/
+ __get_user(entry, (unsigned long __user *)start);
+ __get_user(toc, (unsigned long __user *)start+1);
Note the "__" before get_user(), which bypass any kind of validation on the
addresses.
Amongst the callers, if we look at fs/binfmt_elf.c:load_elf_binary(), we see:
elf_entry = loc->elf_ex.e_entry;
if (BAD_ADDR(elf_entry)) {
force_sig(SIGSEGV, current);
retval = -EINVAL;
goto out_free_dentry;
}
and the elf_entry gets passed to start_thread().
If we craft a binary with elf_entry address of
TASK_SIZE - 1 (1 byte before TASK_SIZE), then I think we could make both
__get_user() calls access data beyond TASK_SIZE, because elf_entry address
is verified, but there is no validation on its range AFAIU. Is it expected ?
Am I missing something ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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 0/2] ION dummy driver
On Thu, Jan 09, 2014 at 07:40:53PM -0800, John Stultz wrote: > Greg: I realize this is after the usual -rc6 cutoff for staging, > so no pressure if you want to defer this for 3.15, but I saw you've > picked up a few things recently, so I figured I'd send it out so > I'm not just sitting on it while we wait for LCA to finish. I would have merged it, but I just tried and got a ton of errors when building: ERROR: "ion_device_destroy" [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! ERROR: "ion_heap_destroy" [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! ERROR: "ion_device_add_heap" [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! ERROR: "ion_heap_create" [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! ERROR: "ion_device_create" [drivers/staging/android/ion/ion_dummy_driver.ko] undefined! So, I'll just drop these patches and forget you ever sent them to me :) greg k-h p.s. Feel free to resend them when they work. -- 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] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
On Thursday 09 January 2014 10:03 PM, Brian Norris wrote: > On Thu, Jan 09, 2014 at 04:09:00PM +0530, Sekhar Nori wrote: >> On Thursday 26 December 2013 05:36 PM, ivan.khoronzhuk wrote: >>> On 12/18/2013 02:13 PM, Sekhar Nori wrote: On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote: > Hi, Sekhar > > This patch is based on "Reuse davinci-nand driver for Keystone arch" > series. > The series has passed review at https://lkml.org/lkml/2013/12/17/241 > and can be found at http://git.infradead.org/l2-mtd.git > > This patch can be still applied on top of the series without conflicts. > > Can you please pick up the $subject patch if you are OK with it? I have no problems with the patch and can pick it too, but need ack from MTD maintainer (David) as it touches drivers/mtd/ too. David, If you do not have the patch, we can resend it. Thanks, Sekhar >>> >>> Hi Brian, >>> >>> Do you agree if this patch will go through Davinci tree? >>> >>> This is the last one we need to reuse Davinci Nand driver for Keystone. >> >> Since we never got an ack from MTD folks, I am going and go ahead and >> try pushing this through ARM-SoC regardless. I will CC the MTD >> maintainers on the pull request so any objections could even be posted >> there. > > Sorry, I've been a little busy / out for vacation. The MTD parts look OK > to me. Feel free to take it in your tree. > > Acked-by: Brian Norris Thanks Brian! Regards, Sekhar -- 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: Freeing of dev->p
On Wed, Jan 08, 2014 at 09:33:30PM +0100, Jean Delvare wrote:
> On Wed, 8 Jan 2014 08:56:28 -0800, Greg Kroah-Hartman wrote:
> > On Wed, Jan 08, 2014 at 04:40:58PM +0100, Jean Delvare wrote:
> > > Hi Greg, hi all,
> > >
> > > A memory leak has been reported to me:
> > > http://marc.info/?l=linux-i2c=138779165123331=2
> > >
> > > The leak is in i801_probe, caused by an early call to
> > > i2c_set_adapdata() which in turn calls dev_set_drvdata() which
> > > allocates some memory in device_private_init(). That memory is only
> > > freed by the driver core when the i2c_adapter class device is removed.
> > > But if the parent (PCI) device probing itself fails for whatever
> > > reason, the class device never gets to be created, so it's never
> > > removed, thus the memory is never freed.
> > >
> > > It is not possible to move the call to i2c_set_adapdata() until after
> > > the class device is created, because the data pointed is needed very
> > > early after (almost during) i2c adapter creation. So I could make the
> > > leak less likely to happen but I can't fix it completely.
> >
> > I don't understand, what exactly is leaking? You have control over your
> > own structures, so can't you clean things up on the error path if you
> > know something went wrong?
>
> I do, but I can only care for memory I allocated myself, not the memory
> allocated by the driver core.
>
> > > I am wondering how this can be solved, and this brought three questions:
> > >
> > > 1* What is the rationale for allocating dev->p dynamically? It is
> > > allocated as soon as the device is created (in device_add), so as far
> > > as I can see every device will need the allocation. Including struct
> > > device_private in struct device would not cost more memory, plus it
> > > would reduce memory fragmentation. So is this a lifetime issue? Or
> > > something else I can't think of?
> >
> > I did it to keep things that non-driver-core code should not be
> > touching. Previously, lots of people messed around with the device
> > private fields that could confuse the driver core. Ideally, I'd like to
> > be able to move the kobject itself into this structure, to allow devices
> > to handle static initialization better, but that never happened, unlike
> > other driver core structures.
> >
> > > 2* What is the rationale for making void *driver_data part of struct
> > > device_private and not struct device itself?
> >
> > To "hide" information / details that non-driver core code should not
> > care about or touch.
>
> This is a respectable goal, but I'm unsure it's worth the price...
>
> > > 3* If the current implementation is considered correct, does it mean
> > > that dev_set_drvdata() should never be used for class devices?
> >
> > No, it should be fine, I don't understand the issue with your usage that
> > is causing the problem, care to explain it better, or point me at some
> > code?
>
> Sorry I wasn't clear. Let me guide you step by step with the real-world
> example that caused me to look into this. It all starts in
> drivers/i2c/busses/i2c-i801.c, function i801_probe(). This is a driver
> for a PCI device implementing an SMBus controller (aka i2c_adapter.)
>
> static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
> {
> int err;
> struct i801_priv *priv;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> i2c_set_adapdata(>adapter, priv);
>
> So we allocate private data for the i2c_adapter we're about to create.
> i2c_set_adapdata() is a wrapper around dev_set_drvdata() for class
> devices of type i2c_adapter. If everything goes well, we would end up
> doing:
>
> err = i2c_add_adapter(>adapter);
>
> and everything would be fine. However, there are a number of things
> that can go wrong in between, for example if an ACPI resource conflict
> is detected:
>
> err = acpi_check_resource_conflict(>resource[SMBBAR]);
> if (err) {
> err = -ENODEV;
> goto exit;
> }
>
> (...)
> exit:
> kfree(priv);
> return err;
> }
>
> As you can see, we properly free the memory we allocated ourselves for
> the i2c_adapter's data on the error path. You'd think we're alright
> then, but we're not. The problem is that i2c_set_adapdata() indirectly
> allocated some memory:
>
> static inline void i2c_set_adapdata(struct i2c_adapter *dev, void *data)
> {
> dev_set_drvdata(>dev, data);
> }
>
> int dev_set_drvdata(struct device *dev, void *data)
> {
> int error;
>
> if (!dev->p) {
> error = device_private_init(dev);
> if (error)
> return error;
> }
> dev->p->driver_data = data;
> return 0;
> }
>
> int device_private_init(struct device *dev)
> {
> dev->p = kzalloc(sizeof(*dev->p), GFP_KERNEL);
> (...)
> }
>
> In the success case, it's fine because the memory gets freed at device
>
Donation!
My wife and I won £148m on the Euromillions lottery & will be donating £1.5 Million each to you and four other individuals in our ongoing charity project, get back to us for more details on how you can receieve your donation. See article for more info - http://www.bbc.co.uk/news/uk-england-19254228 Best regards, Adrian & Gillian Bayford -- 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/rfc] perf on raspberry-pi without overflow interrupt
On Thu, 9 Jan 2014, Will Deacon wrote:
> I'd rather see it in the generic code if at all possible. Maybe we could add
> a flags field to perf_pmu_register?
I can look into adding the check in generic code.
In the meantime, would you consider a patch like this that disables
the IRQ check and lets ARM devices missing an IRQ (such as the rasp-pi)
still have access to the counters?
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index d85055c..ff1a752 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -97,8 +97,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu,
irq_handler_t handler)
irqs = min(pmu_device->num_resources, num_possible_cpus());
if (irqs < 1) {
- pr_err("no irqs for PMUs defined\n");
- return -ENODEV;
+ printk_once("no irqs for PMUs defined, sampling events not
supported\n");
+ return 0;
}
for (i = 0; i < irqs; ++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] Staging: comedi: fix spacing coding style issue in 8255.c.
This patch for 8255.c fixes a spacing warning found by checkpatch.pl.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/8255.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/8255.c
b/drivers/staging/comedi/drivers/8255.c
index b4009e8..48817f0 100644
--- a/drivers/staging/comedi/drivers/8255.c
+++ b/drivers/staging/comedi/drivers/8255.c
@@ -94,7 +94,7 @@ I/O port base address can be found in the output of 'lspci
-v'.
struct subdev_8255_private {
unsigned long iobase;
- int (*io) (int, int, int, unsigned long);
+ int (*io)(int, int, int, unsigned long);
};
static int subdev_8255_io(int dir, int port, int data, unsigned long iobase)
@@ -262,7 +262,7 @@ static int subdev_8255_cancel(struct comedi_device *dev,
}
int subdev_8255_init(struct comedi_device *dev, struct comedi_subdevice *s,
-int (*io) (int, int, int, unsigned long),
+int (*io)(int, int, int, unsigned long),
unsigned long iobase)
{
struct subdev_8255_private *spriv;
@@ -289,7 +289,7 @@ int subdev_8255_init(struct comedi_device *dev, struct
comedi_subdevice *s,
EXPORT_SYMBOL_GPL(subdev_8255_init);
int subdev_8255_init_irq(struct comedi_device *dev, struct comedi_subdevice *s,
-int (*io) (int, int, int, unsigned long),
+int (*io)(int, int, int, unsigned long),
unsigned long iobase)
{
int ret;
--
1.8.4.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] acpi memory hotplug, add parameter to disable memory hotplug for kexec
(2014/01/10 6:44), Vivek Goyal wrote: On Thu, Jan 09, 2014 at 04:34:16PM -0500, KOSAKI Motohiro wrote: On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal wrote: On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote: [..] The system then panics and the kdump/kexec kernel boots. During this boot ACPi is initialized and the kernel (as can be seen above) Which is a bug. You're not supposed to initialize ACPI twice in a row. [CC lkml, kexec mailing list, dave young] It is a fresh instance of kernel booting and it is initializing its data structures fresh. It is *not* re-initializing ACPI in same kernel. This patchset resolves the problem by adding a kernel parameter, no_memory_hotplug, to disable ACPI memory hotplug. It can be added by default as a parameter to the kexec/kdump kernel so the kernel boots correctly. This problem is specific to kexec/kdump, so please don't add *generic* command line parameters to address this. There are other command line options to solve kdump problems. In general one might want to disable memory hogplug on the fly even if it is compiled in the kernel. So it can act as a good debugging aid. Secondly, it can be specified with memmap=exactmap and mem=X paramters to make sure no memory is hot added in the system. So I can see other usages of this parameter. To me it makes sense to have a separate command line option to disable memory hotplug feature on the fly. I'm ok this option. But note, even if this option is specified, SH, Power and S390 still be able to use memory hotplug because their firmware are totally different from ACPI. Maybe, adding acpi prefix provides good clarification. Makes sense. Something like "acpi_no_memhotplug" or "acpi_disable_memhotplug" or something else. I like Prarit's patch and the boot option name. If it is updated, I'll test it. Thanks, Yasuaki Ishimatsu Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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/
[PATCH v3 6/6] arm64: add early_ioremap support
Add support for early IO or memory mappings which are needed
before the normal ioremap() is usable. This also adds fixmap
support for permanent fixed mappings such as that used by the
earlyprintk device register region.
Signed-off-by: Mark Salter
CC: linux-arm-ker...@lists.infradead.org
CC: Catalin Marinas
CC: Will Deacon
---
Documentation/arm64/memory.txt | 4 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/fixmap.h | 68
arch/arm64/include/asm/io.h | 1 +
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/kernel/early_printk.c | 8 +++-
arch/arm64/kernel/head.S | 9 ++---
arch/arm64/kernel/setup.c| 2 +
arch/arm64/mm/ioremap.c | 85
arch/arm64/mm/mmu.c | 41 ---
11 files changed, 170 insertions(+), 52 deletions(-)
create mode 100644 arch/arm64/include/asm/fixmap.h
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 5e054bf..953c81e 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,7 +35,7 @@ ffbc ffbd 8GB
vmemmap
ffbe ffbffbbf ~8GB [guard, future
vmmemap]
-ffbffbc0 ffbffbdf 2MB earlyprintk
device
+ffbffbc0 ffbffbdf 2MB fixed mappings
ffbffbe0 ffbffbe0 64KB PCI I/O space
@@ -60,7 +60,7 @@ fdfc fdfd 8GB
vmemmap
fdfe fdfffbbf ~8GB [guard, future
vmmemap]
-fdfffbc0 fdfffbdf 2MB earlyprintk
device
+fdfffbc0 fdfffbdf 2MB fixed mappings
fdfffbe0 fdfffbe0 64KB PCI I/O space
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d4dd22..e66a317 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select CLONE_BACKWARDS
select COMMON_CLK
select GENERIC_CLOCKEVENTS
+ select GENERIC_EARLY_IOREMAP
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 519f89f..b7f99a3 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -10,6 +10,7 @@ generic-y += delay.h
generic-y += div64.h
generic-y += dma.h
generic-y += emergency-restart.h
+generic-y += early_ioremap.h
generic-y += errno.h
generic-y += ftrace.h
generic-y += hw_irq.h
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
new file mode 100644
index 000..7ad4f29
--- /dev/null
+++ b/arch/arm64/include/asm/fixmap.h
@@ -0,0 +1,68 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ * Copyright (C) 2013 Mark Salter
+ *
+ * Adapted from arch/x86_64 version.
+ *
+ */
+
+#ifndef _ASM_ARM64_FIXMAP_H
+#define _ASM_ARM64_FIXMAP_H
+
+#ifndef __ASSEMBLY__
+#include
+#include
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process.
+ *
+ * These 'compile-time allocated' memory buffers are
+ * page-sized. Use set_fixmap(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ */
+enum fixed_addresses {
+ FIX_EARLYCON,
+ __end_of_permanent_fixed_addresses,
+
+ /*
+* Temporary boot-time mappings, used by early_ioremap(),
+* before ioremap() is functional.
+*/
+#ifdef CONFIG_ARM64_64K_PAGES
+#define NR_FIX_BTMAPS 4
+#else
+#define NR_FIX_BTMAPS 64
+#endif
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1,
+ __end_of_fixed_addresses
+};
+
+#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
+
+#define FIXMAP_PAGE_NORMAL PAGE_KERNEL_EXEC
+#define FIXMAP_PAGE_IO __pgprot(PROT_DEVICE_nGnRE)
+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define __set_fixmap __early_set_fixmap
+
+#include
+
+#endif /* !__ASSEMBLY__ */
+#endif /* _ASM_ARM64_FIXMAP_H */
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index
[PATCH v3 2/6] mm: create generic early_ioremap() support
This patch creates a generic implementation of early_ioremap() support
based on the existing x86 implementation. early_ioremp() is useful for
early boot code which needs to temporarily map I/O or memory regions
before normal mapping functions such as ioremap() are available.
Signed-off-by: Mark Salter
Acked-by: Catalin Marinas
CC: x...@kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: Andrew Morton
CC: Arnd Bergmann
CC: Ingo Molnar
CC: Thomas Gleixner
CC: "H. Peter Anvin"
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
---
include/asm-generic/early_ioremap.h | 41 ++
mm/Kconfig | 3 +
mm/Makefile | 1 +
mm/early_ioremap.c | 249
4 files changed, 294 insertions(+)
create mode 100644 include/asm-generic/early_ioremap.h
create mode 100644 mm/early_ioremap.c
diff --git a/include/asm-generic/early_ioremap.h
b/include/asm-generic/early_ioremap.h
new file mode 100644
index 000..d43e187
--- /dev/null
+++ b/include/asm-generic/early_ioremap.h
@@ -0,0 +1,41 @@
+#ifndef _ASM_EARLY_IOREMAP_H_
+#define _ASM_EARLY_IOREMAP_H_
+
+#include
+
+#ifdef CONFIG_GENERIC_EARLY_IOREMAP
+/*
+ * early_ioremap() and early_iounmap() are for temporary early boot-time
+ * mappings, before the real ioremap() is functional.
+ */
+extern void __iomem *early_ioremap(resource_size_t phys_addr,
+ unsigned long size);
+extern void *early_memremap(resource_size_t phys_addr,
+ unsigned long size);
+extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
+
+/* Arch-specific initialization */
+extern void early_ioremap_init(void);
+
+/* Generic initialization called by architecture code */
+extern void early_ioremap_setup(void);
+
+/*
+ * Called as last step in paging_init() so library can act
+ * accordingly for subsequent map/unmap requests.
+ */
+extern void early_ioremap_reset(void);
+
+/*
+ * Weak function called by early_ioremap_reset(). It does nothing, but
+ * architectures may provide their own version to do any needed cleanups.
+ */
+extern void early_ioremap_shutdown(void);
+#else
+static inline void early_ioremap_init(void) { }
+static inline void early_ioremap_setup(void) { }
+static inline void early_ioremap_reset(void) { }
+#endif
+
+#endif /* _ASM_EARLY_IOREMAP_H_ */
diff --git a/mm/Kconfig b/mm/Kconfig
index 723bbe0..0dcebf2a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -552,3 +552,6 @@ config MEM_SOFT_DIRTY
it can be cleared by hands.
See Documentation/vm/soft-dirty.txt for more details.
+
+config GENERIC_EARLY_IOREMAP
+ bool
diff --git a/mm/Makefile b/mm/Makefile
index 305d10a..4e102e9 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
obj-$(CONFIG_CLEANCACHE) += cleancache.o
obj-$(CONFIG_MEMORY_ISOLATION) += page_isolation.o
obj-$(CONFIG_ZBUD) += zbud.o
+obj-$(CONFIG_GENERIC_EARLY_IOREMAP) += early_ioremap.o
diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c
new file mode 100644
index 000..8c1ac48
--- /dev/null
+++ b/mm/early_ioremap.c
@@ -0,0 +1,249 @@
+/*
+ * Provide common bits of early_ioremap() support for architectures needing
+ * temporary mappings during boot before ioremap() is available.
+ *
+ * This is mostly a direct copy of the x86 early_ioremap implementation.
+ *
+ * (C) Copyright 1995 1996 Linus Torvalds
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int early_ioremap_debug __initdata;
+
+static int __init early_ioremap_debug_setup(char *str)
+{
+ early_ioremap_debug = 1;
+
+ return 0;
+}
+early_param("early_ioremap_debug", early_ioremap_debug_setup);
+
+static int after_paging_init __initdata;
+
+void __init __attribute__((weak)) early_ioremap_shutdown(void)
+{
+}
+
+void __init early_ioremap_reset(void)
+{
+ early_ioremap_shutdown();
+ after_paging_init = 1;
+}
+
+/*
+ * Generally, ioremap() is available after paging_init() has been called.
+ * Architectures wanting to allow early_ioremap after paging_init() can
+ * define __late_set_fixmap and __late_clear_fixmap to do the right thing.
+ */
+#ifndef __late_set_fixmap
+static inline void __init __late_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t prot)
+{
+ BUG();
+}
+#endif
+
+#ifndef __late_clear_fixmap
+static inline void __init __late_clear_fixmap(enum fixed_addresses idx)
+{
+ BUG();
+}
+#endif
+
+static void __iomem *prev_map[FIX_BTMAPS_SLOTS] __initdata;
+static unsigned long prev_size[FIX_BTMAPS_SLOTS] __initdata;
+static unsigned long slot_virt[FIX_BTMAPS_SLOTS] __initdata;
+
+void __init early_ioremap_setup(void)
+{
+ int i;
+
+ for (i = 0; i < FIX_BTMAPS_SLOTS; i++) {
+ if (prev_map[i]) {
+
[PATCH v3 0/6] generic early_ioremap support
This patch series takes the common bits from the x86 early ioremap implementation and creates a generic implementation which may be used by other architectures. The early ioremap interfaces are intended for situations where boot code needs to make temporary virtual mappings before the normal ioremap interfaces are available. Typically, this means before paging_init() has run. These patches are layered on top of generic fixmap patches which were discussed here (and are in the akpm tree): http://lkml.org/lkml/2013/11/25/474 This is version 3 of the patch series. These patches (and underlying fixmap patches) may be found at: git://github.com/mosalter/linux.git (early-ioremap-v3 branch) Changes from version 2: * Added some Acks * Incorporated a patch from Dave Young to change the signature of early_memremap() (dropping __iomem from returned pointer) which is the first patch in a larger series: https://lkml.org/lkml/2013/12/22/69 This allows the change of just the x86 function signature to be bisected. Changes from version 1: * Moved the generic code into linux/mm instead of linux/lib * Have early_memremap() return normal pointer instead of __iomem This is in response to sparse warning cleanups being made in an unrelated patch series: https://lkml.org/lkml/2013/12/22/69 * Added arm64 patch to call init_mem_pgprot() earlier so that the pgprot macros are valid in time for early_ioremap use * Added validity checking for early_ioremap pgd, pud, and pmd in arm64 Dave Young (1): x86/mm: sparse warning fix for early_memremap Mark Salter (5): mm: create generic early_ioremap() support x86: use generic early_ioremap arm: add early_ioremap support arm64: initialize pgprot info earlier in boot arm64: add early_ioremap support Documentation/arm64/memory.txt | 4 +- arch/arm/Kconfig| 11 ++ arch/arm/include/asm/Kbuild | 1 + arch/arm/include/asm/fixmap.h | 18 +++ arch/arm/include/asm/io.h | 1 + arch/arm/kernel/setup.c | 3 + arch/arm/mm/Makefile| 1 + arch/arm/mm/early_ioremap.c | 93 ++ arch/arm/mm/mmu.c | 2 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/Kbuild | 1 + arch/arm64/include/asm/fixmap.h | 68 ++ arch/arm64/include/asm/io.h | 1 + arch/arm64/include/asm/memory.h | 2 +- arch/arm64/include/asm/mmu.h| 1 + arch/arm64/kernel/early_printk.c| 8 +- arch/arm64/kernel/head.S| 9 +- arch/arm64/kernel/setup.c | 4 + arch/arm64/mm/ioremap.c | 85 arch/arm64/mm/mmu.c | 44 +-- arch/x86/Kconfig| 1 + arch/x86/include/asm/Kbuild | 1 + arch/x86/include/asm/fixmap.h | 6 + arch/x86/include/asm/io.h | 14 +- arch/x86/mm/ioremap.c | 224 +--- arch/x86/mm/pgtable_32.c| 2 +- include/asm-generic/early_ioremap.h | 41 ++ mm/Kconfig | 3 + mm/Makefile | 1 + mm/early_ioremap.c | 249 30 files changed, 611 insertions(+), 289 deletions(-) create mode 100644 arch/arm/mm/early_ioremap.c create mode 100644 arch/arm64/include/asm/fixmap.h create mode 100644 include/asm-generic/early_ioremap.h create mode 100644 mm/early_ioremap.c -- 1.8.3.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/
[PATCH v3 5/6] arm64: initialize pgprot info earlier in boot
Presently, paging_init() calls init_mem_pgprot() to initialize pgprot
values used by macros such as PAGE_KERNEL, PAGE_KERNEL_EXEC, etc. The
new fixmap and early_ioremap support also needs to use these macros
before paging_init() is called. This patch moves the init_mem_pgprot()
call out of paging_init() and into setup_arch() so that pgprot_default
gets initialized in time for fixmap and early_ioremap.
Signed-off-by: Mark Salter
CC: linux-arm-ker...@lists.infradead.org
CC: Catalin Marinas
CC: Will Deacon
---
arch/arm64/include/asm/mmu.h | 1 +
arch/arm64/kernel/setup.c| 2 ++
arch/arm64/mm/mmu.c | 3 +--
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 2494fc0..f600d40 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -27,5 +27,6 @@ typedef struct {
extern void paging_init(void);
extern void setup_mm_for_reboot(void);
extern void __iomem *early_io_map(phys_addr_t phys, unsigned long virt);
+extern void init_mem_pgprot(void);
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..029ecfe 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -221,6 +221,8 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
+ init_mem_pgprot();
+
parse_early_param();
arm64_memblock_init();
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f557ebb..541c782 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -125,7 +125,7 @@ early_param("cachepolicy", early_cachepolicy);
/*
* Adjust the PMD section entries according to the CPU in use.
*/
-static void __init init_mem_pgprot(void)
+void __init init_mem_pgprot(void)
{
pteval_t default_pgprot;
int i;
@@ -349,7 +349,6 @@ void __init paging_init(void)
{
void *zero_page;
- init_mem_pgprot();
map_mem();
/*
--
1.8.3.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/
[PATCH v3 4/6] arm: add early_ioremap support
This patch uses the generic early_ioremap code to implement
early_ioremap for ARM. The ARM-specific bits come mostly from
an earlier patch from Leif Lindholm
here:
https://lkml.org/lkml/2013/10/3/279
Signed-off-by: Mark Salter
Tested-by: Leif Lindholm
Acked-by: Catalin Marinas
CC: linux-arm-ker...@lists.infradead.org
CC: Russell King
CC: Catalin Marinas
CC: Will Deacon
CC: Arnd Bergmann
---
arch/arm/Kconfig | 11 +
arch/arm/include/asm/Kbuild | 1 +
arch/arm/include/asm/fixmap.h | 18 +
arch/arm/include/asm/io.h | 1 +
arch/arm/kernel/setup.c | 3 ++
arch/arm/mm/Makefile | 1 +
arch/arm/mm/early_ioremap.c | 93 +++
arch/arm/mm/mmu.c | 2 +
8 files changed, 130 insertions(+)
create mode 100644 arch/arm/mm/early_ioremap.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..78a79a6a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1842,6 +1842,17 @@ config UACCESS_WITH_MEMCPY
However, if the CPU data cache is using a write-allocate mode,
this option is unlikely to provide any performance gain.
+config EARLY_IOREMAP
+ depends on MMU
+ bool "Provide early_ioremap() support for kernel initialization."
+ select GENERIC_EARLY_IOREMAP
+ help
+ Provide a mechanism for kernel initialisation code to temporarily
+ map, in a highmem-agnostic way, memory pages in before ioremap()
+ and friends are available (before paging_init() has run). It uses
+ the same virtual memory range as kmap so all early mappings must
+ be unapped before paging_init() is called.
+
config SECCOMP
bool
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index c38b58c..49ec506 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -4,6 +4,7 @@ generic-y += auxvec.h
generic-y += bitsperlong.h
generic-y += cputime.h
generic-y += current.h
+generic-y += early_ioremap.h
generic-y += emergency-restart.h
generic-y += errno.h
generic-y += exec.h
diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 68ea615..e92b7a4 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -21,8 +21,26 @@ enum fixed_addresses {
FIX_KMAP_BEGIN,
FIX_KMAP_END = (FIXADDR_TOP - FIXADDR_START) >> PAGE_SHIFT,
__end_of_fixed_addresses
+/*
+ * 224 temporary boot-time mappings, used by early_ioremap(),
+ * before ioremap() is functional.
+ *
+ * (P)re-using the FIXADDR region, which is used for highmem
+ * later on, and statically aligned to 1MB.
+ */
+#define NR_FIX_BTMAPS 32
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+#define FIX_BTMAP_END FIX_KMAP_BEGIN
+#define FIX_BTMAP_BEGIN(FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1)
};
+#define FIXMAP_PAGE_NORMAL (L_PTE_MT_WRITEBACK | L_PTE_YOUNG | L_PTE_PRESENT)
+#define FIXMAP_PAGE_IO (L_PTE_MT_DEV_NONSHARED | L_PTE_YOUNG | L_PTE_PRESENT)
+
+extern void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
#include
#endif
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index fbeb39c..6b2cc53 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
/*
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 987a7f5..038fb75 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -887,6 +888,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+ early_ioremap_init();
+
sort(, meminfo.nr_banks, sizeof(meminfo.bank[0]),
meminfo_cmp, NULL);
early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index ecfe6e5..fea855e 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -15,6 +15,7 @@ endif
obj-$(CONFIG_MODULES) += proc-syms.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
+obj-$(CONFIG_EARLY_IOREMAP)+= early_ioremap.o
obj-$(CONFIG_HIGHMEM) += highmem.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/arm/mm/early_ioremap.c b/arch/arm/mm/early_ioremap.c
new file mode 100644
index 000..c3e2bf2
--- /dev/null
+++ b/arch/arm/mm/early_ioremap.c
@@ -0,0 +1,93 @@
+/*
+ * early_ioremap() support for ARM
+ *
+ * Based on existing support in arch/x86/mm/ioremap.c
+ *
+ * Restrictions: currently only functional before paging_init()
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+static pte_t bm_pte[PTRS_PER_PTE] __aligned(PTE_HWTABLE_SIZE)
[PATCH v3 3/6] x86: use generic early_ioremap
Move x86 over to the generic early ioremap implementation.
Signed-off-by: Mark Salter
CC: x...@kernel.org
CC: Andrew Morton
CC: Arnd Bergmann
CC: Ingo Molnar
CC: Thomas Gleixner
CC: "H. Peter Anvin"
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/Kbuild | 1 +
arch/x86/include/asm/fixmap.h | 6 ++
arch/x86/include/asm/io.h | 15 +--
arch/x86/mm/ioremap.c | 228 +-
arch/x86/mm/pgtable_32.c | 2 +-
6 files changed, 13 insertions(+), 240 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0952ecd..50e1eab 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -125,6 +125,7 @@ config X86
select RTC_LIB
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
+ select GENERIC_EARLY_IOREMAP
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index 7f66985..203f5f9 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -5,3 +5,4 @@ genhdr-y += unistd_64.h
genhdr-y += unistd_x32.h
generic-y += clkdev.h
+generic-y += early_ioremap.h
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 7252cd3..e5f236d 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -177,5 +177,11 @@ static inline void __set_fixmap(enum fixed_addresses idx,
#include
+#define __late_set_fixmap(idx, phys, flags) __set_fixmap(idx, phys, flags)
+#define __late_clear_fixmap(idx) __set_fixmap(idx, 0, __pgprot(0))
+
+void __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_X86_FIXMAP_H */
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 1db414f..aae7010 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
@@ -316,20 +317,6 @@ extern int ioremap_change_attr(unsigned long vaddr,
unsigned long size,
unsigned long prot_val);
extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
-/*
- * early_ioremap() and early_iounmap() are for temporary early boot-time
- * mappings, before the real ioremap() is functional.
- * A boot-time mapping is currently limited to at most 16 pages.
- */
-extern void early_ioremap_init(void);
-extern void early_ioremap_reset(void);
-extern void __iomem *early_ioremap(resource_size_t phys_addr,
- unsigned long size);
-extern void *early_memremap(resource_size_t phys_addr,
- unsigned long size);
-extern void early_iounmap(void __iomem *addr, unsigned long size);
-extern void early_memunmap(void *addr, unsigned long size);
-extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
#ifdef CONFIG_XEN
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index bbb4504..597ac15 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -328,17 +328,6 @@ void unxlate_dev_mem_ptr(unsigned long phys, void *addr)
return;
}
-static int __initdata early_ioremap_debug;
-
-static int __init early_ioremap_debug_setup(char *str)
-{
- early_ioremap_debug = 1;
-
- return 0;
-}
-early_param("early_ioremap_debug", early_ioremap_debug_setup);
-
-static __initdata int after_paging_init;
static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __page_aligned_bss;
static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
@@ -362,18 +351,11 @@ bool __init is_early_ioremap_ptep(pte_t *ptep)
return ptep >= _pte[0] && ptep < _pte[PAGE_SIZE/sizeof(pte_t)];
}
-static unsigned long slot_virt[FIX_BTMAPS_SLOTS] __initdata;
-
void __init early_ioremap_init(void)
{
pmd_t *pmd;
- int i;
- if (early_ioremap_debug)
- printk(KERN_INFO "early_ioremap_init()\n");
-
- for (i = 0; i < FIX_BTMAPS_SLOTS; i++)
- slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS*i);
+ early_ioremap_setup();
pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
memset(bm_pte, 0, sizeof(bm_pte));
@@ -402,13 +384,8 @@ void __init early_ioremap_init(void)
}
}
-void __init early_ioremap_reset(void)
-{
- after_paging_init = 1;
-}
-
-static void __init __early_set_fixmap(enum fixed_addresses idx,
- phys_addr_t phys, pgprot_t flags)
+void __init __early_set_fixmap(enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags)
{
unsigned long addr = __fix_to_virt(idx);
pte_t *pte;
@@ -425,202 +402,3 @@ static void __init __early_set_fixmap(enum
fixed_addresses idx,
[PATCH v3 1/6] x86/mm: sparse warning fix for early_memremap
From: Dave Young
There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);
early_memremap intend to map kernel memory with ioremap facility, the return
pointer should be a kernel ram pointer instead of iomem one.
For making the function clearer and supressing sparse warnings this patch
do below two things:
1. cast to (__force void *) for the return value of early_memremap
2. add early_memunmap function and pass (__force void __iomem *) to iounmap
>From Boris:
> Ingo told me yesterday, it makes sense too. I'd guess we can try it.
> FWIW, all callers of early_memremap use the memory they get remapped as
> normal memory so we should be safe.
Signed-off-by: Dave Young
Signed-off-by: Mark Salter
---
arch/x86/include/asm/io.h | 3 ++-
arch/x86/mm/ioremap.c | 10 +++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34f69cb..1db414f 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -325,9 +325,10 @@ extern void early_ioremap_init(void);
extern void early_ioremap_reset(void);
extern void __iomem *early_ioremap(resource_size_t phys_addr,
unsigned long size);
-extern void __iomem *early_memremap(resource_size_t phys_addr,
+extern void *early_memremap(resource_size_t phys_addr,
unsigned long size);
extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void early_memunmap(void *addr, unsigned long size);
extern void fixup_early_ioremap(void);
extern bool is_early_ioremap_ptep(pte_t *ptep);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580c..bbb4504 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -562,10 +562,9 @@ early_ioremap(resource_size_t phys_addr, unsigned long
size)
}
/* Remap memory */
-void __init __iomem *
-early_memremap(resource_size_t phys_addr, unsigned long size)
+void __init *early_memremap(resource_size_t phys_addr, unsigned long size)
{
- return __early_ioremap(phys_addr, size, PAGE_KERNEL);
+ return (__force void *)__early_ioremap(phys_addr, size, PAGE_KERNEL);
}
void __init early_iounmap(void __iomem *addr, unsigned long size)
@@ -620,3 +619,8 @@ void __init early_iounmap(void __iomem *addr, unsigned long
size)
}
prev_map[slot] = NULL;
}
+
+void __init early_memunmap(void *addr, unsigned long size)
+{
+ early_iounmap((__force void __iomem *)addr, size);
+}
--
1.8.3.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/
[PATCH 2/2] ion: Add carveout and chunk heaps to dummy driver
Add support to the dummy driver for basic carveout and chunk heaps.
Since we're generating these heaps at module_init, and we want
this driver to be generic enough to be tested on any arch, we
don't have the ability to alloc bootmem, so both of these heaps
are conventionally allocated using alloc_pages(), which limits us
to 4M in size.
Should look into using CMA for heap allocation eventually, but
this provides enough to test the basic functionality of the
heaps.
Cc: Colin Cross
Cc: Greg KH
Cc: Jesse Barker
Cc: Android Kernel Team
Signed-off-by: John Stultz
---
drivers/staging/android/ion/ion_dummy_driver.c | 67 +-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_dummy_driver.c
b/drivers/staging/android/ion/ion_dummy_driver.c
index 6749d29..55b2002 100644
--- a/drivers/staging/android/ion/ion_dummy_driver.c
+++ b/drivers/staging/android/ion/ion_dummy_driver.c
@@ -26,6 +26,9 @@
struct ion_device *idev;
struct ion_heap **heaps;
+void *carveout_ptr;
+void *chunk_ptr;
+
struct ion_platform_heap dummy_heaps[] = {
{
.id = ION_HEAP_TYPE_SYSTEM,
@@ -37,10 +40,24 @@ struct ion_platform_heap dummy_heaps[] = {
.type = ION_HEAP_TYPE_SYSTEM_CONTIG,
.name = "system contig",
},
+ {
+ .id = ION_HEAP_TYPE_CARVEOUT,
+ .type = ION_HEAP_TYPE_CARVEOUT,
+ .name = "carveout",
+ .size = SZ_4M,
+ },
+ {
+ .id = ION_HEAP_TYPE_CHUNK,
+ .type = ION_HEAP_TYPE_CHUNK,
+ .name = "chunk",
+ .size = SZ_4M,
+ .align = SZ_16K,
+ .priv = (void *)(SZ_16K),
+ },
};
struct ion_platform_data dummy_ion_pdata = {
- .nr = 2,
+ .nr = 4,
.heaps = dummy_heaps,
};
@@ -54,9 +71,36 @@ static int __init ion_dummy_init(void)
if (!heaps)
return PTR_ERR(heaps);
+
+ /* Allocate a dummy carveout heap */
+ carveout_ptr = alloc_pages_exact(
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size,
+ GFP_KERNEL);
+ if (carveout_ptr)
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].base =
+ virt_to_phys(carveout_ptr);
+ else
+ pr_err("ion_dummy: Could not allocate carveout\n");
+
+ /* Allocate a dummy chunk heap */
+ chunk_ptr = alloc_pages_exact(
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size,
+ GFP_KERNEL);
+ if (chunk_ptr)
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].base = virt_to_phys(chunk_ptr);
+ else
+ pr_err("ion_dummy: Could not allocate chunk\n");
+
for (i = 0; i < dummy_ion_pdata.nr; i++) {
struct ion_platform_heap *heap_data = _ion_pdata.heaps[i];
+ if (heap_data->type == ION_HEAP_TYPE_CARVEOUT &&
+ !heap_data->base)
+ continue;
+
+ if (heap_data->type == ION_HEAP_TYPE_CHUNK && !heap_data->base)
+ continue;
+
heaps[i] = ion_heap_create(heap_data);
if (IS_ERR_OR_NULL(heaps[i])) {
err = PTR_ERR(heaps[i]);
@@ -72,6 +116,16 @@ err:
}
kfree(heaps);
+ if (carveout_ptr) {
+ free_pages_exact(carveout_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
+ carveout_ptr = NULL;
+ }
+ if (chunk_ptr) {
+ free_pages_exact(chunk_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
+ chunk_ptr = NULL;
+ }
return err;
}
@@ -85,6 +139,17 @@ static void __exit ion_dummy_exit(void)
ion_heap_destroy(heaps[i]);
kfree(heaps);
+ if (carveout_ptr) {
+ free_pages_exact(carveout_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
+ carveout_ptr = NULL;
+ }
+ if (chunk_ptr) {
+ free_pages_exact(chunk_ptr,
+ dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
+ chunk_ptr = NULL;
+ }
+
return;
}
--
1.8.3.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 1/2] ion: Add dummy driver for testing
Provide a basic dummy driver to register the ion device
and to install basic SYSTEM and SYSTEM_CONTIG heaps.
This allows for basic testing with ION without having
access to drivers or systems that have been enabled to use
ION.
Cc: Colin Cross
Cc: Greg KH
Cc: Jesse Barker
Cc: Android Kernel Team
Signed-off-by: John Stultz
---
drivers/staging/android/ion/Kconfig| 10 +++
drivers/staging/android/ion/Makefile | 3 +
drivers/staging/android/ion/ion_dummy_driver.c | 93 ++
3 files changed, 106 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index a9a64ea..a087b19 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,6 +17,16 @@ config ION_TEST
Choose this option to create a device that can be used to test the
kernel and device side ION functions.
+config ION_DUMMY
+ tristate "Dummy Ion driver"
+ depends on ION
+ help
+ Provides a dummy ION driver that registers the
+ /dev/ion device and some basic heaps. This can
+ be used for testing the ION infrastructure if
+ one doesn't have access to hardware drivers that
+ use ION.
+
config ION_TEGRA
tristate "Ion for Tegra"
depends on ARCH_TEGRA && ION
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 75039b9..b56fd2b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,4 +4,7 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
ifdef CONFIG_COMPAT
obj-$(CONFIG_ION) += compat_ion.o
endif
+
+obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
obj-$(CONFIG_ION_TEGRA) += tegra/
+
diff --git a/drivers/staging/android/ion/ion_dummy_driver.c
b/drivers/staging/android/ion/ion_dummy_driver.c
new file mode 100644
index 000..6749d29
--- /dev/null
+++ b/drivers/staging/android/ion/ion_dummy_driver.c
@@ -0,0 +1,93 @@
+/*
+ * drivers/gpu/ion/ion_dummy_driver.c
+ *
+ * Copyright (C) 2013 Linaro, 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 "ion.h"
+#include "ion_priv.h"
+
+struct ion_device *idev;
+struct ion_heap **heaps;
+
+struct ion_platform_heap dummy_heaps[] = {
+ {
+ .id = ION_HEAP_TYPE_SYSTEM,
+ .type = ION_HEAP_TYPE_SYSTEM,
+ .name = "system",
+ },
+ {
+ .id = ION_HEAP_TYPE_SYSTEM_CONTIG,
+ .type = ION_HEAP_TYPE_SYSTEM_CONTIG,
+ .name = "system contig",
+ },
+};
+
+struct ion_platform_data dummy_ion_pdata = {
+ .nr = 2,
+ .heaps = dummy_heaps,
+};
+
+static int __init ion_dummy_init(void)
+{
+ int i, err;
+
+ idev = ion_device_create(NULL);
+ heaps = kzalloc(sizeof(struct ion_heap *) * dummy_ion_pdata.nr,
+ GFP_KERNEL);
+ if (!heaps)
+ return PTR_ERR(heaps);
+
+ for (i = 0; i < dummy_ion_pdata.nr; i++) {
+ struct ion_platform_heap *heap_data = _ion_pdata.heaps[i];
+
+ heaps[i] = ion_heap_create(heap_data);
+ if (IS_ERR_OR_NULL(heaps[i])) {
+ err = PTR_ERR(heaps[i]);
+ goto err;
+ }
+ ion_device_add_heap(idev, heaps[i]);
+ }
+ return 0;
+err:
+ for (i = 0; i < dummy_ion_pdata.nr; i++) {
+ if (heaps[i])
+ ion_heap_destroy(heaps[i]);
+ }
+ kfree(heaps);
+
+ return err;
+}
+
+static void __exit ion_dummy_exit(void)
+{
+ int i;
+
+ ion_device_destroy(idev);
+
+ for (i = 0; i < dummy_ion_pdata.nr; i++)
+ ion_heap_destroy(heaps[i]);
+ kfree(heaps);
+
+ return;
+}
+
+module_init(ion_dummy_init);
+module_exit(ion_dummy_exit);
+
--
1.8.3.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 0/2] ION dummy driver
The ION subsystem requires something register it along with the various heaps that may be available on a system in order to work (Otherwise no /dev/ion is created). This can make it difficult to play with. Thus I've created this simple dummy driver which allocates and registers some basic heaps. I've been using this dummy driver, along with Colin's unit tests and test driver, to be able to validate basic functionality on a number of architectures and it was handy to chase down a few issues before ION was submitted to staging. If you want to play with all of this, Colin's unit tests can be found in AOSP under the system/core/libion directory, but if you want to try to use them in a non-Android environment, I've mirrored that directory and added some changes to get it building under Ubuntu here: https://github.com/johnstultz-work/ion-test Greg: I realize this is after the usual -rc6 cutoff for staging, so no pressure if you want to defer this for 3.15, but I saw you've picked up a few things recently, so I figured I'd send it out so I'm not just sitting on it while we wait for LCA to finish. thanks -john Cc: Colin Cross Cc: Greg KH Cc: Jesse Barker Cc: Android Kernel Team John Stultz (2): ion: Add dummy driver for testing ion: Add carveout and chunk heaps to dummy driver drivers/staging/android/ion/Kconfig| 10 ++ drivers/staging/android/ion/Makefile | 3 + drivers/staging/android/ion/ion_dummy_driver.c | 158 + 3 files changed, 171 insertions(+) create mode 100644 drivers/staging/android/ion/ion_dummy_driver.c -- 1.8.3.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 3/6] [v5] phylib: turn genphy_driver to an array
> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, January 10, 2014 10:45 AM > To: shh@gmail.com > Cc: jg1@samsung.com; mugunthan...@ti.com; f.faine...@gmail.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Xie Shaohui-B21989 > Subject: Re: [PATCH 3/6] [v5] phylib: turn genphy_driver to an array > > > Many of these patches give rejects when I try to apply them to net-next, > you will need to respin this series. > [S.H] These patches were based on Linus's tree. I'll rebase them to the net-next. I'm Sorry for inconvenient! Thank you! Best Regards, Shaohui Xie -- 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 3/3] iscsi-target: Pre-allocate more tags to avoid ack starvation
From: Nicholas Bellinger This patch addresses an traditional iscsi-target fabric ack starvation issue where iscsit_allocate_cmd() -> percpu_ida_alloc_state() ends up hitting slow path percpu-ida code, because iscsit_ack_from_expstatsn() is expected to free ack'ed tags after tag allocation. This is done to take into account the tags waiting to be acknowledged and released in iscsit_ack_from_expstatsn(), but who's number are not directly limited by the CmdSN Window queue_depth being enforced by the target. So that said, this patch bumps up the pre-allocated number of per session tags to: min(queue_depth, ISCSIT_MIN_TAGS * 2) + ISCSIT_EXTRA_TAGS for good measure to avoid the percpu_ida_alloc_state() slow path. Signed-off-by: Nicholas Bellinger --- drivers/target/iscsi/iscsi_target_nego.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/iscsi_target_nego.c b/drivers/target/iscsi/iscsi_target_nego.c index 83c965c..582ba84 100644 --- a/drivers/target/iscsi/iscsi_target_nego.c +++ b/drivers/target/iscsi/iscsi_target_nego.c @@ -1192,7 +1192,7 @@ get_target: */ alloc_tags: tag_num = max_t(u32, ISCSIT_MIN_TAGS, queue_depth); - tag_num += (tag_num / 2) + ISCSIT_EXTRA_TAGS; + tag_num = (tag_num * 2) + ISCSIT_EXTRA_TAGS; tag_size = sizeof(struct iscsi_cmd) + conn->conn_transport->priv_size; ret = transport_alloc_session_tags(sess->se_sess, tag_num, tag_size); -- 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/
[Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400
Robert, is there a patch for this case? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1152484/comments/12 3.10.2 - 3.13.0-0.rc7: ACPI: Low-level resume complete PM: Restoring platform NVS memory microcode: CPU0: new patch_level=0x01c8 Enabling non-boot CPUs ... x86: Booting SMP configuration: smpboot: Booting Node 0 Processor 1 APIC 0x1 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #1 kvm: enabling virtualization on CPU1 process: Switch to broadcast mode on CPU1 microcode: CPU1: new patch_level=0x01c8 CPU1 is up smpboot: Booting Node 0 Processor 2 APIC 0x2 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-0.rc7.git2.2.fc21.x86_64 #1 [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #2 kvm: enabling virtualization on CPU2 process: Switch to broadcast mode on CPU2 microcode: CPU2: new patch_level=0x01c8 CPU2 is up smpboot: Booting Node 0 Processor 3 APIC 0x3 [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #3 kvm: enabling virtualization on CPU3 process: Switch to broadcast mode on CPU3 microcode: CPU3: new patch_level=0x01c8 CPU3 is up ACPI: Waking up from system sleep state S3 poma -- 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 0/3] percpu-ida/iscsi-target: Address connection reset starved tag hang
From: Nicholas Bellinger Hi folks, This short series addresses a bug in >= v3.12 iscsi-target code where a connection reset occuring once percpu_ida_alloc() goes into starved tag uninterruptible sleep mode causes an indefinate hang, due to the SIGINT being ignored that normally forces the sleeping rx thread into connection cleanup state. This includes modifying existing percpu_ida_alloc() to allow an state to be passed so that TASK_INTERRUPTIBLE may be optionally set to address this particular case with iscsi-target, and also includes a simple backwards compatibility wrapper for existing consumers. It also bumps the number of pre-allocated tags by double the allowed per session CmdSN queue_depth in order to avoid the percpu_ida_alloc() straved tags slow path during normal ExpStatSN acknowledgement if at all possible. Thank you, --nab Kent Overstreet (1): percpu_ida: Add tag alloc interface for interruptible sleep Nicholas Bellinger (2): iscsi-target: Fix connection reset hang with percpu_ida_alloc iscsi-target: Pre-allocate more tags to avoid ack starvation drivers/target/iscsi/iscsi_target_nego.c |2 +- drivers/target/iscsi/iscsi_target_util.c |8 ++-- include/linux/percpu_ida.h | 11 ++- lib/percpu_ida.c | 13 + 4 files changed, 26 insertions(+), 8 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/
[PATCH 1/3] percpu_ida: Add tag alloc interface for interruptible sleep
From: Kent Overstreet
This patch adds an tag allocation interface that allows for
interruptible sleep with GFP_KERNEL, instead of always assuming
uninterruptible sleep preventing a signal from being delivered
to a scheduled process context in the tag stealing slow path.
This includes a wrapper for backwards compatiblity with
existing percpu_ida_alloc() consumers.
Signed-off-by: Kent Overstreet
Signed-off-by: Nicholas Bellinger
---
include/linux/percpu_ida.h | 11 ++-
lib/percpu_ida.c | 13 +
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/include/linux/percpu_ida.h b/include/linux/percpu_ida.h
index 1900bd0..bcf31a5 100644
--- a/include/linux/percpu_ida.h
+++ b/include/linux/percpu_ida.h
@@ -3,7 +3,9 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -61,9 +63,16 @@ struct percpu_ida {
/* Max size of percpu freelist, */
#define IDA_DEFAULT_PCPU_SIZE ((IDA_DEFAULT_PCPU_BATCH_MOVE * 3) / 2)
-int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp);
+int percpu_ida_alloc_state(struct percpu_ida *pool, int state);
void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
+static inline int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp)
+{
+ return percpu_ida_alloc_state(pool, (gfp & __GFP_WAIT)
+ ? TASK_UNINTERRUPTIBLE
+ : TASK_RUNNING);
+}
+
void percpu_ida_destroy(struct percpu_ida *pool);
int __percpu_ida_init(struct percpu_ida *pool, unsigned long nr_tags,
unsigned long max_size, unsigned long batch_size);
diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index 9d054bf..58b2268 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -147,7 +147,7 @@ static inline unsigned alloc_local_tag(struct
percpu_ida_cpu *tags)
*
* Will not fail if passed __GFP_WAIT.
*/
-int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp)
+int percpu_ida_alloc_state(struct percpu_ida *pool, int state)
{
DEFINE_WAIT(wait);
struct percpu_ida_cpu *tags;
@@ -174,7 +174,7 @@ int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp)
*
* global lock held and irqs disabled, don't need percpu lock
*/
- prepare_to_wait(>wait, , TASK_UNINTERRUPTIBLE);
+ prepare_to_wait(>wait, , state);
if (!tags->nr_free)
alloc_global_tags(pool, tags);
@@ -191,9 +191,14 @@ int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp)
spin_unlock(>lock);
local_irq_restore(flags);
- if (tag >= 0 || !(gfp & __GFP_WAIT))
+ if (tag >= 0 || state == TASK_RUNNING)
break;
+ if (signal_pending_state(state, current)) {
+ tag = -ERESTARTSYS;
+ break;
+ }
+
schedule();
local_irq_save(flags);
@@ -203,7 +208,7 @@ int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp)
finish_wait(>wait, );
return tag;
}
-EXPORT_SYMBOL_GPL(percpu_ida_alloc);
+EXPORT_SYMBOL_GPL(percpu_ida_alloc_state);
/**
* percpu_ida_free - free a tag
--
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 2/3] iscsi-target: Fix connection reset hang with percpu_ida_alloc
From: Nicholas Bellinger
This patch addresses a bug where connection reset would hang
indefinately when percpu_ida_alloc() was starved for tags,
and always assumed uninterruptible sleep mode.
So now with percpu_ida_alloc_state() available to make
interruptible sleep optional, convert iscsit_allocate_cmd()
to set TASK_INTERRUPTIBLE when GFP_KERNEL is passed, or
set TASK_RUNNING when GFP_ATOMIC is passed.
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target_util.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_util.c
b/drivers/target/iscsi/iscsi_target_util.c
index 0819e68..6cf1d95 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -156,9 +156,13 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
*conn, gfp_t gfp_mask)
{
struct iscsi_cmd *cmd;
struct se_session *se_sess = conn->sess->se_sess;
- int size, tag;
+ int size, tag, state = (gfp_mask & __GFP_WAIT) ? TASK_INTERRUPTIBLE :
+ TASK_RUNNING;
+
+ tag = percpu_ida_alloc_state(_sess->sess_tag_pool, state);
+ if (tag < 0)
+ return NULL;
- tag = percpu_ida_alloc(_sess->sess_tag_pool, gfp_mask);
size = sizeof(struct iscsi_cmd) + conn->conn_transport->priv_size;
cmd = (struct iscsi_cmd *)(se_sess->sess_cmd_map + (tag * size));
memset(cmd, 0, size);
--
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/
