Re: [PATCH 1/1] Input: mma8450 - fix signed 12bits to 32bits conversion
Hi Seb, On Wed, Mar 27, 2013 at 09:17:43AM +0100, seb wrote: > Event value is wrong. Should be in range -2048 to 2047, but is in range 0 to > 4095. > Use int8_t to int conversion and remove 0xfff mask. > > Signed-off-by: seb > --- > drivers/input/misc/mma8450.c | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/input/misc/mma8450.c b/drivers/input/misc/mma8450.c > index 480557f..c3781a1 100644 > --- a/drivers/input/misc/mma8450.c > +++ b/drivers/input/misc/mma8450.c > @@ -110,7 +110,7 @@ static void mma8450_poll(struct input_polled_dev *dev) > struct mma8450 *m = dev->private; > int x, y, z; > int ret; > - u8 buf[6]; > + int8_t buf[6]; > > ret = mma8450_read(m, MMA8450_STATUS); > if (ret < 0) > @@ -119,13 +119,18 @@ static void mma8450_poll(struct input_polled_dev *dev) > if (!(ret & MMA8450_STATUS_ZXYDR)) > return; > > - ret = mma8450_read_block(m, MMA8450_OUT_X_LSB, buf, sizeof(buf)); > + ret = mma8450_read_block(m, MMA8450_OUT_X_LSB, (u8*)buf, sizeof(buf)); > if (ret < 0) > return; > > - x = ((buf[1] << 4) & 0xff0) | (buf[0] & 0xf); > - y = ((buf[3] << 4) & 0xff0) | (buf[2] & 0xf); > - z = ((buf[5] << 4) & 0xff0) | (buf[4] & 0xf); > + /* convert 8 MSB from int8_t to int */ > + x = buf[1]; > + y = buf[3]; > + z = buf[5]; > + /* add 4 LSB */ > + x = (x << 4) | (buf[0] & 0xf); > + y = (y << 4) | (buf[2] & 0xf); > + z = (z << 4) | (buf[4] & 0xf); Should we just say: x = ((int)(s8)buf[1] << 4) | (buf[0] & 0xf); y = ... z = ... and leave the rest as is? Thanks. -- Dmitry -- 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 v4 5/6] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
arch/arm/boot/dts/omap3.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |2 ++
3 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..9324e79 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num_eps = <16>;
ram_bits = <12>;
ctrl-module = <_control_usb>;
+ phys = <_phy>;
+ phy-names = "usb2-phy";
};
Board specific device node entry
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1e21565..dd7d2ff 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -405,6 +405,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <_phy>;
+ phys = <_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 06d044e..b673f0f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -550,6 +550,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <_phy>;
+ phys = <_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
--
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 v4 0/6] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linus tree HEAD. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. Changes from v3: * Changed the return value of PHY APIs to ENOSYS * Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting PHYs if the same IP implements multiple PHYs. * modified phy_bind API so that the binding information can now be _updated_. In effect of this removed the binding information added in board files and added only in usb-musb.c. If a particular board uses a different phy binding, it can update it in board file after usb_musb_init(). * Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding information. Changes from v2: * removed phy_descriptor structure completely so changed the APIs which were taking phy_descriptor as parameters * Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used by PHY user drivers which has *phy* and *phy-names* binding in the dt data * Fixed a few typos * Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and class_dev_iter_exit for traversing through the phy list. (Note we still need phy_bind list and phy_bind_mutex). * Changed the sysfs entry name from *bind* to *phy_bind*. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (6): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information ARM: dts: omap: update usb_otg_hs data usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy | 15 + .../devicetree/bindings/phy/phy-bindings.txt | 76 +++ Documentation/devicetree/bindings/usb/omap-usb.txt |5 + Documentation/phy.txt | 119 MAINTAINERS|7 + arch/arm/boot/dts/omap3.dtsi |2 + arch/arm/boot/dts/omap4.dtsi |2 + arch/arm/mach-omap2/usb-musb.c |7 +- drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 689 drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c| 22 +- drivers/usb/otg/twl4030-usb.c | 36 + drivers/usb/phy/omap-usb2.c| 47 ++ include/linux/phy/phy.h| 237 +++ 18 files changed, 1281 insertions(+), 7 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 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 v4 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/omap-usb2.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..819ba71 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy *x)
+{
+ struct omap_usb *phy = dev_get_drvdata(>dev);
+
+ if (!phy->is_suspended) {
+ omap_control_usb_phy_power(phy->control_dev, 0);
+ pm_runtime_put_sync(phy->dev);
+ phy->is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+ u32 ret;
+ struct omap_usb *phy = dev_get_drvdata(>dev);
+
+ if (phy->is_suspended) {
+ ret = pm_runtime_get_sync(phy->dev);
+ if (ret < 0) {
+ dev_err(phy->dev, "get_sync failed with err %d\n",
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy->control_dev, 1);
+ phy->is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= omap_usb_suspend,
+ .resume = omap_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +184,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type = USB_PHY_TYPE_USB2;
+ generic_phy = devm_phy_create(phy->dev, "omap-usb2", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, , phy);
+ if (IS_ERR(generic_phy)) {
+ dev_dbg(>dev, "Failed to create PHY\n");
+ return PTR_ERR(generic_phy);
+ }
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(>dev, "Failed to get control device\n");
--
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 v4 3/6] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..aebcd6a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -575,10 +576,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl4030_usb_suspend(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(>dev);
+
+ twl4030_phy_suspend(twl, 1);
+
+ return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(>dev);
+
+ if (!twl->asleep)
+ return -EBUSY;
+ __twl4030_phy_resume(twl);
+ twl->asleep = 0;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev->dev.of_node;
@@ -617,6 +646,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
+ phy = devm_phy_create(twl->dev, "twl4030", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, , twl);
+ if (IS_ERR(phy)) {
+ dev_dbg(>dev, "Failed to create PHY\n");
+ return PTR_ERR(phy);
+ }
+
/* init spinlock for workqueue */
spin_lock_init(>lock);
--
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 v4 4/6] ARM: OMAP: USB: Add phy binding information
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/usb-musb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..f01bc42 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "omap_device.h"
#include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+ } else if (cpu_is_omap34xx()) {
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
+ }
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
--
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 v4 1/6] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/ABI/testing/sysfs-class-phy | 15 +
.../devicetree/bindings/phy/phy-bindings.txt | 76 +++
Documentation/phy.txt | 119
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 689
include/linux/phy/phy.h| 237 +++
10 files changed, 1165 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-phy
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/ABI/testing/sysfs-class-phy
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..47f17c9
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What: /sys/class/phy//label
+Date: Feb 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I
+Description:
+ This is a read-only file for getting the label of the phy.
+
+What: /sys/class/phy//phy_bind
+Date: Feb 2013
+KernelVersion: 3.10
+Contact: Kishon Vijay Abraham I
+Description:
+ This is a read-only file for reading the phy binding
+ information. It contains the device name of the controller,
+ the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,76 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Optional Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. However
+ in-order to return the correct PHY, the PHY susbsystem
+ requires the first cell always refers to the port.
+
+This property is optional because it is needed only for the case where a
+single IP implements multiple PHYs.
+
+For example:
+
+phys: phy {
+compatible = "xxx";
+reg1 = <...>;
+reg2 = <...>;
+reg3 = <...>;
+.
+.
+#phy-cells = <1>;
+.
+.
+};
+
+That node describes an IP block that implements 3 different PHYs. In order to
+differentiate between these 3 PHYs, an additonal specifier should be given
+while trying to get a reference to it. (The PHY subsystem assumes the
+specifier is port id).
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example1:
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+phys = <_phy>, <_phy>;
+phy-names = "usb2phy", "usb3phy";
+.
+.
+};
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3. The controller driver can get the appropriate PHY either by using
+devm_of_phy_get/of_phy_get by passing the correct index or by using
+of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
+*phy-names*.
+
+example2:
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+phys = < 1>;
+.
+.
+};
+
+This node represents a controller that uses
[PATCH v4 6/6] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev->parent->of_node)
+ if (dev->parent->of_node) {
+ musb->phy = devm_of_phy_get_byname(dev->parent, "usb2-phy");
+
+ /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
- else
+ } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb->phy = devm_phy_get(dev, 0);
+ }
- if (IS_ERR_OR_NULL(musb->xceiv)) {
- pr_err("HS USB OTG: no transceiver configured\n");
+ if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR_OR_NULL(musb->phy)) {
+ dev_err(dev, "no transceiver configured\n");
return -EPROBE_DEFER;
}
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb->xceiv, 1);
+ phy_suspend(musb->phy);
}
return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
- usb_phy_set_suspend(musb->xceiv, 0);
+ phy_resume(musb->phy);
}
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Generic syscall ABI support
On 03/27/2013 08:09 PM, Ley Foon Tan wrote: > Need advise regarding the generic syscall ABI support. > > We are planning to upstream our Nios II kernel (arch/nios2) to mainline. > But it doesn't support generic syscall ABI yet (It requires an updated > Glibc port as well). > > The question is, is it a requirement for new arch to support generic > syscall ABI when upstreaming? Can we upstream a non-generic syscall ABI > first and migrate to generic syscall ABI in future? > Thanks. > > Regards > LFTAN > That would be extremely difficult. In general, you should use the generic ABI for a new port unless you have *very* strong and convincing reasons not to. Given how long the Nios2 port has been in upstreaming (unfortunate, I like to play with FPGAs ;) it seems worthwhile to adjust it before pushing it. -hpa -- 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] Input: trackpoint - Optimize trackpoint init to use power-on reset
Hi Shawn,
On Tue, Mar 26, 2013 at 12:36:41PM -0700, Shawn Nematbakhsh wrote:
> The trackpoint driver sets various parameter default values, all of
> which happen to be power-on defaults (Source: IBM TrackPoint Engineering
> Specification, Version 4.0. Also confirmed by empirical data).
>
> By sending the power-on reset command to reset all parameters to
> power-on state, we can skip the lengthy process of programming all
> parameters. In testing, ~2.5 secs of time writing parameters was reduced
> to .35 seconds waiting for power-on reset to complete.
>
> Signed-off-by: Shawn Nematbakhsh
> ---
> drivers/input/mouse/trackpoint.c | 223
> +--
> drivers/input/mouse/trackpoint.h | 7 +-
> 2 files changed, 149 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/input/mouse/trackpoint.c
> b/drivers/input/mouse/trackpoint.c
> index f310249..17e9b36 100644
> --- a/drivers/input/mouse/trackpoint.c
> +++ b/drivers/input/mouse/trackpoint.c
> @@ -20,6 +20,26 @@
> #include "trackpoint.h"
>
> /*
> + * Power-on Reset: Resets all trackpoint parameters, including RAM values,
> + * to defaults.
> + * Returns zero on success, non-zero on failure.
> + */
> +static int trackpoint_power_on_reset(struct ps2dev *ps2dev)
> +{
> + unsigned char results[2];
> +
> + if (ps2_command(ps2dev, NULL, MAKE_PS2_CMD(0, 0, TP_COMMAND)) ||
> + ps2_command(ps2dev, results, MAKE_PS2_CMD(0, 2, TP_POR))) {
> + return -1;
> + }
> +
> + /* POR response should be 0xAA00 or 0xFC00 */
> + if ((results[0] != 0xAA && results[0] != 0xFC) || results[1] != 0x00)
> + return -1;
I am a bit concerned about this. 0xfc00 indicates POR failure. In this
case shouldn't we try to reset the device, issue another POR and bail if
it fails again?
>
> static struct attribute *trackpoint_attrs[] = {
> _attr_sensitivity.dattr.attr,
> @@ -179,6 +241,9 @@ static struct attribute *trackpoint_attrs[] = {
> _attr_press_to_select.dattr.attr,
> _attr_skipback.dattr.attr,
> _attr_ext_dev.dattr.attr,
> + _attr_twohand.dattr.attr,
> + _attr_source_tag.dattr.attr,
> + _attr_mb.dattr.attr,
What is the benefit of adding these 3 new attributes?
Thanks.
--
Dmitry
--
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] arm: omap: RX-51: ARM errata 430973 workaround
Tony, Who do you expect to make that code merge? Do you expect us to mechanically merge RX51 PPA API patch with the existing generic OMAP PPA API code putting #ifdefs all over the place? Not that it is impossible, but the only real piece of HW I have here is n900, so I just can't be sure the code will still work on the other platforms besides RX51, once the code modified. Please, advice on how to proceed. Regards, Ivo > Оригинално писмо >От: Tony Lindgren >Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround >До: Pali Rohár >Изпратено на: Сряда, 2013, Март 27 23:12:09 EET > > >* Pali Rohár [130327 14:09]: >> On Wednesday 27 March 2013 21:56:07 Tony Lindgren wrote: >> > * Pali Rohár [130324 07:31]: >> > > it is possible to upstream errata 430973 workaround for >> > > RX-51? >> > >> > I think we should make the SMC handling a generic function for >> > ARM. >> > >> > AFAIK just the SMC call numbering is different for various >> > implementations. So the handler and passing of the parameters >> > seems like it should be generic. >> > >> >> Not only, look at freemangordon's email: >> https://lkml.org/lkml/2013/3/1/62 > >Seem like you may need some SoC specific wrapper to the >generic function to deal with the params. But still seems >like we can have an ARM generic smc funtion. > >Regards, > >Tony > -- 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 Mar 28
Hi all, The next linux-next release will be on Tuesday April 2. Changes since 20130327: The vl4-dvb tree still had its build failure for which I disabled a staging driver. The hid tree gained a conflict against Linus' tree. The net-next tree gained a build failure for which I reverted a commit. The block tree still had its build failure for which I applied a patch. The usb tree gained a build failure for which I reverted a commit. The signal tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. 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. 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. We are up to 222 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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 (9064171 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes) Merging fixes/master (9064171 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes) Merging kbuild-current/rc-fixes (6dbe51c Linux 3.9-rc1) Merging arc-current/for-curr (367f3fc ARC: Fix the typo in event identifier flags used by ptrace) Merging arm-current/fixes (68a154f ARM: 7681/1: hw_breakpoint: use warn_once to avoid spam from reset_ctrl_regs()) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (af81d78 powerpc: Rename USER_ESID_BITS* to ESID_BITS*) Merging sparc/master (53b6809 Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband) Merging net/master (30de83a Merge branch 'fixes-for-3.9' of git://gitorious.org/linux-can/linux-can) Merging ipsec/master (799ef90 xfrm: Fix esn sequence number diff calculation in xfrm_replay_notify_esn()) Merging sound-current/for-linus (55a63d4 ALSA: hda - Fix DAC assignment for independent HP) Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing a device) Merging wireless/master (2e1253d b43: N-PHY: use more bits for offset in RSSI calibration) Merging driver-core.current/driver-core-linus (e5110f4 sysfs: handle failure path correctly for readdir()) Merging tty.current/tty-linus (855f6fd Xilinx: ARM: UART: clear pending irqs before enabling irqs) Merging usb.current/usb-linus (c8fa48d usb: Fix compile error by selecting USB_OTG_UTILS) Merging staging.current/staging-linus (e4317ce8 staging: comedi: s626: fix continuous acquisition) Merging char-misc.current/char-misc-linus (347e089 VMCI: Fix process-to-process DRGAMs.) Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable and disable paths) Merging md-current/for-linus (238f590 md: remove CONFIG_MULTICORE_RAID456 entirely) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (246bbed Revert "crypto: caam - add IPsec ESN support") Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (63662139 params: Fix potential memory leak in add_sysfs_param()) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3
Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell
Date: Thu, 28 Mar 2013 16:04:20 +1100
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> net/packet/af_packet.c: In function 'packet_sendmsg_spkt':
> net/packet/af_packet.c:1515:2: error: implicit declaration of function
> 'skb_probe_transport_header' [-Werror=implicit-function-declaration]
> drivers/net/tun.c: In function 'tun_get_user':
> drivers/net/tun.c:1206:2: error: implicit declaration of function
> 'skb_probe_transport_header' [-Werror=implicit-function-declaration]
>
> Caused by commit 40893fd0fd4e ("net: switch to use
> skb_probe_transport_header()"). This is a 32 bit build, so that
> "BITS_PER_LONG > 32" is false and so NET_SKBUFF_DATA_USES_OFFSET is not
> defined ... and skb_probe_transport_header() is only defined in an area of
> skbuff.h protected by "#ifdef NET_SKBUFF_DATA_USES_OFFSET" :-(
>
> I have reverted that commit for today.
This got fixed about an hour ago :-)
--
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] pinctrl: bcm2835: make use of of_property_read_u32_index()
Use the new standard API of_property_read_u32_index() instead of open-
coding it.
Signed-off-by: Stephen Warren
---
Note: This depends on the proposed patch "of: Add support for reading
a u32 from a multi-value property" by Tony Prisk.
BTW, I realized why I didn't create that standard API, but wrote custom
prop_u32() instead; the code has already looked up the properties, and
validated their length, so prop_u32() can simply index into the property
data, whereas of_property_read_u32_index() needs to go search for the
property and re-validate it every time, so there's a bunch more overhead.
It also means duplicating the property name, although I could use a
define for that. I'm not entirely convinced that using this standard API
is a win in this case. LinusW, Tony, what do you think?
---
drivers/pinctrl/pinctrl-bcm2835.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-bcm2835.c
b/drivers/pinctrl/pinctrl-bcm2835.c
index f28d4b0..c8f20a3 100644
--- a/drivers/pinctrl/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/pinctrl-bcm2835.c
@@ -699,11 +699,6 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct
bcm2835_pinctrl *pc,
return 0;
}
-static inline u32 prop_u32(struct property *p, int i)
-{
- return be32_to_cpup(((__be32 *)p->value) + i);
-}
-
static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
struct device_node *np,
struct pinctrl_map **map, unsigned *num_maps)
@@ -761,7 +756,9 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev
*pctldev,
return -ENOMEM;
for (i = 0; i < num_pins; i++) {
- pin = prop_u32(pins, i);
+ err = of_property_read_u32_index(np, "brcm,pins", i, );
+ if (err)
+ goto out;
if (pin >= ARRAY_SIZE(bcm2835_gpio_pins)) {
dev_err(pc->dev, "%s: invalid brcm,pins value %d\n",
of_node_full_name(np), pin);
@@ -770,14 +767,20 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev
*pctldev,
}
if (num_funcs) {
- func = prop_u32(funcs, (num_funcs > 1) ? i : 0);
+ err = of_property_read_u32_index(np, "brcm,function",
+ (num_funcs > 1) ? i : 0, );
+ if (err)
+ goto out;
err = bcm2835_pctl_dt_node_to_map_func(pc, np, pin,
func, _map);
if (err)
goto out;
}
if (num_pulls) {
- pull = prop_u32(pulls, (num_pulls > 1) ? i : 0);
+ err = of_property_read_u32_index(np, "brcm,pull",
+ (num_funcs > 1) ? i : 0, );
+ if (err)
+ goto out;
err = bcm2835_pctl_dt_node_to_map_pull(pc, np, pin,
pull, _map);
if (err)
--
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/
linux-next: build failure after merge of the final tree (net-next tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
net/packet/af_packet.c: In function 'packet_sendmsg_spkt':
net/packet/af_packet.c:1515:2: error: implicit declaration of function
'skb_probe_transport_header' [-Werror=implicit-function-declaration]
drivers/net/tun.c: In function 'tun_get_user':
drivers/net/tun.c:1206:2: error: implicit declaration of function
'skb_probe_transport_header' [-Werror=implicit-function-declaration]
Caused by commit 40893fd0fd4e ("net: switch to use
skb_probe_transport_header()"). This is a 32 bit build, so that
"BITS_PER_LONG > 32" is false and so NET_SKBUFF_DATA_USES_OFFSET is not
defined ... and skb_probe_transport_header() is only defined in an area of
skbuff.h protected by "#ifdef NET_SKBUFF_DATA_USES_OFFSET" :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5E6pZjGGBR.pgp
Description: PGP signature
Re: [PATCH 6/6] video: fb: vt8500: Convert framebuffer drivers to standardized binding
On Wed, 2013-03-27 at 13:10 +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-03-27 10:47, Tony Prisk wrote:
> > Now that a display timing binding is available, convert our almost identical
> > binding to use the standard binding.
> >
> > This patch converts the vt8500 and wm8505 framebuffer drivers and
> > associated dts/dtsi files to use the standard binding as defined in
> > bindings/video/display-timing.txt.
> >
> > There are two side-effects of making this conversion:
> >
> > 1) The fb node should now be in the board file, rather than the soc file as
> > the display-timing node is a child of the fb node.
> >
> > 2) We still require a bits per pixel property to initialize the framebuffer
> > for the different lcd panels. Rather than including this as part of the
> > display timing, it is moved into the framebuffer node.
> >
> > I have also taken the opportunity to alphabetise the includes of each
> > driver to avoid double-ups.
>
> I don't think this is correct. I don't have that much experience with
> DT, but I think you should have, for example:
>
> wm8850.dtsi:
>
> fb: fb@d8051700 {
> compatible = "wm,wm8505-fb";
> reg = <0xd8051700 0x200>;
> };
>
> wm8850-w70v2.dts:
>
> {
> bits-per-pixel = <16>;
>
> display-timings {
> native-mode = <>;
> timing0: 800x480 {
> clock-frequency = <0>;
> ...
> };
> };
> };
>
> So, the core fb part should be in the SoC's file, as it's part of the
> SoC. And the stuff that tells what kind of display is attached is in the
> board dts file.
>
> Also, just a word of warning, I think the videomode series I've sent for
> review will cause some breakage with this series if the videomode series
> is accepted. Nothing difficult to fix, though, but we'll need some extra
> management to avoid compilation failures.
>
> Tomi
>
>
Thanks for the feedback and the heads-up.
I believe you are correct about the DT info - it looks right when
described the way you did, so I have changed it.
If there is no other feedback, I will post a version 2 after Easter.
Regards
Tony P
--
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: [Bulk] [PATCH] video: fix invalid free of devm_ allocated data
On Thu, 2013-03-28 at 01:55 +0200, Andrei Epure wrote: > The objects allocated by devm_* APIs are managed by devres and are freed when > the device is detached. Hence there is no need to use kfree() explicitly. > Patch found using coccinelle. > > Signed-off-by: Andrei Epure > --- > drivers/video/vt8500lcdfb.c |3 --- > drivers/video/wm8505fb.c|3 --- > 2 files changed, 6 deletions(-) > > diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c > index b4ccca2..ea3ee61 100644 > --- a/drivers/video/vt8500lcdfb.c > +++ b/drivers/video/vt8500lcdfb.c > @@ -465,7 +465,6 @@ failed_free_res: > release_mem_region(res->start, resource_size(res)); > failed_fbi: > platform_set_drvdata(pdev, NULL); > - kfree(fbi); > failed: > return ret; > } > @@ -494,8 +493,6 @@ static int vt8500lcd_remove(struct platform_device *pdev) > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > release_mem_region(res->start, resource_size(res)); > > - kfree(fbi); > - > return 0; > } > > diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c > index 2e8298e..34a2de1 100644 > --- a/drivers/video/wm8505fb.c > +++ b/drivers/video/wm8505fb.c > @@ -427,7 +427,6 @@ failed_free_res: > release_mem_region(res->start, resource_size(res)); > failed_fbi: > platform_set_drvdata(pdev, NULL); > - kfree(fbi); > failed: > return ret; > } > @@ -451,8 +450,6 @@ static int wm8505fb_remove(struct platform_device *pdev) > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > release_mem_region(res->start, resource_size(res)); > > - kfree(fbi); > - > return 0; > } > NACK Already have a patch queued up for this from Julia Lawall Regards Tony P -- 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] video: fixed missing iounmap coccinelle errors
On Thu, 2013-03-28 at 01:43 +0200, Andrei Epure wrote:
> Modified or added the necessary goto statements so that the ioremapped
> regions get unmapped before return.
>
> Signed-off-by: Andrei Epure
> ---
> drivers/video/vt8500lcdfb.c |7 ---
> drivers/video/wm8505fb.c|7 ---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
> index aa2579c..b4ccca2 100644
> --- a/drivers/video/vt8500lcdfb.c
> +++ b/drivers/video/vt8500lcdfb.c
> @@ -350,7 +350,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> if (!np) {
> pr_err("%s: No display description in Device Tree\n", __func__);
> ret = -EINVAL;
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> /*
> @@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> ret |= of_property_read_u32(np, "bpp", );
> if (ret) {
> pr_err("%s: Unable to read display properties\n", __func__);
> - goto failed_free_res;
> + goto failed_free_io;
> }
> of_mode.vmode = FB_VMODE_NONINTERLACED;
>
> @@ -379,7 +379,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!fb_mem_virt) {
> pr_err("%s: Failed to allocate framebuffer\n", __func__);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto failed_free_io;
> };
>
> fbi->fb.fix.smem_start = fb_mem_phys;
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 4dd0580..2e8298e 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -332,7 +332,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
> if (!np) {
> pr_err("%s: No display description in Device Tree\n", __func__);
> ret = -EINVAL;
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> /*
> @@ -351,7 +351,7 @@ static int wm8505fb_probe(struct platform_device *pdev)
> ret |= of_property_read_u32(np, "bpp", );
> if (ret) {
> pr_err("%s: Unable to read display properties\n", __func__);
> - goto failed_free_res;
> + goto failed_free_io;
> }
>
> of_mode.vmode = FB_VMODE_NONINTERLACED;
> @@ -369,7 +369,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!fb_mem_virt) {
> pr_err("%s: Failed to allocate framebuffer\n", __func__);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto failed_free_io;
> };
>
> fbi->fb.var.xres_virtual= of_mode.xres;
NACK
Already have a patch queued up for this from Julia Lawall
Regards
Tony P
--
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] clk: allow reentrant calls into the clk framework
Reentrancy into the clock framework is necessary for clock operations
that result in nested calls to the clk api. A common example is a clock
that is prepared via an i2c transaction, such as a clock inside of a
discrete audio chip or a power management IC. The i2c subsystem itself
will use the clk api resulting in a deadlock:
clk_prepare(audio_clk)
i2c_transfer(..)
clk_prepare(i2c_controller_clk)
The ability to reenter the clock framework prevents this deadlock.
Other use cases exist such as allowing .set_rate callbacks to call
clk_set_parent to achieve the best rate, or to save power in certain
configurations. Yet another example is performing pinctrl operations
from a clk_ops callback. Calls into the pinctrl subsystem may call
clk_{un}prepare on an unrelated clock. Allowing for nested calls to
reenter the clock framework enables both of these use cases.
Reentrancy is implemented by two global pointers that track the owner
currently holding a global lock. One pointer tracks the owner during
sleepable, mutex-protected operations and the other one tracks the owner
during non-interruptible, spinlock-protected operations.
When the clk framework is entered we try to hold the global lock. If it
is held we compare the current task id against the current owner; a
match implies a nested call and we reenter. If the values do not match
then we block on the lock until it is released.
Signed-off-by: Mike Turquette
Cc: Rajagopal Venkat
Cc: David Brown
Cc: Ulf Hansson
Cc: Laurent Pinchart
Cc: Thomas Gleixner
---
Changes since v4:
* remove uneccesary atomic operations
* remove casting bugs
* place reentrancy logic into locking helper functions
* improve debugging with reference counting and WARNs
drivers/clk/clk.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bea47d5..fe7c054 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -19,10 +19,17 @@
#include
#include
#include
+#include
static DEFINE_SPINLOCK(enable_lock);
static DEFINE_MUTEX(prepare_lock);
+static struct task_struct *prepare_owner;
+static struct task_struct *enable_owner;
+
+static int prepare_refcnt;
+static int enable_refcnt;
+
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
@@ -30,21 +37,53 @@ static LIST_HEAD(clk_notifier_list);
/*** locking ***/
static void clk_prepare_lock(void)
{
- mutex_lock(_lock);
+ if (!mutex_trylock(_lock)) {
+ if (prepare_owner == current) {
+ prepare_refcnt++;
+ return;
+ }
+ mutex_lock(_lock);
+ }
+ WARN_ON_ONCE(prepare_owner != NULL);
+ WARN_ON_ONCE(prepare_refcnt != 0);
+ prepare_owner = current;
+ prepare_refcnt = 1;
}
static void clk_prepare_unlock(void)
{
+ WARN_ON_ONCE(prepare_owner != current);
+ WARN_ON_ONCE(prepare_refcnt == 0);
+
+ if (--prepare_refcnt)
+ return;
+ prepare_owner = NULL;
mutex_unlock(_lock);
}
static void clk_enable_lock(unsigned long *flags)
{
- spin_lock_irqsave(_lock, *flags);
+ if (!spin_trylock_irqsave(_lock, *flags)) {
+ if (enable_owner == current) {
+ enable_refcnt++;
+ return;
+ }
+ spin_lock_irqsave(_lock, *flags);
+ }
+ WARN_ON_ONCE(enable_owner != NULL);
+ WARN_ON_ONCE(enable_refcnt != 0);
+ enable_owner = current;
+ enable_refcnt = 1;
}
static void clk_enable_unlock(unsigned long *flags)
{
+ WARN_ON_ONCE(enable_owner != current);
+ WARN_ON_ONCE(enable_refcnt == 0);
+
+ if (--enable_refcnt)
+ return;
+ enable_owner = NULL;
spin_unlock_irqrestore(_lock, *flags);
}
--
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/2] clk: abstract locking out into helper functions
Create locking helpers for the global mutex and global spinlock. The
definitions of these helpers will be expanded upon in the next patch
which introduces reentrancy into the locking scheme.
Signed-off-by: Mike Turquette
Cc: Rajagopal Venkat
Cc: David Brown
Cc: Ulf Hansson
Cc: Laurent Pinchart
Cc: Thomas Gleixner
---
drivers/clk/clk.c | 97 -
1 file changed, 59 insertions(+), 38 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 5e8..bea47d5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -27,6 +27,27 @@ static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
+/*** locking ***/
+static void clk_prepare_lock(void)
+{
+ mutex_lock(_lock);
+}
+
+static void clk_prepare_unlock(void)
+{
+ mutex_unlock(_lock);
+}
+
+static void clk_enable_lock(unsigned long *flags)
+{
+ spin_lock_irqsave(_lock, *flags);
+}
+
+static void clk_enable_unlock(unsigned long *flags)
+{
+ spin_unlock_irqrestore(_lock, *flags);
+}
+
/***debugfs support***/
#ifdef CONFIG_COMMON_CLK_DEBUG
@@ -69,7 +90,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
seq_printf(s, " clockenable_cnt prepare_cnt
rate\n");
seq_printf(s,
"-\n");
- mutex_lock(_lock);
+ clk_prepare_lock();
hlist_for_each_entry(c, _root_list, child_node)
clk_summary_show_subtree(s, c, 0);
@@ -77,7 +98,7 @@ static int clk_summary_show(struct seq_file *s, void *data)
hlist_for_each_entry(c, _orphan_list, child_node)
clk_summary_show_subtree(s, c, 0);
- mutex_unlock(_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -130,7 +151,7 @@ static int clk_dump(struct seq_file *s, void *data)
seq_printf(s, "{");
- mutex_lock(_lock);
+ clk_prepare_lock();
hlist_for_each_entry(c, _root_list, child_node) {
if (!first_node)
@@ -144,7 +165,7 @@ static int clk_dump(struct seq_file *s, void *data)
clk_dump_subtree(s, c, 0);
}
- mutex_unlock(_lock);
+ clk_prepare_unlock();
seq_printf(s, "}");
return 0;
@@ -316,7 +337,7 @@ static int __init clk_debug_init(void)
if (!orphandir)
return -ENOMEM;
- mutex_lock(_lock);
+ clk_prepare_lock();
hlist_for_each_entry(clk, _root_list, child_node)
clk_debug_create_subtree(clk, rootdir);
@@ -326,7 +347,7 @@ static int __init clk_debug_init(void)
inited = 1;
- mutex_unlock(_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -372,7 +393,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
hlist_for_each_entry(child, >children, child_node)
clk_disable_unused_subtree(child);
- spin_lock_irqsave(_lock, flags);
+ clk_enable_lock();
if (clk->enable_count)
goto unlock_out;
@@ -393,7 +414,7 @@ static void clk_disable_unused_subtree(struct clk *clk)
}
unlock_out:
- spin_unlock_irqrestore(_lock, flags);
+ clk_enable_unlock();
out:
return;
@@ -403,7 +424,7 @@ static int clk_disable_unused(void)
{
struct clk *clk;
- mutex_lock(_lock);
+ clk_prepare_lock();
hlist_for_each_entry(clk, _root_list, child_node)
clk_disable_unused_subtree(clk);
@@ -417,7 +438,7 @@ static int clk_disable_unused(void)
hlist_for_each_entry(clk, _orphan_list, child_node)
clk_unprepare_unused_subtree(clk);
- mutex_unlock(_lock);
+ clk_prepare_unlock();
return 0;
}
@@ -600,9 +621,9 @@ void __clk_unprepare(struct clk *clk)
*/
void clk_unprepare(struct clk *clk)
{
- mutex_lock(_lock);
+ clk_prepare_lock();
__clk_unprepare(clk);
- mutex_unlock(_lock);
+ clk_prepare_unlock();
}
EXPORT_SYMBOL_GPL(clk_unprepare);
@@ -648,9 +669,9 @@ int clk_prepare(struct clk *clk)
{
int ret;
- mutex_lock(_lock);
+ clk_prepare_lock();
ret = __clk_prepare(clk);
- mutex_unlock(_lock);
+ clk_prepare_unlock();
return ret;
}
@@ -692,9 +713,9 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
- spin_lock_irqsave(_lock, flags);
+ clk_enable_lock();
__clk_disable(clk);
- spin_unlock_irqrestore(_lock, flags);
+ clk_enable_unlock();
}
EXPORT_SYMBOL_GPL(clk_disable);
@@ -745,9 +766,9 @@ int clk_enable(struct clk *clk)
unsigned long flags;
int ret;
- spin_lock_irqsave(_lock, flags);
+ clk_enable_lock();
ret = __clk_enable(clk);
- spin_unlock_irqrestore(_lock, flags);
+ clk_enable_unlock();
return ret;
}
@@ -792,9
[PATCH v5 0/2] reentrancy in the common clk framework
This fifth attempt at allowing calls to the clk api to reenter splits the last patch into two parts. The first patch abstracts out the locking details into some helper functions and converts all of the direct calls to the mutex and spinlock api to use these helpers. The second patch introduces the reentrancy logic into these helper functions. Fundamentally the reentrancy logic hasn't changed since v4, but fixing casting bugs, removing unnecessary barriers and better design & beautification separate this approach from the last one. Changes tested on top of the latest clk-next branch with an OMAP4430 Panda board. Mike Turquette (2): clk: abstract locking out into helper functions clk: allow reentrant calls into the clk framework drivers/clk/clk.c | 136 ++--- 1 file changed, 98 insertions(+), 38 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] mg_disk: fix error return code in mg_probe()
On Thursday, March 28, 2013 1:32 PM, Wei Yongjun wrote:
>
> From: Wei Yongjun
>
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
CC'ed Jens Axboe
It looks good.
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/block/mg_disk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
> index 532bb89..a56cfcd 100644
> --- a/drivers/block/mg_disk.c
> +++ b/drivers/block/mg_disk.c
> @@ -892,8 +892,10 @@ static int mg_probe(struct platform_device *plat_dev)
> gpio_direction_output(host->rst, 1);
>
> /* reset out pin */
> - if (!(prv_data->dev_attr & MG_DEV_MASK))
> + if (!(prv_data->dev_attr & MG_DEV_MASK)) {
> + err = -EINVAL;
> goto probe_err_3a;
> + }
>
> if (prv_data->dev_attr != MG_BOOT_DEV) {
> rsc = platform_get_resource_byname(plat_dev, IORESOURCE_IO,
--
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] ARM: davinci: use is IS_ENABLED macro
Hi Sekhar,
On Wed, Mar 27, 2013 at 4:13 PM, Stephen Rothwell wrote:
> Hi,
>
> On Mon, 25 Mar 2013 16:51:35 +0530 Prabhakar lad
> wrote:
>>
>> --- a/arch/arm/mach-davinci/board-da830-evm.c
>> +++ b/arch/arm/mach-davinci/board-da830-evm.c
>> @@ -298,7 +298,7 @@ static const short da830_evm_emif25_pins[] = {
>> -1
>> };
>>
>> -#if defined(CONFIG_MMC_DAVINCI) || defined(CONFIG_MMC_DAVINCI_MODULE)
>> +#if IS_ENABLED(CONFIG_MMC_DAVINCI)
>> #define HAS_MMC 1
>> #else
>> #define HAS_MMC 0
>
> Why not
>
> #define HAS_MMC IS_ENABLED(CONFIG_MMC_DAVINCI)
>
> and similarly in the rest?
>
Stephen's suggestion looks good to me, if you haven’t queued it i'll post a v2,
or if you have already queued it I'll create a patch on top of the
same patch fixing it.
lemme know how would you want it.
Regards,
--Prabhakar
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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 -next] mg_disk: fix error return code in mg_probe()
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/block/mg_disk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
index 532bb89..a56cfcd 100644
--- a/drivers/block/mg_disk.c
+++ b/drivers/block/mg_disk.c
@@ -892,8 +892,10 @@ static int mg_probe(struct platform_device *plat_dev)
gpio_direction_output(host->rst, 1);
/* reset out pin */
- if (!(prv_data->dev_attr & MG_DEV_MASK))
+ if (!(prv_data->dev_attr & MG_DEV_MASK)) {
+ err = -EINVAL;
goto probe_err_3a;
+ }
if (prv_data->dev_attr != MG_BOOT_DEV) {
rsc = platform_get_resource_byname(plat_dev, IORESOURCE_IO,
--
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: zsmalloc zbud hybrid design discussion?
On 03/28/2013 04:04 AM, Dan Magenheimer wrote: > Seth and all zproject folks -- > > I've been giving some deep thought as to how a zpage > allocator might be designed that would incorporate the > best of both zsmalloc and zbud. > > Rather than dive into coding, it occurs to me that the > best chance of success would be if all interested parties > could first discuss (on-list) and converge on a design > that we can all agree on. If we achieve that, I don't > care who writes the code and/or gets the credit or > chooses the name. If we can't achieve consensus, at > least it will be much clearer where our differences lie. > > Any thoughts? Can't agree more! Hoping we would agree on a design dealing well with density/fragmentation/pageframe-reclaim and better integration with MM. And then working together to implement it. -- Regards, -Bob -- 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] PCI, ACPI: Don't query OSC support with all possible controls
Found problem on system that firmware that could handle pci aer.
Firmware get error reporting after pci injecting error, before os boots.
But after os boots, firmware can not get report anymore, even pci=noaer
is passed.
Root cause: BIOS _OSC has problem with query bit checking.
It turns out that BIOS vendor is copying example code from ACPI Spec.
In ACPI Spec 5.0, page 290:
If (Not(And(CDW1,1))) // Query flag clear?
{ // Disable GPEs for features granted native control.
If (And(CTRL,0x01)) // Hot plug control granted?
{
Store(0,HPCE) // clear the hot plug SCI enable bit
Store(1,HPCS) // clear the hot plug SCI status bit
}
...
}
When Query flag is set, And(CDW1,1) will be 1, Not(1) will return 0xfffe.
So it will get into code path that should be for control set only.
BIOS acpi code should be changed to "If (LEqual(And(CDW1,1), 0)))"
Current kernel code is using _OSC query to notify firmware about support
from OS and then use _OSC to set control bits.
During query support, current code is using all possible controls.
So will execute code that should be only for control set stage.
That will have problem when pci=noaer or aer firmware_first is used.
As firmware have that control set for os aer already in query support stage,
but later will not os aer handling.
We should avoid passing all possible controls, just use osc_control_set
instead.
That should workaround BIOS bugs with affected systems on the field
as more bios vendors are copying sample code from ACPI spec.
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/acpi/pci_root.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/acpi/pci_root.c
===
--- linux-2.6.orig/drivers/acpi/pci_root.c
+++ linux-2.6/drivers/acpi/pci_root.c
@@ -201,8 +201,8 @@ static acpi_status acpi_pci_query_osc(st
*control &= OSC_PCI_CONTROL_MASKS;
capbuf[OSC_CONTROL_TYPE] = *control | root->osc_control_set;
} else {
- /* Run _OSC query for all possible controls. */
- capbuf[OSC_CONTROL_TYPE] = OSC_PCI_CONTROL_MASKS;
+ /* Run _OSC query only with existing controls. */
+ capbuf[OSC_CONTROL_TYPE] = root->osc_control_set;
}
status = acpi_pci_run_osc(root->device->handle, capbuf, );
--
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 signal tree with Linus' tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in fs/splice.c
between commit 06ae43f34bcc ("Don't bother with redoing rw_verify_area()
from default_file_splice_from()") from Linus' tree and commit
76b021d053ed ("convert vmsplice to COMPAT_SYSCALL_DEFINE") from the
signal tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/splice.c
index 29e394e,23ade0e..000
--- a/fs/splice.c
+++ b/fs/splice.c
@@@ -31,7 -31,7 +31,8 @@@
#include
#include
#include
+ #include
+#include "internal.h"
/*
* Attempt to steal a page from a pipe buffer. This should perhaps go into
pgprhdhWDGjRn.pgp
Description: PGP signature
[PATCH 2/2] eisa, PCI: init eisa early before pnp step in
Mathhew reported kernels fail the pci_eisa probe and are later successful
with the virtual_eisa_root_init force probe without slot0.
The reason for that is: pnp probing is early than pci_eisa_init get called
as pci_eisa_init is called via pci_driver.
pnp 00:0f has 0xc80 - 0xc84 reserved.
[9.700409] pnp 00:0f: [io 0x0c80-0x0c84]
so eisa_probe will fail from pci_eisa_init
==>eisa_root_register
==>eisa_probe path.
as force_probe is not set in pci_eisa_root, it will bail early when
slot0 is not probed and initialized.
Try to use subsys_initcall_sync instead, and will keep following sequence:
pci_subsys_init
pci_eisa_init_early
pnpacpi_init/isapnp_init
After this patch eisa can be initialized properly, and pnp overlapping
resource will not be reserved.
[ 10.104434] system 00:0f: [io 0x0c80-0x0c84] could not be reserved
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/eisa/pci_eisa.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
Index: linux-2.6/drivers/eisa/pci_eisa.c
===
--- linux-2.6.orig/drivers/eisa/pci_eisa.c
+++ linux-2.6/drivers/eisa/pci_eisa.c
@@ -19,8 +19,7 @@
/* There is only *one* pci_eisa device per machine, right ? */
static struct eisa_root_device pci_eisa_root;
-static int __init pci_eisa_init(struct pci_dev *pdev,
- const struct pci_device_id *ent)
+static int __init pci_eisa_init(struct pci_dev *pdev)
{
int rc, n = 0;
struct resource *bus_res;
@@ -49,22 +48,26 @@ static int __init pci_eisa_init(struct p
return 0;
}
-static struct pci_device_id pci_eisa_pci_tbl[] = {
- { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_EISA << 8, 0x00, 0 },
- { 0, }
-};
-
-static struct pci_driver __refdata pci_eisa_driver = {
- .name = "pci_eisa",
- .id_table = pci_eisa_pci_tbl,
- .probe = pci_eisa_init,
-};
-
-static int __init pci_eisa_init_module (void)
+/*
+ * We have to call pci_eisa_init_early() before pnpacpi_init()/isapnp_init().
+ * Otherwise pnp resource will get enabled early and could prevent eisa
+ * to be initialized.
+ * Also need to make sure pci_eisa_init_early() is called after
+ * x86/pci_subsys_init().
+ * So need to use subsys_initcall_sync with it.
+ */
+static int __init pci_eisa_init_early(void)
{
- return pci_register_driver (_eisa_driver);
-}
+ struct pci_dev *dev = NULL;
+ int ret;
+
+ for_each_pci_dev(dev)
+ if ((dev->class >> 8) == PCI_CLASS_BRIDGE_EISA) {
+ ret = pci_eisa_init(dev);
+ if (ret)
+ return ret;
+ }
-device_initcall(pci_eisa_init_module);
-MODULE_DEVICE_TABLE(pci, pci_eisa_pci_tbl);
+ return 0;
+}
+subsys_initcall_sync(pci_eisa_init_early);
--
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] eisa, PCI: Fix bus res reference
Matthem found that 3.8.3 is having problems with an old (ancient)
PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel.
He identified the 82375, but doesn't assign the struct resource *res
pointer inside the struct eisa_root_device, and panics.
After looking at pci_eisa_init(), found it referring bus resource
directly instead of pci_bus_resource_n().
After commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists)
and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus
address offset), bus->resource[] is not used for pci root bus any more.
Fix it by using pci_bus_resource_n() and correct idx for root bus.
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
Signed-off-by: Yinghai Lu
Cc: sta...@kernel.org
---
drivers/eisa/pci_eisa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/eisa/pci_eisa.c
===
--- linux-2.6.orig/drivers/eisa/pci_eisa.c
+++ linux-2.6/drivers/eisa/pci_eisa.c
@@ -22,7 +22,8 @@ static struct eisa_root_device pci_eisa_
static int __init pci_eisa_init(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
- int rc;
+ int rc, n = 0;
+ struct resource *bus_res;
if ((rc = pci_enable_device (pdev))) {
printk (KERN_ERR "pci_eisa : Could not enable device %s\n",
@@ -30,9 +31,12 @@ static int __init pci_eisa_init(struct p
return rc;
}
+ if (pci_is_root_bus(pdev->bus))
+ n = PCI_BRIDGE_RESOURCE_NUM;
+ bus_res = pci_bus_resource_n(pdev->bus, n);
pci_eisa_root.dev = >dev;
- pci_eisa_root.res = pdev->bus->resource[0];
- pci_eisa_root.bus_base_addr= pdev->bus->resource[0]->start;
+ pci_eisa_root.res = bus_res;
+ pci_eisa_root.bus_base_addr= bus_res->start;
pci_eisa_root.slots= EISA_MAX_SLOTS;
pci_eisa_root.dma_mask = pdev->dma_mask;
dev_set_drvdata(pci_eisa_root.dev, _eisa_root);
--
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] eisa: fix eisa with PCI
Looks like pci eisa bridge support is broken for a while. one is root io resource reference, and other one is pnp related. Please check if we can put them in v3.9. eisa, PCI: Fix bus res reference eisa, PCI: init eisa early before pnp step in Thanks Yinghai Lu -- 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 6/7] cpuacct: Remove redundant NULL checks in cpuacct_acount_field()
This is a micro optimazation for a hot path.
- We don't need to check if @ca returned from task_ca() is NULL.
- We don't need to check if @ca returned from parent_ca() is NULL.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 4 ++--
kernel/sched/cpuacct.h | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index b2aaaba..071ae8d 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -237,10 +237,10 @@ void cpuacct_account_field(struct task_struct *p, int
index, u64 val)
rcu_read_lock();
ca = task_ca(p);
- while (ca && (ca != _cpuacct)) {
+ while (ca != _cpuacct) {
kcpustat = this_cpu_ptr(ca->cpustat);
kcpustat->cpustat[index] += val;
- ca = parent_ca(ca);
+ ca = __parent_ca(ca);
}
rcu_read_unlock();
}
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 45c1682..b2f79ad 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -34,6 +34,11 @@ static inline struct cpuacct *task_ca(struct task_struct
*tsk)
struct cpuacct, css);
}
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
if (!ca->css.cgroup->parent)
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] cpuacct: Clean up cpuacct.h
Now most of the code in cpuacct.h can be moved to cpuacct.c
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 44 +++-
kernel/sched/cpuacct.h | 46 --
2 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 071ae8d..9305fd2 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -16,7 +16,49 @@
* (bal...@in.ibm.com).
*/
-struct cpuacct root_cpuacct;
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
+{
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+static struct cpuacct root_cpuacct;
/* create a new cpu accounting group */
static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index b2f79ad..51cd76e 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -1,51 +1,5 @@
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *__parent_ca(struct cpuacct *ca)
-{
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] sched: Split cpuacct out of sched.h
Add cpuacct.h and let sched.h include it.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.h | 52 ++
kernel/sched/sched.h | 49 +--
2 files changed, 53 insertions(+), 48 deletions(-)
create mode 100644 kernel/sched/cpuacct.h
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
new file mode 100644
index 000..a7f3d4a
--- /dev/null
+++ b/kernel/sched/cpuacct.h
@@ -0,0 +1,52 @@
+/* Time spent by the tasks of the cpu accounting group executing in ... */
+enum cpuacct_stat_index {
+ CPUACCT_STAT_USER, /* ... user mode */
+ CPUACCT_STAT_SYSTEM,/* ... kernel mode */
+
+ CPUACCT_STAT_NSTATS,
+};
+
+#ifdef CONFIG_CGROUP_CPUACCT
+
+#include
+/* track cpu usage of a group of tasks and its child groups */
+struct cpuacct {
+ struct cgroup_subsys_state css;
+ /* cpuusage holds pointer to a u64-type object on every cpu */
+ u64 __percpu *cpuusage;
+ struct kernel_cpustat __percpu *cpustat;
+};
+
+extern struct cgroup_subsys cpuacct_subsys;
+extern struct cpuacct root_cpuacct;
+
+/* return cpu accounting group corresponding to this container */
+static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
+{
+ return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+/* return cpu accounting group to which this task belongs */
+static inline struct cpuacct *task_ca(struct task_struct *tsk)
+{
+ return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
+ struct cpuacct, css);
+}
+
+static inline struct cpuacct *parent_ca(struct cpuacct *ca)
+{
+ if (!ca || !ca->css.cgroup->parent)
+ return NULL;
+ return cgroup_ca(ca->css.cgroup->parent);
+}
+
+extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+
+#else
+
+static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
+{
+}
+
+#endif
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index cc03cfd..5bfcaba 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -7,6 +7,7 @@
#include
#include "cpupri.h"
+#include "cpuacct.h"
extern __read_mostly int scheduler_running;
@@ -856,15 +857,6 @@ static const u32 prio_to_wmult[40] = {
/* 15 */ 119304647, 148102320, 186737708, 238609294, 286331153,
};
-/* Time spent by the tasks of the cpu accounting group executing in ... */
-enum cpuacct_stat_index {
- CPUACCT_STAT_USER, /* ... user mode */
- CPUACCT_STAT_SYSTEM,/* ... kernel mode */
-
- CPUACCT_STAT_NSTATS,
-};
-
-
#define sched_class_highest (_sched_class)
#define for_each_class(class) \
for (class = sched_class_highest; class; class = class->next)
@@ -904,45 +896,6 @@ extern void init_rt_bandwidth(struct rt_bandwidth *rt_b,
u64 period, u64 runtime
extern void update_idle_cpu_load(struct rq *this_rq);
-#ifdef CONFIG_CGROUP_CPUACCT
-#include
-/* track cpu usage of a group of tasks and its child groups */
-struct cpuacct {
- struct cgroup_subsys_state css;
- /* cpuusage holds pointer to a u64-type object on every cpu */
- u64 __percpu *cpuusage;
- struct kernel_cpustat __percpu *cpustat;
-};
-
-extern struct cgroup_subsys cpuacct_subsys;
-extern struct cpuacct root_cpuacct;
-
-/* return cpu accounting group corresponding to this container */
-static inline struct cpuacct *cgroup_ca(struct cgroup *cgrp)
-{
- return container_of(cgroup_subsys_state(cgrp, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-/* return cpu accounting group to which this task belongs */
-static inline struct cpuacct *task_ca(struct task_struct *tsk)
-{
- return container_of(task_subsys_state(tsk, cpuacct_subsys_id),
- struct cpuacct, css);
-}
-
-static inline struct cpuacct *parent_ca(struct cpuacct *ca)
-{
- if (!ca || !ca->css.cgroup->parent)
- return NULL;
- return cgroup_ca(ca->css.cgroup->parent);
-}
-
-extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
-#else
-static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime) {}
-#endif
-
#ifdef CONFIG_PARAVIRT
static inline u64 steal_ticks(u64 steal)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] cpuacct: Remove redundant NULL checks in cpuacct_charge()
This is micro optimization for the hot path.
- We don't need to check if @ca is NULL in parent_ca().
- We don't need to check if @ca is NULL in the beginning of the for loop.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 6 +-
kernel/sched/cpuacct.h | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 72bd971..b2aaaba 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -210,9 +210,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
ca = task_ca(tsk);
- for (; ca; ca = parent_ca(ca)) {
+ while (true) {
u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
*cpuusage += cputime;
+
+ ca = parent_ca(ca);
+ if (!ca)
+ break;
}
rcu_read_unlock();
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index bd0409b..45c1682 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -36,7 +36,7 @@ static inline struct cpuacct *task_ca(struct task_struct *tsk)
static inline struct cpuacct *parent_ca(struct cpuacct *ca)
{
- if (!ca || !ca->css.cgroup->parent)
+ if (!ca->css.cgroup->parent)
return NULL;
return cgroup_ca(ca->css.cgroup->parent);
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] cpuacct: Add cpuacct_acount_field()
So we can remove open-coded cpuacct code in cputime.c.
Signed-off-by: Li Zefan
---
kernel/sched/cpuacct.c | 23 +++
kernel/sched/cpuacct.h | 6 ++
kernel/sched/cputime.c | 18 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 48b5e91..72bd971 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,29 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+/*
+ * Add user/system time to cpuacct.
+ *
+ * Note: it's the caller that updates the account of the root cgroup.
+ */
+void cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+ struct kernel_cpustat *kcpustat;
+ struct cpuacct *ca;
+
+ if (unlikely(!cpuacct_subsys.active))
+ return;
+
+ rcu_read_lock();
+ ca = task_ca(p);
+ while (ca && (ca != _cpuacct)) {
+ kcpustat = this_cpu_ptr(ca->cpustat);
+ kcpustat->cpustat[index] += val;
+ ca = parent_ca(ca);
+ }
+ rcu_read_unlock();
+}
+
void __init cpuacct_init(void)
{
root_cpuacct.cpustat = _cpustat;
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index 551acd7..bd0409b 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -43,6 +43,7 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
+extern void cpuacct_account_field(struct task_struct *p, int index, u64 val);
#else
@@ -54,4 +55,9 @@ static inline void cpuacct_charge(struct task_struct *tsk,
u64 cputime)
{
}
+static inline void
+cpuacct_account_field(struct task_struct *p, int index, u64 val)
+{
+}
+
#endif
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index ed12cbb..a5129c7 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -115,10 +115,6 @@ static int irqtime_account_si_update(void)
static inline void task_group_account_field(struct task_struct *p, int index,
u64 tmp)
{
-#ifdef CONFIG_CGROUP_CPUACCT
- struct kernel_cpustat *kcpustat;
- struct cpuacct *ca;
-#endif
/*
* Since all updates are sure to touch the root cgroup, we
* get ourselves ahead and touch it first. If the root cgroup
@@ -127,19 +123,7 @@ static inline void task_group_account_field(struct
task_struct *p, int index,
*/
__get_cpu_var(kernel_cpustat).cpustat[index] += tmp;
-#ifdef CONFIG_CGROUP_CPUACCT
- if (unlikely(!cpuacct_subsys.active))
- return;
-
- rcu_read_lock();
- ca = task_ca(p);
- while (ca && (ca != _cpuacct)) {
- kcpustat = this_cpu_ptr(ca->cpustat);
- kcpustat->cpustat[index] += tmp;
- ca = parent_ca(ca);
- }
- rcu_read_unlock();
-#endif
+ cpuacct_account_field(p, index, tmp);
}
/*
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] cpuacct: Add cpuacct_init()
So we don't open-coded initialization of cpuacct in core.c.
Signed-off-by: Li Zefan
---
kernel/sched/core.c| 8 ++--
kernel/sched/cpuacct.c | 7 +++
kernel/sched/cpuacct.h | 5 +
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8eb3096..9f5a804 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6860,12 +6860,8 @@ void __init sched_init(void)
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
- root_cpuacct.cpustat = _cpustat;
- root_cpuacct.cpuusage = alloc_percpu(u64);
- /* Too early, not expected to fail */
- BUG_ON(!root_cpuacct.cpuusage);
-#endif
+ cpuacct_init();
+
for_each_possible_cpu(i) {
struct rq *rq;
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index 50ec24b..48b5e91 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -218,6 +218,13 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
rcu_read_unlock();
}
+void __init cpuacct_init(void)
+{
+ root_cpuacct.cpustat = _cpustat;
+ root_cpuacct.cpuusage = alloc_percpu(u64);
+ BUG_ON(!root_cpuacct.cpuusage); /* Too early, not expected to fail */
+}
+
struct cgroup_subsys cpuacct_subsys = {
.name = "cpuacct",
.css_alloc = cpuacct_css_alloc,
diff --git a/kernel/sched/cpuacct.h b/kernel/sched/cpuacct.h
index a7f3d4a..551acd7 100644
--- a/kernel/sched/cpuacct.h
+++ b/kernel/sched/cpuacct.h
@@ -41,10 +41,15 @@ static inline struct cpuacct *parent_ca(struct cpuacct *ca)
return cgroup_ca(ca->css.cgroup->parent);
}
+extern void cpuacct_init(void);
extern void cpuacct_charge(struct task_struct *tsk, u64 cputime);
#else
+static inline void cpuacct_init(void)
+{
+}
+
static inline void cpuacct_charge(struct task_struct *tsk, u64 cputime)
{
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] sched: Split cpuacct code out of core.c
Signed-off-by: Li Zefan
---
kernel/sched/Makefile | 1 +
kernel/sched/core.c| 220 ---
kernel/sched/cpuacct.c | 227 +
3 files changed, 228 insertions(+), 220 deletions(-)
create mode 100644 kernel/sched/cpuacct.c
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index f06d249..deaf90e 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
obj-$(CONFIG_SCHEDSTATS) += stats.o
obj-$(CONFIG_SCHED_DEBUG) += debug.o
+obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b7b03cd..8eb3096 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7938,226 +7938,6 @@ struct cgroup_subsys cpu_cgroup_subsys = {
#endif /* CONFIG_CGROUP_SCHED */
-#ifdef CONFIG_CGROUP_CPUACCT
-
-/*
- * CPU accounting code for task groups.
- *
- * Based on the work by Paul Menage (men...@google.com) and Balbir Singh
- * (bal...@in.ibm.com).
- */
-
-struct cpuacct root_cpuacct;
-
-/* create a new cpu accounting group */
-static struct cgroup_subsys_state *cpuacct_css_alloc(struct cgroup *cgrp)
-{
- struct cpuacct *ca;
-
- if (!cgrp->parent)
- return _cpuacct.css;
-
- ca = kzalloc(sizeof(*ca), GFP_KERNEL);
- if (!ca)
- goto out;
-
- ca->cpuusage = alloc_percpu(u64);
- if (!ca->cpuusage)
- goto out_free_ca;
-
- ca->cpustat = alloc_percpu(struct kernel_cpustat);
- if (!ca->cpustat)
- goto out_free_cpuusage;
-
- return >css;
-
-out_free_cpuusage:
- free_percpu(ca->cpuusage);
-out_free_ca:
- kfree(ca);
-out:
- return ERR_PTR(-ENOMEM);
-}
-
-/* destroy an existing cpu accounting group */
-static void cpuacct_css_free(struct cgroup *cgrp)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
-
- free_percpu(ca->cpustat);
- free_percpu(ca->cpuusage);
- kfree(ca);
-}
-
-static u64 cpuacct_cpuusage_read(struct cpuacct *ca, int cpu)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
- u64 data;
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit read safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(_rq(cpu)->lock);
- data = *cpuusage;
- raw_spin_unlock_irq(_rq(cpu)->lock);
-#else
- data = *cpuusage;
-#endif
-
- return data;
-}
-
-static void cpuacct_cpuusage_write(struct cpuacct *ca, int cpu, u64 val)
-{
- u64 *cpuusage = per_cpu_ptr(ca->cpuusage, cpu);
-
-#ifndef CONFIG_64BIT
- /*
-* Take rq->lock to make 64-bit write safe on 32-bit platforms.
-*/
- raw_spin_lock_irq(_rq(cpu)->lock);
- *cpuusage = val;
- raw_spin_unlock_irq(_rq(cpu)->lock);
-#else
- *cpuusage = val;
-#endif
-}
-
-/* return total cpu usage (in nanoseconds) of a group */
-static u64 cpuusage_read(struct cgroup *cgrp, struct cftype *cft)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- u64 totalcpuusage = 0;
- int i;
-
- for_each_present_cpu(i)
- totalcpuusage += cpuacct_cpuusage_read(ca, i);
-
- return totalcpuusage;
-}
-
-static int cpuusage_write(struct cgroup *cgrp, struct cftype *cftype,
- u64 reset)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int err = 0;
- int i;
-
- if (reset) {
- err = -EINVAL;
- goto out;
- }
-
- for_each_present_cpu(i)
- cpuacct_cpuusage_write(ca, i, 0);
-
-out:
- return err;
-}
-
-static int cpuacct_percpu_seq_read(struct cgroup *cgroup, struct cftype *cft,
- struct seq_file *m)
-{
- struct cpuacct *ca = cgroup_ca(cgroup);
- u64 percpu;
- int i;
-
- for_each_present_cpu(i) {
- percpu = cpuacct_cpuusage_read(ca, i);
- seq_printf(m, "%llu ", (unsigned long long) percpu);
- }
- seq_printf(m, "\n");
- return 0;
-}
-
-static const char *cpuacct_stat_desc[] = {
- [CPUACCT_STAT_USER] = "user",
- [CPUACCT_STAT_SYSTEM] = "system",
-};
-
-static int cpuacct_stats_show(struct cgroup *cgrp, struct cftype *cft,
- struct cgroup_map_cb *cb)
-{
- struct cpuacct *ca = cgroup_ca(cgrp);
- int cpu;
- s64 val = 0;
-
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpustat, cpu);
- val += kcpustat->cpustat[CPUTIME_USER];
- val += kcpustat->cpustat[CPUTIME_NICE];
- }
- val = cputime64_to_clock_t(val);
- cb->fill(cb, cpuacct_stat_desc[CPUACCT_STAT_USER], val);
-
- val = 0;
- for_each_online_cpu(cpu) {
- struct kernel_cpustat *kcpustat = per_cpu_ptr(ca->cpustat, cpu);
-
[PATCH 0/7] sched: Split cpuacct
- This patchset splits cpuacct out of core scheduler code. - Plus two small optimizations. 0001-sched-Split-cpuacct-code-out-of-core.c.patch 0002-sched-Split-cpuacct-out-of-sched.h.patch 0003-cpuacct-Add-cpuacct_init.patch 0004-cpuacct-Add-cpuacct_acount_field.patch 0005-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_char.patch 0006-cpuacct-Remove-redundant-NULL-checks-in-cpuacct_acou.patch 0007-cpuacct-Clean-up-cpuacct.h.patch --- kernel/sched/Makefile | 1 + kernel/sched/core.c| 228 +-- kernel/sched/cpuacct.c | 303 +++ kernel/sched/cpuacct.h | 22 + kernel/sched/cputime.c | 18 +--- kernel/sched/sched.h | 49 +-- 6 files changed, 330 insertions(+), 291 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 v4] watchdog: Add Broadcom BCM2835 watchdog timer driver
On Wed, Mar 27, 2013 at 09:00:29PM -0600, Stephen Warren wrote: > On 03/27/2013 10:40 AM, Lubomir Rintel wrote: > > This adds a driver for watchdog timer hardware present on Broadcom BCM2835 > > SoC, > > used in Raspberry Pi and Roku 2 devices. > > > > Signed-off-by: Lubomir Rintel > > Signed-off-by: Dom Cobley > > Those two s-o-b lines should be swapped, since if Dom did sign off on > any part of this patch, he did it before you did. > > That said... > > I wonder if it's actually appropriate to include Dom's s-o-b here, since > I don't think he really wrote this patch itself. I think you mentioned > that you hadn't use much of the downstream driver except for some defines? > > To be clear, I mentioned the existence of the S-o-b line downstream > simply to demonstrate that the commits you were getting information from > had correctly followed the process described in > Documentation/SubmittingPatches, and so it was OK to use that > information while creating a GPL'd driver. > > So there are a couple of ways that this patch could have been created: > > 1) You took the downstream commit itself, cherry-picked it into the > upstream kernel, modified it to suit upstream, and then submitted that. > The modifications might be extensive, such as renaming the file, > removing parts of the code that the upstream watchdog core now handles, > adding some new features, fixing bugs, cleanup, etc.; whatever is needed > to upstream the patch. > > In this case, I believe it would be appropriate to maintain any S-o-b > lines from the original downstream commit, and add yours. But, I believe > you should also (a) maintain the git author field from the original > downstream commit (b) include a list of the changes you made to the > patch in the commit description, so you can be blamed for them rather > than the original author:-) > > 2) You read the downstream commit for information, but created a > completely new driver for the upstream kernel, using the downstream > driver just as a reference. In this case, I believe it's fine for the > git author field to be you, and for the only s-o-b line present to be > yours, since you really did write the patch from scratch. However, you > should credit the downstream work in the (c) header and/or commit > description. > > This current patch sees to be a slight hybrid of both approaches (you're > listed as the git author, but have included Dom's s-o-b line on a patch > I don't think he created, and wasn't directly derived from one he created). > > I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van > Sebroeck, since he's the watchdog maintainer and would be the person who > applies this patch. > I wondered about the same. I think 2) would be more appropriate. My approach would have been to reference previous work in the file header, something along the line of "derived from xxx", and add a copyright statement from the original work if there was one - pretty much what you propose above. Guenter -- 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] checkpatch: do not exit in main process subroutine
Currently checkpatch program exit when process empty file,
This will cause issue when @ARGV include many files ready to check.
For example, there may have Module.symvers empty file in kernel directory.
[root@jovi ~]# scripts/checkpatch.pl -f kernel/*
then many file "after" empty file will not be check by script.
so disallow exit in main process subroutine.
Signed-off-by: zhangwei(Jovi)
---
scripts/checkpatch.pl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..6924733 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3634,19 +3634,19 @@ sub process {
# If we have no input at all, then there is nothing to report on
# so just keep quiet.
if ($#rawlines == -1) {
- exit(0);
+ return $clean;
}
# In mailback mode only produce a report in the negative, for
# things that appear to be patches.
if ($mailback && ($clean == 1 || !$is_patch)) {
- exit(0);
+ return $clean;
}
# This is not a patch, and we are are in 'no-patch' mode so
# just keep quiet.
if (!$chk_patch && !$is_patch) {
- exit(0);
+ return $clean;
}
if (!$is_patch) {
--
1.7.9.7
--
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] tokenring: delete last holdout of CONFIG_TR
From: Paul Bolle Date: Wed, 27 Mar 2013 21:52:28 +0100 > Tokenring support was deleted in v3.5. One last holdout of the macro > CONFIG_TR escaped that fate. Until now. > > Signed-off-by: Paul Bolle Applied to net-next, 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/
RE: Davicom Linux driver
Dear Miller, This is Joseph CHANG. I had sent you the patches used my gmail earlier than Allen did. My gmail account is josright...@gmail.com The patches's subjects were: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial [PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial patch2 Would you help confirm it again, Thanks. Best Regards, Joseph CHANG System Application Engineering Division Davicom Semiconductor, Inc. No. 6 Li-Hsin Rd. VI, Science-Based Park, Hsin-Chu, Taiwan. Tel: 886-3-5798797 Ex 8534 Fax: 886-3-5646929 Web: http://www.davicom.com.tw -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, March 28, 2013 10:10 AM To: allen_hu...@davicom.com.tw Cc: r.e.wo...@bitwizard.nl; cor...@lwn.net; bonb...@linux-vserver.org; wf...@virginia.edu; matt...@mattleach.net; gre...@linuxfoundation.org; j...@resnulli.us; net...@vger.kernel.org; linux-kernel@vger.kernel.org; michael_c...@mail.davicom.com.tw; andrew_c...@davicom.com.tw; spenser_t...@davicom.com.tw; willie_n...@mail.davicom.com.tw; charles_t...@davicom.com.tw; joseph_ch...@mail.davicom.com.tw Subject: Re: Davicom Linux driver This is not the correct way to submit a patch for inclusion upstream You should post each patch in a seperate, numbered, list posting, in plain ASCII text, and not as an attachment. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: Davicom Linux driver
From: "Joseph Chang" Date: Thu, 28 Mar 2013 10:25:58 +0800 > Dear Miller, > > This is Joseph CHANG. > I had sent you the patches used my gmail earlier than Allen did. > My gmail account is josright...@gmail.com > The patches's subjects were: >[PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial >[PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial > patch2 You were given feedback and requested to make changes to those patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel_pstate_timer_func divide by zero oops
On Wed, Mar 27, 2013 at 10:51 PM, Dirk Brandewie wrote: > > Is there any way to capture the beginning of this trace? I tried but since the oops scrolls fast followed by a hard freeze, I wasn't able to capture it completely. May be I can try netconsole and see if that helps. > > pid_param_set() is on the stack which means that something is changing > the debugfs parameters or the stack is FUBAR. > I somehow doubt the stack is messed up as the call traces are always identical. (pid_param_set() seems to be in first trace as well.) > > I don't see how duration_us can be zero unless somehow I am getting > back-to-back > timer callbacks which seems unlikely since the timer is not re-armed until > the timer function is about to return and the driver has done all its work > for the sample period Do the two oops with common call stack suggest back to back callbacks? I will add some debugging checks tomorrow to see what is going on. But sounds like a minimal fix would be to guard against callbacks in quick succession? i.e. return from sample if ktime_us_delta(now, cpu->prev_sample) is zero? Thanks, Parag -- 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: Davicom Linux driver
On Thu, Mar 28, 2013 at 10:25:58AM +0800, Joseph Chang wrote: > Dear Miller, > > This is Joseph CHANG. > I had sent you the patches used my gmail earlier than Allen did. > My gmail account is josright...@gmail.com > The patches's subjects were: >[PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial >[PATCH 2/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial > patch2 > > Would you help confirm it again, Thanks. That is not necessary, you can always "confirm" that a patch made it to a mailing list, by looking at the mailing list. -- 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/
Generic syscall ABI support
Need advise regarding the generic syscall ABI support. We are planning to upstream our Nios II kernel (arch/nios2) to mainline. But it doesn't support generic syscall ABI yet (It requires an updated Glibc port as well). The question is, is it a requirement for new arch to support generic syscall ABI when upstreaming? Can we upstream a non-generic syscall ABI first and migrate to generic syscall ABI in future? Thanks. Regards LFTAN -- 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] watchdog: Add Broadcom BCM2835 watchdog timer driver
On 03/27/2013 10:40 AM, Lubomir Rintel wrote: > This adds a driver for watchdog timer hardware present on Broadcom BCM2835 > SoC, > used in Raspberry Pi and Roku 2 devices. > > Signed-off-by: Lubomir Rintel > Signed-off-by: Dom Cobley Those two s-o-b lines should be swapped, since if Dom did sign off on any part of this patch, he did it before you did. That said... I wonder if it's actually appropriate to include Dom's s-o-b here, since I don't think he really wrote this patch itself. I think you mentioned that you hadn't use much of the downstream driver except for some defines? To be clear, I mentioned the existence of the S-o-b line downstream simply to demonstrate that the commits you were getting information from had correctly followed the process described in Documentation/SubmittingPatches, and so it was OK to use that information while creating a GPL'd driver. So there are a couple of ways that this patch could have been created: 1) You took the downstream commit itself, cherry-picked it into the upstream kernel, modified it to suit upstream, and then submitted that. The modifications might be extensive, such as renaming the file, removing parts of the code that the upstream watchdog core now handles, adding some new features, fixing bugs, cleanup, etc.; whatever is needed to upstream the patch. In this case, I believe it would be appropriate to maintain any S-o-b lines from the original downstream commit, and add yours. But, I believe you should also (a) maintain the git author field from the original downstream commit (b) include a list of the changes you made to the patch in the commit description, so you can be blamed for them rather than the original author:-) 2) You read the downstream commit for information, but created a completely new driver for the upstream kernel, using the downstream driver just as a reference. In this case, I believe it's fine for the git author field to be you, and for the only s-o-b line present to be yours, since you really did write the patch from scratch. However, you should credit the downstream work in the (c) header and/or commit description. This current patch sees to be a slight hybrid of both approaches (you're listed as the git author, but have included Dom's s-o-b line on a patch I don't think he created, and wasn't directly derived from one he created). I'm not sure if I'm being too picky. I guess I'll leave it up to Wim Van Sebroeck, since he's the watchdog maintainer and would be the person who applies this patch. -- 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] ia64: Fix example error_injection_tool
I got a "sched_setaffinity:: Invalid argument" error when using err_injection_tool to inject error on a system with over 32 cpus. Error information when injecting an error on a system with over 32 cpus: $ ./err_injection_tool -i /sys/devices/system/cpu/cpu0/err_inject//err_type_info Begine at Tue Mar 26 11:20:08 2013 Configurations: On cpu32: loop=10, interval=5(s) err_type_info=4101,err_struct_info=95 Error sched_setaffinity:: Invalid argument All done This because there is overflow when calculating the cpumask: the type of (1< 31, (1< --- Documentation/ia64/err_inject.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt index 223e4f0..ec61ac1 100644 --- a/Documentation/ia64/err_inject.txt +++ b/Documentation/ia64/err_inject.txt @@ -882,7 +882,7 @@ int err_inj() cpu=parameters[i].cpu; k = cpu%64; j = cpu/64; - mask[j]=1
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Wed, Mar 20, 2013 at 11:52:47AM +0100, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel
> Reviewed-by: Shawn Guo
> Acked-by: Grant Likely
> ---
> Changes since v8:
> - Changed device tree compatible string to "mmio-sram"
> ---
> arch/arm/boot/dts/imx53.dtsi |5 +
> arch/arm/boot/dts/imx6q.dtsi |6 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index edc3f1e..69d0680 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -664,5 +664,10 @@
> status = "disabled";
> };
> };
> +
> + ocram: ocram@f800 {
> + compatible = "fsl,imx-ocram", "mmio-sram";
We should probably just drop "fsl,imx-ocram".
Shawn
> + reg = <0xf800 0x2>;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index ff1205e..73302db 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -124,6 +124,12 @@
> status = "disabled";
> };
>
> + ocram: ocram@0090 {
> + compatible = "fsl,imx-ocram", "mmio-sram";
> + reg = <0x0090 0x3f000>;
> + clocks = < 142>;
> + };
> +
> timer@00a00600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x00a00600 0x20>;
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: intel_pstate_timer_func divide by zero oops
Is there any way to capture the beginning of this trace? pid_param_set() is on the stack which means that something is changing the debugfs parameters or the stack is FUBAR. On 03/27/2013 06:49 PM, Parag Warudkar wrote: I get this same oops occassionally - the machine freezes and there doesn't seem to be any record of the oops on disk. That is - sample->pstate_pct_busy = 100 - div64_u64( sample->idletime_us * 100, sample->duration_us); I don't see how duration_us can be zero unless somehow I am getting back-to-back timer callbacks which seems unlikely since the timer is not re-armed until the timer function is about to return and the driver has done all its work for the sample period --Dirk So looks like sample->duration_us is 0? If so, that implies that ktime_us_delta(now, cpu->prev_sample) is zero. I am not entirely sure how to handle this case - return if sampling too early, or if there is some other bug making the delta calculation go poof. Thanks, Parag -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd trial
Dear Denis,
Yes, I can tell more detail, Should I re-do the patch and submit again?
I will revise the log as below: (Please help comment again, thanks.)
- Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
-
- The chip of DM9000B(DSP) is different in internal PHY compare to
DM9000A(analog) and
- DM9000E(analog).
- This patch add a PHY RESET and a PHY INIT PARAMETER settings in
- "dm9000_init_dm9000()", and
- This patch change set DM9000_NCR by reset-bit to be set DM9000_NCR by
reset-bit
- conjunction with mac_loopback-bit in "dm9000_probe()".
- The driver could get wrong DM9000B FIFO(internal) state during driver
initialize, But not each
- target board case, error rate is around 2%.
- We patch the driver this way to solve this initial fatal issue.
Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin Rd. VI, Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw
-Original Message-
From: Denis Kirjanov [mailto:k...@linux-powerpc.org]
Sent: Wednesday, March 27, 2013 9:14 PM
To: Joseph CHANG
Cc: David S. Miller; Bill Pemberton; Matthew Leach; Greg Kroah-Hartman; Joseph
CHANG; Jiri Pirko; net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ethernet: dm9000 driver: davicom: upgrade driver: 3rd
trial
It's not clear from your log what was wrong with the driver. Could you
please update the log message.
On 3/27/13, Joseph CHANG wrote:
> Fixing bug for DM9000B(DSP) which is a DSP revision! 3rd trial.
>
> Tested to Davicom DM9000 series include DM9000E(analog),
> DM9000A(analog), DM9000B(DSP), and DM9000C(DSP) in X86 and
> ARM Embedded Linux these years.
>
> Signed-off-by: Joseph CHANG
> ---
> drivers/net/ethernet/davicom/dm9000.c | 219
> +
> drivers/net/ethernet/davicom/dm9000.h | 11 ++-
> 2 files changed, 124 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/net/ethernet/davicom/dm9000.c
> b/drivers/net/ethernet/davicom/dm9000.c
> index 8cdf025..9dd4bd6 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
> @@ -47,7 +47,7 @@
> #define DM9000_PHY 0x40/* PHY address 0x01 */
>
> #define CARDNAME "dm9000"
> -#define DRV_VERSION "1.31"
> +#define DRV_VERSION "1.39"
>
> /*
> * Transmit timeout, default 5 seconds.
> @@ -257,6 +257,109 @@ static void dm9000_dumpblk_32bit(void __iomem *reg,
> int count)
> tmp = readl(reg);
> }
>
> +/*
> + * Sleep, either by using msleep() or if we are suspending, then
> + * use mdelay() to sleep.
> + */
> +static void dm9000_msleep(board_info_t *db, unsigned int ms)
> +{
> + if (db->in_suspend)
> + mdelay(ms);
> + else
> + msleep(ms);
> +}
> +
> +/*
> + * Read a word from phyxcer
> + */
> +static int
> +dm9000_phy_read(struct net_device *dev, int phy_reg_unused, int reg)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned int reg_save;
> + int ret;
> +
> + mutex_lock(>addr_lock);
> +
> + spin_lock_irqsave(>lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + iow(db, DM9000_EPCR, EPCR_ERPRR | EPCR_EPOS); /* Issue phyxcer read
> command */
> +
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(>lock,flags);
> +
> + dm9000_msleep(db, 1); /* Wait read complete */
> +
> + spin_lock_irqsave(>lock,flags);
> + reg_save = readb(db->io_addr);
> +
> + iow(db, DM9000_EPCR, 0x0); /* Clear phyxcer read command */
> +
> + /* The read data keeps on REG_0D & REG_0E */
> + ret = (ior(db, DM9000_EPDRH) << 8) | ior(db, DM9000_EPDRL);
> +
> + /* restore the previous address */
> + writeb(reg_save, db->io_addr);
> + spin_unlock_irqrestore(>lock,flags);
> +
> + mutex_unlock(>addr_lock);
> +
> + dm9000_dbg(db, 5, "phy_read[%02x] -> %04x\n", reg, ret);
> + return ret;
> +}
> +
> +/*
> + * Write a word to phyxcer
> + */
> +static void
> +dm9000_phy_write(struct net_device *dev,
> + int phyaddr_unused, int reg, int value)
> +{
> + board_info_t *db = netdev_priv(dev);
> + unsigned long flags;
> + unsigned long reg_save;
> +
> + dm9000_dbg(db, 5, "phy_write[%02x] = %04x\n", reg, value);
> + mutex_lock(>addr_lock);
> +
> + spin_lock_irqsave(>lock,flags);
> +
> + /* Save previous register address */
> + reg_save = readb(db->io_addr);
> +
> + /* Fill the phyxcer register into REG_0C */
> + iow(db, DM9000_EPAR, DM9000_PHY | reg);
> +
> + /* Fill the written data into REG_0D & REG_0E */
> + iow(db, DM9000_EPDRL, value);
> + iow(db, DM9000_EPDRH, value >> 8);
> +
> + iow(db, DM9000_EPCR, EPCR_EPOS |
Re: [PATCH v7 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver
On 28 March 2013 03:48, Guenter Roeck wrote: > On Wed, Mar 27, 2013 at 03:13:32PM +0800, Hongbo Zhang wrote: >> Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500 >> chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for >> all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this >> designed >> structure, other chip specific files can be added simply using the same >> common >> layer abx500.c. >> >> Signed-off-by: Hongbo Zhang > > Reviewed-by: Guenter Roeck Thank you very much, Guenter. -- 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] i2c: remove CONFIG_HOTPLUG ifdefs
CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in i2c files.
Signed-off-by: Yijing Wang
---
drivers/i2c/i2c-core.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 991d38d..d1db97e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -91,7 +91,6 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
return 0;
}
-#ifdef CONFIG_HOTPLUG
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
@@ -105,10 +104,6 @@ static int i2c_device_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
-#else
-#define i2c_device_uevent NULL
-#endif /* CONFIG_HOTPLUG */
-
static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
--
1.7.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/2] mm: remove CONFIG_HOTPLUG ifdefs
CONFIG_HOTPLUG is going away as an option, cleanup CONFIG_HOTPLUG
ifdefs in mm files.
Signed-off-by: Yijing Wang
Cc: Minchan Kim
Cc: Mel Gorman
Cc: Bartlomiej Zolnierkiewicz
Cc: Rik van Riel
Cc: Hugh Dickins
Cc: Bill Pemberton
Cc: Greg Kroah-Hartman
---
include/linux/vmstat.h |7 +--
mm/vmstat.c|2 --
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index 5fd71a7..c586679 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -48,13 +48,8 @@ static inline void count_vm_events(enum vm_event_item item,
long delta)
}
extern void all_vm_events(unsigned long *);
-#ifdef CONFIG_HOTPLUG
+
extern void vm_events_fold_cpu(int cpu);
-#else
-static inline void vm_events_fold_cpu(int cpu)
-{
-}
-#endif
#else
diff --git a/mm/vmstat.c b/mm/vmstat.c
index e1d8ed1..c823776 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -52,7 +52,6 @@ void all_vm_events(unsigned long *ret)
}
EXPORT_SYMBOL_GPL(all_vm_events);
-#ifdef CONFIG_HOTPLUG
/*
* Fold the foreign cpu events into our own.
*
@@ -69,7 +68,6 @@ void vm_events_fold_cpu(int cpu)
fold_state->event[i] = 0;
}
}
-#endif /* CONFIG_HOTPLUG */
#endif /* CONFIG_VM_EVENT_COUNTERS */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 0/5] virtio-scsi multiqueue
On 03/23/2013 07:28 PM, Wanlong Gao wrote: > This series implements virtio-scsi queue steering, which gives > performance improvements of up to 50% (measured both with QEMU and > tcm_vhost backends). > > This version rebased on Rusty's virtio ring rework patches, which > has already gone into virtio-next today. > We hope this can go into virtio-next together with the virtio ring > rework pathes. > > V7: respin to fix the patch apply error > > V6: rework "redo allocation of target data" (James) > fix comments (Venkatesh) > rebase to virtio-next > > V5: improving the grammar of 1/5 (Paolo) > move the dropping of sg_elems to 'virtio-scsi: use virtqueue_add_sgs for > command buffers'. (Asias) > > V4: rebase on virtio ring rework patches (rusty's pending-rebases branch) > > V3 and be found http://marc.info/?l=linux-virtualization=136067440717154=2 > > > It would probably be easier to get it in via Rusty's tree > because of the prerequisites. James, can we get your Acked-by? James, any thoughts for this version? Thanks, Wanlong Gao > > Paolo Bonzini (3): > virtio-scsi: pass struct virtio_scsi to virtqueue completion function > virtio-scsi: push vq lock/unlock into virtscsi_vq_done > virtio-scsi: introduce multiqueue support > > Wanlong Gao (2): > virtio-scsi: redo allocation of target data > virtio-scsi: reset virtqueue affinity when doing cpu hotplug > > drivers/scsi/virtio_scsi.c | 387 > - > 1 file changed, 309 insertions(+), 78 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: Davicom Linux driver
This is not the correct way to submit a patch for inclusion upstream You should post each patch in a seperate, numbered, list posting, in plain ASCII text, and not as an attachment. -- 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] cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate()
On Wed, Mar 27, 2013 at 11:46:38PM +0100, Guennadi Liakhovetski wrote: > Hi Shawn > > On Mon, 25 Feb 2013, Guennadi Liakhovetski wrote: > > > clk_set_rate() isn't supposed to accept approximate frequencies, instead > > a supported frequency should be obtained from clk_round_rate() and then > > used to set the clock. > > > > Signed-off-by: Guennadi Liakhovetski > > Can I have your ack for this one, please? Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: remove swapcache page early
On Thu, Mar 28, 2013 at 10:18:24AM +0900, Minchan Kim wrote: > On Wed, Mar 27, 2013 at 04:16:48PM -0700, Hugh Dickins wrote: > > On Wed, 27 Mar 2013, Dan Magenheimer wrote: > > > > From: Hugh Dickins [mailto:hu...@google.com] > > > > Subject: Re: [RFC] mm: remove swapcache page early > > > > > > > > On Wed, 27 Mar 2013, Minchan Kim wrote: > > > > > > > > > Swap subsystem does lazy swap slot free with expecting the page > > > > > would be swapped out again so we can't avoid unnecessary write. > > > > so we can avoid unnecessary write. > > > > > > > > > > But the problem in in-memory swap is that it consumes memory space > > > > > until vm_swap_full(ie, used half of all of swap device) condition > > > > > meet. It could be bad if we use multiple swap device, small in-memory > > > > > swap > > > > > and big storage swap or in-memory swap alone. > > > > > > > > That is a very good realization: it's surprising that none of us > > > > thought of it before - no disrespect to you, well done, thank you. > > > > > > Yes, my compliments also Minchan. This problem has been thought of before > > > but this patch is the first to identify a possible solution. > > > > > > > And I guess swap readahead is utterly unhelpful in this case too. > > > > > > Yes... as is any "swap writeahead". Excuse my ignorance, but I > > > think this is not done in the swap subsystem but instead the kernel > > > assumes write-coalescing will be done in the block I/O subsystem, > > > which means swap writeahead would affect zram but not zcache/zswap > > > (since frontswap subverts the block I/O subsystem). > > > > I don't know what swap writeahead is; but write coalescing, yes. > > I don't see any problem with it in this context. > > > > > > > > However I think a swap-readahead solution would be helpful to > > > zram as well as zcache/zswap. > > > > Whereas swap readahead on zmem is uncompressing zmem to pagecache > > which may never be needed, and may take a circuit of the inactive > > LRU before it gets reclaimed (if it turns out not to be needed, > > at least it will remain clean and be easily reclaimed). > > But it could evict more important pages before reaching out the tail. > That's thing we really want to avoid if possible. > > > > > > > > > > > This patch changes vm_swap_full logic slightly so it could free > > > > > swap slot early if the backed device is really fast. > > > > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > > > > > > > But I strongly disagree with almost everything in your patch :) > > > > I disagree with addressing it in vm_swap_full(), I disagree that > > > > it can be addressed by device, I disagree that it has anything to > > > > do with SWP_SOLIDSTATE. > > > > > > > > This is not a problem with swapping to /dev/ram0 or to /dev/zram0, > > > > is it? In those cases, a fixed amount of memory has been set aside > > > > for swap, and it works out just like with disk block devices. The > > > > memory set aside may be wasted, but that is accepted upfront. > > > > > > It is (I believe) also a problem with swapping to ram. Two > > > copies of the same page are kept in memory in different places, > > > right? Fixed vs variable size is irrelevant I think. Or am > > > I misunderstanding something about swap-to-ram? > > > > I may be misrembering how /dev/ram0 works, or simply assuming that > > if you want to use it for swap (interesting for testing, but probably > > not for general use), then you make sure to allocate each page of it > > in advance. > > > > The pages of /dev/ram0 don't get freed, or not before it's closed > > (swapoff'ed) anyway. Yes, swapcache would be duplicating data from > > other memory into /dev/ram0 memory; but that /dev/ram0 memory has > > been set aside for this purpose, and removing from swapcache won't > > free any more memory. > > > > > > > > > Similarly, this is not a problem with swapping to SSD. There might > > > > or might not be other reasons for adjusting the vm_swap_full() logic > > > > for SSD or generally, but those have nothing to do with this issue. > > > > > > I think it is at least highly related. The key issue is the > > > tradeoff of the likelihood that the page will soon be read/written > > > again while it is in swap cache vs the time/resource-usage necessary > > > to "reconstitute" the page into swap cache. Reconstituting from disk > > > requires a LOT of elapsed time. Reconstituting from > > > an SSD likely takes much less time. Reconstituting from > > > zcache/zram takes thousands of CPU cycles. > > > > I acknowledge my complete ignorance of how to judge the tradeoff > > between memory usage and cpu usage, but I think Minchan's main > > concern was with the memory usage. Neither hard disk nor SSD > > is occupying memory. > > Hmm, It seems I misunderstood Dan's opinion in previous thread. > You're right, Hugh. My main concern is memory usage but the rationale > I used SWP_SOLIDSTATE is
smartd broken in 3.9.0-rc4
Hi, just tested my first 3.9 kernel today. During boot, smartd (from smartmontools-6.0) fails to start. Works fine in 3.8.4. In 3.8.4 I get messages like this : Mar 27 22:02:02 ac4tv smartd[3981]: smartd 6.0 2012-10-10 r3643 [x86_64-linux-3.8.4] (local build) Mar 27 22:02:02 ac4tv smartd[3981]: Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org Mar 27 22:02:02 ac4tv smartd[3981]: Opened configuration file /etc/smartd.conf Mar 27 22:02:02 ac4tv smartd[3981]: Configuration file /etc/smartd.conf parsed. Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, opened Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, WDC WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, FW:15.01H15, 500 GB Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, found in smartd database: Western Digital Caviar Blue Serial ATA Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, enabled SMART Automatic Offline Testing. Mar 27 22:02:02 ac4tv smartd[3981]: Device: /dev/sda, is SMART capable. Adding to "monitor" list. Mar 27 22:02:02 ac4tv smartd[3981]: Monitoring 1 ATA and 0 SCSI devices but in 3.9.0-rc4 all I get is Mar 28 00:39:32 ac4tv smartd[2487]: Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org Mar 28 00:39:32 ac4tv smartd[2487]: Opened configuration file /etc/smartd.conf Mar 28 00:39:32 ac4tv smartd[2487]: Configuration file /etc/smartd.conf parsed. Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, opened Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, WDC WD5000AAKX-001CA0, S/N:WD-WMAYU6818967, WWN:5-0014ee-0ad9caed4, FW:15.01H15, 500 GB Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, found in smartd database: Western Digital Caviar Blue Serial ATA Mar 28 00:39:32 ac4tv smartd[2487]: Device: /dev/sda, could not enable SMART capability Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register ATA device /dev/sda at line 1 of file /etc/smartd.conf Mar 28 00:39:32 ac4tv smartd[2487]: Unable to register device /dev/sda (no Directive -d removable). Exiting. Using strace, in the failing version I get 2643 ioctl(3, HDIO_DRIVE_CMD, 0x7fff53288a60) = -1 EIO (Input/output error) instead of the normal 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437340) = 0 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437350) = 0 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 3981 ioctl(3, HDIO_DRIVE_CMD, 0x7fff04437330) = 0 3981 ioctl(3, HDIO_DRIVE_TASK, 0x7fff04437340) = 0 Looks like I'll be bisecting. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- 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: [Suggestion] drivers/block/aoe: using uninitialized variable.
On 2013年03月27日 22:04, Ed Cashin wrote: > Thanks. Jens Axboe said about it to Dan Carpenter that ... > >> > It was fixed up yesterday, it was a merge error in the for-next branch. thanks. :-) -- Chen Gang Flying Transformer -- 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_pstate_timer_func divide by zero oops
I get this same oops occassionally - the machine freezes and there doesn't
seem to be any record of the oops on disk.
I captured it on camera -
https://lh3.googleusercontent.com/-K0lNbJrZBMQ/UVOU1vv1vvI/NqI/pY92mWm3caE/s800/20130327_205245.jpg
If I am reading this right, it dies on this instruction -
0x8145792d <+349>: divq 0x18(%rcx)
>From the lst file that *seems* to be this inline function -
static inline void intel_pstate_calc_busy(struct cpudata *cpu,
struct sample *sample)
{
u64 core_pct;
sample->pstate_pct_busy = 100 - div64_u64(
8145791d: 48 8b 41 20 mov0x20(%rcx),%rax
81457921: 48 8d 04 80 lea(%rax,%rax,4),%rax
81457925: 48 8d 04 80 lea(%rax,%rax,4),%rax
81457929: 48 c1 e0 02 shl$0x2,%rax
8145792d: 48 f7 71 18 divq 0x18(%rcx)
That is -
sample->pstate_pct_busy = 100 - div64_u64(
sample->idletime_us * 100,
sample->duration_us);
So looks like sample->duration_us is 0? If so, that implies that
ktime_us_delta(now, cpu->prev_sample) is zero. I am not entirely sure how
to handle this case - return if sampling too early, or if there is some
other bug making the delta calculation go poof.
Thanks,
Parag
--
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] kernel/range.c: subtract_range: fix the broken phrase issued by printk
Hi Bjorn and others,
On 03/28/2013 01:27 AM, Bjorn Helgaas wrote:
>> - printk(KERN_ERR "run of slot in ranges\n");
>> > + pr_err("%s: run out of slot in ranges\n",
>> > + __func__);
>> > }
>> > range[j].end = start;
>> > continue;
> So now the user might see:
>
> subtract_range: run out of slot in ranges
>
> What is the user supposed to do when he sees that? If he happens to
> mention it on LKML, what are we going to do about it? If he attaches
> the complete dmesg log, is there enough information to do something?
>
> IMHO, that message is still totally useless.
>
Yes, we need to issue some useful message.
How about dump_stack() there so that we can find some clues more since
subtract_range() is called mtrr_bp_init path and pci relative path, then
it may help to instruct us to do something ;-) ?
thanks,
linfeng
--
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] video: mmp: removed reference preceded by free
On 03/28/2013 04:48 AM, Andrei Epure wrote: Patch found with coccinelle. Signed-off-by: Andrei Epure --- drivers/video/mmp/core.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c index 9ed8341..84de263 100644 --- a/drivers/video/mmp/core.c +++ b/drivers/video/mmp/core.c @@ -252,7 +252,5 @@ void mmp_unregister_path(struct mmp_path *path) kfree(path); mutex_unlock(_lock); - - dev_info(path->dev, "de-register %s\n", path->name); } EXPORT_SYMBOL_GPL(mmp_unregister_path); Acked-by: Zhou Zhu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: remove swapcache page early
Hi Seth, On Wed, Mar 27, 2013 at 12:19:11PM -0500, Seth Jennings wrote: > On 03/26/2013 09:22 PM, Minchan Kim wrote: > > Swap subsystem does lazy swap slot free with expecting the page > > would be swapped out again so we can't avoid unnecessary write. > > > > But the problem in in-memory swap is that it consumes memory space > > until vm_swap_full(ie, used half of all of swap device) condition > > meet. It could be bad if we use multiple swap device, small in-memory swap > > and big storage swap or in-memory swap alone. > > > > This patch changes vm_swap_full logic slightly so it could free > > swap slot early if the backed device is really fast. > > Great idea! Thanks! > > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > The comment for SWP_SOLIDSTATE is that "blkdev seeks are cheap". Just > because seeks are cheap doesn't mean the read itself is also cheap. The "read" isn't not concern but "write". > For example, QUEUE_FLAG_NONROT is set for mmc devices, but some of > them can be pretty slow. Yeb. > > > So let's add Ccing Shaohua and Hugh. > > If it's a problem for SSD, I'd like to create new type SWP_INMEMORY > > or something for z* family. > > Afaict, setting SWP_SOLIDSTATE depends on characteristics of the > underlying block device (i.e. blk_queue_nonrot()). zram is a block > device but zcache and zswap are not. > > Any idea by what criteria SWP_INMEMORY would be set? Just in-memory swap, zram, zswap and zcache at the moment. :) > > Also, frontswap backends (zcache and zswap) are a caching layer on top > of the real swap device, which might actually be rotating media. So > you have the issue of to different characteristics, in-memory caching > on top of rotation media, present in a single swap device. Please read my patch completely. I already pointed out the problem and Hugh and Dan are suggesting ideas. Thanks! > > Thanks, > Seth > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- 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/
[patch] mm, memcg: give exiting processes access to memory reserves
A memcg may livelock when oom if the process that grabs the hierarchy's
oom lock is never the first process with PF_EXITING set in the memcg's
task iteration.
The oom killer, both global and memcg, will defer if it finds an eligible
process that is in the process of exiting and it is not being ptraced.
The idea is to allow it to exit without using memory reserves before
needlessly killing another process.
This normally works fine except in the memcg case with a large number of
threads attached to the oom memcg. In this case, the memcg oom killer
only gets called for the process that grabs the hierarchy's oom lock; all
others end up blocked on the memcg's oom waitqueue. Thus, if the process
that grabs the hierarchy's oom lock is never the first PF_EXITING process
in the memcg's task iteration, the oom killer is constantly deferred
without anything making progress.
The fix is to give PF_EXITING processes access to memory reserves so that
we've marked them as oom killed without any iteration. This allows
__mem_cgroup_try_charge() to succeed so that the process may exit. This
makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
immediately granted for processes with pending SIGKILLs and those in the
exit path, to be equivalent to what is done for the global oom killer.
Signed-off-by: David Rientjes
---
mm/memcontrol.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1686,11 +1686,11 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup
*memcg, gfp_t gfp_mask,
struct task_struct *chosen = NULL;
/*
-* If current has a pending SIGKILL, then automatically select it. The
-* goal is to allow it to allocate so that it may quickly exit and free
-* its memory.
+* If current has a pending SIGKILL or is exiting, then automatically
+* select it. The goal is to allow it to allocate so that it may
+* quickly exit and free its memory.
*/
- if (fatal_signal_pending(current)) {
+ if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
set_thread_flag(TIF_MEMDIE);
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] power: pass IRQF_ONESHOT to request_threaded_irq()
> -Original Message- > From: Andrei Epure [mailto:epure.and...@gmail.com] > Sent: Thursday, March 28, 2013 9:43 AM > To: c...@mail.ru; dw...@infradead.org; Kim, Milo; > broo...@opensource.wolfsonmicro.com; linux-kernel@vger.kernel.org; > patc...@opensource.wolfsonmicro.com > Cc: Andrei Epure > Subject: [PATCH] power: pass IRQF_ONESHOT to request_threaded_irq() > > Patch found using coccinelle. > > Signed-off-by: Andrei Epure > --- > drivers/power/ab8500_btemp.c |2 +- > drivers/power/ab8500_charger.c |2 +- > drivers/power/ab8500_fg.c|2 +- > drivers/power/lp8788-charger.c |2 +- > drivers/power/max17042_battery.c |3 ++- > drivers/power/max8903_charger.c | 12 +--- > drivers/power/pm2301_charger.c |2 +- > drivers/power/smb347-charger.c |3 ++- > drivers/power/wm831x_power.c |8 +--- > 9 files changed, 23 insertions(+), 13 deletions(-) Could you share what will happen without this patch? Do you mean the IRQF_ONESHOT flag with a primary IRQ handler? If yes, no need to handle this for lp8788-charger driver because it is a nested handler rather a default primary handler. Handler function is replaced with irq_nested_primary_handler() on setting up the IRQ. Thanks. Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: remove swapcache page early
On Wed, Mar 27, 2013 at 04:16:48PM -0700, Hugh Dickins wrote: > On Wed, 27 Mar 2013, Dan Magenheimer wrote: > > > From: Hugh Dickins [mailto:hu...@google.com] > > > Subject: Re: [RFC] mm: remove swapcache page early > > > > > > On Wed, 27 Mar 2013, Minchan Kim wrote: > > > > > > > Swap subsystem does lazy swap slot free with expecting the page > > > > would be swapped out again so we can't avoid unnecessary write. > > > so we can avoid unnecessary write. > > > > > > > > But the problem in in-memory swap is that it consumes memory space > > > > until vm_swap_full(ie, used half of all of swap device) condition > > > > meet. It could be bad if we use multiple swap device, small in-memory > > > > swap > > > > and big storage swap or in-memory swap alone. > > > > > > That is a very good realization: it's surprising that none of us > > > thought of it before - no disrespect to you, well done, thank you. > > > > Yes, my compliments also Minchan. This problem has been thought of before > > but this patch is the first to identify a possible solution. > > > > > And I guess swap readahead is utterly unhelpful in this case too. > > > > Yes... as is any "swap writeahead". Excuse my ignorance, but I > > think this is not done in the swap subsystem but instead the kernel > > assumes write-coalescing will be done in the block I/O subsystem, > > which means swap writeahead would affect zram but not zcache/zswap > > (since frontswap subverts the block I/O subsystem). > > I don't know what swap writeahead is; but write coalescing, yes. > I don't see any problem with it in this context. > > > > > However I think a swap-readahead solution would be helpful to > > zram as well as zcache/zswap. > > Whereas swap readahead on zmem is uncompressing zmem to pagecache > which may never be needed, and may take a circuit of the inactive > LRU before it gets reclaimed (if it turns out not to be needed, > at least it will remain clean and be easily reclaimed). But it could evict more important pages before reaching out the tail. That's thing we really want to avoid if possible. > > > > > > > This patch changes vm_swap_full logic slightly so it could free > > > > swap slot early if the backed device is really fast. > > > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > > > > > But I strongly disagree with almost everything in your patch :) > > > I disagree with addressing it in vm_swap_full(), I disagree that > > > it can be addressed by device, I disagree that it has anything to > > > do with SWP_SOLIDSTATE. > > > > > > This is not a problem with swapping to /dev/ram0 or to /dev/zram0, > > > is it? In those cases, a fixed amount of memory has been set aside > > > for swap, and it works out just like with disk block devices. The > > > memory set aside may be wasted, but that is accepted upfront. > > > > It is (I believe) also a problem with swapping to ram. Two > > copies of the same page are kept in memory in different places, > > right? Fixed vs variable size is irrelevant I think. Or am > > I misunderstanding something about swap-to-ram? > > I may be misrembering how /dev/ram0 works, or simply assuming that > if you want to use it for swap (interesting for testing, but probably > not for general use), then you make sure to allocate each page of it > in advance. > > The pages of /dev/ram0 don't get freed, or not before it's closed > (swapoff'ed) anyway. Yes, swapcache would be duplicating data from > other memory into /dev/ram0 memory; but that /dev/ram0 memory has > been set aside for this purpose, and removing from swapcache won't > free any more memory. > > > > > > Similarly, this is not a problem with swapping to SSD. There might > > > or might not be other reasons for adjusting the vm_swap_full() logic > > > for SSD or generally, but those have nothing to do with this issue. > > > > I think it is at least highly related. The key issue is the > > tradeoff of the likelihood that the page will soon be read/written > > again while it is in swap cache vs the time/resource-usage necessary > > to "reconstitute" the page into swap cache. Reconstituting from disk > > requires a LOT of elapsed time. Reconstituting from > > an SSD likely takes much less time. Reconstituting from > > zcache/zram takes thousands of CPU cycles. > > I acknowledge my complete ignorance of how to judge the tradeoff > between memory usage and cpu usage, but I think Minchan's main > concern was with the memory usage. Neither hard disk nor SSD > is occupying memory. Hmm, It seems I misunderstood Dan's opinion in previous thread. You're right, Hugh. My main concern is memory usage but the rationale I used SWP_SOLIDSTATE is writing on SSD could be cheap rather than storage. Yeb, it depends on SSD's internal's FTL algorith and fragment ratio due to wear-leveling. That's why I said "It might be controversial". > > > > > > The problem here is peculiar to frontswap, and the variably
Re: [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q
On Wed, Mar 27, 2013 at 03:29:10PM -0700, Andrew Morton wrote: > On Wed, 20 Mar 2013 11:52:47 +0100 Philipp Zabel > wrote: > > > Signed-off-by: Philipp Zabel > > Reviewed-by: Shawn Guo > > Acked-by: Grant Likely > > --- > > Changes since v8: > > - Changed device tree compatible string to "mmio-sram" > > --- > > arch/arm/boot/dts/imx53.dtsi |5 + > > arch/arm/boot/dts/imx6q.dtsi |6 ++ > > This doesn't apply, due to stuff which is pending in linux-next. I had > a go at fixing it but ran out of confidence - those files have changed > significantly. > > Redo and resend, please? We will merge this patch via IMX tree. Shawn -- 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 v9 RESEND 3/4] media: coda: use genalloc API
On Wed, Mar 20, 2013 at 11:52:46AM +0100, Philipp Zabel wrote: > This patch depends on "genalloc: add devres support, allow to find > a managed pool by device", which provides the of_get_named_gen_pool > and dev_get_gen_pool functions. > > Signed-off-by: Philipp Zabel > Acked-By: Javier Martin > Acked-by: Grant Likely > --- > Documentation/devicetree/bindings/media/coda.txt | 30 +++ > drivers/media/platform/Kconfig |1 - > drivers/media/platform/coda.c| 45 > +++--- > include/linux/platform_data/coda.h | 18 + > 4 files changed, 79 insertions(+), 15 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/coda.txt > create mode 100644 include/linux/platform_data/coda.h > > diff --git a/Documentation/devicetree/bindings/media/coda.txt > b/Documentation/devicetree/bindings/media/coda.txt > new file mode 100644 > index 000..2865d04 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/coda.txt > @@ -0,0 +1,30 @@ > +Chips Coda multi-standard codec IP > + > + > +Coda codec IPs are present in i.MX SoCs in various versions, > +called VPU (Video Processing Unit). > + > +Required properties: > +- compatible : should be "fsl,-src" for i.MX SoCs: fsl,-vpu Shawn > + (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27 > + (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53 > + (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: remove swapcache page early
Hi Dan, On Wed, Mar 27, 2013 at 03:24:00PM -0700, Dan Magenheimer wrote: > > From: Hugh Dickins [mailto:hu...@google.com] > > Subject: Re: [RFC] mm: remove swapcache page early > > > > On Wed, 27 Mar 2013, Minchan Kim wrote: > > > > > Swap subsystem does lazy swap slot free with expecting the page > > > would be swapped out again so we can't avoid unnecessary write. > > so we can avoid unnecessary write. > > > > > > But the problem in in-memory swap is that it consumes memory space > > > until vm_swap_full(ie, used half of all of swap device) condition > > > meet. It could be bad if we use multiple swap device, small in-memory swap > > > and big storage swap or in-memory swap alone. > > > > That is a very good realization: it's surprising that none of us > > thought of it before - no disrespect to you, well done, thank you. > > Yes, my compliments also Minchan. This problem has been thought of before > but this patch is the first to identify a possible solution. Thanks! > > > And I guess swap readahead is utterly unhelpful in this case too. > > Yes... as is any "swap writeahead". Excuse my ignorance, but I > think this is not done in the swap subsystem but instead the kernel > assumes write-coalescing will be done in the block I/O subsystem, > which means swap writeahead would affect zram but not zcache/zswap > (since frontswap subverts the block I/O subsystem). Frankly speaking, I don't know why you mentioned "swap writeahead" in this point. Anyway, I dobut how it effect zram, too. A gain I can have a mind is compress ratio would be high thorough multiple page compression all at once. > > However I think a swap-readahead solution would be helpful to > zram as well as zcache/zswap. Hmm, why? swap-readahead is just hint to reduce big stall time to reduce on big seek overhead storage. But in-memory swap is no cost for seeking. So unnecessary swap-readahead can make memory pressure high and it could cause another page swap out so it could be swap-thrashing. And for good swap-readahead hit ratio, swap device shouldn't be fragmented. But as you know, there are many factor to prevent it in the kernel now and Shaohua is tackling on it. > > > > This patch changes vm_swap_full logic slightly so it could free > > > swap slot early if the backed device is really fast. > > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > > > But I strongly disagree with almost everything in your patch :) > > I disagree with addressing it in vm_swap_full(), I disagree that > > it can be addressed by device, I disagree that it has anything to > > do with SWP_SOLIDSTATE. > > > > This is not a problem with swapping to /dev/ram0 or to /dev/zram0, > > is it? In those cases, a fixed amount of memory has been set aside > > for swap, and it works out just like with disk block devices. The > > memory set aside may be wasted, but that is accepted upfront. > > It is (I believe) also a problem with swapping to ram. Two > copies of the same page are kept in memory in different places, > right? Fixed vs variable size is irrelevant I think. Or am > I misunderstanding something about swap-to-ram? > > > Similarly, this is not a problem with swapping to SSD. There might > > or might not be other reasons for adjusting the vm_swap_full() logic > > for SSD or generally, but those have nothing to do with this issue. > > I think it is at least highly related. The key issue is the > tradeoff of the likelihood that the page will soon be read/written > again while it is in swap cache vs the time/resource-usage necessary > to "reconstitute" the page into swap cache. Reconstituting from disk > requires a LOT of elapsed time. Reconstituting from > an SSD likely takes much less time. Reconstituting from > zcache/zram takes thousands of CPU cycles. Yeb. That's why I wanted to use SWP_SOLIDSTATE. > > > The problem here is peculiar to frontswap, and the variably sized > > memory behind it, isn't it? We are accustomed to using swap to free > > up memory by transferring its data to some other, cheaper but slower > > resource. > > Frontswap does make the problem more complex because some pages > are in "fairly fast" storage (zcache, needs decompression) and > some are on the actual (usually) rotating media. Fortunately, > differentiating between these two cases is just a table lookup > (see frontswap_test). Yeb, I thouht it could be a last resort because I'd like to avoid lookup every swapin if possible. > > > But in the case of frontswap and zmem (I'll say that to avoid thinking > > through which backends are actually involved), it is not a cheaper and > > slower resource, but the very same memory we are trying to save: swap > > is stolen from the memory under reclaim, so any duplication becomes > > counter-productive (if we ignore cpu compression/decompression costs: > > I have no idea how fair it is to do so, but anyone who chooses zmem > > is prepared to pay some cpu price for
Re: [PATCH] power: pass IRQF_ONESHOT to request_threaded_irq()
On Thu, Mar 28, 2013 at 02:42:50AM +0200, Andrei Epure wrote: > Patch found using coccinelle. > > Signed-off-by: Andrei Epure Some of these may be false positives especially for PMICs - often the interrupts are guaranteed to be generated from the interrupt controller on the device which runs in thread context. More generally though why not fix this in request_threaded_irq() itself, if there's no hard IRQ handler then add the flag transparently? It'd save boilerplate. Indeed I could've sworn someone did that... signature.asc Description: Digital signature
Re: [LKP] Commit ac3ebafa81a makes NHM EX/EP machines hung out since 3.9-rc1
On 03/28/2013 08:40 AM, Rafael J. Wysocki wrote: >> > >> > It fixes the problem on my 8 sockets Nehalem-EX that will hang around >> > ip_auto_config() >> > >> > Tested-by: Yinghai Lu >> > >> > Rafael, >> > Can you please push this one to Linus tree ? >> > As the offending patch was via your tree to upstream. > I will if there's no better way to address this issue before -rc6. If it can be pushed to upstream, please add: Reported-by: LKP project Reported-by: Xie ChanglongX -- Thanks Alex -- 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 21/21] power: fix invalid free of devm_ allocated data
The objects allocated by devm_* APIs are managed by devres and are freed when the device is detached. Hence there is no need to use kfree() explicitly. Patch found using coccinelle. Signed-off-by: Andrei Epure --- drivers/power/88pm860x_charger.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/power/88pm860x_charger.c b/drivers/power/88pm860x_charger.c index 4b37a5a..36fb4b5 100644 --- a/drivers/power/88pm860x_charger.c +++ b/drivers/power/88pm860x_charger.c @@ -714,7 +714,6 @@ out_irq: while (--i >= 0) free_irq(info->irq[i], info); out: - kfree(info); return ret; } @@ -728,7 +727,6 @@ static int pm860x_charger_remove(struct platform_device *pdev) free_irq(info->irq[0], info); for (i = 0; i < info->irq_nums; i++) free_irq(info->irq[i], info); - kfree(info); return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: pass IRQF_ONESHOT to request_threaded_irq()
Patch found using coccinelle.
Signed-off-by: Andrei Epure
---
drivers/power/ab8500_btemp.c |2 +-
drivers/power/ab8500_charger.c |2 +-
drivers/power/ab8500_fg.c|2 +-
drivers/power/lp8788-charger.c |2 +-
drivers/power/max17042_battery.c |3 ++-
drivers/power/max8903_charger.c | 12 +---
drivers/power/pm2301_charger.c |2 +-
drivers/power/smb347-charger.c |3 ++-
drivers/power/wm831x_power.c |8 +---
9 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c
index 0768906..31073cf 100644
--- a/drivers/power/ab8500_btemp.c
+++ b/drivers/power/ab8500_btemp.c
@@ -1105,7 +1105,7 @@ static int ab8500_btemp_probe(struct platform_device
*pdev)
for (i = 0; i < ARRAY_SIZE(ab8500_btemp_irq); i++) {
irq = platform_get_irq_byname(pdev, ab8500_btemp_irq[i].name);
ret = request_threaded_irq(irq, NULL, ab8500_btemp_irq[i].isr,
- IRQF_SHARED | IRQF_NO_SUSPEND,
+ IRQF_SHARED | IRQF_NO_SUSPEND | IRQF_ONESHOT,
ab8500_btemp_irq[i].name, di);
if (ret) {
diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
index 24b30b7..db16765 100644
--- a/drivers/power/ab8500_charger.c
+++ b/drivers/power/ab8500_charger.c
@@ -3366,7 +3366,7 @@ static int ab8500_charger_probe(struct platform_device
*pdev)
for (i = 0; i < ARRAY_SIZE(ab8500_charger_irq); i++) {
irq = platform_get_irq_byname(pdev, ab8500_charger_irq[i].name);
ret = request_threaded_irq(irq, NULL, ab8500_charger_irq[i].isr,
- IRQF_SHARED | IRQF_NO_SUSPEND,
+ IRQF_SHARED | IRQF_NO_SUSPEND | IRQF_ONESHOT,
ab8500_charger_irq[i].name, di);
if (ret != 0) {
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index 25dae4c..5d5cbb4 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -2749,7 +2749,7 @@ static int ab8500_fg_probe(struct platform_device *pdev)
for (i = 0; i < ARRAY_SIZE(ab8500_fg_irq); i++) {
irq = platform_get_irq_byname(pdev, ab8500_fg_irq[i].name);
ret = request_threaded_irq(irq, NULL, ab8500_fg_irq[i].isr,
- IRQF_SHARED | IRQF_NO_SUSPEND,
+ IRQF_SHARED | IRQF_NO_SUSPEND | IRQF_ONESHOT,
ab8500_fg_irq[i].name, di);
if (ret != 0) {
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
index 6d1f452..1ac1a76 100644
--- a/drivers/power/lp8788-charger.c
+++ b/drivers/power/lp8788-charger.c
@@ -519,7 +519,7 @@ static int lp8788_set_irqs(struct platform_device *pdev,
ret = request_threaded_irq(virq, NULL,
lp8788_charger_irq_thread,
- 0, name, pchg);
+ IRQF_ONESHOT, name, pchg);
if (ret)
break;
}
diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index d664ef5..b3cdd6d 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -751,7 +751,8 @@ static int max17042_probe(struct i2c_client *client,
if (client->irq) {
ret = request_threaded_irq(client->irq, NULL,
max17042_thread_handler,
- IRQF_TRIGGER_FALLING,
+ IRQF_TRIGGER_FALLING
+ | IRQF_ONESHOT,
chip->battery.name, chip);
if (!ret) {
reg = max17042_read_reg(client, MAX17042_CONFIG);
diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 14e2b96..5ed2be0 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -297,7 +297,9 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->dc_valid) {
ret = request_threaded_irq(gpio_to_irq(pdata->dok),
NULL, max8903_dcin,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_FALLING
+ | IRQF_TRIGGER_RISING
+ | IRQF_ONESHOT,
"MAX8903 DC IN", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for DC (%d)\n",
@@ -309,7 +311,9 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->usb_valid) {
ret = request_threaded_irq(gpio_to_irq(pdata->uok),
NULL, max8903_usbin,
-
linux-next: manual merge of the hid tree with Linus' tree
Hi Jiri,
Today's linux-next merge of the hid tree got a conflict in
drivers/hid/hid-multitouch.c between commit 4c43755506ec ("HID:
multitouch: fix touchpad buttons") from Linus' tree and commit
5b62efd8250d ("HID: multitouch: remove useless last_field_index field")
from the hid tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/hid/hid-multitouch.c
index 82e9211,aceaf6c..000
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@@ -680,11 -723,7 +727,7 @@@ static void mt_process_mt_event(struct
if (usage->usage_index + 1 == field->report_count) {
/* we only take into account the last report. */
if (usage->hid == td->last_slot_field)
- mt_complete_slot(td, field->hidinput->input);
+ mt_complete_slot(td, input);
-
- if (field->index == td->last_field_index
- && td->num_received >= td->num_expected)
- mt_sync_frame(td, field->hidinput->input);
}
}
pgplCg_yTKNS7.pgp
Description: PGP signature
Re: [RFC] mm: remove swapcache page early
Hi Hugh, On Wed, Mar 27, 2013 at 02:41:07PM -0700, Hugh Dickins wrote: > On Wed, 27 Mar 2013, Minchan Kim wrote: > > > Swap subsystem does lazy swap slot free with expecting the page > > would be swapped out again so we can't avoid unnecessary write. > so we can avoid unnecessary write. > > > > But the problem in in-memory swap is that it consumes memory space > > until vm_swap_full(ie, used half of all of swap device) condition > > meet. It could be bad if we use multiple swap device, small in-memory swap > > and big storage swap or in-memory swap alone. > > That is a very good realization: it's surprising that none of us > thought of it before - no disrespect to you, well done, thank you. > > And I guess swap readahead is utterly unhelpful in this case too. > > > > > This patch changes vm_swap_full logic slightly so it could free > > swap slot early if the backed device is really fast. > > For it, I used SWP_SOLIDSTATE but It might be controversial. > > But I strongly disagree with almost everything in your patch :) > I disagree with addressing it in vm_swap_full(), I disagree that > it can be addressed by device, I disagree that it has anything to > do with SWP_SOLIDSTATE. > > This is not a problem with swapping to /dev/ram0 or to /dev/zram0, > is it? In those cases, a fixed amount of memory has been set aside > for swap, and it works out just like with disk block devices. The Brd is okay but it seems you are miunderstanding zram. The zram doesn't reserve any memory and allocate dynamic memory when swap out happens so it can make duplicate space in pusdo block device and memory. > memory set aside may be wasted, but that is accepted upfront. > > Similarly, this is not a problem with swapping to SSD. There might > or might not be other reasons for adjusting the vm_swap_full() logic > for SSD or generally, but those have nothing to do with this issue. Yes. > > The problem here is peculiar to frontswap, and the variably sized > memory behind it, isn't it? We are accustomed to using swap to free Zram, too. > up memory by transferring its data to some other, cheaper but slower > resource. > > But in the case of frontswap and zmem (I'll say that to avoid thinking Frankly speaking, I couldn't understand what you means, frontswap and zmem. The frontswap is just layer for hook the swap subsystem. Real instance of frontswap is zcache and zswap at the moment. I will understand them as zcache and zswap. Okay? > through which backends are actually involved), it is not a cheaper and > slower resource, but the very same memory we are trying to save: swap > is stolen from the memory under reclaim, so any duplication becomes > counter-productive (if we ignore cpu compression/decompression costs: > I have no idea how fair it is to do so, but anyone who chooses zmem > is prepared to pay some cpu price for that). Agree. > > And because it's a frontswap thing, we cannot decide this by device: > frontswap may or may not stand in front of each device. There is no > problem with swapcache duplicated on disk (until that area approaches > being full or fragmented), but at the higher level we cannot see what > is in zmem and what is on disk: we only want to free up the zmem dup. That's what I really have a concern and why I begged idea. > > I believe the answer is for frontswap/zmem to invalidate the frontswap > copy of the page (to free up the compressed memory when possible) and > SetPageDirty on the PageUptodate PageSwapCache page when swapping in > (setting page dirty so nothing will later go to read it from the > unfreed location on backing swap disk, which was never written). You mean that zcache and zswap have to do garbage collection by some policy? It could be but how about zram? It's just pseudo block device and he don't have any knowledge on top of it. It could be swap or normal block device. I mean zram has no information of swap to handle it. > > We cannot rely on freeing the swap itself, because in general there > may be multiple references to the swap, and we only satisfy the one > which has faulted. It may or may not be a good idea to use rmap to > locate the other places to insert pte in place of swap entry, to > resolve them all at once; but we have chosen not to do so in the > past, and there's no need for that, if the zmem gets invalidated > and the swapcache page set dirty. Yes it could be better but as I mentioned above, it couldn't handle zram case. If there is a solution for zram, I will be happy. :) And another point, fronstwap is already percolated into swap subsystem very tightly. So I doubt adding one another hook is a really problem. Thanks for great comment, Hugh! > > Hugh > > > So let's add Ccing Shaohua and Hugh. > > If it's a problem for SSD, I'd like to create new type SWP_INMEMORY > > or something for z* family. > > > > Other problem is zram is block device so that it can set SWP_INMEMORY > > or SWP_SOLIDSTATE easily(ie,
Re: [LKP] Commit ac3ebafa81a makes NHM EX/EP machines hung out since 3.9-rc1
On Wednesday, March 27, 2013 09:36:44 AM Yinghai Lu wrote:
> On Tue, Mar 26, 2013 at 9:39 PM, Alex Shi wrote:
> > On 03/13/2013 10:27 AM, Changlong Xie wrote:
> >> Hi Len,
> >>
> >> FYI, since 3.9-rc1 our three NHM EP/EX LKP(linux kernel performance)
> >> test servers
> >> except SNB/IVB/WSM hung up unexpectly.
> >>
> >> We did git bisect for about 8 times on all servers, it said that the
> >> first bad commit is ac3ebafa.
> >>
> >> commit ac3ebafa81af76d65e4fb45c6388f08e90ddcc6d
> >> Author: Daniel Lezcano
> >> Date: Mon Feb 4 22:44:43 2013 +
> >
> > fixing patch for review:
> >
> >
> > ---
> > From 78a74aea386b0969909c2e4ae388024ce71fdb18 Mon Sep 17 00:00:00 2001
> > From: Alex Shi
> > Date: Tue, 26 Mar 2013 22:57:47 +0800
> > Subject: [PATCH] cpuidle/acpi: recover percpu acpi processor cstate
> >
> > Commit: ac3ebafa81af76d6 "ACPI / idle: remove usage of the statedata"
> > change the percpu processor cstate to a unify unique cstate in acpi
> > idle. That cause all our NHM box boot hang or panic.
> >
> > 2178751 Task dump for CPU 1:^M
> > 2178752 swapper/1 R running task 6736 0 1
> > 0x^M
> > 2178753 8801e8029dc8 8101cf96 8801e8029e28
> > 813d294b^M
> > 2178754 0f99 0003 003cf654
> > 25c17d03^M
> > 2178755 8801e8029e38 8801e74fc000 0002590dc5c4
> > 8163cdb0^M
> > 2178756 Call Trace:^M
> > 2178757 [] ?
> > acpi_processor_ffh_cstate_enter+0x2d/0x2f^M
> > 2178758 [] acpi_idle_enter_bm+0x1b1/0x236^M
> > 2178759 [] ? disable_cpuidle+0x10/0x10^M
> > 2178760 [] cpuidle_enter+0x12/0x14^M
> > 2178761 [] cpuidle_wrap_enter+0x2f/0x6d^M
> > 2178762 [] cpuidle_enter_tk+0x10/0x12^M
> > 2178763 [] cpuidle_enter_state+0x12/0x3a^M
> > 2178764 [] cpuidle_idle_call+0xe8/0x161^M
> > 2178765 [] cpu_idle+0x5e/0xa4^M
> > 2178766 [] start_secondary+0x1a9/0x1ad^M
> > 2178767 Task dump for CPU 2:^M
> >
> > In fact, the acpi idle bases on percpu cstate difference assumption, the
> > infrastructure use many percpu structures to implement self.
> > Just unique acpi_processor_cx is far far not enough.
> >
> > This patch just is a quick fix by introducing back the percpu cstates.
> > And keep driver_data away.
> >
> > If someone really want to unify the acpi cstates, please make sure whole
> > software infrastructure changed and get the grant from hardware,
> > include many kinds of BIOS setting.
> >
> > Signed-off-by: Alex Shi
> > ---
> > drivers/acpi/processor_idle.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> > index fc95308..ee255c6 100644
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -66,7 +66,8 @@ module_param(latency_factor, uint, 0644);
> >
> > static DEFINE_PER_CPU(struct cpuidle_device *, acpi_cpuidle_device);
> >
> > -static struct acpi_processor_cx *acpi_cstate[CPUIDLE_STATE_MAX];
> > +static DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX],
> > +
> > acpi_cstate);
> >
> > static int disabled_by_idle_boot_param(void)
> > {
> > @@ -722,7 +723,7 @@ static int acpi_idle_enter_c1(struct cpuidle_device
> > *dev,
> > struct cpuidle_driver *drv, int index)
> > {
> > struct acpi_processor *pr;
> > - struct acpi_processor_cx *cx = acpi_cstate[index];
> > + struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index],
> > dev->cpu);
> >
> > pr = __this_cpu_read(processors);
> >
> > @@ -745,7 +746,7 @@ static int acpi_idle_enter_c1(struct cpuidle_device
> > *dev,
> > */
> > static int acpi_idle_play_dead(struct cpuidle_device *dev, int index)
> > {
> > - struct acpi_processor_cx *cx = acpi_cstate[index];
> > + struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index],
> > dev->cpu);
> >
> > ACPI_FLUSH_CPU_CACHE();
> >
> > @@ -775,7 +776,7 @@ static int acpi_idle_enter_simple(struct cpuidle_device
> > *dev,
> > struct cpuidle_driver *drv, int index)
> > {
> > struct acpi_processor *pr;
> > - struct acpi_processor_cx *cx = acpi_cstate[index];
> > + struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index],
> > dev->cpu);
> >
> > pr = __this_cpu_read(processors);
> >
> > @@ -833,7 +834,7 @@ static int acpi_idle_enter_bm(struct cpuidle_device
> > *dev,
> > struct cpuidle_driver *drv, int index)
> > {
> > struct acpi_processor *pr;
> > - struct acpi_processor_cx *cx = acpi_cstate[index];
> > + struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index],
> > dev->cpu);
> >
> > pr = __this_cpu_read(processors);
> >
> > @@ -960,7 +961,7
Re: [PATCH] powerpc: drop even more unused Kconfig symbols
On Wed, Mar 27, 2013 at 11:51:35AM +0100, Paul Bolle wrote: > On Thu, 2013-03-21 at 12:10 +0100, Paul Bolle wrote: > > diff --git a/arch/powerpc/platforms/wsp/Kconfig > > b/arch/powerpc/platforms/wsp/Kconfig > > index 79d2225..9eea710 100644 > > --- a/arch/powerpc/platforms/wsp/Kconfig > > +++ b/arch/powerpc/platforms/wsp/Kconfig > > @@ -29,7 +29,3 @@ config PPC_CHROMA > > default y > > > > endmenu > > - > > -config PPC_A2_DD2 > > - bool "Support for DD2 based A2/WSP systems" > > - depends on PPC_A2 > > This part was not included in the "powerpc: remove PReP" follow up > patch. Should I resend separately? Yes thanks. It was added in commit a1d0d98 "Add WSP platform" but should not have been, it was to support bringup hacks that were never merged upstream. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] regulator: palmas: add input supply names
On Wed, Mar 20, 2013 at 07:26:37PM +0530, Laxman Dewangan wrote: > Palmas regulator support the different input supply pins for each of > the rails. Fill the regulator info data with their input supply pin > names. Applied, thanks. signature.asc Description: Digital signature
Re: PROBLEM: All CPUs in soft lockup
On Wed, Mar 27, 2013 at 12:55:41PM +1100, Robert Norris wrote: > The console shows a new "BUG: soft lockup" line every few seconds Looking closer, the whole thing starts with a _hard_ lockup. 2013-03-26T08:33:39.921834-04:00 imap30 kernel: [185090.090328] Watchdog detected hard LOCKUP on cpu 3 (also in the logs of the other two servers I mentioned). Looking down to where the watchdog interrupt comes in: 2013-03-26T08:33:39.921870-04:00 imap30 kernel: [185090.090426] <> [] ? end_buffer_async_read+0x79/0xff Disassembling: 0x8112a57a <+66>:mov%rbx,%rdi 0x8112a57d <+69>:callq 0x81129265 0x8112a582 <+74>:lock orb $0x2,0x0(%rbp) 0x8112a587 <+79>:mov0x0(%rbp),%rax 0x8112a58b <+83>:test $0x8,%ah 0x8112a58e <+86>:jne0x8112a594 0x8112a590 <+88>:ud2 0x8112a592 <+90>:jmp0x8112a592 That lock at +74 is presumably the offender here. Which is line 275 of fs/buffer.c: 275 SetPageError(page); So another CPU has these page flags locked right now, and isn't keen to release that lock? I don't know how to debug this further. What's the next step? Thanks, Rob. -- 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 46/46] ARM: ux500: Regulators: Bring the AB8500 regulator platform data up-to-date
On Thu, Mar 21, 2013 at 03:59:43PM +, Lee Jones wrote: > Quite a few changes in this patch, including: supply-name changes, new > consumers, initialisation and capability updates and new regulators. All the patches I just applied adding consumers and whatnot probably ought to have been squashed down into this too... signature.asc Description: Digital signature
Re: [PATCH 44/46] regulator: ab8500: Amend the update value for AB8500_LDO_INTCORE regulator
On Thu, Mar 21, 2013 at 03:59:41PM +, Lee Jones wrote: > The issues probably originated from a typo in the initial submission. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 37/46] regulator: ab8500-ext: Adapt regulator registration for newly changed API
On Thu, Mar 21, 2013 at 03:59:34PM +, Lee Jones wrote: > From: Gabriel Fernandez > > Instead of using a long list of arguments for registering a new > regulator, the API has changed to accommodate a new structure > which is to contain the necessary runtime configuration. This > patch allows the external regulator to follow suit and continue > to successfully register itself with the Regulator subsystem. This really ought to be squashed in to the earlier commits which won't compile without this fix... signature.asc Description: Digital signature
Re: [PATCH 14/14] tracing: fix regression of perf function tracing
On 2013/3/27 21:09, Steven Rostedt wrote:
> On Wed, 2013-03-27 at 17:44 +0800, zhangwei(Jovi) wrote:
>> From: "zhangwei(Jovi)"
>>
>> Using perf command: perf stat -e ftrace:function ls
>>
>> this will cause kernel warning and oops.
>>
>> [ 797.828904] [ cut here ]
>> [ 797.828946] WARNING: at include/linux/ftrace.h:209
>> ftrace_ops_control_func+0xb1/0xc0()
>> [ 797.829065] Pid: 6086, comm: perf Not tainted 3.8.0-rc4+ #88
>> [ 797.829066] Call Trace:
>> [ 797.829078] [] warn_slowpath_common+0x72/0xa0
>> [ 797.829080] [] ? ftrace_ops_control_func+0xb1/0xc0
>> [ 797.829082] [] ? ftrace_ops_control_func+0xb1/0xc0
>> [ 797.829083] [] ? synchronize_sched+0x3/0x50
>> [ 797.829085] [] ? __unregister_ftrace_function+0x8f/0x170
>> [ 797.829087] [] warn_slowpath_null+0x22/0x30
>> [ 797.829089] [] ftrace_ops_control_func+0xb1/0xc0
>> [ 797.829099] [] ftrace_call+0x5/0xb
>> [ 797.829100] [] ? synchronize_sched+0x8/0x50
>> [ 797.829102] [] __unregister_ftrace_function+0x8f/0x170
>> [ 797.829104] [] unregister_ftrace_function+0x1f/0x50
>> [ 797.829109] [] perf_ftrace_event_register+0x9d/0x140
>> [ 797.829111] [] perf_trace_destroy+0x2b/0x50
>> [ 797.829117] [] tp_perf_event_destroy+0x8/0x10
>> [ 797.829119] [] free_event+0x42/0x110
>> [ 797.829121] [] perf_event_release_kernel+0x56/0x90
>> [ 797.829122] [] put_event+0x7c/0xa0
>> [ 797.829124] [] perf_release+0xb/0x10
>> [ 797.829128] [] __fput+0xc6/0x1f0
>> [ 797.829130] [] fput+0xd/0x10
>> [ 797.829134] [] task_work_run+0x81/0xa0
>> [ 797.829142] [] do_notify_resume+0x59/0x90
>> [ 797.829150] [] work_notifysig+0x30/0x37
>> [ 797.829152] ---[ end trace 4dbd63f12b55163f ]---
>>
>> This bug was introduced by below commit(in 3.8-rc4):
>> commit 0a016409e42f273415f8225ddf2c58eb2df88034
>> Author: Steven Rostedt
>> Date: Fri Nov 2 17:03:03 2012 -0400
>>
>> ftrace: Optimize the function tracer list loop
>>
>> When variable op is ftrace_list_end, it cannot pass control ops checking,
>> so that loop optimize is not suit for ftrace_control_list, change it back.
>>
>
> Thanks for finding the bug, but this isn't the fix.
>
>> Signed-off-by: zhangwei(Jovi)
>> Cc: sta...@vger.kernel.org
>> ---
>> kernel/trace/ftrace.c |7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
>> index 2577082..2899974 100644
>> --- a/kernel/trace/ftrace.c
>> +++ b/kernel/trace/ftrace.c
>> @@ -4185,11 +4185,14 @@ ftrace_ops_control_func(unsigned long ip, unsigned
>> long parent_ip,
>> */
>> preempt_disable_notrace();
>> trace_recursion_set(TRACE_CONTROL_BIT);
>> -do_for_each_ftrace_op(op, ftrace_control_list) {
>
> I'd much rather keep the do_for_each_op() as it keeps everything
> consistent, and I don't have to worry about this if I change things in
> the future.
I changed this on thought of this would save a duplicate checking in hot path.
But never mind, it's a only tiny change, either way don't have big issue.
>
> I'll fix this so that it wont process stub functions.
>
> Thanks!
>
> -- Steve
>
>
>> +op = rcu_dereference_raw(ftrace_control_list);
>> +while (op != _list_end) {
>> if (!ftrace_function_local_disabled(op) &&
>> ftrace_ops_test(op, ip))
>> op->func(ip, parent_ip, op, regs);
>> -} while_for_each_ftrace_op(op);
>> +
>> +op = rcu_dereference_raw(op->next);
>> +}
>> trace_recursion_clear(TRACE_CONTROL_BIT);
>> preempt_enable_notrace();
>> }
>
>
>
> .
>
--
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 28/46] regulator: ab8500: Delete useless fixed_uV field
On Thu, Mar 21, 2013 at 03:59:25PM +, Lee Jones wrote: > From: Mustapha Ben Zoubeir > > The fixed_uV property residing in ab8500_ext_regulator_info is > currently unused. We remove it here. This is definitely a bugfix to an earlier commit in the series, can we please have these squashed into the original commits? signature.asc Description: Digital signature
Re: [PATCH 24/46] ARM: ux500: regulator: Add accelerometer and fix magnetometer supply device ID
On Thu, Mar 21, 2013 at 03:59:21PM +, Lee Jones wrote: > This patch adds the LSM303DLHC Accelerometer to the list of VAUX1 > consumers, as well as amending the already added LSM303DLHC > Magnetometer's device ID. Applied, though this looks suspicously like it's bugfixing an earlier commit in the series... signature.asc Description: Digital signature
Re: [PATCH 21/46] regulator: ab8500: Correct TVOUT regulator start-up delay
On Thu, Mar 21, 2013 at 03:59:18PM +, Lee Jones wrote: > From: Jonas Aaberg > > Update TVOUT regulator to match specification. (Was 10ms, > changed to 500us.) This fails to apply due to Axel's changes which remove delay entirely... signature.asc Description: Digital signature
Re: [PATCH 18/46] regulator: ab8500: Clean out SoC registers
On Thu, Mar 21, 2013 at 03:59:15PM +, Lee Jones wrote: > Clean out initialisation that is handled by SoC. Regulator > settings for Vpll (partly), Vsmps1, Vsmps2, Vsmps3 (partly), > Vrf1, Varm, Vape, Vbb, Vmod are cleaned out. They should not > be touched by the kernel. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 16/46] ARM: ux500: Add supply for the Cypress TrueTouch Touchscreen
On Thu, Mar 21, 2013 at 03:59:13PM +, Lee Jones wrote: > This patch lists the Cypress TrueTouch Touchscreen as a consumer > of the AB8500 VAUX1 regulator. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 17/46] ARM: ux500: regulators: List the MMIO camera as a consumer of VAUX1
On Thu, Mar 21, 2013 at 03:59:14PM +, Lee Jones wrote: > The MMIO camera uses the VAUX1 as it's voltage supply. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 15/46] ARM: ux500: Add supply for the Pressure sensor
On Thu, Mar 21, 2013 at 03:59:12PM +, Lee Jones wrote: > This patch lists the Pressure sensor as a consumer of the AB8500 > VAUX1 regulator. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 13/46] ARM: ux500: Add supply for the L3G4200D Gyroscope
On Thu, Mar 21, 2013 at 03:59:10PM +, Lee Jones wrote: > This patch lists the L3G4200D Gyroscope as a consumer of the > AB8500 VAUX1 regulator. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 14/46] ARM: ux500: Add supply for the Ambient light sensor device
On Thu, Mar 21, 2013 at 03:59:11PM +, Lee Jones wrote: > This patch lists the Ambient light sensor device as a consumer > of the AB8500 VAUX1 regulator. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 08/46] ARM: ux500: Update displays in vaux1 consumer list
On Thu, Mar 21, 2013 at 03:59:05PM +, Lee Jones wrote: > Add 3 more specific consumers pertaining to the displays found > on the u8500 and ST User Interface Boards (UIBs). Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 07/46] regulator: ab8500: Add support of low voltage battery
On Thu, Mar 21, 2013 at 03:59:04PM +, Lee Jones wrote: > Low voltage batteries have a wider voltage range with > lower operating voltages. Some consumers in the platform > may not work with the lower voltages and therefore need > an extra regulator to boost the voltage in this case. So, the reason I keep stopping at this commit is that the changelog bears no relationship to what the code is actually doing - the low voltage battery stuff is a board specific thing not the device feature which is rather buried here... this all suggests that there's a confusion between device and system code here. > This driver adds support for checking the consumers that > need higher voltage (Vaux1, 2 and 3 regulators, 3 V SIM) > and control the external buck/boost regulator > accordingly. > Note that to utilize the low voltage battery support, > the battery voltage thresholds must be changed. This > applies for the low battery voltage threshold of the > battery manager and the OTP setting for the AB8500 > BattOk levels. This all looks board specific really, there's presumably a few signals coming out of the AB8500 but the regulator definitions themselves (and the names they're given) look rather more specific than that. Which bits of this are for the AB8500 external regulator feature and which bits are the external regulators? signature.asc Description: Digital signature
Re: [PATCH] fs: f2fs: Use kmemdup
2013/3/28, Alexandru Gheorghiu : > Used kmemdup instead of kzalloc and memcpy. > > Signed-off-by: Alexandru Gheorghiu > --- > fs/f2fs/node.c| 11 --- > fs/f2fs/segment.c |3 +-- > 2 files changed, 5 insertions(+), 9 deletions(-) > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > index e275218..920f53a 100644 > --- a/fs/f2fs/node.c > +++ b/fs/f2fs/node.c > @@ -1661,19 +1661,16 @@ static int init_node_manager(struct f2fs_sb_info > *sbi) > spin_lock_init(_i->free_nid_list_lock); > rwlock_init(_i->nat_tree_lock); > > - nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); > nm_i->init_scan_nid = le32_to_cpu(sbi->ckpt->next_free_nid); > nm_i->next_scan_nid = le32_to_cpu(sbi->ckpt->next_free_nid); > - > - nm_i->nat_bitmap = kzalloc(nm_i->bitmap_size, GFP_KERNEL); > - if (!nm_i->nat_bitmap) > - return -ENOMEM; > + nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); > version_bitmap = __bitmap_ptr(sbi, NAT_BITMAP); > if (!version_bitmap) > return -EFAULT; > > - /* copy version bitmap */ > - memcpy(nm_i->nat_bitmap, version_bitmap, nm_i->bitmap_size); > + nm_i->nat_bitmap = kmemdup(version_bitmap, nm_i->bitmap_size, > GFP_KERNEL); maybe, this line is over 80 characters. plz fix it after running checkpatch.pl. Thanks. > + if (!nm_i->nat_bitmap) > + return -ENOMEM; > return 0; > } > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > index 777f17e..1758149 100644 > --- a/fs/f2fs/segment.c > +++ b/fs/f2fs/segment.c > @@ -1403,10 +1403,9 @@ static int build_sit_info(struct f2fs_sb_info *sbi) > bitmap_size = __bitmap_size(sbi, SIT_BITMAP); > src_bitmap = __bitmap_ptr(sbi, SIT_BITMAP); > > - dst_bitmap = kzalloc(bitmap_size, GFP_KERNEL); > + dst_bitmap = kmemdup(src_bitmap, bitmap_size, GFP_KERNEL); > if (!dst_bitmap) > return -ENOMEM; > - memcpy(dst_bitmap, src_bitmap, bitmap_size); > > /* init SIT information */ > sit_i->s_ops = _salloc_ops; > -- > 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] video: exynos: remove useless safety check in list traversal
Hi,
It looks good to me.
Acked-by: Donghwa Lee
Best regard,
Donghwa Lee
On Thu, Mar 28, 2013 at 06:19, Andrei Epure wrote:
list_for_each_entry_safe() does not require safety check.
Patch found using coccinelle.
Signed-off-by: Andrei Epure
---
drivers/video/exynos/exynos_mipi_dsi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c
b/drivers/video/exynos/exynos_mipi_dsi.c
index dd5e5e9..fe84f08 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -214,8 +214,6 @@ static struct mipi_dsim_ddi
*exynos_mipi_dsi_find_lcd_device(
mutex_lock(_dsim_lock);
list_for_each_entry_safe(dsim_ddi, next, _ddi_list, list) {
- if (!dsim_ddi)
- goto out;
lcd_dev = dsim_ddi->dsim_lcd_dev;
if (!lcd_dev)
@@ -473,17 +471,15 @@ static int exynos_mipi_dsi_remove(struct platform_device
*pdev)
clk_disable(dsim->clock);
list_for_each_entry_safe(dsim_ddi, next, _ddi_list, list) {
- if (dsim_ddi) {
- if (dsim->id != dsim_ddi->bus_id)
- continue;
+ if (dsim->id != dsim_ddi->bus_id)
+ continue;
- dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
+ dsim_lcd_drv = dsim_ddi->dsim_lcd_drv;
- if (dsim_lcd_drv->remove)
- dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
+ if (dsim_lcd_drv->remove)
+ dsim_lcd_drv->remove(dsim_ddi->dsim_lcd_dev);
- kfree(dsim_ddi);
- }
+ kfree(dsim_ddi);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] ACPI,acpi_memhotplug: Remove acpi_memory_info->failed bit
Hi Rafael,
2013/03/26 22:41, Rafael J. Wysocki wrote:
On Tuesday, March 26, 2013 08:57:05 AM Yasuaki Ishimatsu wrote:
2013/03/23 5:24, Toshi Kani wrote:
On Fri, 2013-03-22 at 10:53 +0900, Yasuaki Ishimatsu wrote:
acpi_memory_info has enabled bit and failed bit for controlling memory
hotplug. But we don't need to keep both bits.
The patch removes acpi_memory_info->failed bit.
Signed-off-by: yasuaki ishimatsu
Thanks for the update. It looks good. For the series:
Acked-by: Toshi Kani
Thanks!
Both patches applied to linux-pm.git/linux-next.
Thank you for applying both patches.
If you don't mind, I hope these patches are merged into linux-3.9
since this is bug fix.
Thanks,
Yasuaki Ishimatsu
Thanks,
Rafael
---
v3 : Continue to memory hot remove when (!info->enabled) case.
v2 : Changed a based kernel from linux-3.9-rc2 to linux-pm.git/bleeding-edge.
---
drivers/acpi/acpi_memhotplug.c | 15 ++-
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index ea78988..5e6301e 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -73,7 +73,6 @@ struct acpi_memory_info {
unsigned short caching; /* memory cache attribute */
unsigned short write_protect; /* memory read/write attribute */
unsigned int enabled:1;
- unsigned int failed:1;
};
struct acpi_memory_device {
@@ -201,10 +200,8 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
* returns -EEXIST. If add_memory() returns the other error, it
* means that this memory block is not used by the kernel.
*/
- if (result && result != -EEXIST) {
- info->failed = 1;
+ if (result && result != -EEXIST)
continue;
- }
info->enabled = 1;
@@ -238,16 +235,8 @@ static int acpi_memory_remove_memory(struct
acpi_memory_device *mem_device)
nid = acpi_get_node(mem_device->device->handle);
list_for_each_entry_safe(info, n, _device->res_list, list) {
- if (info->failed)
- /* The kernel does not use this memory block */
- continue;
-
if (!info->enabled)
- /*
-* The kernel uses this memory block, but it may be not
-* managed by us.
-*/
- return -EBUSY;
+ continue;
if (nid < 0)
nid = memory_add_physaddr_to_nid(info->start_addr);
--
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/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On 03/25/2013 08:47 AM, Richard Genoud wrote: > If a new state is applied, the groups configured in the old state but > not in the new state are disabled. > If something goes wrong and the new state can't be applied, we have to > re-enable those groups. What is the use-case for this? I wonder if it isn't better to simply undo the partial selection of the new state (as patch 3/4 attempts to do) and then leave p->state==NULL, indicating that no state is actively selected. IIRC, this would be the same as right after the initial pinctrl_select(). I wonder if it's likely that attempting to re-apply the old state would actually work, given that applying something just failed. Finally, this recovery code doesn't: a) Process anything except MUX_GROUP; any pin config settings in the old state aren't restored. b) (I think) Apply any mux settings that don't involve groups that are referenced by both the old and new states; given that patch 3/4 attempts to undo everything in the failed application of the new state, I think this "re-apply the old state" code should simple run through everything in the old state any apply it unconditionally. c) Set p->state = oldstate, so it's left at NULL, which would confuse any future pinctrl_select(). -- 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] video: fix invalid free of devm_ allocated data
The objects allocated by devm_* APIs are managed by devres and are freed when the device is detached. Hence there is no need to use kfree() explicitly. Patch found using coccinelle. Signed-off-by: Andrei Epure --- drivers/video/vt8500lcdfb.c |3 --- drivers/video/wm8505fb.c|3 --- 2 files changed, 6 deletions(-) diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c index b4ccca2..ea3ee61 100644 --- a/drivers/video/vt8500lcdfb.c +++ b/drivers/video/vt8500lcdfb.c @@ -465,7 +465,6 @@ failed_free_res: release_mem_region(res->start, resource_size(res)); failed_fbi: platform_set_drvdata(pdev, NULL); - kfree(fbi); failed: return ret; } @@ -494,8 +493,6 @@ static int vt8500lcd_remove(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); release_mem_region(res->start, resource_size(res)); - kfree(fbi); - return 0; } diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c index 2e8298e..34a2de1 100644 --- a/drivers/video/wm8505fb.c +++ b/drivers/video/wm8505fb.c @@ -427,7 +427,6 @@ failed_free_res: release_mem_region(res->start, resource_size(res)); failed_fbi: platform_set_drvdata(pdev, NULL); - kfree(fbi); failed: return ret; } @@ -451,8 +450,6 @@ static int wm8505fb_remove(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); release_mem_region(res->start, resource_size(res)); - kfree(fbi); - return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
