Re: h8300 build failures ijn linux-next
On Tue, 25 Aug 2015 03:34:20 +0900, Guenter Roeck wrote: > > Hi, > > In linux-next as of today (0824), all h8300 builds fail for me with an > internal > compiler error. > > Building h8300:allnoconfig ... failed > -- > Error log: > > In file included from include/linux/rcupdate.h:429:0, > from include/linux/rcusync.h:5, > from kernel/rcu/sync.c:1: > include/linux/rcutiny.h: In function ‘rcu_barrier_sched’: > include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault > static inline void rcu_barrier_sched(void) > ^ > > I tried both gcc 5.1 and 5.2, built with the patch set available to me. > > Is there a more recent compiler / patch set available that might fix the > problem ? > No. I tried gcc 6.0. It got same error. It looks optimization problem on h8300 target. I will investigate it. > Thanks, > Guenter -- Yoshinori Sato -- 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] regulator:lp872x: use the private data instead of updating I2C device platform data
Currently, lp872x driver parses the DT and copies values into the
'cl->dev.platform_data' if 'of_node' exists.
This may have architectural issue. Platform data is configurable through
the DT or I2C board info inside the platform area.
However, lp872x driver changes this configuration when it is loaded.
The lp872x driver should get data from the platform side and use the private
data, 'lp872x->pdata' instead of changing the original platform data.
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
drivers/regulator/lp872x.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 3de328a..9142c1a 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -903,6 +903,7 @@ static struct lp872x_platform_data
static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
struct lp872x *lp;
+ struct lp872x_platform_data *pdata;
int ret;
const int lp872x_num_regulators[] = {
[LP8720] = LP8720_NUM_REGULATORS,
@@ -910,8 +911,10 @@ static int lp872x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
};
if (cl->dev.of_node)
- cl->dev.platform_data = lp872x_populate_pdata_from_dt(>dev,
+ pdata = lp872x_populate_pdata_from_dt(>dev,
(enum lp872x_id)id->driver_data);
+ else
+ pdata = dev_get_platdata(>dev);
lp = devm_kzalloc(>dev, sizeof(struct lp872x), GFP_KERNEL);
if (!lp)
@@ -927,7 +930,7 @@ static int lp872x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
}
lp->dev = >dev;
- lp->pdata = dev_get_platdata(>dev);
+ lp->pdata = pdata;
lp->chipid = id->driver_data;
i2c_set_clientdata(cl, lp);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] regulator:lp872x: handle error case
If memory allocation gets failed on parsing the DT, then it returns error
'-ENOMEM' explicitly. Then, the driver exists from the _probe().
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim
---
drivers/regulator/lp872x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 9142c1a..8702e73 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -849,7 +849,7 @@ static struct lp872x_platform_data
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
- goto out;
+ return ERR_PTR(-ENOMEM);
of_property_read_u8(np, "ti,general-config", >general_config);
if (of_find_property(np, "ti,update-config", NULL))
@@ -857,7 +857,7 @@ static struct lp872x_platform_data
pdata->dvs = devm_kzalloc(dev, sizeof(struct lp872x_dvs), GFP_KERNEL);
if (!pdata->dvs)
- goto out;
+ return ERR_PTR(-ENOMEM);
pdata->dvs->gpio = of_get_named_gpio(np, "ti,dvs-gpio", 0);
of_property_read_u8(np, "ti,dvs-vsel", (u8 *)>dvs->vsel);
@@ -910,11 +910,14 @@ static int lp872x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
[LP8725] = LP8725_NUM_REGULATORS,
};
- if (cl->dev.of_node)
+ if (cl->dev.of_node) {
pdata = lp872x_populate_pdata_from_dt(>dev,
(enum lp872x_id)id->driver_data);
- else
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+ } else {
pdata = dev_get_platdata(>dev);
+ }
lp = devm_kzalloc(>dev, sizeof(struct lp872x), GFP_KERNEL);
if (!lp)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: cros_ec: i2c: Add OF match table
The Documentation/devicetree/bindings/mfd/cros-ec.txt DT binding doc lists
"google,cros-ec-i2c" as a compatible string but the corresponding driver
does not have an OF match table. Add the table to the driver so the I2C
core can do an OF style match.
Signed-off-by: Javier Martinez Canillas
---
drivers/mfd/cros_ec_i2c.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index d06e4b46db80..56a466469664 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -344,6 +344,12 @@ static int cros_ec_i2c_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(cros_ec_i2c_pm_ops, cros_ec_i2c_suspend,
cros_ec_i2c_resume);
+static const struct of_device_id cros_ec_i2c_of_match[] = {
+ { .compatible = "google,cros-ec-i2c", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+
static const struct i2c_device_id cros_ec_i2c_id[] = {
{ "cros-ec-i2c", 0 },
{ }
@@ -353,6 +359,7 @@ MODULE_DEVICE_TABLE(i2c, cros_ec_i2c_id);
static struct i2c_driver cros_ec_driver = {
.driver = {
.name = "cros-ec-i2c",
+ .of_match_table = of_match_ptr(cros_ec_i2c_of_match),
.pm = _ec_i2c_pm_ops,
},
.probe = cros_ec_i2c_probe,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
Hi Geert-san,
> Sent: Monday, August 24, 2015 9:13 PM
>
> Hi Shimoda-san,
>
> On Thu, Aug 20, 2015 at 8:28 AM, Yoshihiro Shimoda
> wrote:
> > This patch adds support for R-Car generation 3 USB2 PHY driver.
> > This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
> > with the HSUSB (USB2.0 peripheral) device.
> >
> > So, the purpose of this driver is:
> > 1) initializes some registers of SoC specific to use the
> > {ehci,ohci}-platform driver.
> >
> > 2) detects id pin to select host or peripheral on the channel 0.
> >
> > For now, this driver only supports 1) above.
>
> Thanks for your patch!
Thank you very much for your review!
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> > @@ -0,0 +1,37 @@
> > +* Renesas R-Car generation 3 USB 2.0 PHY
> > +
> > +This file provides information on what the device node for the R-Car
> > generation
> > +3 USB 2.0 PHY contains.
> > +
> > +Required properties:
> > +- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of
> > R8A7795 SoC.
>
> "an R8A7795 SoC".
I will fix this in v2.
(I will submit v2 patch late today.)
> > +- reg: offset and length of the USB2.0 host register block.
> > +- reg-names: must be "usb2".
> > +- clocks: clock phandle and specifier pair.
>
> "pair(s)."
I will fix this.
> > +- clock-names: string, clock input name, must be "usb2", and optional
> > "hsusb".
>
> names
Thank you for the point.
As you mentioned about runtime PM below, I will remove this property.
> > +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> > +
> > +Optional proparies:
>
> properties
Oops, I will fix it.
I should have done aspell command before I submitted.
If I did that command, I found other typo in this patch :)
> > +To use a USB channel which EHCI/OHCI and HSUSB are combined, the device
> > tree
>
> s/which/where/
>
> > +node should set HSUSB proparies to reg and reg-names proparies:
>
> properties (x2)
I will fix it.
> > +- reg: offset and length of the HSUSB register block.
> > +- reg-names: must be "hsusb".
> > +
> > +Example (R-Car H3):
> > +
> > + usb-phy@ee080200 {
> > + compatible = "renesas,usb2-phy-r8a7795";
> > + reg = <0 0xee080200 0 0x6ff>, <0 0xe6590100 0 0x100>;
> > + reg-names = "usb2", "hsusb";
> > + clocks = <_clks R8A7795_CLK_EHCI0>,
> > +<_clks R8A7795_CLK_HSUSB>;
>
> If you ever want to enable Runtime PM, do you want the first MSTP clock to be
> managed automatically?
> What about the second optional clock?
Thank you very much for the point.
I didn't take care about Runtime PM. However, I want to enable Runtime PM
because usb host and function drivers support it.
> > + clock-names = "usb2", "hsusb";
> > + };
> > +
> > + usb-phy@ee0a0200 {
> > + compatible = "renesas,usb2-phy-r8a7795";
> > + reg = <0 0xee0a0200 0 0x6ff>;
> > + reg-names = "usb2";
> > + clocks = <_clks R8A7795_CLK_EHCI0>;
> > + clock-names = "usb2";
> > + };
>
> > --- /dev/null
> > +++ b/drivers/phy/phy-rcar-gen3-usb2.c
>
> > +static int rcar_gen3_phy_usb2_init(struct phy *p)
> > +{
> > + struct rcar_gen3_phy_usb2_channel *channel = phy_get_drvdata(p);
> > + unsigned long flags;
> > + void __iomem *usb2_base = channel->usb2.base;
> > + void __iomem *hsusb_base = channel->hsusb.base;
> > + u32 tmp;
> > +
> > + /* Since ops->init() is called once, this driver enables both
> > clocks */
> > + clk_prepare_enable(channel->usb2.clk);
> > + clk_prepare_enable(channel->hsusb.clk);
>
> So this driver manages its clock(s) itself, and doesn't support Runtime PM.
So, I will use remove clk APIs in this driver.
Best regards,
Yoshihiro Shimoda
> > +static int rcar_gen3_phy_usb2_exit(struct phy *p)
> > +{
> > + struct rcar_gen3_phy_usb2_channel *channel = phy_get_drvdata(p);
> > +
> > + writel(0, channel->usb2.base + USB2_INT_ENABLE);
> > +
> > + clk_disable_unprepare(channel->hsusb.clk);
> > + clk_disable_unprepare(channel->usb2.clk);
> > +
> > + return 0;
> > +}
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/7] phy: exynos-usb2: add vbus regulator support
Hello, On 2015-08-21 14:44, Kishon Vijay Abraham I wrote: On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote: Exynos USB2 PHY has separate power supply, which is usually provided by VBUS regulator. This patch adds support for it. VBUS regulator is optional, to keep compatibility with boards, which have VBUS provided from some always-on power source. Signed-off-by: Marek Szyprowski --- .../devicetree/bindings/phy/samsung-phy.txt| 3 +++ drivers/phy/phy-samsung-usb2.c | 25 -- drivers/phy/phy-samsung-usb2.h | 2 ++ 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 60c6f2a633e0..0289d3b07853 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -44,6 +44,9 @@ Required properties: - the "ref" clock is used to get the rate of the clock provided to the PHY module +Optional properties: +- vbus-supply: power-supply phandle for vbus power source how about using phy-supply? I wanted to make it a bit more descriptive (vbus-supply is rather self explaining name) and keep it in line with Exynos usb3-drd phy, which already supports vbus-supply. If you think that this is a bad idea, a will use phy-supply then. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland -- 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: [RFT PATCH] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
On Tuesday 25 August 2015 02:54 AM, Russell King - ARM Linux wrote: On Tue, Aug 18, 2015 at 03:40:01PM +0530, Keerthy wrote: Currently apart from dra7, omap5 and amx3 all the other SoCs are identified using cpu_is_* functions which is not right since they are all SoCs(System on Chips). Hence changing the SoC identificätion code to use soc_is instead of cpu_is and keeping ^ typo I will correct and send a v2. defines for cpu_is where needed. This allows us to replace the rest of cpu_is usage along with other fixes as needed. Good to see this change to a more sensible naming of these, despite the obvious churn. Acked-by: Russell King Thanks Russel. I will fix the above typo and add your Ack in the next version. -- 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 5/5] mfd: 88pm800: Add support for clk subdevice
On 25.08.2015 03:56, Vaibhav Hiremath wrote:
> This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
> (and family of devices).
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/mfd/88pm800.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index c4e097d..a928eed 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
> },
> };
>
> +static struct mfd_cell clk_devs[] = {
> + {
> + .name = "88pm80x-clk",
> + .of_compatible = "marvell,88pm800-clk",
> + .id = -1,
The "-1" here stands for PLATFORM_DEVID_NONE?
Best regards,
Krzysztof
> + },
> +};
> +
> static const struct regmap_irq pm800_irqs[] = {
> /* INT0 */
> [PM800_IRQ_ONKEY] = {
> @@ -344,6 +352,17 @@ static int device_regulator_init(struct pm80x_chip *chip)
> ARRAY_SIZE(regulator_devs), NULL, 0, NULL);
> }
>
> +static int device_clk_init(struct pm80x_chip *chip)
> +{
> + if (chip->type == CHIP_PM800)
> + clk_devs[0].name = "88pm800-clk";
> + else if (chip->type == CHIP_PM860)
> + clk_devs[0].name = "88pm860-clk";
> +
> + return mfd_add_devices(chip->dev, 0, _devs[0],
> + ARRAY_SIZE(clk_devs), NULL, 0, NULL);
> +}
> +
> static int device_irq_init_800(struct pm80x_chip *chip)
> {
> struct regmap *map = chip->regmap;
> @@ -511,6 +530,12 @@ static int device_800_init(struct pm80x_chip *chip)
> goto out;
> }
>
> + ret = device_clk_init(chip);
> + if (ret) {
> + dev_err(chip->dev, "Failed to add clk subdev\n");
> + goto out;
> + }
> +
> return 0;
> out_dev:
> mfd_remove_devices(chip->dev);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] tools/liblockdep: correct macro for WARN
As Peter Zijlstra pointed out, the varargs for WARN() are optional, so we need to correctly handle the case where they don't exist. This would cause a compilation error. Signed-off-by: Sasha Levin --- tools/lib/lockdep/uinclude/linux/kernel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/lockdep/uinclude/linux/kernel.h b/tools/lib/lockdep/uinclude/linux/kernel.h index cd2cc59..276c7a8 100644 --- a/tools/lib/lockdep/uinclude/linux/kernel.h +++ b/tools/lib/lockdep/uinclude/linux/kernel.h @@ -23,7 +23,7 @@ #define WARN_ON(x) (x) #define WARN_ON_ONCE(x) (x) #define likely(x) (x) -#define WARN(x, y, z) (x) +#define WARN(x, y...) (x) #define uninitialized_var(x) x #define __init #define noinline -- 2.1.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 3/3] tools/liblockdep: use the rbtree header provided by common tools headers
Recent changes to rbtree.h may break compilation. There is no reason to use a liblockdep specific header to begin with, so we'll use the one shared with all other tools/. Signed-off-by: Sasha Levin --- tools/lib/lockdep/preload.c | 2 +- tools/lib/lockdep/uinclude/linux/rbtree.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) delete mode 100644 tools/lib/lockdep/uinclude/linux/rbtree.h diff --git a/tools/lib/lockdep/preload.c b/tools/lib/lockdep/preload.c index 0b0112c..21cdf86 100644 --- a/tools/lib/lockdep/preload.c +++ b/tools/lib/lockdep/preload.c @@ -5,7 +5,7 @@ #include #include #include "include/liblockdep/mutex.h" -#include "../../../include/linux/rbtree.h" +#include "../../include/linux/rbtree.h" /** * struct lock_lookup - liblockdep's view of a single unique lock diff --git a/tools/lib/lockdep/uinclude/linux/rbtree.h b/tools/lib/lockdep/uinclude/linux/rbtree.h deleted file mode 100644 index 965901d..000 --- a/tools/lib/lockdep/uinclude/linux/rbtree.h +++ /dev/null @@ -1 +0,0 @@ -#include "../../../include/linux/rbtree.h" -- 2.1.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: [BUG] arm: kgdb: patch_text() in kgdb_arch_set_breakpoint() may sleep
On Mon, Aug 24, 2015 at 4:56 PM, Doug Anderson wrote: > Kees, > > On Mon, Aug 24, 2015 at 10:46 AM, Kees Cook wrote: >> On Sun, Aug 23, 2015 at 7:45 PM, Doug Anderson wrote: >>> On Wed, Aug 5, 2015 at 8:50 AM, Aapo Vienamo wrote: Hi, The breakpoint setting code in arch/arm/kernel/kgdb.c calls patch_text(), which ends up trying to sleep while in interrupt context. The bug was introduced by commit: 23a4e40 arm: kgdb: Handle read-only text / modules. The resulting behavior is "BUG: scheduling while atomic..." when setting a breakpoint in kgdb. This was tested on an Nvidia Jetson TK1 board with 4.2.0-rc5-next-20150805 kernel. Regards, Aapo Vienamo >>> >>> Aapo, >>> >>> Including the stack trace with this would have been helpful, though >>> it's not too hard to reproduce. Here it is: >>> >>> [ 416.510559] BUG: scheduling while atomic: swapper/0/0/0x00010007 >>> [ 416.516554] Modules linked in: >>> [ 416.519614] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 4.2.0-rc7-00133-geb63b34 #1073 >>> [ 416.527341] Hardware name: Rockchip (Device Tree) >>> [ 416.532042] [] (unwind_backtrace) from [] >>> (show_stack+0x20/0x24) >>> [ 416.539772] [] (show_stack) from [] >>> (dump_stack+0x84/0xb8) >>> [ 416.546983] [] (dump_stack) from [] >>> (__schedule_bug+0x54/0x6c) >>> [ 416.554540] [] (__schedule_bug) from [] >>> (__schedule+0x80/0x668) >>> [ 416.562183] [] (__schedule) from [] >>> (schedule+0xb8/0xd4) >>> [ 416.569219] [] (schedule) from [] >>> (schedule_timeout+0x2c/0x234) >>> [ 416.576861] [] (schedule_timeout) from [] >>> (wait_for_common+0xf4/0x188) >>> [ 416.585109] [] (wait_for_common) from [] >>> (wait_for_completion+0x20/0x24) >>> [ 416.593531] [] (wait_for_completion) from [] >>> (__stop_cpus+0x58/0x70) >>> [ 416.601608] [] (__stop_cpus) from [] >>> (stop_cpus+0x3c/0x54) >>> [ 416.608817] [] (stop_cpus) from [] >>> (__stop_machine+0xcc/0xe8) >>> [ 416.616286] [] (__stop_machine) from [] >>> (stop_machine+0x34/0x44) >>> [ 416.624016] [] (stop_machine) from [] >>> (patch_text+0x28/0x34) >>> [ 416.631399] [] (patch_text) from [] >>> (kgdb_arch_set_breakpoint+0x40/0x4c) >>> [ 416.639823] [] (kgdb_arch_set_breakpoint) from >>> [] (kgdb_validate_break_address+0x2c/0x60) >>> [ 416.649719] [] (kgdb_validate_break_address) from >>> [] (dbg_set_sw_break+0x1c/0xdc) >>> [ 416.658922] [] (dbg_set_sw_break) from [] >>> (gdb_serial_stub+0x9c4/0xba4) >>> [ 416.667259] [] (gdb_serial_stub) from [] >>> (kgdb_cpu_enter+0x1f8/0x60c) >>> [ 416.675423] [] (kgdb_cpu_enter) from [] >>> (kgdb_handle_exception+0x19c/0x1d0) >>> [ 416.684106] [] (kgdb_handle_exception) from [] >>> (kgdb_compiled_brk_fn+0x30/0x3c) >>> [ 416.693135] [] (kgdb_compiled_brk_fn) from [] >>> (do_undefinstr+0x1a4/0x20c) >>> [ 416.701643] [] (do_undefinstr) from [] >>> (__und_svc_finish+0x0/0x34) >>> [ 416.709543] Exception stack(0xc07c1ce8 to 0xc07c1d30) >>> [ 416.714584] 1ce0: c07c6504 c086e290 >>> c086e294 c086e294 c086e290 >>> [ 416.722745] 1d00: c07c6504 0067 0001 c07c2100 0027 >>> c07c1d4c c07c1d50 c07c1d30 >>> [ 416.730905] 1d20: c00a0990 c00a08d0 6193 >>> [ 416.735947] [] (__und_svc_finish) from [] >>> (kgdb_breakpoint+0x58/0x94) >>> [ 416.744110] [] (kgdb_breakpoint) from [] >>> (sysrq_handle_dbg+0x58/0x6c) >>> [ 416.752273] [] (sysrq_handle_dbg) from [] >>> (__handle_sysrq+0xac/0x15c) >>> [ 416.760437] [] (__handle_sysrq) from [] >>> (handle_sysrq+0x30/0x34) >>> >>> >>> Kees: I think you've dealt with a lot more of these types of issues >>> than I have. Any quick thoughts? If not I can put it on my long-term >>> list of things to do, but until then we could always just post a >>> Revert... >> >> I don't think a revert is in order here. CONFIG_DEBUG_RODATA could be >> turned off for builds where you need kgdb while this bug gets found. > > I don't think that's right. In my testing I don't have > CONFIG_DEBUG_RODATA. I think I did the right grep: > > $ grep ARM_KERNMEM_PERMS .config > # CONFIG_ARM_KERNMEM_PERMS is not set > > Basically no matter what we'll call: > - kgdb_arch_set_breakpoint > -- patch_text > --- stop_machine > > ...no dependencies on RODATA. I said DEBUG_RODATA since that's the stricter of the options (it requires KERNMEM_PERMS). But yes, I see now that patch.c doesn't test for this feature at all (which probably makes sense). >> I >> don't actually see where we've gone wrong, though. Looks like >> scheduling happened while waiting for CPUs to stop? Where did we enter >> atomic? > > We're in kdb. That's a stop mode debugger. No sleeping allowed while > in the debugger. > > >> Perhaps we need to test if we're already atomic in patch_text, and >> only call stop_machine if we need to? >> >> Untested (and likely mangled by gmail): >> >> diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c >> index 69bda1a5707e..855696bfe072 100644 >> --- a/arch/arm/kernel/patch.c >> +++
[PATCH 1/3] tools: restore export.h
Commit 3f735377b ("tools: Copy lib/rbtree.c to tools/lib/") has removed
export.h, which was still in use by liblockdep. Restore it.
Signed-off-by: Sasha Levin
---
tools/include/linux/export.h | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 tools/include/linux/export.h
diff --git a/tools/include/linux/export.h b/tools/include/linux/export.h
new file mode 100644
index 000..d07e586
--- /dev/null
+++ b/tools/include/linux/export.h
@@ -0,0 +1,10 @@
+#ifndef _TOOLS_LINUX_EXPORT_H_
+#define _TOOLS_LINUX_EXPORT_H_
+
+#define EXPORT_SYMBOL(sym)
+#define EXPORT_SYMBOL_GPL(sym)
+#define EXPORT_SYMBOL_GPL_FUTURE(sym)
+#define EXPORT_UNUSED_SYMBOL(sym)
+#define EXPORT_UNUSED_SYMBOL_GPL(sym)
+
+#endif
--
2.1.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 v3] dmaengine: hdmac: Add memset capabilities
On Mon, Aug 24, 2015 at 07:54:25PM +0530, Vinod Koul wrote: > On Mon, Aug 24, 2015 at 11:21:15AM +0200, Maxime Ripard wrote: > > Just like for the XDMAC, the SoCs that embed the HDMAC don't have any kind > > of GPU, and need to accelerate a few framebuffer-related operations through > > their DMA controller. > > > > However, unlike the XDMAC, the HDMAC doesn't have the memset capability > > built-in. That can be easily emulated though, by doing a transfer with a > > fixed address on the variable that holds the value we want to set. > > Applied, thanks Thanks for merging it so quickly, and sorry for the silent conflict. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH-v2 4/5] clk: 88pm800: Add clk provider driver for 88pm800 family of devices
On 25.08.2015 03:56, Vaibhav Hiremath wrote:
> 88PM800 family of devices supports buffered 32KHz clock output,
> for example,
>
> 88PM800: CLK32k_1, CLK32k_2 and CLK32k_3
> 88PM860: CLK32K_1 and CLK32K_2
>
> This patch adds new clk provider driver to support enable/disable
> of the 32KHz clock output from 88PM800 family of devices.
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/clk/Kconfig | 8 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-88pm800.c | 341
> ++
> 3 files changed, 350 insertions(+)
> create mode 100644 drivers/clk/clk-88pm800.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 42f7120..c34c14d 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -167,6 +167,14 @@ config COMMON_CLK_CDCE706
> ---help---
> This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
>
> +config COMMON_CLK_88PM800
> + tristate "Clock driver for 88PM800 MFD"
> + depends on MFD_88PM800
> + ---help---
> + This driver supports 88PM800 & 88PM860 crystal oscillator
> + clock. These multi-function devices have two (88PM860) or three
> + (88PM800) fixed-rate output, clocked at 32KHz each.
> +
> source "drivers/clk/bcm/Kconfig"
> source "drivers/clk/hisilicon/Kconfig"
> source "drivers/clk/qcom/Kconfig"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index c4cf075..5248cd3 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -80,3 +80,4 @@ obj-$(CONFIG_X86) += x86/
> obj-$(CONFIG_ARCH_ZX)+= zte/
> obj-$(CONFIG_ARCH_ZYNQ) += zynq/
> obj-$(CONFIG_H8300) += h8300/
> +obj-$(CONFIG_COMMON_CLK_88PM800) += clk-88pm800.o
> diff --git a/drivers/clk/clk-88pm800.c b/drivers/clk/clk-88pm800.c
> new file mode 100644
> index 000..4c045e1
> --- /dev/null
> +++ b/drivers/clk/clk-88pm800.c
> @@ -0,0 +1,341 @@
> +/*
> + * clk-88pm800.c - Clock driver for 88PM800 family of devices
> + *
> + * This driver is created based on clk-s2mps11.c
> + *
> + * Copyright (C) 2015 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Number of clocks output from 88pm800 family of device */
> +enum {
> + PM800_CLK32K_1 = 0,
> + PM800_CLK32K_2,
> + PM800_CLK32K_3,
> + PM800_CLKS_NUM,
> +};
> +
> +struct pm800_clk {
> + struct pm80x_chip *chip;
> + struct device_node *clk_np;
> + struct clk_hw hw;
> + struct clk *clk;
> + struct clk_lookup *lookup;
> + u32 mask;
> + u32 shift;
> + unsigned int reg;
> +};
> +
> +static struct pm800_clk *to_pm800_clk(struct clk_hw *hw)
> +{
> + return container_of(hw, struct pm800_clk, hw);
> +}
> +
> +static int pm800_clk_prepare(struct clk_hw *hw)
> +{
> + struct pm800_clk *pm800 = to_pm800_clk(hw);
> +
> + /* We always want to use XO clock */
> + return regmap_update_bits(pm800->chip->regmap,
> + pm800->reg,
> + pm800->mask,
> + PM800_32K_OUTX_SEL_XO_32KHZ << pm800->shift);
> +}
> +
> +static void pm800_clk_unprepare(struct clk_hw *hw)
> +{
> + struct pm800_clk *pm800 = to_pm800_clk(hw);
> +
> + regmap_update_bits(pm800->chip->regmap, pm800->reg,
> + pm800->mask, ~pm800->mask);
> +}
> +
> +static int pm800_clk_is_prepared(struct clk_hw *hw)
> +{
> + int ret;
> + u32 val;
> + struct pm800_clk *pm800 = to_pm800_clk(hw);
> +
> + ret = regmap_read(pm800->chip->regmap,
> + pm800->reg, );
> + if (ret < 0)
> + return -EINVAL;
> +
> + return (val & pm800->mask) >> pm800->shift;
> +}
> +
> +static unsigned long pm800_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return 32768;
> +}
> +
> +static const struct clk_ops pm800_clk_ops = {
> + .prepare= pm800_clk_prepare,
> + .unprepare = pm800_clk_unprepare,
> + .is_prepared= pm800_clk_is_prepared,
> + .recalc_rate= pm800_clk_recalc_rate,
> +};
> +
> +static struct clk_init_data pm800_clks_init[PM800_CLKS_NUM] = {
> + [PM800_CLK32K_1] = {
> + .name = "pm800_clk32k_1",
> + .ops= _clk_ops,
> +
Re: [RFC 0/1] i2c: acpi: revert setting a "stable" device name
On Mon Aug 17 11:00, Jarkko Nikula wrote: > If I remember correctly ACPI ID should not ever change and instance id :xy > after INTABCD:xy should also be visible and keep the order even if device is > disabled or not plugged. But I'm not absolute sure about this. > > At least on a test platform that allow disable devices will show those > devices off-line (/sys/bus/acpi/devices/INTABCD:xy/status == 0). I'm always surprised how hard it is to tell what *can't* happen in ACPI. How about a conditional call to LoadTable()? Seems like that would mess up the :xy. Moot point, I think you're on the right track in your RFC patch. --Dustin -- 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] regulator: 88pm800: Add support for configuration of dual phase on BUCK1
On 24.08.2015 21:40, Vaibhav Hiremath wrote:
> 88PM860 device supports dual phase mode on BUCK1 output.
> In normal usecase, BUCK1A and BUCK1B operates independently with 3A
> capacity. And they both can work as a dual phase providing 6A capacity.
>
> This patch updates the regulator driver to read the respective
> DT property and enable dual-phase mode on BUCK1.
> Note that if dual phase mode is enabled, then BUCK1B will not be
> registered to the regulator framework and the current capacity of
> BUCK1(A) would be set to 6A [3A of BUCK1A + 3A of BUCK1B].
>
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/regulator/88pm800.c | 40
> include/linux/mfd/88pm80x.h | 3 +++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/regulator/88pm800.c b/drivers/regulator/88pm800.c
> index 365a154..7aca6d17 100644
> --- a/drivers/regulator/88pm800.c
> +++ b/drivers/regulator/88pm800.c
> @@ -267,6 +267,37 @@ static struct pm800_regulator_info
> pm860_regulator_info[] = {
> PM800_LDO(ldo20, LDO20, LDO_ENA1_3, 3, 1, ldo_volt_table2),
> };
>
> +static int pm800_regulator_init(struct platform_device *pdev,
> + struct pm800_regulator_info *info)
> +{
> + struct pm800_regulators *pm800_data = platform_get_drvdata(pdev);
> + struct pm80x_chip *chip = pm800_data->chip;
> + int ret = 0;
> +
> + /* Currently only supported on 88pm860 device */
> + if (chip->type != CHIP_PM860)
> + return 0;
> +
> + if (of_property_read_bool(pdev->dev.of_node,
> + "marvell,88pm860-buck1-dualphase-en")) {
> + /* Update the constraint to [3A (BUCK1A) + 3A (BUCK1B)] */
> + info[PM800_ID_BUCK1].max_ua = 600;
> + /* Remove BUCK1B from the list, as we are in dual phase mode */
> + memset([PM800_ID_BUCK1B], 0, sizeof(*info));
> + /* Enable dual phase mode */
> + ret = regmap_update_bits(chip->subchip->regmap_power,
> + PM860_BUCK1_MISC,
> + BUCK1_DUAL_PHASE_SEL,
> + BUCK1_DUAL_PHASE_SEL);
> + if (ret) {
> + dev_err(chip->dev, "failed to set dual-pase mode %d\n",
> ret);
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
> static int pm800_regulator_probe(struct platform_device *pdev)
> {
> struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
> @@ -311,11 +342,20 @@ static int pm800_regulator_probe(struct platform_device
> *pdev)
> return -ENODEV;
> }
>
> + ret = pm800_regulator_init(pdev, info);
> + if (ret) {
> + dev_err(>dev, "failed to init 88pm800 regulator
> device\n");
> + return ret;
> + }
> +
> config.dev = chip->dev;
> config.regmap = pm800_data->map;
> for (i = 0; i < PM800_ID_RG_MAX; i++) {
> struct regulator_dev *regulator;
>
> + if (!info[i].desc.name)
> + continue;
How the driver was working without this on 88PM800? There is a gap in
pm800_regulator_info - three regulators are not set.
The patch itself looks good
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
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: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7
On 2015/8/25 12:03, Alex Deucher wrote: > On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher wrote: >>> Any ideas? I'll see if I can find the time to bisect this. >> >> I attempted to bisect this, however the regression happened prior to >> my driver being merged upstream: >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=099bfbfc7fbbe22356c02f0caf709ac32e1126ea >> So I can't easily bisect it further without backporting the driver to >> each commit before that. This may take a while... > > Just a heads up, this ended up being an alignment issue in the driver > and was not a regression. Thanks for confirmation:) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] pinctrl: digicolor: convert null test to IS_ERR test
Hi Julia,
On Mon, Aug 24, 2015 at 11:12:27PM +0200, Julia Lawall wrote:
> Since commit 323de9efdf3e ("pinctrl: make pinctrl_register() return proper
> error code"), pinctrl_register returns an error code rather than NULL on
> failure. Update a driver that was introduced more recently.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression e,e1,e2;
> @@
>
> e = pinctrl_register(...)
> ... when != e = e1
> if (
> - e == NULL
> + IS_ERR(e)
>) {
> ...
> return
> - e2
> + PTR_ERR(e)
> ;
> }
> //
>
> Signed-off-by: Julia Lawall
Acked-by: Baruch Siach
Thanks,
baruch
> drivers/pinctrl/pinctrl-digicolor.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-digicolor.c
> b/drivers/pinctrl/pinctrl-digicolor.c
> index 461fffc..11f8b83 100644
> --- a/drivers/pinctrl/pinctrl-digicolor.c
> +++ b/drivers/pinctrl/pinctrl-digicolor.c
> @@ -337,9 +337,9 @@ static int dc_pinctrl_probe(struct platform_device *pdev)
> pmap->dev = >dev;
>
> pmap->pctl = pinctrl_register(pctl_desc, >dev, pmap);
> - if (!pmap->pctl) {
> + if (IS_ERR(pmap->pctl)) {
> dev_err(>dev, "pinctrl driver registration failed\n");
> - return -EINVAL;
> + return PTR_ERR(pmap->pctl);
> }
>
> ret = dc_gpiochip_add(pmap, pdev->dev.of_node);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: xpad - Fix double URB submission races
On 08/21/2015 09:50 AM, Dmitry Torokhov wrote: Hi Laura, On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote: v2: Created a proper queue for events instead of just dropping them How long does it take for the queue to exhaust your memory if you keep bombarding the driver with requests? My script which changes the LEDs as fast as possible ran for 7+ hours on my machine with 16GB of RAM without exhausting all of it. This is also a very extreme case as almost any kind of delay between sending commands will drain the queue. I do not think you need a queue. I believe the nature of LEDs and rumble force feedback effect is such that you can discard all requests but the latest that arrived between the moment you submitted a request to the device and the moment you are ready submit a new one. So your suggestion is to only keep a single item in the queue? Thanks. Thanks, Laura -- 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] zswap: update docs for runtime-changeable attributes
On (08/19/15 11:56), Dan Streetman wrote: [..] > > Ugh that's madness. Still, a documented madness is better than an > > undocumented one. > > heh, i'm not sure why it's madness, the alternative of > uncompressing/recompressing all pages into the new zpool and/or with > the new compressor seems much worse ;-) > Well, I sort of still think that 'change compressor and reboot' is OK. 5cents. > > > >>> > The zsmalloc type zpool has a more > +complex compressed page storage method, and it can achieve greater > storage > +densities. However, zsmalloc does not implement compressed page > eviction, so > +once zswap fills it cannot evict the oldest page, it can only reject > new pages. > >>> > >>> I still wonder why anyone would use zsmalloc with zswap given this > >>> limitation. > >>> It seems only fine for zram which has no real swap as fallback. And even > >>> zbud > >>> doesn't have any shrinker interface that would react to memory pressure, > >>> so > >>> there's a possibility of premature OOM... sigh. > >> > >> for situations where zswap isn't expected to ever fill up, zsmalloc > >> will outperform zbud, since it has higher density. > > > > But then you could just use zram? :) > > well not *expected* to fill up doesn't mean it *won't* fill up :) > > > > >> i'd argue that neither zbud nor zsmalloc are responsible for reacting > >> to memory pressure, they just store the pages. It's zswap that has to > >> limit its size, which it does with max_percent_pool. > > > > Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim > > requests > > from zswap when zswap hits the limit. Zswap could easily add a shrinker that > > would relay this requests in response to memory pressure as well. However, > > zsmalloc doesn't implement the reclaim, or LRU tracking. > > I wrote a patch for zsmalloc reclaim a while ago: > > https://lwn.net/Articles/611713/ > > however it didn't make it in, due to the lack of zsmalloc LRU, or any > proven benefit to zsmalloc reclaim. > > It's not really possible to add LRU to zsmalloc, by the nature of its > design, using the struct page fields directly; there's no extra field > to use as a lru entry. Just for information, zsmalloc now registers shrinker callbacks https://lkml.org/lkml/2015/7/8/497 -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 08:03 PM, Zhao Qiang wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:32 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user
+ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could pass
in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
gen_pool_alloc will return 0 if there is error, but if the address returned is
just 0x0, it can't distinguish it is address or error.
Yes, that's a bad limitation of gen_pool. Maybe one day that will get fixed.
In a previous out of tree driver, I worked around this by offsetting the
gen_pool_add by a constant so any return value was non-zero and out of memory
was zero and then subtracting the constant off of the return value. Not sure
if that's better or worse than just fixing gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry->start = start;
+ entry->size = size;
+ list_add(>head, _block_list);
What's the point of keeping the block list anyway? It's used only in this
file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a
gen_alloc API to do so?
I need to record the size when allocation, so when free the block, I can get
The right size for the block, and pass the right size to
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).
Yes, I see now what you are doing.
Thanks,
Laura
Thanks
Zhao
Thanks,
Laura
--
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/1] of: to support binding numa node to specified device
Changelog: v1 -> v2: In patch v1, binding numa node to specified device only take effect for dt-nodes directly of root. Patch v2 removed this limitation, we can binding numa node to any specified device in devicetree. Zhen Lei (1): of: to support binding numa node to specified device in devicetree drivers/base/core.c | 2 +- drivers/of/device.c | 11 ++- 2 files changed, 7 insertions(+), 6 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] of: to support binding numa node to specified device in devicetree
For now, in function device_add, the new device will be forced to inherit the numa node of its parent. But this will override the device's numa node which configured in devicetree. Signed-off-by: Zhen Lei --- drivers/base/core.c | 2 +- drivers/of/device.c | 11 ++- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index dafae6d..e06de82 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1017,7 +1017,7 @@ int device_add(struct device *dev) dev->kobj.parent = kobj; /* use parent numa_node */ - if (parent) + if (parent && (dev_to_node(dev) == NUMA_NO_NODE)) set_dev_node(dev, dev_to_node(parent)); /* first, register with generic layer. */ diff --git a/drivers/of/device.c b/drivers/of/device.c index 8b91ea2..e5f47ce 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -60,11 +60,12 @@ int of_device_add(struct platform_device *ofdev) ofdev->name = dev_name(>dev); ofdev->id = -1; - /* device_add will assume that this device is on the same node as -* the parent. If there is no parent defined, set the node -* explicitly */ - if (!ofdev->dev.parent) - set_dev_node(>dev, of_node_to_nid(ofdev->dev.of_node)); + /* +* If this device has not binding numa node in devicetree, that is +* of_node_to_nid returns NUMA_NO_NODE. device_add will assume that this +* device is on the same node as the parent. +*/ + set_dev_node(>dev, of_node_to_nid(ofdev->dev.of_node)); return device_add(>dev); } -- 2.5.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: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7
On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher wrote:
> On Thu, Aug 13, 2015 at 4:15 PM, Alex Deucher wrote:
>> On Thu, Aug 13, 2015 at 3:46 PM, Alex Deucher wrote:
>>> On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu
>>> wrote:
On 2015/8/10 23:00, Alex Deucher wrote:
> On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu
> wrote:
>> Alex Deucher, Mark Rustad and Alexander Holler reported a regression
>> with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
>> With multi-MSI capable SATA controllers, only the first port works,
>> all other ports times out when executing SATA commands. This regression
>> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage
>> MSI interrupts"), but it's not the root cause, it just triggers a bug
>> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage
>> CPU interrupt vectors").
>>
>> With this patch applied, the affected SATA controllers work as expected.
>
> Yes, this fixes the SATA regression:
> Tested-by: Alex Deucher
>
> I'm not sure if it's related to this patch or not (I haven't bisected
> it independently yet), but MSIs don't seem to work on GPUs. See the
> line for amdgpu. This is just after loading the driver.
Hi Alex,
This patch only affects multiple-MSI, and it seems that your
gpu only uses one MSI interrupt, so it may not be related to this patch.
And this seems like a sort of interrupt storm.
> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI
> 524288-edge amdgpu
Does it make any change by disable interrupt remapping?
>>>
>>> Nope. Still going crazy:
>>> 46:4769660476913047758994784657 PCI-MSI
>>> 524288-edge amdgpu
>>>
>>>
Does it make any change by disable MSI?
>>>
>>> If I set pci=nomsi, the sata controllers time out. If I disable MSIs
>>> just for the gpu, I don't get any interrupts:
>>> 25: 0 0 0 0 IR-IO-APIC
>>> 0-fasteoi amdgpu
>>>
>>
>> Strangely, it only seems to affect certain boards. E.g., this card works
>> fine:
>> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
>> [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00
>> [VGA controller])
>> Subsystem: Diamond Multimedia Systems Device 2329
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 52
>> Region 0: Memory at c000 (64-bit, prefetchable) [size=256M]
>> Region 2: Memory at d000 (64-bit, prefetchable) [size=8M]
>> Region 4: I/O ports at e000 [size=256]
>> Region 5: Memory at ff60 (32-bit, non-prefetchable) [size=256K]
>> Expansion ROM at ff64 [disabled] [size=128K]
>> Capabilities: [48] Vendor Specific Information: Len=08
>> Capabilities: [50] Power Management version 3
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0-,D1+,D2+,D3hot+,D3cold-)
>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
>> DevCap:MaxPayload 256 bytes, PhantFunc 0, Latency L0s
>> <4us, L1 unlimited
>> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>> DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
>> MaxPayload 256 bytes, MaxReadReq 512 bytes
>> DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
>> TransPend-
>> LnkCap:Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit
>> Latency L0s <64ns, L1 <1us
>> ClockPM- Surprise- LLActRep- BwNot-
>> LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- CommClk+
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta:Speed 8GT/s, Width x16, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>> DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-,
>> OBFF Not Supported
>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
>> OBFF Disabled
>> LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
>> Transmit Margin: Normal Operating Range,
>> EnterModifiedCompliance- ComplianceSOS-
>> Compliance De-emphasis: -6dB
>> LnkSta2: Current De-emphasis Level: -6dB,
>> EqualizationComplete+, EqualizationPhase1+
>> EqualizationPhase2+, EqualizationPhase3+,
>> LinkEqualizationRequest-
>> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: fee0 Data:
>> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
>> Len=010
>> Capabilities: [150 v2] Advanced Error Reporting
>> UESta:
Re: [PATCH v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On 08/24/2015 07:40 PM, Zhao Qiang wrote:
On 08/25/2015 07:11 AM, Laura Abbott wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:11 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 1/3] genalloc:support memory-allocation with
bytes-alignment to genalloc
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
Bytes alignment is required to manage some special RAM, so add
gen_pool_first_fit_align to genalloc, meanwhile add
gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang
---
Changes for v6:
- patches set v6 include a new patch because of using
- genalloc to manage QE MURAM, patch 0001 is the new
- patch, adding bytes alignment for allocation for use.
include/linux/genalloc.h | 23 +++
lib/genalloc.c | 58
+++-
2 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
1ccaab4..55da07e 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -34,6 +34,7 @@
struct device;
struct device_node;
+struct gen_pool;
/**
* Allocation callback function type definition @@ -47,7 +48,7 @@
typedef unsigned long (*genpool_algo_t)(unsigned long *map,
unsigned long size,
unsigned long start,
unsigned int nr,
- void *data);
+ void *data, struct gen_pool *pool);
/*
* General purpose special memory pool descriptor.
@@ -73,6 +74,13 @@ struct gen_pool_chunk {
unsigned long bits[0]; /* bitmap for allocating memory chunk
*/
};
+/*
+ * gen_pool data descriptor for gen_pool_first_fit_align.
+ */
+struct genpool_data_align {
+ int align; /* alignment by bytes for starting address */
+};
+
(sorry for chiming in late, I've been traveling)
Is there an advantage here to wrapping this in a structure instead of
just passing a pointer to an align integer?
Please look at the commit message for
ca279cf1065fb689abea1dc7d8c11787729bb185 which adds "data":
"As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm."
Right, I understand what the purpose is but I'm not sure what you're getting
from the structure vs passing a pointer, e.g.
int align;
align = 4;
gen_pool_alloc_data(, size, );
it just seems to obfuscate what's going on by wrapping a single integer in
a structure that's narrowly defined in a generic function right now. I guess
it could change later which would necessitate having the structure but again
it's so generic I'm not sure what else you would pass that would be applicable
to all clients.
Thanks,
Laura
--
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 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > > On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > >> > >> On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey > Minyard > > This patch will break ATN handling on the interfaces. So we can't do > this. > >>> I understand. So how about doing like this: > >>> > >>> /* All states wait for ibf, so just do it here. */ > >>> - if (!check_ibf(kcs, status, time)) > >>> + if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time)) > >>> return SI_SM_CALL_WITH_DELAY; > >>> > >>> I think it is not necessary to wait IBF when the state is IDLE. > >>> In this way, we can also handle the ATN case. > >> I think it would be more reliable to go up a level and add a timeout. > > It may be so, but we should address this issue separately (at least > > I think above solution reasonably solves the issue). > > > > This issue happens after all queued messages are processed or dropped > > by timeout. There is no current message. So what should we set > > a timeout against? We can add a timeout into my new flush_messages(), > > but that is meaningful only in panic context. That doesn't help > > in normal context; we would perform a busy loop of smi_event_handler() > > and schedule() in ipmi_thread(). > > I'm a little confused here. Is the problem that the ATN bit is stuck > high? If so, it's going to be really hard to work around this without > breaking ATN handling. Sorry for my insufficient explanation. I assume the case where IBF bit is always 1. I don't know what happens when BMC hangs up, but I guess IBF stays in 1 because my server's BMC behaves as such while rebooting. Regards, Hidehiro Kawai > >> One should > >> be there, anyway. I thought they were all covered, but I may have missed > >> something. > >> > >> -corey > >> > >>> Regards, > >>> > >>> Hidehiro Kawai > >>> Hitachi, Ltd. Research & Development Group > >>> > It's going to be extremely hard to recover if the BMC is not working > correctly when a panic happens. I'm not sure what can be done, but if > you can fix it another way it would be good. > > -corey > > On 07/27/2015 12:55 AM, Hidehiro Kawai wrote: > > If a BMC is unresponsive for some reason, it ends up completing > > the requested message as an error, then kcs_event() is called once > > to advance the state machine. However, since the BMC is > > unresponsive now, the status of the KCS interface may not be > > idle. As the result, the state machine can continue to run and > > comsume CPU time indefinitely even if there is no more request > > message. Moreover, if this happens in run-to-completion mode > > (i.e. context of panic_event()), the kernel hangs up. > > > > To fix this problem, this patch ignores kcs_event() call if there > > is no request message to be processed. > > > > Signed-off-by: Hidehiro Kawai > > --- > > drivers/char/ipmi/ipmi_kcs_sm.c |4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c > > b/drivers/char/ipmi/ipmi_kcs_sm.c > > index 8c25f59..0e187fb 100644 > > --- a/drivers/char/ipmi/ipmi_kcs_sm.c > > +++ b/drivers/char/ipmi/ipmi_kcs_sm.c > > @@ -353,6 +353,10 @@ static enum si_sm_result kcs_event(struct > > si_sm_data *kcs, long time) > > if (kcs_debug & KCS_DEBUG_STATES) > > printk(KERN_DEBUG "KCS: State = %d, %x\n", kcs->state, > > status); > > > > + /* We don't want to run the state machine when the state is > > IDLE */ > > + if (kcs->state == KCS_IDLE) > > + return SI_SM_IDLE; > > + > > /* All states wait for ibf, so just do it here. */ > > if (!check_ibf(kcs, status, time)) > > return SI_SM_CALL_WITH_DELAY; > > > >
Re: [PATCH v6 0/6] mmc: imx: a few fixes and new feature
On Thu, Aug 13, 2015 at 04:58:56PM +0800, Dong Aisheng wrote: > On Tue, Aug 11, 2015 at 07:38:25PM +0800, Haibo Chen wrote: > > Changes for v6: > > -remove duplicate code in esdhc_set_uhs_signaling(). > > -fix a typo for patch-2. > > -make commit log of patch-3 more specific. > > > > Haibo Chen (6): > > mmc: sdhci-esdhc-imx: add imx7d support and support HS400 > > mmc: sdhci-esdhc-imx: add tuning-step setting support > > mmc: sdhci-esdhc-imx: add imx7d support in bingding doc > > ARM: dts: imx7d-sdb: add eMMC5.0 support > > mmc: sdhci-esdhc-imx: set back the burst_length_enable bit to 1 > > mmc: sdhci-esdhc-imx: change default watermark level and burst length > > > > .../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 6 ++ > > arch/arm/boot/dts/imx7d-sdb.dts| 13 +++ > > drivers/mmc/host/sdhci-esdhc-imx.c | 114 > > - > > include/linux/platform_data/mmc-esdhc-imx.h| 1 + > > 4 files changed, 130 insertions(+), 4 deletions(-) > > > > -- > > 1.9.1 > > > > The patch set looks good to me. > > Acked-by: Dong Aisheng > > Regards > Dong Aisheng Hi Ulf, Can you help pull these patches into your branch? Best regards Haibo -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
On Tue, Aug 25, 2015 at 8:35 AM, Olof Johansson wrote: > That's OK, others surely capitalize their platform names too in > documentation. Some of them even have funkier capitalization than > that, such as "SPEAr". That's how the company projected it :( www.st.com/spear -- 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] drm/crtc: Add a helper func to get a registered crtc from its index
This patch add a helper func to get a registered crtc from its index.
In some case, where we know the crtc's index and we want to know the
crtc too.
For example, the enable_vblank func of struct drm_driver:
In the implementation of this func, we know the index of the crtc but
we want to know the crtc. This helper func can get the crtc easily.
A sample impelmentation of enable_vblank is as shown as bellow:
int hisi_drm_crtc_enable_vblank(struct drm_device *dev, int c)
{
struct drm_crtc *crtc = drm_get_crtc_from_index(dev, c);
struct hisi_crtc *hcrtc = to_hisi_crtc(crtc);
struct hisi_crtc_ops *ops = hcrtc->ops;
int ret = 0;
if (ops->enable_vblank)
ret = ops->enable_vblank(hcrtc);
return ret;
}
Signed-off-by: Xinliang Liu
---
drivers/gpu/drm/drm_crtc.c | 25 +
include/drm/drm_crtc.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b9ba061..8764765 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -747,6 +747,31 @@ unsigned int drm_crtc_index(struct drm_crtc *crtc)
}
EXPORT_SYMBOL(drm_crtc_index);
+/**
+ * drm_get_crtc_from_index - find a registered CRTC from the index
+ * @dev: DRM device
+ * @index: index of a registered CRTC
+ *
+ * Given a index, return the registered CRTC within a DRM
+ * device's list of CRTCs.
+ */
+struct drm_crtc *drm_get_crtc_from_index(struct drm_device *dev,
+unsigned int index)
+{
+ unsigned int index_tmp = 0;
+ struct drm_crtc *crtc;
+
+ list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+ if (index_tmp == index)
+ return crtc;
+
+ index_tmp++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_get_crtc_from_index);
+
/*
* drm_mode_remove - remove and free a mode
* @connector: connector list to modify
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 57ca8cc..3a46d39d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1225,6 +1225,8 @@ extern int drm_crtc_init_with_planes(struct drm_device
*dev,
const struct drm_crtc_funcs *funcs);
extern void drm_crtc_cleanup(struct drm_crtc *crtc);
extern unsigned int drm_crtc_index(struct drm_crtc *crtc);
+extern struct drm_crtc *drm_get_crtc_from_index(struct drm_device *dev,
+ unsigned int index);
/**
* drm_crtc_mask - find the mask of a registered CRTC
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
Call path is
"proc_dointvec-->do_proc_dointvec-->__do_proc_dointvec-->proc_get_long".
file: kernel/sysctl.c
function: proc_get_long
...
1927 if (len < *size && perm_tr_len && !memchr(perm_tr, *p,
perm_tr_len)) //this line should accept two bytes
"1\0".
1928 return -EINVAL;
...
The latest upstream kernel is also tested, and it is same as 3.16.7 kernel.
3.16.7 kernel:
sean@linux-dunz:~/work/suse_lab/proc_test> cat /proc/version
Linux version 3.16.7-7-desktop (geeko@buildhost) (gcc version 4.8.3
20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP
PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a)
sean@linux-dunz:~/work/suse_lab/proc_test> gcc ./proc_test.c -o proc_test
sean@linux-dunz:~/work/suse_lab/proc_test> sudo ./proc_test enp0s25
Input: ./proc_test, enp0s25
file is: /proc/sys/net/ipv4/conf/enp0s25/rp_filter.
open /proc/sys/net/ipv4/conf/enp0s25/rp_filter ok, fd=3
write 3: len=-1, errno=22, Invalid argument
2.6.16.60 kernel:
linux-8lij:~ # gcc ./proc_test.c -o ./proc_test
linux-8lij:~ # cat /proc/version
Linux version 2.6.16.60-0.83.2-bigsmp (geeko@buildhost) (gcc version
4.1.2 20070115 (SUSE Linux)) #1 SMP Fri Sep 2 13:49:16 UTC 2011
linux-8lij:~ # gcc ./proc_test.c -o ./proc_test
linux-8lij:~ # ./proc_test eth7
Input: ./proc_test, eth7
file is: /proc/sys/net/ipv4/conf/eth7/rp_filter.
open /proc/sys/net/ipv4/conf/eth7/rp_filter ok, fd=3
write 3: len=1, errno=0, Success
On Tue, Aug 25, 2015 at 8:57 AM, Sean Fu wrote:
> An application from HuaWei which works fine on 2.6 encounters this
> issue on 3.0 or later kernel.
>
> Test code:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define MAXLEN (100)
>
> int main(int argc, char** argv)
> {
> int fd = 0;
> int len = 0;
> char pathname[MAXLEN] = {0};
> char buf[2] = {0};
> int ret = 0xF;
> int value = 0xF;
>
> if (argc < 2)
> {
> printf("Input param error, less 2 param: %s, %s.\n",
> argv[0], argv[1]);
> return 1;
> }
>
> printf("Input: %s, %s \n", argv[0], argv[1]);
>
> ret = sprintf(pathname,
> "/proc/sys/net/ipv4/conf/%s/rp_filter", argv[1]);
> if (ret < 0)
> printf("sprintf error, errno %d, %s\n", errno,
> strerror(errno));
> printf("file is: %s. \n", pathname);
>
> fd = open(pathname, O_RDWR, S_IRUSR);
> if (fd <=0 )
> {
> printf("open %s failed, errno=%d, %s.\n", pathname,
> errno, strerror(errno));
> return 1;
> }
> printf("open %s ok, fd=%d\n", pathname, fd);
>
> len = write(fd, "0\0", 2);
> printf("write %d: len=%d, errno=%d, %s\n", fd, len, errno,
> strerror(errno));
>
> close(fd);
> return 0;
> }
>
> On Tue, Aug 25, 2015 at 12:59 AM, Steven Rostedt wrote:
>> On Mon, 24 Aug 2015 16:56:13 +0800
>> Sean Fu wrote:
>>
>>> when the input argument "count" including the terminating byte "\0",
>>> The write system call return EINVAL on proc file.
>>> But it return success on regular file.
>>>
>>> E.g. Writting two bytes ("1\0") to "/proc/sys/net/ipv4/conf/eth0/rp_filter".
>>> write(fd, "1\0", 2) return EINVAL.
>>
>> And what would do that? What tool broke because of this?
>>
>> echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
>>
>> works just fine. strlen("string") would not include the nul character.
>> The only thing I could think of would be a sizeof(str), but then that
>> would include someone hardcoding an integer in a string, like:
>>
>> char val[] = "1"
>>
>> write(fd, val, sizeof(val));
>>
>> Again, what tool does that?
>>
>> If there is a tool out in the wild that use to work on 2.6 (and was
>> running on 2.6 then, and not something that was created after that
>> change), then we can consider this fix.
>>
>> -- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
On Mon, Aug 24, 2015 at 6:50 PM, Masahiro Yamada wrote: > Hi Olof, > > > 2015-08-25 6:47 GMT+09:00 Olof Johansson : >> Hi, >> >> On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada >> wrote: >>> 1/3: add outer cache support >>> 2/3: rework SMP operations >>> 3/3: add device tree nodes >> >> Timing of this is unfortunate, please resend after 4.3-rc1 is out and >> we can queue it up. > > Given that rc8 is out and the merge window has been delayed, > is it still too late for 4.3-rc1? Yes. >>> Because 2/3 highly depends on 1/3, I hope whole of this series >>> is applied to ARM-SOC tree. >> >> Review or acked-by from Russell would be appreciated in that case. >> >>> Olof, >>> From this series, I am using "ARM: uniphier:" rather than "ARM: UniPhier:" >>> for the subject prefixes because I noticed you often rephased so when you >>> applied my patches. >>> Are sub-arch names in lower cases preferable in subject prefixes? >> >> If you look at "git log --no-merges --oneline arch/arm/mach-*" you'll >> see that most platforms use either all-caps or all-lowercase. > > I see. > > But, we use "UniPhier" (with only U and P capitalized) in our official > documents. That's OK, others surely capitalize their platform names too in documentation. Some of them even have funkier capitalization than that, such as "SPEAr". -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses
On 08/24/2015 10:05 PM, Cornelia Huck wrote:
> On Mon, 24 Aug 2015 11:29:29 +0800
> Jason Wang wrote:
>
>> On 08/21/2015 05:29 PM, Cornelia Huck wrote:
>>> On Fri, 21 Aug 2015 16:03:52 +0800
>>> Jason Wang wrote:
@@ -850,9 +845,15 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct
kvm_ioeventfd *args)
>>> Unfortunately snipped by diff, but the check here is on !len && !PIO,
>>> which only does the desired thing as VIRTIO_CCW always uses len == 8.
>>> Should the check be for !len && MMIO instead?
>> I think the answer depends on whether len == 0 is valid for ccw. If not
>> we can fail the assign earlier. Since even without this patch, if
>> userspace tries to register a dev with len equals to zero, it will also
>> be registered to KVM_FAST_MMIO_BUS. If yes, we need check as you
>> suggested here.
> I don't think len != 8 makes much sense for the way ioeventfd is
> defined for ccw (we handle hypercalls with a payload specifying the
> device), but we currently don't actively fence it.
>
> But regardless, I'd prefer to decide directly upon whether userspace
> actually tried to register for the mmio bus.
Ok.
>
ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
p->addr, 0, >dev);
if (ret < 0)
- goto register_fail;
+ goto unlock_fail;
+ } else {
+ ret = kvm_io_bus_register_dev(kvm, bus_idx, p->addr, p->length,
+>dev);
+ if (ret < 0)
+ goto unlock_fail;
}
>>> Hm... maybe the following would be more obvious:
>>>
>>> my_bus = (p->length == 0) && (bus_idx == KVM_MMIO_BUS) ? KVM_FAST_MMIO_BUS
>>> : bus_idx;
>>> ret = kvm_io_bus_register_dev(kvm, my_bus, p->addr, p->length, >dev);
>>>
+
kvm->buses[bus_idx]->ioeventfd_count++;
list_add_tail(>list, >ioeventfds);
>>> (...)
>>>
@@ -900,10 +899,11 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct
kvm_ioeventfd *args)
if (!p->wildcard && p->datamatch != args->datamatch)
continue;
- kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
if (!p->length) {
kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
>dev);
+ } else {
+ kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
}
>>> Similar comments here... do you want to check for bus_idx ==
>>> KVM_MMIO_BUS as well?
>> Good catch. I think keep the original code as is will be also ok to
>> solve this. (with changing the bus_idx to KVM_FAST_MMIO_BUS during
>> registering if it was an wildcard mmio).
> Do you need to handle the ioeventfd_count changes on the fast mmio bus
> as well?
Yes. So actually, it needs some changes: checking the return value of
kvm_io_bus_unregister_dev() and decide which bus does the device belongs to.
>
kvm->buses[bus_idx]->ioeventfd_count--;
ioeventfd_release(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] arch/sh: provide unified syscall trap compatible with all SH models
From: Rich Felker Historically SH-2 Linux (and originally uClinux) used a syscall calling convention incompatible with the established SH-3/4 Linux ABI. This choice was made because the trap range used by the existing ABI, 0x10-0x17, overlaps with the hardware exception/interrupt trap range reserved by SH-2, and in particular, with the SH-2A divide-by-zero and division-overflow exceptions. Despite the documented syscall convention using the low bits of the trap number to signal the number of arguments the kernel should expect, no version of the kernel has ever used this information, nor is it useful; all of the registers need to be saved anyway. Therefore, it is possible to pick a new trap number, 0x1f, that is both supported by all existing SH-3/4 kernels and unassigned as a hardware trap in the SH-2 range. This makes it possible to produce SH-2 application binaries that are forwards-compatible with running on SH-3/4 kernels and to treat SH as a unified platform with varying ISA support levels rather than multiple gratuitously-incompatible platforms. This patch adjusts the range checking SH-2 and SH-2A kernels make for the syscall trap to accept the range 0x1f-0x2f rather than just 0x20-0x2f. As a result, trap 0x1f now acts as a syscall for all SH models. Signed-off-by: Rich Felker --- The original proposal for using 0x1f as a unified syscall trap was reviewed by Jeff Dionne, Yoshinori Sato, and Shumpei Kawasaki for conflicts with existing trap number assignments, and none were found. I introduced this proposal as a way to add SH-2 support to musl libc in a forwards-compatible way, treating SH as a unified architecture, with the particular intent of supporting the Open Processor Foundation's J2 Core (SH-2 ISA plus some extensions) and providing a smooth upgrade path to the future J4 Core (SH-4 equivalent) and other full-fledged SH platforms with MMU. There is also some interest in having glibc's SH port support SH-2/J2, which is more practical with a common syscall ABI; whether this will actually happen remains uncertain. Rich diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2/entry.S ./arch/sh/kernel/cpu/sh2/entry.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2/entry.S2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/cpu/sh2/entry.S2015-08-24 03:23:34.159387924 + @@ -144,9 +144,9 @@ ENTRY(exception_handler) mov #64,r8 cmp/hs r8,r9 bt interrupt_entry ! vec >= 64 is interrupt - mov #32,r8 + mov #31,r8 cmp/hs r8,r9 - bt trap_entry ! 64 > vec >= 32 is trap + bt trap_entry ! 64 > vec >= 31 is trap mov.l 4f,r8 mov r9,r4 @@ -178,9 +178,9 @@ interrupt_entry: trap_entry: mov #0x30,r8 - cmp/ge r8,r9 ! vector 0x20-0x2f is systemcall + cmp/ge r8,r9 ! vector 0x1f-0x2f is systemcall bt 1f - add #-0x10,r9 ! convert SH2 to SH3/4 ABI + mov #0x1f,r9! convert to unified SH2/3/4 trap number 1: shll2 r9 ! TRA bra system_call ! jump common systemcall entry diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2a/entry.S ./arch/sh/kernel/cpu/sh2a/entry.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2a/entry.S 2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/cpu/sh2a/entry.S 2015-08-24 03:23:58.849386418 + @@ -109,9 +109,9 @@ ENTRY(exception_handler) mov #64,r8 cmp/hs r8,r9 bt interrupt_entry ! vec >= 64 is interrupt - mov #32,r8 + mov #31,r8 cmp/hs r8,r9 - bt trap_entry ! 64 > vec >= 32 is trap + bt trap_entry ! 64 > vec >= 31 is trap mov.l 4f,r8 mov r9,r4 @@ -143,9 +143,9 @@ interrupt_entry: trap_entry: mov #0x30,r8 - cmp/ge r8,r9 ! vector 0x20-0x2f is systemcall + cmp/ge r8,r9 ! vector 0x1f-0x2f is systemcall bt 1f - add #-0x10,r9 ! convert SH2 to SH3/4 ABI + mov #0x1f,r9! convert to unified SH2/3/4 trap number 1: shll2 r9 ! TRA bra system_call ! jump common systemcall entry diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/entry-common.S ./arch/sh/kernel/entry-common.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/entry-common.S 2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/entry-common.S 2015-08-24 03:33:50.062683702 + @@ -268,19 +268,20 @@ debug_trap: * Syscall #: R3 * Arguments #0 to #3: R4--R7 * Arguments #4 to #6: R0, R1, R2 - * TRA: (number of arguments + ABI revision) x 4 + * TRA>>2: 0x1f, or one of a model-specific set of legacy values: * - * This code also handles delegating other traps to the BIOS/gdb stub - * according to: - * - * Trap number * (TRA>>2)Purpose *
RE: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Tuesday, August 25, 2015 7:32 AM
> To: Zhao Qiang-B45475; Wood Scott-B07421
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
> muram
>
> On 08/24/2015 02:31 AM, Zhao Qiang wrote:
>
>
> > +out:
> > + of_node_put(np);
> > + return ret;
> > +}
> > +
> > +/**
> > + * qe_muram_alloc - allocate the requested size worth of multi-user
> > +ram
> > + * @size: number of bytes to allocate
> > + * @align: requested alignment, in bytes
> > + *
> > + * This function returns an offset into the muram area.
> > + * Use qe_dpram_addr() to get the virtual address of the area.
> > + * Use qe_muram_free() to free the allocation.
> > + */
> > +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> > +{
> > + unsigned long start;
> > + unsigned long flags;
> > + struct muram_block *entry;
> > +
> > + spin_lock_irqsave(_muram_lock, flags);
> > + muram_pool_data.align = align;
> > + start = gen_pool_alloc(muram_pool, size);
>
> The advantage of creating gen_pool_alloc_data was so that you could pass
> in the align automatically without having to modify the structure.
> Is there a reason you aren't using that?
>
> > + memset(qe_muram_addr(start), 0, size);
>
> There doesn't seem to be a check for allocation failure from the
> gen_alloc.
gen_pool_alloc will return 0 if there is error, but if the address returned is
just 0x0, it can't distinguish it is address or error.
>
> > + entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> > + if (!entry)
> > + goto out;
> > + entry->start = start;
> > + entry->size = size;
> > + list_add(>head, _block_list);
>
> What's the point of keeping the block list anyway? It's used only in this
> file and it only seems to duplicate what gen_alloc is doing internally.
> Is there some lookup functionality you still need? Could you use a
> gen_alloc API to do so?
I need to record the size when allocation, so when free the block, I can get
The right size for the block, and pass the right size to
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).
>
>
> Thanks,
> Laura
Thanks
Zhao
--
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] clk: Add missing header for 'bool' definition to clk-conf.h
On Tue, Aug 25, 2015 at 5:28 AM, Stephen Boyd wrote: > On 08/18, Chen-Yu Tsai wrote: >> of_clk_set_defaults uses the type 'bool', but clk-conf.h does not >> include its definition. >> >> This results in a compile error when only clk-conf.h is used. >> >> Signed-off-by: Chen-Yu Tsai >> Cc: sta...@vger.kernel.org > > Why is stable Cc-ed? Is there some sort of compilation failure on > stable kernels? There isn't for now. Though I don't see why we shouldn't fix this for stable kernels as well. It's possible other people or third-party vendors working with stable/LTS kernels (Android?) may run into it. I'm perfectly fine with not Cc-ing stable. It just seemed like the right thing to do. Regards ChenYu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] cgroup: pids: fix invalid get/put usage
Fix incorrect usage of css_get and css_put to put a different css in
pids_{cancel_,}attach() than the one grabbed in pids_can_attach(). This
could lead to quite serious memory leakage (and unsafe operations on the
putted css).
Signed-off-by: Aleksa Sarai
---
kernel/cgroup_pids.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
index d75488824ae2..056564f8dd85 100644
--- a/kernel/cgroup_pids.c
+++ b/kernel/cgroup_pids.c
@@ -173,11 +173,11 @@ static int pids_can_attach(struct cgroup_subsys_state
*css,
struct pids_cgroup *old_pids;
/*
-* Grab a ref to each task's css. We don't drop the ref until
-* we either fail and hit ->cancel_attach() or succeed and hit
-* ->attach().
+* We don't need to grab a ref between here and cancel_attach()
+* because cgroup_migrate_prepare_src() protects the task's css
+* from being freed before the migration completed or failed.
*/
- old_css = task_get_css(task, pids_cgrp_id);
+ old_css = task_css(task, pids_cgrp_id);
old_pids = css_pids(old_css);
pids_charge(pids, 1);
@@ -202,19 +202,9 @@ static void pids_cancel_attach(struct cgroup_subsys_state
*css,
pids_charge(old_pids, 1);
pids_uncharge(pids, 1);
- css_put(old_css);
}
}
-static void pids_attach(struct cgroup_subsys_state *css,
- struct cgroup_taskset *tset)
-{
- struct task_struct *task;
-
- cgroup_taskset_for_each(task, tset)
- css_put(task_css(task, pids_cgrp_id));
-}
-
static int pids_can_fork(struct task_struct *task, void **priv_p)
{
struct cgroup_subsys_state *css;
@@ -354,7 +344,6 @@ static struct cftype pids_files[] = {
struct cgroup_subsys pids_cgrp_subsys = {
.css_alloc = pids_css_alloc,
.css_free = pids_css_free,
- .attach = pids_attach,
.can_attach = pids_can_attach,
.cancel_attach = pids_cancel_attach,
.can_fork = pids_can_fork,
--
2.5.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 v6 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc
On 08/25/2015 07:11 AM, Laura Abbott wrote:
> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Tuesday, August 25, 2015 7:11 AM
> To: Zhao Qiang-B45475; Wood Scott-B07421
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v6 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
>
> On 08/24/2015 02:31 AM, Zhao Qiang wrote:
> > Bytes alignment is required to manage some special RAM, so add
> > gen_pool_first_fit_align to genalloc, meanwhile add
> > gen_pool_alloc_data to pass data to gen_pool_first_fit_align(modify
> > gen_pool_alloc as a wrapper)
> >
> > Signed-off-by: Zhao Qiang
> > ---
> > Changes for v6:
> > - patches set v6 include a new patch because of using
> > - genalloc to manage QE MURAM, patch 0001 is the new
> > - patch, adding bytes alignment for allocation for use.
> >
> > include/linux/genalloc.h | 23 +++
> > lib/genalloc.c | 58
> +++-
> > 2 files changed, 72 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h index
> > 1ccaab4..55da07e 100644
> > --- a/include/linux/genalloc.h
> > +++ b/include/linux/genalloc.h
> > @@ -34,6 +34,7 @@
> >
> > struct device;
> > struct device_node;
> > +struct gen_pool;
> >
> > /**
> >* Allocation callback function type definition @@ -47,7 +48,7 @@
> > typedef unsigned long (*genpool_algo_t)(unsigned long *map,
> > unsigned long size,
> > unsigned long start,
> > unsigned int nr,
> > - void *data);
> > + void *data, struct gen_pool *pool);
> >
> > /*
> >* General purpose special memory pool descriptor.
> > @@ -73,6 +74,13 @@ struct gen_pool_chunk {
> > unsigned long bits[0]; /* bitmap for allocating memory chunk
> */
> > };
> >
> > +/*
> > + * gen_pool data descriptor for gen_pool_first_fit_align.
> > + */
> > +struct genpool_data_align {
> > + int align; /* alignment by bytes for starting address */
> > +};
> > +
>
> (sorry for chiming in late, I've been traveling)
>
> Is there an advantage here to wrapping this in a structure instead of
> just passing a pointer to an align integer?
Please look at the commit message for
ca279cf1065fb689abea1dc7d8c11787729bb185 which adds "data":
"As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed
information to the allocation function. For example 'data' could be used
to handle a structure where you store the alignment, the expected memory
bank, the requester device, or any information that could influence the
allocation algorithm."
>
> Thanks,
> Laura
-Zhao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
On 2015/08/25 8:15, Paul Turner wrote: On Mon, Aug 24, 2015 at 3:49 PM, Tejun Heo wrote: Hello, On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: Hmm... I was hoping for an actual configurations and usage scenarios. Preferably something people can set up and play with. This is much easier to set up and play with synthetically. Just create the 10 threads and 100 threads above then experiment with configurations designed at guaranteeing the set of 100 threads relatively uniform throughput regardless of how many are active. I don't think trying to run a VM stack adds anything except complexity of reproduction here. Well, but that loses most of details and why such use cases matter to begin with. We can imagine up stuff to induce arbitrary set of requirements. All that's being proved or disproved here is that it's difficult to coordinate the consumption of asymmetric thread pools using nice. The constraints here were drawn from a real-world example. I take that the CPU intensive helper threads are usually IO workers? Is the scenario where the VM is set up with a lot of IO devices and different ones may consume large amount of CPU cycles at any given point? Yes, generally speaking there are a few major classes of IO (flash, disk, network) that a guest may invoke. Each of these backends is separate and chooses its own threading. Hmmm... if that's the case, would limiting iops on those IO devices (or classes of them) work? qemu already implements IO limit mechanism after all. No. 1) They should proceed at the maximum rate that they can that's still within their provisioning budget. 2) The cost/IO is both inconsistent and changes over time. Attempting to micro-optimize every backend for this is infeasible, this is exactly the type of problem that the scheduler can usefully help arbitrate. 3) Even pretending (2) is fixable, dynamically dividing these right-to-work tokens between different I/O device backends is extremely complex. I think I should explain my customer's use case of qemu + cpuset/cpu (via libvirt) (1) Isolating hypervisor thread. As already discussed, hypervisor threads are isolated by cpuset. But their purpose is to avoid _latency_ spike caused by hypervisor behavior. So, "nice" cannot be solution as already discussed. (2) Fixed rate vcpu service. With using cpu controller's quota/period feature, my customer creates vcpu models like Low(1GHz), Mid(2GHz), High(3GHz) for IaaS system. To do this, each vcpus should be quota-limited independently, with per-thread cpu control. Especially, the method (1) is used in several enterprise customers for stabilizing their system. Sub-process control should be provided by some way. Thanks, -Kame Anyways, a point here is that threads of the same process competing isn't a new problem. There are many ways to make those threads play nice as the application itself often has to be involved anyway, especially for something like qemu which is heavily involved in provisioning resources. It's certainly not a new problem, but it's a real one, and it's _hard_. You're proposing removing the best known solution. cgroups can be a nice brute-force add-on which lets sysadmins do wild things but it's inherently hacky and incomplete for coordinating threads. For example, what is it gonna do if qemu cloned vcpus and IO helpers dynamically off of the same parent thread? We're talking about sub-process usage here. This is the application coordinating itself, NOT the sysadmin. Processes are becoming larger and larger, we need many of the same controls within them that we have between them. It requires application's cooperation anyway but at the same time is painful to actually interact from those applications. As discussed elsewhere on thread this is really not a problem if you define consistent rules with respect to which parts are managed by who. The argument of potential interference is no different to messing with an application's on-disk configuration behind its back. Alternate strawmen which greatly improve this from where we are today have also been proposed. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register support
Hi Jagan,
> -Original Message-
> From: Jagan Teki [mailto:jt...@openedev.com]
> Sent: 2015年8月21日 15:12
> To: Hou Zhiqiang-B48286
> Cc: linux-...@lists.infradead.org; Hu Mingkai-B21284; Brian Norris; David
> Woodhouse; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register
> support
>
> Hi Zhiqiang,
>
> On 20 August 2015 at 08:36, Hou Zhiqiang wrote:
> > Hello Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jt...@openedev.com]
> >> Sent: 2015年8月20日 1:49
> >> To: Hou Zhiqiang-B48286
> >> Cc: linux-...@lists.infradead.org; Hu Mingkai-B21284; Brian Norris;
> >> David Woodhouse; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status
> >> register support
> >>
> >> Hi Zhiqiang,
> >>
> >> On 19 August 2015 at 17:42, Hou Zhiqiang wrote:
> >> > Hi Jagan,
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:jt...@openedev.com]
> >> >> Sent: 2015年8月19日 17:57
> >> >> To: linux-...@lists.infradead.org
> >> >> Cc: linux-kernel@vger.kernel.org; Jagan Teki; Hou Zhiqiang-B48286;
> >> >> Hu Mingkai-B21284; David Woodhouse; Brian Norris
> >> >> Subject: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status
> >> >> register support
> >> >>
> >> >> The clear flag status register operation was required by Micron
> >> >> SPI-NOR chips, which support FSR. And if an error bit of FSR have
> >> >> been set like protection, voltage, erase, and program, it must be
> >> >> cleared by the clear FSR operation.
> >> >>
> >> >> Signed-off-by: Jagan Teki
> >> >> Cc: Hou Zhiqiang
> >> >> Cc: Mingkai.Hu
> >> >> Cc: David Woodhouse
> >> >> Cc: Brian Norris
> >> >> ---
> >> >> drivers/mtd/spi-nor/spi-nor.c | 35
> >> >> +++---
> >> -
> >> >> include/linux/mtd/spi-nor.h | 9 +
> >> >> 2 files changed, 40 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> >> >> b/drivers/mtd/spi-nor/spi- nor.c index f954d03..c5c472d5 100644
> >> >> --- a/drivers/mtd/spi-nor/spi-nor.c
> >> >> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> >> @@ -100,6 +100,28 @@ static int read_fsr(struct spi_nor *nor) }
> >> >>
> >> >> /*
> >> >> + * Read the clear flag status register.
> >> >> + * The clear flag status register operation was required by
> >> >> +Micron
> >> >> + * SPI-NOR chips, which support FSR. And if an error bit of FSR
> >> >> + * have been set like protection, voltage, erase, and program,
> >> >> + * it must be cleared by the clear FSR operation.
> >> >> + * Returns zero for FSR bits cleared and negative if error
> occurred.
> >> >> + */
> >> >> +static int read_cfsr(struct spi_nor *nor) {
> >> >> + int ret;
> >> >> + u8 val;
> >> >> +
> >> >> + ret = nor->read_reg(nor, SPINOR_OP_RDCFSR, , 1);
> >> >
> >> > There should be a write_reg instead of read_reg.
> >> > There isn’t a register named CFSR, and the command SPINOR_OP_RDCFSR
> >> > is used to clear the FSR, another words reset FSR to default value.
> >>
> >> Yes, SPINOR_OP_RDCFSR is clear flag status register, for clearing
> >> errors bits on fsr we need to read cfsr once.
> >>
> >
> > Sorry, I'm not clear for this operation. Please correct me if I'm wrong.
> > As far as I understand, this command is used to reset the FSR. Does a
> > value Will be read back? And there is not the register CFSR, so I
> > don't know which register will be read by SPINOR_OP_RDCFSR?
>
> Sorry for the confusion in previous email.
>
> If there is any error bits set during FSR operation, those will reset
> back to original values by reading CFSR ie means the bits on flag status
> register revert back to original state, so-that the flag status register
> is ready for next FSR operation.
>
> I have defined this, SPINOR_OP_RDCFSR on the patch
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index c5a58c4..36c1681 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -35,6 +35,7 @@
> #define SPINOR_OP_RDID 0x9f/* Read JEDEC ID */
> #define SPINOR_OP_RDCR 0x35/* Read configuration register */
> #define SPINOR_OP_RDFSR0x70/* Read flag status
> register */
> +#define SPINOR_OP_RDCFSR 0x50/* Read clear flag status
> register */
>
> For more information pls- refer flash datasheet[1]
>
> Page, 29: about fsr
> Page, 41: about cfsr
Upon page 41, I think, it is a CMD which is used to clear the FSR instead of
a CFSR Register. This section is to expound the "CLEAR FLAG STATUS REGISTER
Command", and it says execute this CMD to clear the error bits, rather than
read the CFSR to clear those bits.
>
> [1]
> https://www.google.co.in/url?sa=t=j==s=web=2=rja
> =8=0CCIQFjABahUKEwjTwY3zzbnHAhXVj44KHdiWDVU=https%3A%2F%2Fww
> w.micron.com%2F~%2Fmedia%2Fdocuments%2Fproducts%2Fdata-sheet%2Fnor-
> flash%2Fserial-
> nor%2Fn25q%2Fn25q_512mb_1ce_3v_65nm.pdf=Uc3WVZPVCNWfugTYrbaoBQ=AFQ
>
[PATCH 03/20] ACPICA: Update parameter validation for data_table_region and load_table.
From: Bob Moore
ACPICA commit 51ab555e60b4a3de3cc4a846e86d0de255be441a
Add additional validation for the table signature and
the OEM strings. Eliminates buffer read overrun in data_table_region.
ACPICA BZ 1184.
Link: https://bugs.acpica.org/show_bug.cgi?id=1184
Link: https://github.com/acpica/acpica/commit/51ab555e
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/actables.h |2 ++
drivers/acpi/acpica/dsopcode.c | 31 ---
drivers/acpi/acpica/exconfig.c |8
drivers/acpi/acpica/tbfind.c | 15 ++-
drivers/acpi/acpica/tbutils.c | 33 +
5 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 7e0b6f1..58497b7 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -164,4 +164,6 @@ acpi_tb_install_fixed_table(acpi_physical_address address,
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
+u8 acpi_is_valid_signature(char *signature);
+
#endif /* __ACTABLES_H__ */
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index ea0cc4e..81d7b986 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -480,8 +480,8 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
union acpi_operand_object **operand;
struct acpi_namespace_node *node;
union acpi_parse_object *next_op;
- u32 table_index;
struct acpi_table_header *table;
+ u32 table_index;
ACPI_FUNCTION_TRACE_PTR(ds_eval_table_region_operands, op);
@@ -504,6 +504,8 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
return_ACPI_STATUS(status);
}
+ operand = _state->operands[0];
+
/*
* Resolve the Signature string, oem_id string,
* and oem_table_id string operands
@@ -511,32 +513,34 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
status = acpi_ex_resolve_operands(op->common.aml_opcode,
ACPI_WALK_OPERANDS, walk_state);
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ goto cleanup;
}
- operand = _state->operands[0];
-
/* Find the ACPI table */
status = acpi_tb_find_table(operand[0]->string.pointer,
operand[1]->string.pointer,
operand[2]->string.pointer, _index);
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ if (status == AE_NOT_FOUND) {
+ ACPI_ERROR((AE_INFO,
+ "ACPI Table [%4.4s] OEM:(%s, %s) not found
in RSDT/XSDT",
+ operand[0]->string.pointer,
+ operand[1]->string.pointer,
+ operand[2]->string.pointer));
+ }
+ goto cleanup;
}
- acpi_ut_remove_reference(operand[0]);
- acpi_ut_remove_reference(operand[1]);
- acpi_ut_remove_reference(operand[2]);
-
status = acpi_get_table_by_index(table_index, );
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ goto cleanup;
}
obj_desc = acpi_ns_get_attached_object(node);
if (!obj_desc) {
- return_ACPI_STATUS(AE_NOT_EXIST);
+ status = AE_NOT_EXIST;
+ goto cleanup;
}
obj_desc->region.address = ACPI_PTR_TO_PHYSADDR(table);
@@ -551,6 +555,11 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
obj_desc->region.flags |= AOPOBJ_DATA_VALID;
+cleanup:
+ acpi_ut_remove_reference(operand[0]);
+ acpi_ut_remove_reference(operand[1]);
+ acpi_ut_remove_reference(operand[2]);
+
return_ACPI_STATUS(status);
}
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 24a4c5c..b540913 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -162,14 +162,6 @@ acpi_ex_load_table_op(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ex_load_table_op);
- /* Validate lengths for the Signature, oem_id, and oem_table_id strings
*/
-
- if ((operand[0]->string.length > ACPI_NAME_SIZE) ||
- (operand[1]->string.length > ACPI_OEM_ID_SIZE) ||
- (operand[2]->string.length > ACPI_OEM_TABLE_ID_SIZE)) {
- return_ACPI_STATUS(AE_AML_STRING_LIMIT);
- }
-
/* Find the ACPI table in the RSDT/XSDT */
status = acpi_tb_find_table(operand[0]->string.pointer,
diff --git a/drivers/acpi/acpica/tbfind.c b/drivers/acpi/acpica/tbfind.c
index 119c84a..405529d 100644
---
Re: [PATCH 1/1] of: to support binding numa node to root subnode(non-bus)
On 2015/8/24 21:25, Rob Herring wrote: > +benh > > On Mon, Aug 24, 2015 at 7:30 AM, Zhen Lei wrote: >> If use of_platform_populate to scan dt-nodes and add devices, the >> subnode of root(such as /smmu), when being scanned and invoke > > You should have a bus as the sub-node of root rather than devices > directly off of root. You still have a problem though... But actually the parent of bus is also _bus if we didn't have special initialization. For example: The function of_platform_device_create_pdata invoke of_device_alloc first, then invoke of_device_add. But in of_device_alloc, we can find that: dev->dev.parent = parent ? : _bus; > >> of_device_add, the ofdev->dev.parent is always equal _bus. So >> that, function set_dev_node will not be called. And in device_add, >> dev_to_node(parent) always return NUMA_NO_NODE. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/base/core.c | 2 +- >> drivers/of/device.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/base/core.c b/drivers/base/core.c >> index dafae6d..5df4f46b 100644 >> --- a/drivers/base/core.c >> +++ b/drivers/base/core.c >> @@ -1017,7 +1017,7 @@ int device_add(struct device *dev) >> dev->kobj.parent = kobj; >> >> /* use parent numa_node */ >> - if (parent) >> + if (parent && (parent != _bus)) > > This is only fixing one specific case, but I think things are broken > for any case where the NUMA associativity if not set at the top level > bus node. I think this should be something like: > > if (parent && (dev_to_node(dev) != NO_NUMA_NODE)) It seems a mistake, we should use equal sign. if (parent && (dev_to_node(dev) == NUMA_NO_NODE)) > > Then the OF code can set the node however it wants. OK. I will send patch v2 base upon your advice. Thank you. > >> set_dev_node(dev, dev_to_node(parent)); >> >> /* first, register with generic layer. */ >> diff --git a/drivers/of/device.c b/drivers/of/device.c >> index 8b91ea2..96ebece 100644 >> --- a/drivers/of/device.c >> +++ b/drivers/of/device.c >> @@ -63,7 +63,7 @@ int of_device_add(struct platform_device *ofdev) >> /* device_add will assume that this device is on the same node as >> * the parent. If there is no parent defined, set the node >> * explicitly */ >> - if (!ofdev->dev.parent) >> + if (!ofdev->dev.parent || (ofdev->dev.parent == _bus)) > > And then remove the if here. > OK. I also think remove this statement will be better. Althouth set_dev_node maybe called two times, but it only spends very little time, and this almost happened at initialization phase. >> set_dev_node(>dev, >> of_node_to_nid(ofdev->dev.of_node)); >> >> return device_add(>dev); >> -- >> 2.5.0 >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: message: remove redundant declaration
Fix the Sparse warning:
message.c:1390:21: warning: symbol 'i' shadows an earlier one
message.c:1294:13: originally declared here
Signed-off-by: Kris Borer
---
drivers/usb/core/message.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index f368d20..e83648d 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1387,7 +1387,6 @@ int usb_set_interface(struct usb_device *dev, int
interface, int alternate)
* new altsetting.
*/
if (manual) {
- int i;
for (i = 0; i < alt->desc.bNumEndpoints; i++) {
epaddr = alt->endpoint[i].desc.bEndpointAddress;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/20] ACPICA: Debugger: Split debugger initialization/termination APIs.
ACPICA commit 7a3f22baab000b186779dac64ad71d9776b8f432
It is likely that the debugger is enabled only when a userspace program
explicitly tells a kernel to do so, so it shouldn't be initialized as
early as current implementation.
The only tool requiring ACPI_DEBUGGER is acpiexec, so acpiexec need to call
the new APIs by itself. And BSD developers may also get notified to invoke
the APIs for DDB enabling. Lv Zheng.
This patch doesn't affect Linux kernel as debugger is currently not enabled
in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/7a3f22ba
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acdebug.h |4
drivers/acpi/acpica/utxface.c |7 ---
drivers/acpi/acpica/utxfinit.c | 11 ---
include/acpi/acpixf.h |3 +++
4 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index b5a9c51..447f6d3 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -77,10 +77,6 @@ struct acpi_db_execute_walk {
/*
* dbxface - external debugger interfaces
*/
-acpi_status acpi_db_initialize(void);
-
-void acpi_db_terminate(void);
-
acpi_status
acpi_db_single_step(struct acpi_walk_state *walk_state,
union acpi_parse_object *op, u32 op_type);
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index c2bd5e2..4f33281 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -92,13 +92,6 @@ acpi_status __init acpi_terminate(void)
acpi_ut_mutex_terminate();
-#ifdef ACPI_DEBUGGER
-
- /* Shut down the debugger */
-
- acpi_db_terminate();
-#endif
-
/* Now we can shutdown the OS-dependent layer */
status = acpi_os_terminate();
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 42a32a6..a7137ec 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -124,17 +124,6 @@ acpi_status __init acpi_initialize_subsystem(void)
return_ACPI_STATUS(status);
}
- /* If configured, initialize the AML debugger */
-
-#ifdef ACPI_DEBUGGER
- status = acpi_db_initialize();
- if (ACPI_FAILURE(status)) {
- ACPI_EXCEPTION((AE_INFO, status,
- "During Debugger initialization"));
- return_ACPI_STATUS(status);
- }
-#endif
-
return_ACPI_STATUS(AE_OK);
}
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index f2e2327..d3d7ea0 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -917,6 +917,9 @@ ACPI_DBG_DEPENDENT_RETURN_VOID(void
ACPI_APP_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(1)
void ACPI_INTERNAL_VAR_XFACE
acpi_log_error(const char *format, ...))
+ acpi_status acpi_initialize_debugger(void);
+
+void acpi_terminate_debugger(void);
/*
* Divergences
--
1.7.10
--
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 15/20] ACPICA: Header support to improve compatibility with MSVC.
From: Bob Moore ACPICA commit 5b4087fba991d8383046b550bbe22f3d8d9b9c8f Needed to improve MSVC editor support for symbols. For Linux kernel, this change is a no-op. Link: https://github.com/acpica/acpica/commit/5b4087fb Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/platform/acenv.h |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h index 1332537..ec00e2b 100644 --- a/include/acpi/platform/acenv.h +++ b/include/acpi/platform/acenv.h @@ -70,13 +70,14 @@ #ifdef ACPI_ASL_COMPILER #define ACPI_APPLICATION -#define ACPI_DISASSEMBLER #define ACPI_DEBUG_OUTPUT #define ACPI_CONSTANT_EVAL_ONLY #define ACPI_LARGE_NAMESPACE_NODE #define ACPI_DATA_TABLE_DISASSEMBLY #define ACPI_SINGLE_THREADED #define ACPI_32BIT_PHYSICAL_ADDRESS + +#define ACPI_DISASSEMBLER 1 #endif /* acpi_exec configuration. Multithreaded with full AML debugger */ @@ -151,12 +152,12 @@ #define ACPI_USE_LOCAL_CACHE #endif -/* Common debug support */ +/* Common debug/disassembler support */ #ifdef ACPI_FULL_DEBUG -#define ACPI_DEBUGGER #define ACPI_DEBUG_OUTPUT -#define ACPI_DISASSEMBLER +#define ACPI_DEBUGGER 1 +#define ACPI_DISASSEMBLER 1 #endif -- 1.7.10 -- 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 20/20] ACPICA: Update version to 20150818.
From: Bob Moore ACPICA commit d93470de8febeecdc20633fde11cb0b200fa773b Version 20150818. Link: https://github.com/acpica/acpica/commit/d93470de Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index d3d7ea0..c33eeab 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150717 +#define ACPI_CA_VERSION 0x20150818 #include #include -- 1.7.10 -- 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 17/20] ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm.
ACPICA commit 969989cf7f85e2a2a0cd048cd25fc706246a48a2 This patch cleans up the following global variable - acpi_gbl_db_opt_disasm: The setting is used to control the full disassembly feature for iasl. ACPI debugger (acpiexec) shall have nothing to do with it. Actually, acpiexec never links to ad_aml_disassemble(). This patch thus renames this global option to acpi_gbl_dm_opt_disasm and removes all acpiexec and debugger references on it. Lv Zheng. This patch doesn't affect Linux kernel. Link: https://github.com/acpica/acpica/commit/969989cf Signed-off-by: Lv Zheng Signed-off-by: Bob Moore --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 03c443b..0007eb7 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -313,7 +313,7 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_disasm); ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); -- 1.7.10 -- 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 19/20] ACPICA: Debugger: Cleanup debugging outputs to dump name path without trailing underscores.
ACPICA commit 51a49c2fb4a73f302a6df2b8ddc1350dd261684d
It is better to use unified ASL path name to interact with the developers.
There are following acpi_ns_build_normalized_pathname() users invoking it for
debugging purposes (acpiexec test results are attached):
1. acpi_ut_display_init_pathname (acpi_ns_handle_to_pathname):
-
Initializing Region\_SB.H_EC.ECF2
-
2. acpi_ns_print_node_pathname (acpi_ns_handle_to_pathname):
-
- ex \_SB.H_EC._STA
Evaluating \_SB.H_EC._STA
-
3. acpi_ds_print_node_pathname (acpi_ns_handle_to_pathname):
-
- level 211b console
- execute \M1
...
Exception AE_AML_UNINITIALIZED_ARG during execution of method [\M1]
(Node 009CB6B8)
-
4. acpi_ex_dump_reference_obj (acpi_ns_handle_to_pathname):
-
- dump \_TZ.FAN4._PR0
...
[00] 00835E98 [Object Reference] Type [Named Object] 05 00828878 \_TZ.FN04
-
5. acpi_db_bus_walk (acpi_ns_handle_to_pathname):
-
- businfo
\_SB.PCI0Type 6
...
-
6. acpi_db_walk_and_match_name (acpi_ns_handle_to_pathname):
-
- find _PR0
\_TZ.FAN4._PR0 Package 002D8DF8 01 Elements 01
-
7. acpi_db_walk_for_specific_objects (acpi_ns_handle_to_pathname):
-
- methods
...
\_SB.PCI0._PRT Method 0026D918 01 Args 0 Len 0005
Aml 0026B199
...
-
8. acpi_db_decode_and_dispaly_object (acpi_get_name):
-
- gpes
Block 0 - Info 003AC7B0 device_node 003A0E08 [\_GPE] - FADT-defined GPE
block
...
-
9. acpi_db_display_gpes (acpi_get_name):
-
- dump \_GPE
Object (003A0E08) Pathname: \_GPE
-
10.ae_miscellaneous_tests (acpi_get_name):
No output available
This patch cleans up all of the above usages. ACPICA BZ 1178, Lv Zheng.
Linux kernel's ACPICA debugging messages may also be changed.
Link: https://github.com/acpica/acpica/commit/51a49c2f
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dsdebug.c |2 +-
drivers/acpi/acpica/exdump.c |2 +-
drivers/acpi/acpica/nsutils.c |2 +-
drivers/acpi/acpica/utmisc.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/dsdebug.c b/drivers/acpi/acpica/dsdebug.c
index a651d30..309556e 100644
--- a/drivers/acpi/acpica/dsdebug.c
+++ b/drivers/acpi/acpica/dsdebug.c
@@ -89,7 +89,7 @@ acpi_ds_print_node_pathname(struct acpi_namespace_node *node,
buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
- status = acpi_ns_handle_to_pathname(node, , FALSE);
+ status = acpi_ns_handle_to_pathname(node, , TRUE);
if (ACPI_SUCCESS(status)) {
if (message) {
ACPI_DEBUG_PRINT_RAW((ACPI_DB_DISPATCH, "%s ",
diff --git a/drivers/acpi/acpica/exdump.c b/drivers/acpi/acpica/exdump.c
index b6495fb..d836f88 100644
--- a/drivers/acpi/acpica/exdump.c
+++ b/drivers/acpi/acpica/exdump.c
@@ -996,7 +996,7 @@ static void acpi_ex_dump_reference_obj(union
acpi_operand_object *obj_desc)
acpi_os_printf(" %p ", obj_desc->reference.node);
status = acpi_ns_handle_to_pathname(obj_desc->reference.node,
- _buf, FALSE);
+ _buf, TRUE);
if (ACPI_FAILURE(status)) {
acpi_os_printf(" Could not convert name to pathname\n");
} else {
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index d1261fe..de325ae 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -83,7 +83,7 @@ acpi_ns_print_node_pathname(struct acpi_namespace_node *node,
buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
- status = acpi_ns_handle_to_pathname(node, , FALSE);
+ status = acpi_ns_handle_to_pathname(node, , TRUE);
if (ACPI_SUCCESS(status)) {
if (message) {
acpi_os_printf("%s ", message);
diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c
index 517a5ec..bd4443b 100644
---
[PATCH 18/20] ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_verbose acpiexec usage.
ACPICA commit 42d7ad7bfb1cfb95183c1386c77509f2036f521d
When acpi_gbl_db_opt_verbose is used in acpi_dm_descending_op() (invoked by
acpi_dm_disassemble()), it is actually exported by the disassembler but used
by the debugger to distinguish the output of the disassembler for different
debugger commands. It is by default TRUE but is set to FALSE for control
method disassembly command - "disassemble". So it's initialization should
be a part of the ACPI_DISASSEMBLER conditioned code. This patch uses
ACPI_INIT_GLOBAL to achieve a clean manner so that when ACPI_DISASSEMBLER
is not defined, ACPI_DEBUGGER conditioned code needn't link to this option.
Since it is a disassembler exported variable, it is renamed to
acpi_gbl_dm_opt_Verbose in this patch.
As VERBOSE_PRINT() macro has only one user, this patch also removes the
definition of this macro. Lv Zheng.
This patch doesn't affect Linux kernel.
Link: https://github.com/acpica/acpica/commit/42d7ad7b
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acdebug.h |3 ---
drivers/acpi/acpica/acglobal.h |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index 447f6d3..eb2e926 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -67,9 +67,6 @@ struct acpi_db_execute_walk {
};
#define PARAM_LIST(pl) pl
-#define DBTEST_OUTPUT_LEVEL(lvl)if (acpi_gbl_db_opt_verbose)
-#define VERBOSE_PRINT(fp) DBTEST_OUTPUT_LEVEL(lvl) {\
- acpi_os_printf PARAM_LIST(fp);}
#define EX_NO_SINGLE_STEP 1
#define EX_SINGLE_STEP 2
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 0007eb7..09f37b5 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -312,10 +312,10 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly,
FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_dm_opt_verbose, TRUE);
ACPI_GLOBAL(u8, acpi_gbl_dm_opt_disasm);
ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing);
-ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose);
ACPI_GLOBAL(u8, acpi_gbl_num_external_methods);
ACPI_GLOBAL(u32, acpi_gbl_resolved_external_methods);
ACPI_GLOBAL(struct acpi_external_list *, acpi_gbl_external_list);
--
1.7.10
--
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 09/20] ACPICA: acpinames: Add new options and wildcard support.
From: Bob Moore ACPICA commit 0ecf5b5a41c3d2e09af48f0fdbc9ae784f631788 - Add wilcard support for input filenames. - Add -l option to load tables and exit, no display. This is useful for validation of the namespace during BIOS generation. - Add -x option for specifying debug level. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/0ecf5b5a Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/utmisc.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h index 566ff4df..fb2aa50 100644 --- a/drivers/acpi/acpica/acutils.h +++ b/drivers/acpi/acpica/acutils.h @@ -517,7 +517,7 @@ const struct acpi_exception_info *acpi_ut_validate_exception(acpi_status u8 acpi_ut_is_pci_root_bridge(char *id); -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) u8 acpi_ut_is_aml_table(struct acpi_table_header *table); #endif diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c index 98087ea..517a5ec 100644 --- a/drivers/acpi/acpica/utmisc.c +++ b/drivers/acpi/acpica/utmisc.c @@ -75,7 +75,7 @@ u8 acpi_ut_is_pci_root_bridge(char *id) return (FALSE); } -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) /*** * * FUNCTION:acpi_ut_is_aml_table -- 1.7.10 -- 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 14/20] ACPICA: Make the max-number-of-loops runtime configurable.
From: Bob Moore
ACPICA commit a9d9c2d0c2d077bb3175ec9c252cf0e5da3efd45
Was previously compile-time only.
Add support option for acpiexec.
Link: https://github.com/acpica/acpica/commit/a9d9c2d0
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |4
drivers/acpi/acpica/dscontrol.c |2 +-
drivers/acpi/acpica/utinit.c|1 +
include/acpi/acconfig.h |4
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index c597192..03c443b 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -236,6 +236,10 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_nesting_level, 0);
ACPI_GLOBAL(struct acpi_thread_state *, acpi_gbl_current_walk_list);
+/* Maximum number of While() loop iterations before forced abort */
+
+ACPI_GLOBAL(u16, acpi_gbl_max_loop_iterations);
+
/* Control method single step flag */
ACPI_GLOBAL(u8, acpi_gbl_cm_single_step);
diff --git a/drivers/acpi/acpica/dscontrol.c b/drivers/acpi/acpica/dscontrol.c
index 39da9da..435fc16 100644
--- a/drivers/acpi/acpica/dscontrol.c
+++ b/drivers/acpi/acpica/dscontrol.c
@@ -212,7 +212,7 @@ acpi_ds_exec_end_control_op(struct acpi_walk_state *
walk_state,
*/
control_state->control.loop_count++;
if (control_state->control.loop_count >
- ACPI_MAX_LOOP_ITERATIONS) {
+ acpi_gbl_max_loop_iterations) {
status = AE_AML_INFINITE_LOOP;
break;
}
diff --git a/drivers/acpi/acpica/utinit.c b/drivers/acpi/acpica/utinit.c
index 7f897c6..28ab3a1 100644
--- a/drivers/acpi/acpica/utinit.c
+++ b/drivers/acpi/acpica/utinit.c
@@ -207,6 +207,7 @@ acpi_status acpi_ut_init_globals(void)
acpi_gbl_debugger_configuration = DEBUGGER_THREADING;
acpi_gbl_osi_mutex = NULL;
acpi_gbl_reg_methods_executed = FALSE;
+ acpi_gbl_max_loop_iterations = 0x;
/* Hardware oriented */
diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index 03aacfb..e11611c 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -136,10 +136,6 @@
#define ACPI_ROOT_TABLE_SIZE_INCREMENT 4
-/* Maximum number of While() loop iterations before forced abort */
-
-#define ACPI_MAX_LOOP_ITERATIONS0x
-
/* Maximum sleep allowed via Sleep() operator */
#define ACPI_MAX_SLEEP 2000 /* 2000 millisec == two seconds
*/
--
1.7.10
--
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 11/20] ACPICA: Table handling: Cleanup and update debug output for tools.
From: Bob Moore
ACPICA commit 93862bd7a227543bc617d822ef5c4f8a5d68b519
Add output of table OEM ID along with signature to support lots
of SSDTs.
Cleanup use of table pointers.
Link: https://github.com/acpica/acpica/commit/93862bd7
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dsinit.c | 11 +
drivers/acpi/acpica/tbxfload.c | 53 ++--
2 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index bbf52f0..920f1b1 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -247,11 +247,12 @@ acpi_ds_initialize_objects(u32 table_index,
/* Summary of objects initialized */
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
- "Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices, "
- "%3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
- table->signature, owner_id, info.object_count,
- info.device_count, info.op_region_count,
- info.method_count, info.serial_method_count,
+ "Table [%4.4s:%8.8s] (id %.2X) - %4u Objects with
%3u Devices, "
+ "%3u Regions, %4u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
+ table->signature, table->oem_table_id, owner_id,
+ info.object_count, info.device_count,
+ info.op_region_count, info.method_count,
+ info.serial_method_count,
info.non_serial_method_count,
info.serialized_method_count));
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 96b82a8..55ee14c 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -105,6 +105,7 @@ acpi_status acpi_tb_load_namespace(void)
acpi_status status;
u32 i;
struct acpi_table_header *new_dsdt;
+ struct acpi_table_desc *table;
u32 tables_loaded = 0;
u32 tables_failed = 0;
@@ -116,15 +117,11 @@ acpi_status acpi_tb_load_namespace(void)
* Load the namespace. The DSDT is required, but any SSDT and
* PSDT tables are optional. Verify the DSDT.
*/
+ table = _gbl_root_table_list.tables[acpi_gbl_dsdt_index];
+
if (!acpi_gbl_root_table_list.current_table_count ||
- !ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index].signature),
- ACPI_SIG_DSDT)
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index]))) {
+ !ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_DSDT) ||
+ ACPI_FAILURE(acpi_tb_validate_table(table))) {
status = AE_NO_ACPI_TABLES;
goto unlock_and_exit;
}
@@ -135,8 +132,7 @@ acpi_status acpi_tb_load_namespace(void)
* array can change dynamically as tables are loaded at run-time. Note:
* .Pointer field is not validated until after call to
acpi_tb_validate_table.
*/
- acpi_gbl_DSDT =
- acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index].pointer;
+ acpi_gbl_DSDT = table->pointer;
/*
* Optionally copy the entire DSDT to local memory (instead of simply
@@ -174,21 +170,15 @@ acpi_status acpi_tb_load_namespace(void)
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
+ table = _gbl_root_table_list.tables[i];
+
if (!acpi_gbl_root_table_list.tables[i].address ||
- (!ACPI_COMPARE_NAME
-(&(acpi_gbl_root_table_list.tables[i].signature),
- ACPI_SIG_SSDT)
-&&
-!ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_PSDT)
-&&
-!ACPI_COMPARE_NAME(&
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_OSDT))
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(_gbl_root_table_list.tables[i]))) {
+ (!ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_SSDT)
+&& !ACPI_COMPARE_NAME(table->signature.ascii,
+ ACPI_SIG_PSDT)
+&& !ACPI_COMPARE_NAME(table->signature.ascii,
+ ACPI_SIG_OSDT))
+
[PATCH 12/20] ACPICA: Add additional debug info/statements.
From: Bob Moore
ACPICA commit 74094ca9f51e2652a9b5f01722d8640a653cc75a
For _REG methods and module-level code blocks.
For acpiexec, add deletion of module-level blocks in case
of an early abort.
Link: https://github.com/acpica/acpica/commit/74094ca9
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |7 +++
drivers/acpi/acpica/evregion.c | 22 ++
drivers/acpi/acpica/nseval.c |3 ++-
drivers/acpi/acpica/nsutils.c | 17 +
drivers/acpi/acpica/psloop.c | 14 +-
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 92cbaee..acbf68b 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -406,6 +406,13 @@ struct acpi_simple_repair_info {
#define ACPI_NUM_RTYPES 5 /* Number of actual object
types */
+/* Info for running the _REG methods */
+
+struct acpi_reg_walk_info {
+ acpi_adr_space_type space_id;
+ u32 reg_run_count;
+};
+
/*
*
* Event typedefs and structs
diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index 2ba28a6..5ee79a1 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -626,9 +626,17 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_adr_space_type space_id)
{
acpi_status status;
+ struct acpi_reg_walk_info info;
ACPI_FUNCTION_TRACE(ev_execute_reg_methods);
+ info.space_id = space_id;
+ info.reg_run_count = 0;
+
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ "Running _REG methods for SpaceId %s\n",
+ acpi_ut_get_region_name(info.space_id)));
+
/*
* Run all _REG methods for all Operation Regions for this space ID.
This
* is a separate walk in order to handle any interdependencies between
@@ -637,7 +645,7 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
*/
status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, node, ACPI_UINT32_MAX,
ACPI_NS_WALK_UNLOCK, acpi_ev_reg_run,
- NULL, _id, NULL);
+ NULL, , NULL);
/* Special case for EC: handle "orphan" _REG methods with no region */
@@ -645,6 +653,11 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_ev_orphan_ec_reg_method(node);
}
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ "Executed %u _REG methods for SpaceId %s\n",
+ info.reg_run_count,
+ acpi_ut_get_region_name(info.space_id)));
+
return_ACPI_STATUS(status);
}
@@ -664,10 +677,10 @@ acpi_ev_reg_run(acpi_handle obj_handle,
{
union acpi_operand_object *obj_desc;
struct acpi_namespace_node *node;
- acpi_adr_space_type space_id;
acpi_status status;
+ struct acpi_reg_walk_info *info;
- space_id = *ACPI_CAST_PTR(acpi_adr_space_type, context);
+ info = ACPI_CAST_PTR(struct acpi_reg_walk_info, context);
/* Convert and validate the device handle */
@@ -696,13 +709,14 @@ acpi_ev_reg_run(acpi_handle obj_handle,
/* Object is a Region */
- if (obj_desc->region.space_id != space_id) {
+ if (obj_desc->region.space_id != info->space_id) {
/* This region is for a different address space, just ignore it
*/
return (AE_OK);
}
+ info->reg_run_count++;
status = acpi_ev_execute_reg_method(obj_desc, ACPI_REG_CONNECT);
return (status);
}
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 88822b7a..7eba578 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -465,7 +465,8 @@ acpi_ns_exec_module_code(union acpi_operand_object
*method_obj,
status = acpi_ns_evaluate(info);
- ACPI_DEBUG_PRINT((ACPI_DB_INIT, "Executed module-level code at %p\n",
+ ACPI_DEBUG_PRINT((ACPI_DB_INIT_NAMES,
+ "Executed module-level code at %p\n",
method_obj->method.aml_start));
/* Delete a possible implicit return value (in slack mode) */
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 9a34c5f..d1261fe 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -596,6 +596,23 @@ void acpi_ns_terminate(void)
ACPI_FUNCTION_TRACE(ns_terminate);
+#ifdef ACPI_EXEC_APP
+ {
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
+
+ /* Delete any module-level code blocks */
+
+
[PATCH 10/20] ACPICA: acpiexec/acpinames: Support very large number of ACPI tables.
From: Bob Moore
ACPICA commit ca3bd4c5cdc39a9009280032adbbc20f34e94c47
Fix a couple of issues with >40 ACPI tables.
Return exit error for acpinames to enable use with BIOS builds.
The new exported function is used by acpinames. For Linux kernel, this
change is a no-op.
Link: https://github.com/acpica/acpica/commit/ca3bd4c5
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/actables.h |5 +
drivers/acpi/acpica/tbxfload.c | 17 -
drivers/acpi/acpica/utfileio.c |2 +-
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index ab7f3a0..f7731f2 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -165,4 +165,9 @@ acpi_status acpi_tb_parse_root_table(acpi_physical_address
rsdp_address);
u8 acpi_is_valid_signature(char *signature);
+/*
+ * tbxfload
+ */
+acpi_status acpi_tb_load_namespace(void);
+
#endif /* __ACTABLES_H__ */
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index fb4d4e6..96b82a8 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -51,9 +51,6 @@
#define _COMPONENT ACPI_TABLES
ACPI_MODULE_NAME("tbxfload")
-/* Local prototypes */
-static acpi_status acpi_tb_load_namespace(void);
-
/***
*
* FUNCTION:acpi_load_tables
@@ -65,7 +62,6 @@ static acpi_status acpi_tb_load_namespace(void);
* DESCRIPTION: Load the ACPI tables from the RSDT/XSDT
*
**/
-
acpi_status __init acpi_load_tables(void)
{
acpi_status status;
@@ -75,6 +71,13 @@ acpi_status __init acpi_load_tables(void)
/* Load the namespace from the tables */
status = acpi_tb_load_namespace();
+
+ /* Don't let single failures abort the load */
+
+ if (status == AE_CTRL_TERMINATE) {
+ status = AE_OK;
+ }
+
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"While loading namespace from ACPI tables"));
@@ -97,7 +100,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_load_tables)
* the RSDT/XSDT.
*
**/
-static acpi_status acpi_tb_load_namespace(void)
+acpi_status acpi_tb_load_namespace(void)
{
acpi_status status;
u32 i;
@@ -214,6 +217,10 @@ static acpi_status acpi_tb_load_namespace(void)
ACPI_ERROR((AE_INFO,
"%u ACPI AML tables successfully acquired and
loaded, %u failed",
tables_loaded, tables_failed));
+
+ /* Indicate at least one failure */
+
+ status = AE_CTRL_TERMINATE;
}
unlock_and_exit:
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index 857af82..75a94f5 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -312,7 +312,7 @@ acpi_ut_read_table_from_file(char *filename, struct
acpi_table_header ** table)
/* Get the entire file */
fprintf(stderr,
- "Reading ACPI table from file %10s - Length %.8u (0x%06X)\n",
+ "Reading ACPI table from file %12s - Length %.8u (0x%06X)\n",
filename, file_size, file_size);
status = acpi_ut_read_table(file, table, _length);
--
1.7.10
--
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 13/20] ACPICA: Debugger: Add option to display namespace summary/counts.
From: Bob Moore
ACPICA commit bba222c15c2ce79076eb3a5e9d4d5f7120db8a00
If "Objects" command is invoked with no arguments, the counts
for each object type are displayed.
Linux kernel is not affected by this commit as currently debugger is
not enabled in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/bba222c1
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |4 ++--
drivers/acpi/acpica/aclocal.h |4
include/acpi/actypes.h |2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 95ed861..c597192 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -346,8 +346,8 @@ ACPI_GLOBAL(char,
acpi_gbl_db_debug_filename[ACPI_DB_LINE_BUFFER_SIZE]);
/*
* Statistic globals
*/
-ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
-ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
+ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TOTAL_TYPES]);
+ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TOTAL_TYPES]);
ACPI_GLOBAL(u16, acpi_gbl_obj_type_count_misc);
ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc);
ACPI_GLOBAL(u32, acpi_gbl_num_nodes);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index acbf68b..6f70826 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -1131,6 +1131,10 @@ struct acpi_integrity_info {
#define ACPI_DB_CONSOLE_OUTPUT 0x02
#define ACPI_DB_DUPLICATE_OUTPUT0x03
+struct acpi_object_info {
+ u32 types[ACPI_TOTAL_TYPES];
+};
+
/*
*
* Debug
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 531eca4..f914958 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -662,6 +662,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_DEBUG_OBJECT 0x10
#define ACPI_TYPE_EXTERNAL_MAX 0x10
+#define ACPI_NUM_TYPES (ACPI_TYPE_EXTERNAL_MAX + 1)
/*
* These are object types that do not map directly to the ACPI
@@ -683,6 +684,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_LOCAL_SCOPE 0x1B /* 1 Name, multiple object_list
Nodes */
#define ACPI_TYPE_NS_NODE_MAX 0x1B /* Last typecode used within a
NS Node */
+#define ACPI_TOTAL_TYPES(ACPI_TYPE_NS_NODE_MAX + 1)
/*
* These are special object types that never appear in
--
1.7.10
--
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 08/20] ACPICA: Headers: Fix some comments, no functional change.
From: Bob Moore ACPICA commit 539f8c03fe64305725bd85343e42f3b6c42aad14 A couple typos and long lines. Link: https://github.com/acpica/acpica/commit/539f8c03 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/platform/acenv.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h index 3cedd43..1332537 100644 --- a/include/acpi/platform/acenv.h +++ b/include/acpi/platform/acenv.h @@ -89,8 +89,8 @@ #endif /* - * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example configuration. - * All single threaded. + * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example + * configuration. All single threaded. */ #if (defined ACPI_BIN_APP) || \ (defined ACPI_DUMP_APP) || \ @@ -123,7 +123,7 @@ #define ACPI_USE_NATIVE_RSDP_POINTER #endif -/* acpi_dump configuration. Native mapping used if provied by OSPMs */ +/* acpi_dump configuration. Native mapping used if provided by the host */ #ifdef ACPI_DUMP_APP #define ACPI_USE_NATIVE_MEMORY_MAPPING @@ -323,8 +323,8 @@ * ACPI_USE_STANDARD_HEADERS - Define this if linking to a C library and * the standard header files may be used. * - * The ACPICA subsystem only uses low level C library functions that do not call - * operating system services and may therefore be inlined in the code. + * The ACPICA subsystem only uses low level C library functions that do not + * call operating system services and may therefore be inlined in the code. * * It may be necessary to tailor these include files to the target * generation environment. -- 1.7.10 -- 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 07/20] ACPICA: Tables: Cleanup to reduce FACS globals.
ACPICA commit 3f42ba76e2a0453976d3108296d5f656fdf2bd6e
In this patch, FACS table mapping is also tuned a bit so that only the
selected FACS table will be mapped by the OSPM (mapped on demand) and the
FACS related global variables can be reduced. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3f42ba76
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |2 --
drivers/acpi/acpica/hwxfsleep.c | 15 ++-
drivers/acpi/acpica/tbutils.c |9 +
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index e78667e..95ed861 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -64,8 +64,6 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index,
ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs32);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs64);
#endif /* !ACPI_REDUCED_HARDWARE */
diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
index 52dfd0d..d62a616 100644
--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -160,19 +160,8 @@ acpi_set_firmware_waking_vectors(acpi_physical_address
physical_address,
ACPI_FUNCTION_TRACE(acpi_set_firmware_waking_vectors);
- /* If Hardware Reduced flag is set, there is no FACS */
-
- if (acpi_gbl_reduced_hardware) {
- return_ACPI_STATUS (AE_OK);
- }
-
- if (acpi_gbl_facs32) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs32,
- physical_address,
- physical_address64);
- }
- if (acpi_gbl_facs64) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs64,
+ if (acpi_gbl_FACS) {
+ (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_FACS,
physical_address,
physical_address64);
}
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index b1d500e..4337990 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -68,6 +68,7 @@ acpi_tb_get_root_table_entry(u8 *table_entry, u32
table_entry_size);
acpi_status acpi_tb_initialize_facs(void)
{
+ struct acpi_table_facs *facs;
/* If Hardware Reduced flag is set, there is no FACS */
@@ -80,14 +81,14 @@ acpi_status acpi_tb_initialize_facs(void)
(void)acpi_get_table_by_index(acpi_gbl_xfacs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
_gbl_facs32));
- acpi_gbl_FACS = acpi_gbl_facs32;
+));
+ acpi_gbl_FACS = facs;
} else if (acpi_gbl_FADT.facs) {
(void)acpi_get_table_by_index(acpi_gbl_facs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
_gbl_facs64));
- acpi_gbl_FACS = acpi_gbl_facs64;
+));
+ acpi_gbl_FACS = facs;
}
/* If there is no FACS, just continue. There was already an error msg */
--
1.7.10
--
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 04/20] ACPICA: Disassembler: Update for new listing mode.
From: Bob Moore ACPICA commit 2ed09bb7619d25f5a5c065c33a8a775a6db3a856 ACPICA commit 2fefacf73825b0ec96bbfc4f70a256735b715d6c This mode emits AML code along with the ASL code. A new global was needed to ensure the listing mode is completely separate from the debugger verbose mode. Emits the correct AML offset for the AML code. The -l option now works for both the compiler and disassembler. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/2fefacf7 Link: https://github.com/acpica/acpica/commit/2ed09bb7 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 79eb35d..1283b19 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -307,9 +307,9 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_INIT_GLOBAL(union acpi_parse_object *, acpi_gbl_previous_op, NULL); ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); ACPI_GLOBAL(u32, acpi_gbl_resolved_external_methods); -- 1.7.10 -- 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 06/20] ACPICA: Tables: Fix global table list issues by removing fixed table indexes.
ACPICA commit c0b38b4c3982c2336ee92a2a14716107248bd941
The fixed table indexes leave holes in the global table list:
1. One hole can be seen when there is only 1 FACS provided by the BIOS.
2. Tow holes can be seen when it is a reduced hardware platform.
The holes do not break OSPMs but have broken ACPI debugger "tables"
command.
Also the "fixed table indexes" mechanism may make the descriptors of the
standard tables installed earlier than DSDT to be overwritten by the
descriptors of the fixed tables. For example, FACP disappears from the
global table list after DSDT is installed.
This patch fixes all above issues by removing the "fixed table indexes"
mechanism which is too complicated to be maintained in a regression safe
manner. After removal, the table loader will determine the indexes of the
fixed tables. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c0b38b4c
Cc:
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |3 +++
drivers/acpi/acpica/aclocal.h |6 ++
drivers/acpi/acpica/actables.h |7 +++
drivers/acpi/acpica/tbfadt.c |6 +++---
drivers/acpi/acpica/tbinstal.c | 40 +---
drivers/acpi/acpica/tbutils.c | 37 ++---
drivers/acpi/acpica/tbxfload.c | 10 +-
7 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 1283b19..e78667e 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -58,6 +58,9 @@ ACPI_GLOBAL(struct acpi_table_list, acpi_gbl_root_table_list);
ACPI_GLOBAL(struct acpi_table_header *, acpi_gbl_DSDT);
ACPI_GLOBAL(struct acpi_table_header, acpi_gbl_original_dsdt_header);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_dsdt_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_facs_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index, ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index a6b6887..92cbaee 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -213,11 +213,9 @@ struct acpi_table_list {
#define ACPI_ROOT_ORIGIN_ALLOCATED (1)
#define ACPI_ROOT_ALLOW_RESIZE (2)
-/* Predefined (fixed) table indexes */
+/* Predefined table indexes */
-#define ACPI_TABLE_INDEX_DSDT (0)
-#define ACPI_TABLE_INDEX_FACS (1)
-#define ACPI_TABLE_INDEX_X_FACS (2)
+#define ACPI_INVALID_TABLE_INDEX(0x)
struct acpi_find_context {
char *search_for;
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 58497b7..ab7f3a0 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -154,13 +154,12 @@ void acpi_tb_check_dsdt_header(void);
struct acpi_table_header *acpi_tb_copy_dsdt(u32 table_index);
void
-acpi_tb_install_table_with_override(u32 table_index,
- struct acpi_table_desc *new_table_desc,
- u8 override);
+acpi_tb_install_table_with_override(struct acpi_table_desc *new_table_desc,
+ u8 override, u32 *table_index);
acpi_status
acpi_tb_install_fixed_table(acpi_physical_address address,
- char *signature, u32 table_index);
+ char *signature, u32 *table_index);
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 6253001..455a070 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -345,7 +345,7 @@ void acpi_tb_parse_fadt(u32 table_index)
/* Obtain the DSDT and FACS tables via their addresses within the FADT
*/
acpi_tb_install_fixed_table((acpi_physical_address) acpi_gbl_FADT.Xdsdt,
- ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);
+ ACPI_SIG_DSDT, _gbl_dsdt_index);
/* If Hardware Reduced flag is set, there is no FACS */
@@ -354,13 +354,13 @@ void acpi_tb_parse_fadt(u32 table_index)
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.facs,
ACPI_SIG_FACS,
- ACPI_TABLE_INDEX_FACS);
+ _gbl_facs_index);
}
if (acpi_gbl_FADT.Xfacs) {
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.Xfacs,
ACPI_SIG_FACS,
-
[PATCH 05/20] ACPICA: Update info messages during ACPICA init.
From: Bob Moore
ACPICA commit 4ccf8a1cc499ec8f00345f662a5887483980e1dd
Small cleanup of messages.
Link: https://github.com/acpica/acpica/commit/4ccf8a1c
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dsinit.c |9 +
drivers/acpi/acpica/tbxfload.c |4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 95779e8..bbf52f0 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -237,6 +237,15 @@ acpi_ds_initialize_objects(u32 table_index,
return_ACPI_STATUS(status);
}
+ /* DSDT is always the first AML table */
+
+ if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT)) {
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
+ "\nInitializing Namespace objects:\n"));
+ }
+
+ /* Summary of objects initialized */
+
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
"Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices, "
"%3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n",
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 7862cf0..6cbb2f7 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -208,11 +208,11 @@ static acpi_status acpi_tb_load_namespace(void)
if (!tables_failed) {
ACPI_INFO((AE_INFO,
- "All (%u) ACPI AML tables successfully loaded",
+ "%u ACPI AML tables successfully acquired and
loaded",
tables_loaded));
} else {
ACPI_ERROR((AE_INFO,
- "%u ACPI AML tables loaded, %u failed",
+ "%u ACPI AML tables successfully acquired and
loaded, %u failed",
tables_loaded, tables_failed));
}
--
1.7.10
--
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 02/20] ACPICA: Disassembler: Remove duplicate code in _PLD processing.
From: Bob Moore
ACPICA commit 6d9c827b540837b6e54059e17756a06985e4a196
ACPICA BZ 1176.
Link: https://bugs.acpica.org/show_bug.cgi?id=1176
Link: https://github.com/acpica/acpica/commit/6d9c827b
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/utxface.c |5 +++--
include/acpi/acbuffer.h |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index 51cf52d..c2bd5e2 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -517,7 +517,8 @@ acpi_decode_pld_buffer(u8 *in_buffer,
/* Parameter validation */
- if (!in_buffer || !return_buffer || (length < 16)) {
+ if (!in_buffer || !return_buffer
+ || (length < ACPI_PLD_REV1_BUFFER_SIZE)) {
return (AE_BAD_PARAMETER);
}
@@ -567,7 +568,7 @@ acpi_decode_pld_buffer(u8 *in_buffer,
pld_info->rotation = ACPI_PLD_GET_ROTATION();
pld_info->order = ACPI_PLD_GET_ORDER();
- if (length >= ACPI_PLD_BUFFER_SIZE) {
+ if (length >= ACPI_PLD_REV2_BUFFER_SIZE) {
/* Fifth 32-bit DWord (Revision 2 of _PLD) */
diff --git a/include/acpi/acbuffer.h b/include/acpi/acbuffer.h
index 6b040f4..fcf9080 100644
--- a/include/acpi/acbuffer.h
+++ b/include/acpi/acbuffer.h
@@ -147,6 +147,7 @@ struct acpi_pld_info {
*(Intended for BIOS use only)
*/
#define ACPI_PLD_REV1_BUFFER_SIZE 16 /* For Revision 1 of
the buffer (From ACPI spec) */
+#define ACPI_PLD_REV2_BUFFER_SIZE 20 /* For Revision 2 of
the buffer (From ACPI spec) */
#define ACPI_PLD_BUFFER_SIZE20 /* For Revision 2 of
the buffer (From ACPI spec) */
/* First 32-bit dword, bits 0:32 */
--
1.7.10
--
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 00/20] ACPICA: 20150818 Release
The 20150818 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. i386 + allyes + CONFIG_ACPI=y 3. i386 + default + COFNIG_ACPI=n 4. i386 + allyes + CONFIG_ACPI=n 5. x86_64 + default + COFNIG_ACPI=y 6. x86_64 + allyes + CONFIG_ACPI=y 7. x86_64 + default + COFNIG_ACPI=n 8. x86_64 + allyes + CONFIG_ACPI=n Boot tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. x86_64 + default + COFNIG_ACPI=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150717 Release): 518 lines After applying (20150818 Release): 517 lines Bob Moore (14): ACPICA: Correctly cleanup after a ACPI table load failure. ACPICA: Disassembler: Remove duplicate code in _PLD processing. ACPICA: Update parameter validation for data_table_region and load_table. ACPICA: Disassembler: Update for new listing mode. ACPICA: Update info messages during ACPICA init. ACPICA: Headers: Fix some comments, no functional change. ACPICA: acpinames: Add new options and wildcard support. ACPICA: acpiexec/acpinames: Support very large number of ACPI tables. ACPICA: Table handling: Cleanup and update debug output for tools. ACPICA: Add additional debug info/statements. ACPICA: Debugger: Add option to display namespace summary/counts. ACPICA: Make the max-number-of-loops runtime configurable. ACPICA: Header support to improve compatibility with MSVC. ACPICA: Update version to 20150818. Lv Zheng (6): ACPICA: Tables: Fix global table list issues by removing fixed table indexes. ACPICA: Tables: Cleanup to reduce FACS globals. ACPICA: Debugger: Split debugger initialization/termination APIs. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_verbose acpiexec usage. ACPICA: Debugger: Cleanup debugging outputs to dump name path without trailing underscores. drivers/acpi/acpica/acdebug.h |7 --- drivers/acpi/acpica/acglobal.h | 19 +--- drivers/acpi/acpica/aclocal.h | 17 +-- drivers/acpi/acpica/actables.h | 14 -- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/dscontrol.c |2 +- drivers/acpi/acpica/dsdebug.c |2 +- drivers/acpi/acpica/dsinit.c| 20 ++--- drivers/acpi/acpica/dsopcode.c | 31 - drivers/acpi/acpica/evregion.c | 22 +++-- drivers/acpi/acpica/exconfig.c |8 drivers/acpi/acpica/exdump.c|2 +- drivers/acpi/acpica/exresnte.c |2 +- drivers/acpi/acpica/exresolv.c | 16 --- drivers/acpi/acpica/hwxfsleep.c | 15 +-- drivers/acpi/acpica/nseval.c|4 +- drivers/acpi/acpica/nsload.c| 16 ++- drivers/acpi/acpica/nsutils.c | 19 +++- drivers/acpi/acpica/psloop.c| 14 +- drivers/acpi/acpica/tbfadt.c|6 +-- drivers/acpi/acpica/tbfind.c| 15 ++- drivers/acpi/acpica/tbinstal.c | 40 + drivers/acpi/acpica/tbutils.c | 73 -- drivers/acpi/acpica/tbxfload.c | 93 +-- drivers/acpi/acpica/utfileio.c |2 +- drivers/acpi/acpica/utinit.c|1 + drivers/acpi/acpica/utmisc.c|4 +- drivers/acpi/acpica/utxface.c | 12 ++--- drivers/acpi/acpica/utxfinit.c | 11 - include/acpi/acbuffer.h |1 + include/acpi/acconfig.h |4 -- include/acpi/acexcep.h |7 ++- include/acpi/acpixf.h |5 ++- include/acpi/actypes.h |2 + include/acpi/platform/acenv.h | 19 35 files changed, 330 insertions(+), 197 deletions(-) -- 1.7.10 -- 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 01/20] ACPICA: Correctly cleanup after a ACPI table load failure.
From: Bob Moore
ACPICA commit ed7769e832de6c7ba90615480d916c85fd100422
If a table load fails, delete all namespace objects created by the
table, otherwise these objects will be uninitialized, causing
problems later. This appears to be a very rare problem.
Also handle the unitialized node problem to prevent possible
faults. ACPICA BZ 1185.
Link: https://github.com/acpica/acpica/commit/ed7769e8
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/exresnte.c |2 +-
drivers/acpi/acpica/exresolv.c | 16 +++-
drivers/acpi/acpica/nseval.c |1 +
drivers/acpi/acpica/nsload.c | 16 +++-
drivers/acpi/acpica/tbxfload.c | 29 ++---
include/acpi/acexcep.h |7 +--
6 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/acpica/exresnte.c b/drivers/acpi/acpica/exresnte.c
index c7e3b92..1b372ef 100644
--- a/drivers/acpi/acpica/exresnte.c
+++ b/drivers/acpi/acpica/exresnte.c
@@ -126,7 +126,7 @@ acpi_ex_resolve_node_to_value(struct acpi_namespace_node
**object_ptr,
if (!source_desc) {
ACPI_ERROR((AE_INFO, "No object attached to node [%4.4s] %p",
node->name.ascii, node));
- return_ACPI_STATUS(AE_AML_NO_OPERAND);
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
}
/*
diff --git a/drivers/acpi/acpica/exresolv.c b/drivers/acpi/acpica/exresolv.c
index b6b7f3a..7b10912 100644
--- a/drivers/acpi/acpica/exresolv.c
+++ b/drivers/acpi/acpica/exresolv.c
@@ -337,8 +337,9 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
acpi_object_type * return_type,
union acpi_operand_object **return_desc)
{
- union acpi_operand_object *obj_desc = (void *)operand;
- struct acpi_namespace_node *node;
+ union acpi_operand_object *obj_desc = ACPI_CAST_PTR(void, operand);
+ struct acpi_namespace_node *node =
+ ACPI_CAST_PTR(struct acpi_namespace_node, operand);
acpi_object_type type;
acpi_status status;
@@ -355,9 +356,7 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
case ACPI_DESC_TYPE_NAMED:
type = ((struct acpi_namespace_node *)obj_desc)->type;
- obj_desc =
- acpi_ns_get_attached_object((struct acpi_namespace_node *)
- obj_desc);
+ obj_desc = acpi_ns_get_attached_object(node);
/* If we had an Alias node, use the attached object for type
info */
@@ -368,6 +367,13 @@ acpi_ex_resolve_multiple(struct acpi_walk_state
*walk_state,
acpi_namespace_node *)
obj_desc);
}
+
+ if (!obj_desc) {
+ ACPI_ERROR((AE_INFO,
+ "[%4.4s] Node is unresolved or
uninitialized",
+ acpi_ut_get_node_name(node)));
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
+ }
break;
default:
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 80670cb..88822b7a 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -274,6 +274,7 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info
*info)
acpi_ex_exit_interpreter();
if (ACPI_FAILURE(status)) {
+ info->return_object = NULL;
goto cleanup;
}
diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index bd6cd4a..14ab836 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -111,7 +111,21 @@ acpi_ns_load_table(u32 table_index, struct
acpi_namespace_node *node)
if (ACPI_SUCCESS(status)) {
acpi_tb_set_table_loaded_flag(table_index, TRUE);
} else {
- (void)acpi_tb_release_owner_id(table_index);
+ /*
+* On error, delete any namespace objects created by this table.
+* We cannot initialize these objects, so delete them. There are
+* a couple of expecially bad cases:
+* AE_ALREADY_EXISTS - namespace collision.
+* AE_NOT_FOUND - the target of a Scope operator does not
+* exist. This target of Scope must already exist in the
+* namespace, as per the ACPI specification.
+*/
+ (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ acpi_ns_delete_namespace_by_owner(acpi_gbl_root_table_list.
+ tables[table_index].owner_id);
+ acpi_tb_release_owner_id(table_index);
+
+ return_ACPI_STATUS(status);
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On August 24, 2015 6:57:57 PM MDT, Sean Fu wrote: >An application from HuaWei which works fine on 2.6 encounters this >issue on 3.0 or later kernel. My sympathies. Being stuck with a 3rd party application you can barely talk about that has been broken for 5years and no one reported it. Ordinarily we would fix a regression like this. As it has been 5years the challenge now is how do we tell if there are applications that depend on the current behavior. Before we can change the behavior back we need a convincing argument that we won't cause a regression in another application by making the change. I do not see how such an argument can be made. So you have my sympathies but I do not see how we can help you. Eric -- 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 0/7] Add support for Exynos SROM Controller driver
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch set adds support for Exynos SROM controller DT based driver. > Currently SROM register sets are used only during S2R, so driver > basically added for taking care of S2R. It will help us in removing > static mapping from exynos.c and other extra code handline during S2R. > > This patch set also updated exynos4 and exynos5 dtsi files for with device > node for srom, and added binding documentation for the same. > > First two patches are some minor cleanup in mach-exynos. > > Patchset v1 was posted here[1] > [1]: https://lkml.org/lkml/2015/4/29/98 > > Changes since v1: > - Rebased to latest kgene tree. > - Addressed review comments from Krzysztof Kozlowski. > - Add two new patches for minor cleanup in exynos.c and map.h > > Pankaj Dubey (7): > ARM: EXYNOS: remove unused static mapping of CMU for exynos5 > ARM: EXYNOS: code cleanup in map.h > drivers: soc: add support for exynos SROM driver > ARM: EXYNOS: Remove SROM related register settings from mach-exynos > ARM: dts: add SROM device node for exynos4 > ARM: dts: add SROM device node for exynos5 > Documentation: dt-bindings: add exynos-srom binding information One more thing: please update the existing Exynos entry in maintainers so it would cover drivers/soc/samsung. Best regards, Krzysztof > > .../bindings/arm/samsung/exynos-srom.txt | 12 ++ > arch/arm/boot/dts/exynos4.dtsi | 5 + > arch/arm/boot/dts/exynos5.dtsi | 5 + > arch/arm/mach-exynos/Kconfig | 2 + > arch/arm/mach-exynos/common.h | 2 - > arch/arm/mach-exynos/exynos.c | 22 > arch/arm/mach-exynos/include/mach/map.h| 8 -- > arch/arm/mach-exynos/regs-srom.h | 53 > arch/arm/mach-exynos/suspend.c | 20 +-- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > drivers/soc/Kconfig| 1 + > drivers/soc/Makefile | 1 + > drivers/soc/samsung/Kconfig| 13 ++ > drivers/soc/samsung/Makefile | 1 + > drivers/soc/samsung/exynos-srom.c | 143 > + > drivers/soc/samsung/exynos-srom.h | 51 > 16 files changed, 236 insertions(+), 104 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > delete mode 100644 arch/arm/mach-exynos/regs-srom.h > create mode 100644 drivers/soc/samsung/Kconfig > create mode 100644 drivers/soc/samsung/Makefile > create mode 100644 drivers/soc/samsung/exynos-srom.c > create mode 100644 drivers/soc/samsung/exynos-srom.h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/4] zsmalloc: use page->private instead of page->first_page
On (08/17/15 18:09), Kirill A. Shutemov wrote: [..] > @@ -980,7 +979,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) > if (i == 1) > set_page_private(first_page, (unsigned long)page); > if (i >= 1) > - page->first_page = first_page; > + set_page_private(first_page, (unsigned long)first_page); This patch breaks zram/zsmalloc. Shouldn't it be `page->private = first_page' instead of `first_page->private = first_page'? IOW: - set_page_private(first_page, (unsigned long)first_page); + set_page_private(page, (unsigned long)first_page); ? -ss -- 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] xen/blkfront: convert to blk-mq APIs
Hi Rafal, Please have a try adding "--iodepth_batch=32 --iodepth_batch_complete=32" to the fio command line. I didn't see this issue any more, neither for domU. Thanks, -Bob On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote: > On 19/08/15 12:12, Bob Liu wrote: >> Hi Jens & Christoph, >> >> Rafal reported an issue about this patch, that's after this patch no more >> merges happen and the performance dropped if "modprobe null_blk irqmode=2 >> completion_nsec=100", >> but works fine if "modprobe null_blk". >> >> I'm not sure whether it's as expect or not. >> Do you have any suggestions? Thank you! >> >> Here is the test result: >> >> fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ >> --time_based=1 --runtime=30 --bs=4KB --filename=/dev/xvdb \ >> --direct=1 --group_reporting=1 --iodepth_batch=16 >> >> >> modprobe null_blk >> >> >> *no patch* (avgrq-sz = 8.00 avgqu-sz=5.00) >> >> READ: io=10655MB, aggrb=363694KB/s, minb=363694KB/s, maxb=363694KB/s, >> mint=30001msec, maxt=30001msec >> >> Disk stats (read/write): >> xvdb: ios=2715852/0, merge=1089/0, ticks=126572/0, in_queue=127456, >> util=100.00% >> >> >> *with patch* (avgrq-sz = 8.00 avgqu-sz=8.00) >> >> READ: io=20655MB, aggrb=705010KB/s, minb=705010KB/s, maxb=705010KB/s, >> mint=30001msec, maxt=30001msec >> >> Disk stats (read/write): >> xvdb: ios=5274633/0, merge=22/0, ticks=243208/0, in_queue=242908, >> util=99.98% >> >> >> modprobe null_blk irqmode=2 completion_nsec=100 >> >> >> *no patch* (avgrq-sz = 34.00 avgqu-sz=38.00) >> >> READ: io=10372MB, aggrb=354008KB/s, minb=354008KB/s, maxb=354008KB/s, >> mint=30003msec, maxt=30003msec >> >> Disk stats (read/write): >> xvdb: ios=621760/0, *merge=1988170/0*, ticks=1136700/0, in_queue=1146020, >> util=99.76% >> >> >> *with patch* (avgrq-sz = 8.00 avgqu-sz=28.00) >> >> READ: io=2876.8MB, aggrb=98187KB/s, minb=98187KB/s, maxb=98187KB/s, >> mint=30002msec, maxt=30002msec >> >> Disk stats (read/write): >> xvdb: ios=734048/0, merge=0/0, ticks=843584/0, in_queue=843080, util=99.72% >> >> Regards, >> -Bob > > Hello, > > We got a problem with the lack of merges also when we tested on null_blk > device in dom0 directly. > When we enabled multi queue block-layer we got no merges, even when we set > the number of submission queues to 1. > > If I don't miss anything, that could suggest the problem lays somewhere in > the blk-mq layer itself? > > Please take a look at the results below: > > fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ > --time_based=1 --runtime=30 --bs=4KB --filename=/dev/nullb0 \ > --direct=1 --group_reporting=1 > > > modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=1 > submit_queues=1 > >READ: io=13692MB, aggrb=467320KB/s, minb=467320KB/s, maxb=467320KB/s, > mint=30002msec, maxt=30002msec > > Disk stats (read/write): > nullb0: ios=991026/0, merge=2499524/0, ticks=1846952/0, in_queue=900012, > util=100.00% > > > modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=2 > submit_queues=1 > >READ: io=6839.1MB, aggrb=233452KB/s, minb=233452KB/s, maxb=233452KB/s, > mint=30002msec, maxt=30002msec > > Disk stats (read/write): > nullb0: ios=1743967/0, merge=0/0, ticks=1712900/0, in_queue=1839072, > util=100.00% > > Thanks, > Rafal > >> >> On 07/13/2015 05:55 PM, Bob Liu wrote: >>> Note: This patch is based on original work of Arianna's internship for >>> GNOME's Outreach Program for Women. >>> >>> Only one hardware queue is used now, so there is no performance change. >>> >>> The legacy non-mq code is deleted completely which is the same as other >>> drivers like virtio, mtip, and nvme. >>> >>> Also dropped one unnecessary holding of info->io_lock when calling >>> blk_mq_stop_hw_queues(). >>> >>> Changes in v2: >>> -
Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen wrote: > MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster > share the same power and clock domain. This series tries to add cpufreq > support > for MT8173 SoC. The v6 of this series is resent with Acks added. Hi Rafael, Not sure if I has missed the merge window. Do I have chance to have this series merged for 4.3? Would you please take [1,2] of this series? Thanks. Best Regards, Pi-Cheng > > changes in v6: > - Move clock and regulator consumer properties document to the device tree > bindings documents of MT8173 CPU DVFS clock driver > - Add change log to describe what is implemented in the MT8173 cpufreq driver > - Add missed rcu_read_unlock() in the error path > - Move of_init_opp_table() call to make sure all required hardware resources > are already there before it is called > - Add comments to describe why both platform driver and deivce registration > codes are put in the initcall function > - Use the term "voltage tracking" instead of "voltage trace" according to an > internal SoC document > > changes in v5: > - Move resource allocation code from init() into probe() and remove some > unused > functions due to this change > - Fix descriptions for device tree binding document > - Address review comments for last version > - Register CPU cooling device > > Changes in v4: > - Add bindings for MT8173 cpufreq driver > - Move OPP table back into device tree > - Address comments for last version > > Changes in v3: > - Implement MT8173 specific standalone cpufreq driver instead of using > cpufreq-dt driver > - Define OPP table in the driver source code until new OPP binding is ready > > Changes in v2: > - Add intermediate frequency support in cpufreq-dt driver > - Use voltage scaling code of cpufreq-dt for little cluster instead of > implementaion in notifier of mtk-cpufreq driver > - Code refinement for mtk-cpufreq driver > > Pi-Cheng Chen (3): > dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings > cpufreq: mediatek: Add MT8173 cpufreq driver > arm64: dts: mt8173: Add mt8173 cpufreq driver support > > .../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 > arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 18 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 64 +++ > drivers/cpufreq/Kconfig.arm| 7 + > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/mt8173-cpufreq.c | 524 > + > 6 files changed, 697 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > create mode 100644 drivers/cpufreq/mt8173-cpufreq.c > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] memory-hotplug: fix comment in zone_spanned_pages_in_node() and zone_spanned_pages_in_node()
When hotadd a node from add_memory(), we will add memblock first, so the
node is not empty. But when from cpu_up(), the node should be empty.
Signed-off-by: Xishi Qiu
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ec3ca3..d370445 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5051,7 +5051,7 @@ static unsigned long __meminit
zone_spanned_pages_in_node(int nid,
{
unsigned long zone_start_pfn, zone_end_pfn;
- /* When hotadd a new node, the node should be empty */
+ /* When hotadd a new node from cpu_up(), the node should be empty */
if (!node_start_pfn && !node_end_pfn)
return 0;
@@ -5118,7 +5118,7 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];
unsigned long zone_start_pfn, zone_end_pfn;
- /* When hotadd a new node, the node should be empty */
+ /* When hotadd a new node from cpu_up(), the node should be empty */
if (!node_start_pfn && !node_end_pfn)
return 0;
--
2.0.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] ipmi: add of_device_id in MODULE_DEVICE_TABLE
> On Aug 25, 2015, at 08:48, Corey Minyard wrote: > > Well, I should have compile tested first. On x86_64: > > > CC [M] drivers/char/ipmi/ipmi_si_intf.o > In file included from ../drivers/char/ipmi/ipmi_si_intf.c:42:0: > ../drivers/char/ipmi/ipmi_si_intf.c:2804:25: error: ‘ipmi_match’ > undeclared here (not in a function) > MODULE_DEVICE_TABLE(of, ipmi_match); > ^ > ../include/linux/module.h:223:21: note: in definition of macro > ‘MODULE_DEVICE_TABLE’ > extern const typeof(name) __mod_##type##__##name##_device_table \ > ^ > ../include/linux/module.h:223:27: error: > ‘__mod_of__ipmi_match_device_table’ aliased to undefined symbol ‘ipmi_match’ > extern const typeof(name) __mod_##type##__##name##_device_table \ > ^ > ../drivers/char/ipmi/ipmi_si_intf.c:2804:1: note: in expansion of macro > ‘MODULE_DEVICE_TABLE’ > MODULE_DEVICE_TABLE(of, ipmi_match); > > > This has to compile on all arches. I'm not sure what is wrong, but I've > removed the patch. > > -corey it seems should be : MODULE_DEVICE_TABLE(of, of_ipmi_match); -- 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 7/7] Documentation: dt-bindings: add exynos-srom binding information
On 24.08.2015 17:02, Pankaj Dubey wrote: > This patch adds exynos-srom binding information for SROM Controller > driver on Exynos SoCs. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > .../devicetree/bindings/arm/samsung/exynos-srom.txt | 12 > > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 6/7] ARM: dts: add SROM device node for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add SROM controller device node for exynos5. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos5.dtsi | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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] cgroup: get a ref to source csses when migrating
> Have you verified that the scenario you're describing can actually > happen? AFAICS, cgroup_migrate_add_src() already does the pinning. Hmmm. Looking at it, group_migrate_add_src() does grab a ref on the css_set which contains the css, and the comments mention that grabbing a ref on the css_set will stop the css from being dropped. I must've misunderstood one of your previous emails (where you said that such code was not safe in the ->can_fork(), ->cancel_fork() and ->fork()) path. You also mentioned that depending on the css_set's ref being bumped to protect the contained csses is "sort of implementation detail. It can be implemented in different ways." Which made me think that depending on that is not a good idea. But if it's safe to depend on the cgroup_migrate_add_src() pinning the ref on the css_set, I'll drop this patch and fix up the other one accordingly. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: sdhci: fix dma memory leak in sdhci_pre_req()
Currently one mrq->data maybe execute dma_map_sg() twice
when mmc subsystem prepare over one new request, and the
following log show up:
sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req
for the first time, and map another dma-memory(2) in sdhci_prepare_data
for the second time. But driver only unmap the dma-memory(2), and
dma-memory(1) never unmapped, which cause the dma memory leak issue.
This patch use another method to map the dma memory for the mrq->data
which can fix this dma memory leak issue.
Fixes: commit 348487cb28e66b0 ("mmc: sdhci: use pipeline mmc requests to
improve performance")
Cc: sta...@vger.kernel.org # 4.0+
Reported-and-tested-by: Jiri Slaby
Signed-off-by: Haibo Chen
---
drivers/mmc/host/sdhci.c | 67 ++--
drivers/mmc/host/sdhci.h | 8 +++---
2 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c83d110..8d2864b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -54,8 +54,7 @@ static void sdhci_finish_command(struct sdhci_host *);
static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
static void sdhci_enable_preset_value(struct sdhci_host *host, bool enable);
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next);
+ struct mmc_data *data);
static int sdhci_do_get_cd(struct sdhci_host *host);
#ifdef CONFIG_PM
@@ -495,7 +494,7 @@ static int sdhci_adma_table_pre(struct sdhci_host *host,
goto fail;
BUG_ON(host->align_addr & host->align_mask);
- host->sg_count = sdhci_pre_dma_transfer(host, data, NULL);
+ host->sg_count = sdhci_pre_dma_transfer(host, data);
if (host->sg_count < 0)
goto unmap_align;
@@ -634,9 +633,11 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
}
}
- if (!data->host_cookie)
+ if (data->host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host->mmc), data->sg,
data->sg_len, direction);
+ data->host_cookie = COOKIE_UNMAPPED;
+ }
}
static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
@@ -832,7 +833,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
} else {
int sg_cnt;
- sg_cnt = sdhci_pre_dma_transfer(host, data, NULL);
+ sg_cnt = sdhci_pre_dma_transfer(host, data);
if (sg_cnt <= 0) {
/*
* This only happens when someone fed
@@ -948,11 +949,13 @@ static void sdhci_finish_data(struct sdhci_host *host)
if (host->flags & SDHCI_USE_ADMA)
sdhci_adma_table_post(host, data);
else {
- if (!data->host_cookie)
+ if (data->host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host->mmc),
data->sg, data->sg_len,
(data->flags & MMC_DATA_READ) ?
DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ data->host_cookie = COOKIE_UNMAPPED;
+ }
}
}
@@ -2105,49 +2108,36 @@ static void sdhci_post_req(struct mmc_host *mmc, struct
mmc_request *mrq,
struct mmc_data *data = mrq->data;
if (host->flags & SDHCI_REQ_USE_DMA) {
- if (data->host_cookie)
+ if (data->host_cookie == COOKIE_GIVEN ||
+ data->host_cookie == COOKIE_MAPPED)
dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
data->flags & MMC_DATA_WRITE ?
DMA_TO_DEVICE : DMA_FROM_DEVICE);
- mrq->data->host_cookie = 0;
+ data->host_cookie = COOKIE_UNMAPPED;
}
}
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next)
+ struct mmc_data *data)
{
int sg_count;
- if (!next && data->host_cookie &&
- data->host_cookie != host->next_data.cookie) {
- pr_debug(DRIVER_NAME "[%s] invalid cookie: %d, next-cookie
%d\n",
- __func__, data->host_cookie, host->next_data.cookie);
- data->host_cookie = 0;
+ if (data->host_cookie == COOKIE_MAPPED) {
+
RE: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for suspend
Hi, Boris,thanks for your review
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, August 24, 2015 4:50 PM
> To: Chen, Yu C
> Cc: r...@rjwysocki.net; pa...@ucw.cz; t...@linutronix.de;
> mi...@redhat.com; h...@zytor.com; Zhang, Rui; l...@kernel.org;
> x...@kernel.org; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for
> suspend
>
> On Fri, Aug 21, 2015 at 07:53:34PM +0800, Chen Yu wrote:
> > +struct msr_type {
> > + unsigned int msr_id;
> > + bool msr_saved;
> > + u64 msr_value;
> > +};
>
> These definitions look awfully close to struct msr_info in include/asm/msr.h
>
> Maybe reuse them instead of growing yet another type...
>
OK, I'll use msr_info instead of msr_id and msr_value:
struct msr_type {
bool msr_saved;
struct msr_info rv;
};
> > +static void msr_save_context(struct saved_context *ctxt) {
> > + int i = 0;
> > +
> > + for (i = 0; i < ctxt->msr_for_save.num; i++) {
> > + struct msr_type *msr =
> > + >msr_for_save.msr_array[i];
>
> No need for the line breaks here, let them stick out for better readability.
>
OK, will do.
> > + msr->msr_saved = !rdmsrl_safe(msr->msr_id,
> > + >msr_value);
> > + }
> > + struct msr_type *msr =
> > + >msr_for_save.msr_array[i];
> > + if (msr->msr_saved)
> > + wrmsrl(msr->msr_id, msr->msr_value);
>
> Ditto.
>
OK, will do.
Best Regards,
Yu
Re: [PATCH v2 5/7] ARM: dts: add SROM device node for exynos4
On 24.08.2015 17:02, Pankaj Dubey wrote: > Add device node of SROM controller for exynos4. > > CC: Rob Herring > CC: Mark Rutland > CC: Ian Campbell > Signed-off-by: Pankaj Dubey > --- > arch/arm/boot/dts/exynos4.dtsi | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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] SCSI: dtc: Fixed a brace issue on return 0
On Sun, 28 Jun 2015, Rudhresh wrote:
> From: rudhresh
>
> Return is not a function so parenthesis is not required
>
> Signed-off-by: Rudhresh
Can you put your full name here?
You must address your patches to all of the interested parties (see
scripts/get_maintainer.pl).
Please read Documentation/SubmittingPatches and adhere to the instructions
therein.
--
>
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..c793ecf 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -363,7 +363,7 @@ static inline int NCR5380_pread(struct Scsi_Host
> *instance, unsigned char *dst,
> NCR5380_read(RESET_PARITY_INTERRUPT_REG);
> if (i > hostdata->spin_max_r)
> hostdata->spin_max_r = i;
> - return (0);
> + return 0;
> }
>
> /
> @@ -417,7 +417,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host
> *instance, unsigned char *src,
> rtrc(0);
> if (i > hostdata->spin_max_w)
> hostdata->spin_max_w = i;
> - return (0);
> + return 0;
> }
>
> MODULE_LICENSE("GPL");
>
--
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] SCSI: DTC: Removed 0 initialization for statics
On Mon, 29 Jun 2015, Rudhresh wrote:
> Removed unneccessary initialization of zero to a static variable
>
> Signed-off-by: Rudhresh Kumar J
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..99164d6 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -150,7 +150,7 @@ static const struct signature {
>
> static int __init dtc_setup(char *str)
> {
> - static int commandline_current = 0;
> + static int commandline_current;
> int i;
> int ints[10];
>
> @@ -188,7 +188,7 @@ __setup("dtc=", dtc_setup);
>
> static int __init dtc_detect(struct scsi_host_template * tpnt)
> {
> - static int current_override = 0, current_base = 0;
> + static int current_override, current_base;
> struct Scsi_Host *instance;
> unsigned int addr;
> void __iomem *base;
>
This issue affects all four copies of this code in the NCR5380 drivers:
drivers/scsi/t128.c:static int commandline_current = 0;
drivers/scsi/t128.c:static int current_override = 0, current_base = 0;
drivers/scsi/dtc.c: static int commandline_current = 0;
drivers/scsi/dtc.c: static int current_override = 0, current_base = 0;
drivers/scsi/g_NCR5380.c: static int commandline_current = 0;
drivers/scsi/g_NCR5380.c: static int current_override = 0;
drivers/scsi/pas16.c:static int commandline_current = 0;
drivers/scsi/pas16.c:static int current_override = 0;
drivers/scsi/pas16.c:static unsigned short current_base = 0;
And there are more instances of redundant initialization in pas16.c,
NCR5380.c and sun3_scsi.c.
All of these drivers have the same maintainers, so I'd prefer a single
patch to fix this.
You must address your patches to all of the interested parties (see
scripts/get_maintainer.pl).
--
--
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] SCSI: DTC: Adding KERN_ facility level
On Tue, 30 Jun 2015, Rudhresh Kumar J wrote:
> Fixed coding style issue by adding KERN_ facility level to some of
> the printk functions.
>
> Signed-off-by: Rudhresh Kumar J
> ---
> drivers/scsi/dtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
> index 4c74c7b..a3a2a71 100644
> --- a/drivers/scsi/dtc.c
> +++ b/drivers/scsi/dtc.c
> @@ -156,7 +156,7 @@ static int __init dtc_setup(char *str)
>
> get_options(str, ARRAY_SIZE(ints), ints);
> if (ints[0] != 2)
> - printk("dtc_setup: usage dtc=address,irq\n");
> + printk(KERN_DEBUG "dtc_setup: usage dtc=address,irq\n");
No, that is an error message that the user needs to see.
> else if (commandline_current < NO_OVERRIDES) {
> overrides[commandline_current].address = ints[1];
> overrides[commandline_current].irq = ints[2];
> @@ -272,7 +272,7 @@ found:
> instance->irq = NO_IRQ;
> #endif
> #if defined(DTCDEBUG) && (DTCDEBUG & DTCDEBUG_INIT)
> - printk("scsi%d : irq = %d\n", instance->host_no, instance->irq);
> + printk(KERN_DEBUG "scsi%d : irq = %d\n", instance->host_no,
> instance->irq);
> #endif
>
> ++current_override;
>
I have a better patch for this, which makes use of the dprintk macro to
replace {DTC,P,T}DEBUG_INIT with NDEBUG_INIT. Thanks anyway.
--
--
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 4/7] ARM: EXYNOS: Remove SROM related register settings from mach-exynos
On 24.08.2015 17:02, Pankaj Dubey wrote: > As now we have dedicated driver for SROM controller, it will take care > of saving register banks during S2R so we can safely remove these > settings from mach-exynos. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/Kconfig | 2 ++ > arch/arm/mach-exynos/common.h| 2 -- > arch/arm/mach-exynos/exynos.c| 17 - > arch/arm/mach-exynos/include/mach/map.h | 3 -- > arch/arm/mach-exynos/regs-srom.h | 53 > > arch/arm/mach-exynos/suspend.c | 20 ++- > arch/arm/plat-samsung/include/plat/map-s5p.h | 1 - > 7 files changed, 4 insertions(+), 94 deletions(-) > delete mode 100644 arch/arm/mach-exynos/regs-srom.h The order of patches looks wrong. Is this fully bisectable? You are removing here support for SROM but DTS bindings are not added yet. > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 3a10f1a..7c917ef 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -27,6 +27,8 @@ menuconfig ARCH_EXYNOS > select SRAM > select THERMAL > select MFD_SYSCON > + select SOC_SAMSUNG > + select EXYNOS_SROM > help > Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) > > diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h > index 1534925..1c04741 100644 > --- a/arch/arm/mach-exynos/common.h > +++ b/arch/arm/mach-exynos/common.h > @@ -108,8 +108,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, > EXYNOS5_SOC_MASK) > > #define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \ > soc_is_exynos4412()) > -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \ > - soc_is_exynos5420() || soc_is_exynos5800()) That wasn't here in v1. I see that it is not used any more and of_machine_is_compatible is preferred but I would prefer to leave it. In certain cases you cannot use of_machine_is_compatible (e.g. in platform_do_lowpower). Rest looks good. Best regards, Krzysztof -- 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] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]
Hi Laura,
You can find the patch here:
http://patchwork.kernerl.xyz/patch/6967161/
I will send this patch again and cc to you.
Best regards
Haibo
> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Tuesday, August 25, 2015 12:27 AM
> To: Chen Haibo-B51421; Jiri Slaby; Ulf Hansson
> Cc: linux-...@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
>
> On 08/06/2015 02:17 AM, Chen Bough wrote:
> > I will format a patch based on your diff file firstly. I will test
> > this on my side, If any issue, like dma issue or performance issue, I
> will add some modification.
> > Then I will send the patch for review, and you can test the patch on
> your platform.
> >
> > Best Regards
> > Haibo Chen
> >
>
> Did I miss the follow up patch or is this still pending? If it's still
> pending, would you mind Ccing me when it's available for testing?
>
> Thanks,
> Laura
>
> >
> >> -Original Message-
> >> From: Jiri Slaby [mailto:jsl...@suse.cz]
> >> Sent: Thursday, August 06, 2015 5:07 PM
> >> To: Chen Haibo-B51421; Ulf Hansson
> >> Cc: linux-...@vger.kernel.org; Linux kernel mailing list
> >> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy
> >> (thousands) DMA leaks]
> >>
> >> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> >>> I read your attached log and patch, yes, dma memory leak will happen
> >>> when more than one pre_request execute. The method of ++next->cookie
> >>> is not good, your patch seems good, but I still need some time to
> >>> test the patch, because you unmap the dma in sdhci_finish_data
> >>> rather than
> >> the sdhci_post_req.
> >>
> >> Hi,
> >>
> >> yes, this is not correct. We can perhaps differentiate according to
> >> the COOKIE value. Should I fix it or are you going to prepare a patch
> >> based on my RFC?
> >>
> >> thanks,
> >> --
> >> js
> >> suse labs
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, 2015-08-25 6:47 GMT+09:00 Olof Johansson : > Hi, > > On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada > wrote: >> 1/3: add outer cache support >> 2/3: rework SMP operations >> 3/3: add device tree nodes > > Timing of this is unfortunate, please resend after 4.3-rc1 is out and > we can queue it up. Given that rc8 is out and the merge window has been delayed, is it still too late for 4.3-rc1? >> Because 2/3 highly depends on 1/3, I hope whole of this series >> is applied to ARM-SOC tree. > > Review or acked-by from Russell would be appreciated in that case. > >> Olof, >> From this series, I am using "ARM: uniphier:" rather than "ARM: UniPhier:" >> for the subject prefixes because I noticed you often rephased so when you >> applied my patches. >> Are sub-arch names in lower cases preferable in subject prefixes? > > If you look at "git log --no-merges --oneline arch/arm/mach-*" you'll > see that most platforms use either all-caps or all-lowercase. I see. But, we use "UniPhier" (with only U and P capitalized) in our official documents. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/4] zsmalloc: use page->private instead of page->first_page
Add Minchan to the thread. -ss On (08/17/15 18:09), Kirill A. Shutemov wrote: > We are going to rework how compound_head() work. It will not use > page->first_page as we have it now. > > The only other user of page->fisrt_page beyond compound pages is > zsmalloc. > > Let's use page->private instead of page->first_page here. It occupies > the same storage space. > > Signed-off-by: Kirill A. Shutemov > --- > mm/zsmalloc.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index 0a7f81aa2249..a85754e69879 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -16,7 +16,7 @@ > * struct page(s) to form a zspage. > * > * Usage of struct page fields: > - * page->first_page: points to the first component (0-order) page > + * page->private: points to the first component (0-order) page > * page->index (union with page->freelist): offset of the first object > * starting in this page. For the first page, this is > * always 0, so we use this field (aka freelist) to point > @@ -26,8 +26,7 @@ > * > * For _first_ page only: > * > - * page->private (union with page->first_page): refers to the > - * component page after the first page > + * page->private: refers to the component page after the first page > * If the page is first_page for huge object, it stores handle. > * Look at size_class->huge. > * page->freelist: points to the first free object in zspage. > @@ -770,7 +769,7 @@ static struct page *get_first_page(struct page *page) > if (is_first_page(page)) > return page; > else > - return page->first_page; > + return (struct page *)page_private(page); > } > > static struct page *get_next_page(struct page *page) > @@ -955,7 +954,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) >* Allocate individual pages and link them together as: >* 1. first page->private = first sub-page >* 2. all sub-pages are linked together using page->lru > - * 3. each sub-page is linked to the first page using page->first_page > + * 3. each sub-page is linked to the first page using page->private >* >* For each size class, First/Head pages are linked together using >* page->lru. Also, we set PG_private to identify the first page > @@ -980,7 +979,7 @@ static struct page *alloc_zspage(struct size_class > *class, gfp_t flags) > if (i == 1) > set_page_private(first_page, (unsigned long)page); > if (i >= 1) > - page->first_page = first_page; > + set_page_private(first_page, (unsigned long)first_page); > if (i >= 2) > list_add(>lru, _page->lru); > if (i == class->pages_per_zspage - 1) /* last page */ > -- > 2.5.0 > > -- > 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 > -- 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 linux-next v4 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller
>+ nor->read_reg = atmel_qspi_read_reg;
>+ nor->write_reg = atmel_qspi_write_reg;
>+ nor->read = atmel_qspi_read;
>+ nor->write = atmel_qspi_write;
>+ nor->erase = atmel_qspi_erase;
>+ nor->set_protocol = atmel_qspi_set_protocol;
This is very good, the structure of spi_nor should add a hook function to
notify spi controller
That spi nor transfer protocol already changed.
>+
>+ if (of_modalias_node(child, modalias, sizeof(modalias)) < 0) {
>+ err = -ENODEV;
>+ goto release_channel;
>+ }
>+
>+ err = of_property_read_u32(child, "spi-max-frequency", >clk_rate);
>+ if (err < 0)
>+ goto release_channel;
>+
>+ err = atmel_qspi_init(aq);
>+ if (err)
>+ goto release_channel;
>+
>+ nor->dev->of_node = child;
>+ err = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
> goto release_channel;
>+
...
>static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd) {
return mtd->priv;
>@@ -944,6 +960,11 @@ static int micron_quad_enable(struct spi_nor *nor)
> return ret;
> }
>
>+ /* switch protocol to Quad CMD 4-4-4 */
>+ ret = spi_nor_set_protocol(nor, SPI_PROTO_4_4_4);
>+ if (ret)
>+ return ret;
>+
This make sense,from spi nor side,once its protocol being changed,
Mtd layer must notify this status to spi nor controller immediately,
And spi nor controller also should re-adjust its protocol.
Otherwise, following reading SR operation will fail.
>
> ret = spi_nor_wait_till_ready(nor);
> if (ret)
> return ret;
If my ack has any value in here, feel free to add it.
Acked-by: Bean Huo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] f2fs: fix to release inode correctly
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, August 25, 2015 12:54 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] f2fs: fix to release inode correctly
>
[snip]
> > +* if we skip truncate_node in remove_inode_page bacause we failed
> > +* before, it's better to find another way to release resource of
> > +* this inode (e.g. valid block count, node block or nid). Here we
> > +* choose to add this inode to orphan list, so that we can call iput
> > +* for releasing in orphan recovery flow.
> > +*
> > +* Note: we should add inode to orphan list before f2fs_unlock_op()
> > +* so we can prevent losing this orphan when encoutering checkpoint
> > +* and following suddenly power-off.
> > +*/
> > + if (err && err != -ENOENT) {
> > + err = acquire_orphan_inode(sbi);
> > + if (!err)
> > + add_orphan_inode(sbi, inode->i_ino);
>
> Need this too?
>
> if (err)
> set_sbi_flag(sbi, SBI_NEED_FSCK);
We have another chance to release inode resource in following path:
- handle_failed_inode
- iput
- f2fs_evict_inode
- f2fs_truncate
- remove_inode_page
So I choose to set SBI_NEED_FSCK in the end of f2fs_evict_inode.
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: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Heiko,
在 2015/8/24 21:03, Heiko Stuebner 写道:
Hi Yakir,
Am Montag, 24. August 2015, 20:48:01 schrieb Yakir Yang:
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop. If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
In a generic driver, the property should have either none, or the analogix
prefix. But DT-properties need to be backwards compatible, meaning an older
Exynos devicetree should run unmodified with a newer kernel.
So the common course of action is to mark the old one as deprecated but still
test for both, so something like:
if (of_property_read_u32(dp_node, "analogix,color-space",
_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
Wow, thanks a lot for your explain and code, it do help me to understand
this suggest rightly :-)
Thanks,
- Yakir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations
Hi Russell, Olof, 2015-08-25 6:44 GMT+09:00 Olof Johansson : > On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux > wrote: >> On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: >>> Easiest of all would probably be to get the sub-arch patches into one >>> release, then switch the prototypes and function definitions in the >>> next. If you switch prototypes first you'll get a bunch of warnings, >>> right? >> >> Wrong way around. :) >> >> If you change the sub-arches to declare the smp operations as const, >> and try and pass them into a function which doesn't take a const-pointer, >> you'll get a warning. The core bits need to go in first before the >> sub-arch patches. > > Ah yes, my bad. > >> I think the series has limited value - it allows us to (a) check that a >> small quantity of code doesn't write to these things, and (b) allows us >> to move the SMP operations structure from __initdata to __initconstdata. >> It's still going to end up in the init region which is read/write in any >> case, and still gets thrown away. >> >> Given where we are, I don't think we need to rush this in during the >> last week before the merge window opens, even though it's trivial. > > Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5. > OK. I will put 01 and 02 to Russell's patch tracker (after waiting for a bit more comments just in case). I will do the rest later. -- Best Regards Masahiro Yamada -- 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 06/14] Documentation: drm/bridge: add document for analogix_dp
On 25.08.2015 10:33, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
>> On 24.08.2015 21:48, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
> Hi Krzysztof,
>
> 在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
>> 2015-08-24 8:23 GMT+09:00 Rob Herring :
>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
>>> wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
>>> You can't just change the exynos bindings and break
>>> compatibility. Is
>>> there some agreement with exynos folks to do this?
>> No, there is no agreement. This wasn't even sent to Exynos
>> maintainers.
> Sorry about this one, actually I have add Exynos maintainers in
> version
> 1 & version 2,
> but lose some maintainers in version 3, I would fix it in bellow
> versions.
>
>> Additionally the patchset did not look interesting to me because of
>> misleading subject - Documentation instead of "ARM: dts:".
>>
>> Yakir, please:
>> 1. Provide backward compatibility. Mark old properties as deprecated
>> but still support them.
> Do you mean that I should keep the old properties declare in
> exynos-dp.txt,
> but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way
as it
was supporting before the change?
>>> Okay, I got your means. So document is not the focus, the most important
>>> is that
>>> driver should support the old dts prop.
>> Right, the focus is on the driver.
>>
>>> If so the new analogix dp driver
>>> should keep
>>> the "samsung,color-space", rather then just mark it with [DEPRECATED]
>>> flag.
>> If you are replacing a binding/property then it should be marked
>> deprecated. This means that the old property is still working but new
>> users of it should not be added.
>
> Okay, so just quote Heiko's reply, such code would be need in analogix
> dp driver.
>
>if (of_property_read_u32(dp_node, "analogix,color-space",
> _video_config->color_space))
>if (of_property_read_u32(dp_node, "samsung,color-space",
> _video_config->color_space)) {
>
> dev_err(dev, "failed to get color-space\n");
> return ERR_PTR(-EINVAL);
> }
Yes. It does not look pretty but something like this is needed.
Best regards,
Krzysztof
--
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: parse_args() is too unforgivable?
Oleg Nesterov writes:
> On 08/24, Oleg Nesterov wrote:
>>
>> I booted the kernel with the additional patch below, and nothing bad has
>> happened,
>
> Until I tried reboot it once with "locktorture.verbose=true" paramater.
> It didn't boot.
>
> This is because parse_args() just aborts after it hits the error, so other
> arguments at the same initcall level are simply ignored.
>
> Fixed by the patch below, but I simply can't believe nobody hit this (imo)
> bug before.
>
> Why does parse_args() do this?? I simply can't understand why parse_args()
> adds more random and hard-to-understand problems if one of the args ("=true"
> in this particular case) is wrong.
>
> Yes, the patch below is probably oversimplified / incomplete but imho the
> current behaviour is confusing. At least I was greatly confused ;) At least
> (I think) it makes sense to let the user know that the rest of command line
> was probably ignored.
This is nice, but please save and return the error properly; modules need
this too.
I think nobody hit this before because they notice that they screwed up
the commandline and it didn't boot.
Thanks,
Rusty.
--
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 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Krzysztof,
在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
On 24.08.2015 21:48, Yakir Yang wrote:
Hi Krzysztof,
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring :
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang
wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 & version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of "ARM: dts:".
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop.
Right, the focus is on the driver.
If so the new analogix dp driver
should keep
the "samsung,color-space", rather then just mark it with [DEPRECATED] flag.
If you are replacing a binding/property then it should be marked
deprecated. This means that the old property is still working but new
users of it should not be added.
Okay, so just quote Heiko's reply, such code would be need in analogix
dp driver.
if (of_property_read_u32(dp_node, "analogix,color-space",
_video_config->color_space))
if (of_property_read_u32(dp_node, "samsung,color-space",
_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, "samsung,color-space",
+ if (of_property_read_u32(dp_node, "analogix,color-space",
It looks wrong because it breaks backward compatibility with existing
DTB. As I said before:
1. Provide backward compatibility. Mark old properties
as deprecated but still support them.
And actually @Rob have suggest me to remove the prefix, just use
"color-space" here.
For new bindings I don't mind. But please remember about existing users,
existing DTB and bisectability.
Let me show same examples, make
me understand your suggest rightly.
exynos-dp already contains deprecated properties. Other ways of doing
this would be:
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Documentation/devicetree/bindings/rtc/s3c-rtc.txt
It depends up to you. The "touchscreen" looks good because it organizes
old properties in a common section. In case of exynos-dp.txt you can add
at beginning of file information about new bindings and mark everything
deprecated.
Whoops, thanks for your remind, I prefer the "touchscreen" style.
1. "samsung,ycbcr-coeff" is abandoned in latest analogix-dp driver,
absolutely
I should not carry this to analogix-dp.txt document. But I should
keep this in
exynos-dp.txt document, and mark them with an little
"deprecated" flag.
[Documentation/devicetree/bindings/video/exynos_dp.txt]
Required properties for dp-controller:
[...]
-samsung,ycbcr-coeff (DEPRECATED):
YCbCr co-efficients for input video.
COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
Is it right ?
Yes, this is right.
2. Separate all DTS changes to a separate patch, unless bisectability
would be hurt. Anyway you should prepare it in a such way that
separation would be possible without breaking bisectability.
So I should separate this patch into two parts, one is name "Document:",
the other is "ARM: dts: ".
Yes.
Honestly, I don't understand what the "bisectability" means in this
case.
I was referring to bisectability in general. The patchset should be
fully bisectable which means that it does not introduce any issues
during "git bisect". This effectively means that at each intermediate
step (after applying each
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On Tue, Aug 25, 2015 at 09:46:11AM +1000, Dave Chinner wrote: > On Mon, Aug 24, 2015 at 01:19:24PM -0400, Jeff Moyer wrote: > > Brian Norris writes: > > > > > On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote: > > >> Now, some user-space fails when direct I/O is not supported. > > > > > > I think the whole argument rested on what it means when "some user space > > > fails"; apparently that "user space" is just a test suite (which > > > can/should be fixed). > > > > Even if it wasn't a test suite it should still fail. Either the fs > > supports O_DIRECT or it doesn't. Right now, the only way an application > > can figure this out is to try an open and see if it fails. Don't break > > that. > > Who cares how a filesystem implements O_DIRECT as long as it does > not corrupt data? ext3 fell back to buffered IO in many situations, > yet the only complaints about that were performance. IOWs, it's long been > true that if the user cares about O_DIRECT *performance* then they > have to be careful about their choice of filesystem. > > But if it's only 5 lines of code per filesystem to support O_DIRECT > *correctly* via buffered IO, then exactly why should userspace have > to jump through hoops to explicitly handle open(O_DIRECT) failure? > Especially when you consider that all they can do is fall back to > buffered IO themselves This is what btrfs already does for O_DIRECT plus compressed, or other cases where people don't want their applications to break on top of new features that aren't quite compatible with it. -chris -- 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 3/7] drivers: soc: add support for exynos SROM driver
On 24.08.2015 17:02, Pankaj Dubey wrote:
> This patch adds Exynos SROM controller driver which will handle
> save restore of SROM registers during S2R.
>
> Signed-off-by: Pankaj Dubey
Hi,
Thanks for the fixes. I got some more questions. Sorry that I did not
bring up them before.
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/samsung/Kconfig | 13
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-srom.c | 143
> ++
> drivers/soc/samsung/exynos-srom.h | 51 ++
> 6 files changed, 210 insertions(+)
> create mode 100644 drivers/soc/samsung/Kconfig
> create mode 100644 drivers/soc/samsung/Makefile
> create mode 100644 drivers/soc/samsung/exynos-srom.c
> create mode 100644 drivers/soc/samsung/exynos-srom.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 96ddecb..69107c9 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/mediatek/Kconfig"
> source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/samsung/Kconfig"
> source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 7dc7c0d..34c4398 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> obj-$(CONFIG_ARCH_QCOM) += qcom/
> +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> new file mode 100644
> index 000..ea4bc2a
> --- /dev/null
> +++ b/drivers/soc/samsung/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# SAMSUNG SoC drivers
> +#
> +menu "Samsung SOC driver support"
> +
> +config SOC_SAMSUNG
> + bool
> +
> +config EXYNOS_SROM
> + bool
> + depends on ARM && ARCH_EXYNOS
> +
> +endmenu
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> new file mode 100644
> index 000..9c554d5
> --- /dev/null
> +++ b/drivers/soc/samsung/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_EXYNOS_SROM)+= exynos-srom.o
> diff --git a/drivers/soc/samsung/exynos-srom.c
> b/drivers/soc/samsung/exynos-srom.c
> new file mode 100644
> index 000..d7c4aa7
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-srom.c
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * EXYNOS - SROM Controller support
> + * Author: Pankaj Dubey
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "exynos-srom.h"
> +
> +static void __iomem *exynos_srom_base;
> +
> +static const unsigned long exynos_srom_offsets[] = {
> + /* SROM side */
> + EXYNOS_SROM_BW,
> + EXYNOS_SROM_BC0,
> + EXYNOS_SROM_BC1,
> + EXYNOS_SROM_BC2,
> + EXYNOS_SROM_BC3,
> +};
> +
> +/**
> + * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
> + * @offset: srom register offset from the controller base address.
> + * @value: the value of register under the offset.
> + */
> +struct exynos_srom_reg_dump {
> + u32 offset;
> + u32 value;
> +};
> +
> +static struct exynos_srom_reg_dump *exynos_srom_regs;
> +
> +static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
> + const unsigned long *rdump,
> + unsigned long nr_rdump)
> +{
> + struct exynos_srom_reg_dump *rd;
> + unsigned int i;
> +
> + rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
> + if (!rd)
> + return NULL;
> +
> + for (i = 0; i < nr_rdump; ++i)
> + rd[i].offset = rdump[i];
> +
> + return rd;
> +}
> +
> +static const struct of_device_id of_exynos_srom_ids[] = {
> + {
> + .compatible = "samsung,exynos-srom",
> + },
> + {},
> +};
> +
> +static int exynos_srom_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct device *dev = >dev;
> +
> + np = dev->of_node;
> + exynos_srom_base = of_iomap(np, 0);
The existing file-scope "exynos_srom_base" would be overwritten for any
consecutive device bind. There shouldn't be more binds than one (there
is only one SROM on board) but still someone may create such DTB. By
mistake or by booting with some newer DTB (where for example two SROMs
would be allowed) with older kernel.
The question is should we handle such case?
E.g.
if (exynos_srom_base)
return -EINVAL; /* Doubled bind */
Re: [v2 03/11] soc/fsl: Introduce the DPAA BMan portal driver
On Wed, Aug 12, 2015 at 04:14:49PM -0400, Roy Pledge wrote:
> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> index 9a500ce..d6e2204 100644
> --- a/drivers/soc/fsl/qbman/bman.c
> +++ b/drivers/soc/fsl/qbman/bman.c
> @@ -165,11 +165,11 @@ static struct bman *bm_create(void *regs)
>
> static inline u32 __bm_in(struct bman *bm, u32 offset)
> {
> - return in_be32((void *)bm + offset);
> + return ioread32be((void *)bm + offset);
> }
> static inline void __bm_out(struct bman *bm, u32 offset, u32 val)
> {
> - out_be32((void *)bm + offset, val);
> + iowrite32be(val, (void*) bm + offset);
> }
Don't introduce a problem in one patch and then fix it in another. What
does this change have to do with introducing the portal driver?
> #define bm_in(reg) __bm_in(bm, REG_##reg)
> #define bm_out(reg, val) __bm_out(bm, REG_##reg, val)
> @@ -341,6 +341,7 @@ u32 bm_pool_free_buffers(u32 bpid)
> {
> return bm_in(POOL_CONTENT(bpid));
> }
> +EXPORT_SYMBOL(bm_pool_free_buffers);
If you're exporting this (or even making it global), where's the
documentation?
> +/* BTW, the drivers (and h/w programming model) already obtain the required
> + * synchronisation for portal accesses via lwsync(), hwsync(), and
> + * data-dependencies. Use of barrier()s or other order-preserving primitives
> + * simply degrade performance. Hence the use of the __raw_*() interfaces,
> which
> + * simply ensure that the compiler treats the portal registers as volatile
> (ie.
> + * non-coherent). */
volatile does not mean "non-coherent".
Be careful with this regarding endian, e.g. on ARM we can run the CPU in
big or little endian on the same chip, and the raw accessors also
unfortunately bypass endian conversion.
> +
> +/* Cache-inhibited register access. */
> +#define __bm_in(bm, o) __raw_readl((bm)->addr_ci + (o))
> +#define __bm_out(bm, o, val) __raw_writel((val), (bm)->addr_ci + (o))
> +#define bm_in(reg) __bm_in(>addr, BM_REG_##reg)
> +#define bm_out(reg, val) __bm_out(>addr, BM_REG_##reg, val)
Don't have multiple implementations of bm_in/out, with the same name,
where bm in both refers to "bman", but which have different functions.
> +/* Cache-enabled (index) register access */
> +#define __bm_cl_touch_ro(bm, o) dcbt_ro((bm)->addr_ce + (o))
> +#define __bm_cl_touch_rw(bm, o) dcbt_rw((bm)->addr_ce + (o))
> +#define __bm_cl_in(bm, o)__raw_readl((bm)->addr_ce + (o))
> +#define __bm_cl_out(bm, o, val) \
> + do { \
> + u32 *__tmpclout = (bm)->addr_ce + (o); \
> + __raw_writel((val), __tmpclout); \
> + dcbf(__tmpclout); \
> + } while (0)
> +#define __bm_cl_invalidate(bm, o) dcbi((bm)->addr_ce + (o))
> +#define bm_cl_touch_ro(reg) __bm_cl_touch_ro(>addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_touch_rw(reg) __bm_cl_touch_rw(>addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_in(reg)__bm_cl_in(>addr,
> BM_CL_##reg##_CENA)
> +#define bm_cl_out(reg, val) __bm_cl_out(>addr, BM_CL_##reg##_CENA,
> val)
> +#define bm_cl_invalidate(reg)\
> + __bm_cl_invalidate(>addr, BM_CL_##reg##_CENA)
Define these using functions to operate on pointers, and pass the pointer
in without all the token-pasting. Some extra explanation of the cache
manipulation would also be helpful.
> +/* --- RCR API --- */
> +
> +/* Bit-wise logic to wrap a ring pointer by clearing the "carry bit" */
> +#define RCR_CARRYCLEAR(p) \
> + (void *)((unsigned long)(p) & (~(unsigned long)(BM_RCR_SIZE << 6)))
This could be a function.
Where does 6 come from? You use it again in the next function. Please
define it symbolically.
> +
> +/* Bit-wise logic to convert a ring pointer to a ring index */
> +static inline u8 RCR_PTR2IDX(struct bm_rcr_entry *e)
> +{
> + return ((uintptr_t)e >> 6) & (BM_RCR_SIZE - 1);
> +}
This is a function, so don't use ALLCAPS.
> +/* Increment the 'cursor' ring pointer, taking 'vbit' into account */
> +static inline void RCR_INC(struct bm_rcr *rcr)
> +{
> + /* NB: this is odd-looking, but experiments show that it generates
> + * fast code with essentially no branching overheads. We increment to
> + * the next RCR pointer and handle overflow and 'vbit'. */
> + struct bm_rcr_entry *partial = rcr->cursor + 1;
> +
> + rcr->cursor = RCR_CARRYCLEAR(partial);
> + if (partial != rcr->cursor)
> + rcr->vbit ^= BM_RCR_VERB_VBIT;
> +}
> +
> +static inline int bm_rcr_init(struct bm_portal *portal, enum bm_rcr_pmode
> pmode,
> + __maybe_unused enum bm_rcr_cmode cmode)
> +{
> + /* This use of 'register', as well as all other occurrences, is because
> + * it has been observed to generate much faster code with gcc than is
> + * otherwise the case. */
> + register struct bm_rcr *rcr = >rcr;
What version of GCC? Normal optimization settings?
Has the seemingly excessive use of inline also been benchmarked against
not doing so?
> +/* Buffer
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
在 2015/8/24 22:48, Rob Herring 写道:
On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
wrote:
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
+ -analogix,color-depth:
+ number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.
Please think about this some more. What does "color-depth" mean? Does it
mean the number of bits per colour _component_, or does it mean the total
number of bits to represent a particular colour. It's confusing as it
stands.
Then "component-color-bpp" perhaps?
Actually this "color-bpp" should come from crtc driver, maybe should
come from
"struct drm_crtc {".
Like rockchip stuffs, analogix_dp-rockchip call an mode_config from
rockchip_drm_vop
driver and set output mode to RGB[10:10:10], then vop driver just store
the output mode
type to the private struct "vop->connecot_out_mode". do think that this
outmode should
store into crtc, not just come from DT prop.
- Yakir
--
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: [BUG/RFC] perf test fails on AMD CPUs
On 08/18/2015 05:10 AM, Jiri Olsa wrote: On Mon, Aug 17, 2015 at 09:06:59AM -0700, Andy Lutomirski wrote: On Sun, Aug 16, 2015 at 9:36 PM, Borislav Petkov wrote: On Mon, Aug 17, 2015 at 12:29:56AM +0200, Jiri Olsa wrote: hi, 'perf test 18' is failing on systems with AMD processor. Hmm, still using that b0rked test box? :-) Also, which kernel? There have been substantial changes to the entry code recently. Although I don't see anything being done differently on AMD there except X86_BUG_SYSRET_SS_ATTRS but that should be unrelated. The only reason I could find is that AMD does not set 'resume flag' in RFLAGS register the way the Intel CPU does. (simplified) test scenario: - create breakpoint (on test_function) perf event with SIGIO signal to be delivered any time the breakpoint is hit - run test_function expected course of actions is: 1) CPU hits 'test_function' 2) DB exception is triggered, with RFLAGS.RF=0 3) DB exception handler sets regs->RFLAGS.RF=1 and perf handler triggers irq_work pending work 4) DB exception executes iretd 5) irq_work interrupt is triggered, with RFLAGS.RF=1 6) irq_work interrupt calls kill_fasync with SIGIO signal 7) irq_work interrupt on return to userspace calls prepare_exit_to_usermode which actually delivers the SIGIO signal 8) sigreturn syscall prepare registers to return to the instruction from step 1) and sets RFLAGS.RF to the its original value from step 5) (RFLAGS.RF=1) 9) CPU hits 'test_function' and DB exception is NOT triggered due to RFLAGS.RF=1 this is how I see it works on Intel But AMD gives me RFLAGS.RF=0 on step 5, which makes the step 9 to trigger the DB exception once again and makes the test fail. Adding Andy, he might have an idea. Leaving in the rest for reference. Gee thanks :-p Jiri, did you instrument the code and observe do_IRQ sees RF clear in its pt_regs? Also, it might be worth checking that regs->ip in the irq_work matches regs->ip. yep, thats what I saw.. once irq_work interrupt was triggered the regs->ip was same as for the previous debug exception but the RFLAGS.RF was 0 It's *possible* that I messed up and broke RF restore with opportunistic sysret, but the code looks correct: testq $(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11 jnz opportunistic_sysret_failed AFAICS the problematic paths did not hit syscalls buut anyway, it looks like latest AMD firmware issue: [root@amd-pike-07 ~]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000822 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : Ok [root@amd-pike-07 perf]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000832 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : FAILED! [root@amd-pike-07 ~]# cat /proc/cpuinfo processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 3380 stepping: 0 microcode : 0x6000832 SNIP AMD description of RF flag (SDM 3.1.6): === Resume Flag (RF) Bit. Bit 16. The RF bit allows an instruction to be restarted following an instruction breakpoint resulting in a debug exception (#DB). This bit prevents multiple debug exceptions from occurring on the same instruction. The processor clears the RF bit after every instruction is successfully executed, except when the instruction is: • • An IRET that sets the RF bit. JMP, CALL, or INTn through a task gate. In both of the above cases, RF is not cleared to 0 until the next instruction successfully executes. When an exception occurs (or when a string instruction is interrupted), the processor normally sets RF=1 in the RFLAGS image saved on the interrupt stack. However, when a #DB exception occurs as a result of an instruction breakpoint, the processor clears the RF bit to 0 in the interrupt-stack RFLAGS image. That's a little weird, I think. Shouldn't RF be zero on #DB due to a *watchpoint* so that a watchpoint followed immediately by a breakpoint works? the AMD description looked to be more vague (compared to Intels) • For other cases, the value pushed for RF is the value that was in EFLAG.RF at the time the event handler was called. This includes: — Debug exceptions generated in response to instruction breakpoints — Hardware-generated interrupts arriving between instructions (including those arriving after the last iteration of a repeated string instruction) This appears to be why it works on Intel. Does AMD not do that? We could probably work around this in software (by not using irq work for this), but yuck. yep, but hopefuly it's the issue microcode ;-) Cc-ing guys from linux-firmware git Sherry, Suravee, any idea? thanks, jirka Jiri, I have duplicated your problem and asked the HW architect that wrote 832 to review the diff between the 822
Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular
[Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular] On 24/08/2015 (Mon 20:10) Konrad Rzeszutek Wilk wrote: > On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker > wrote: > >The Kconfig currently controlling compilation of this code is: > > > >config CLEANCACHE > >bool "Enable cleancache driver to cache clean pages if tmem is present" > > > >...meaning that it currently is not being built as a module by anyone. > > Why not make it a tristate? Simple. I'm making the code consistent with its current behaviour. I'm not looking to extend functionality in code that I don't know intimately. I can't do that and do it reliably and guarantee it works as a module when it has never been used as such before. I've got about 130 of these and counting. Some of them have been bool since before git history ; before the turn of the century. If there was demand for them to be tristate, then it would have happened by now. So clearly there is no point in looking at making _those_ tristate. I did have one uart driver author indicate that he _meant_ his code to be tristate, and he tested it as such, and asked if I would convert it to tristate on his behalf. And that was fine and I did exactly that. But unless there are interested users who want their code tristate and can vouch that their code works OK as such, I can only make the code consistent with the implicit non-modular behaviour that the Kconfig and Makefiles have dictated up to now. Are there such users for CLEANCACHE? Paul. -- > > > > > >Lets remove the couple traces of modularity so that when reading the > >driver there is no doubt it is builtin-only. > > > >Since module_init translates to device_initcall in the non-modular > >case, the init ordering remains unchanged with this commit. > > > >Cc: Konrad Rzeszutek Wilk > >Cc: linux...@kvack.org > >Signed-off-by: Paul Gortmaker > >--- > > mm/cleancache.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >diff --git a/mm/cleancache.c b/mm/cleancache.c > >index 8fc5089b..ee0646d1c2fa 100644 > >--- a/mm/cleancache.c > >+++ b/mm/cleancache.c > >@@ -11,7 +11,7 @@ > > * This work is licensed under the terms of the GNU GPL, version 2. > > */ > > > >-#include > >+#include > > #include > > #include > > #include > >@@ -316,4 +316,4 @@ static int __init init_cleancache(void) > > #endif > > return 0; > > } > >-module_init(init_cleancache) > >+device_initcall(init_cleancache) > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] memhp: Add hot-added memory ranges to memblock before allocate node_data for a node.
On 2015/8/24 17:22, Xishi Qiu wrote: > On 2015/8/24 1:06, Tang Chen wrote: > >> The commit below adds hot-added memory range to memblock, after >> creating pgdat for new node. >> >> commit f9126ab9241f66562debf69c2c9d8fee32ddcc53 >> Author: Xishi Qiu >> Date: Fri Aug 14 15:35:16 2015 -0700 >> >> memory-hotplug: fix wrong edge when hot add a new node >> >> But there is a problem: >> >> add_memory() >> |--> hotadd_new_pgdat() >> |--> free_area_init_node() >> |--> get_pfn_range_for_nid() >>|--> find start_pfn and end_pfn in memblock >> |--> .. >> |--> memblock_add_node(start, size, nid)Here, just too late. >> >> get_pfn_range_for_nid() will find that start_pfn and end_pfn are both 0. >> As a result, when adding memory, dmesg will give the following wrong message. >> Hi Tang, Another question, if we add cpu first, there will be print error too. cpu_up() try_online_node() hotadd_new_pgdat() So how about just skip the print if the size is empty or just print "node xx is empty now, will update when online memory"? Thanks, Xishi Qiu >> [ 2007.577000] Initmem setup node 5 [mem >> 0x-0x] >> [ 2007.584000] On node 5 totalpages: 0 >> [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on. Total >> pages: 32588823 >> [ 2007.594000] Policy zone: Normal >> [ 2007.598000] init_memory_mapping: [mem 0x600-0x607] >> -- 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/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
An application from HuaWei which works fine on 2.6 encounters this
issue on 3.0 or later kernel.
Test code:
#include
#include
#include
#include
#include
#include
#include
#define MAXLEN (100)
int main(int argc, char** argv)
{
int fd = 0;
int len = 0;
char pathname[MAXLEN] = {0};
char buf[2] = {0};
int ret = 0xF;
int value = 0xF;
if (argc < 2)
{
printf("Input param error, less 2 param: %s, %s.\n",
argv[0], argv[1]);
return 1;
}
printf("Input: %s, %s \n", argv[0], argv[1]);
ret = sprintf(pathname,
"/proc/sys/net/ipv4/conf/%s/rp_filter", argv[1]);
if (ret < 0)
printf("sprintf error, errno %d, %s\n", errno, strerror(errno));
printf("file is: %s. \n", pathname);
fd = open(pathname, O_RDWR, S_IRUSR);
if (fd <=0 )
{
printf("open %s failed, errno=%d, %s.\n", pathname,
errno, strerror(errno));
return 1;
}
printf("open %s ok, fd=%d\n", pathname, fd);
len = write(fd, "0\0", 2);
printf("write %d: len=%d, errno=%d, %s\n", fd, len, errno,
strerror(errno));
close(fd);
return 0;
}
On Tue, Aug 25, 2015 at 12:59 AM, Steven Rostedt wrote:
> On Mon, 24 Aug 2015 16:56:13 +0800
> Sean Fu wrote:
>
>> when the input argument "count" including the terminating byte "\0",
>> The write system call return EINVAL on proc file.
>> But it return success on regular file.
>>
>> E.g. Writting two bytes ("1\0") to "/proc/sys/net/ipv4/conf/eth0/rp_filter".
>> write(fd, "1\0", 2) return EINVAL.
>
> And what would do that? What tool broke because of this?
>
> echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
>
> works just fine. strlen("string") would not include the nul character.
> The only thing I could think of would be a sizeof(str), but then that
> would include someone hardcoding an integer in a string, like:
>
> char val[] = "1"
>
> write(fd, val, sizeof(val));
>
> Again, what tool does that?
>
> If there is a tool out in the wild that use to work on 2.6 (and was
> running on 2.6 then, and not something that was created after that
> change), then we can consider this fix.
>
> -- Steve
--
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 2/7] ARM: EXYNOS: code cleanup in map.h
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused exynos5440 uart offset macro. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/include/mach/map.h | 4 > 1 file changed, 4 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 1/7] ARM: EXYNOS: remove unused static mapping of CMU for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: > Remove unused static mapping of exynos5 CMU and related code. > > Signed-off-by: Pankaj Dubey > --- > arch/arm/mach-exynos/exynos.c | 5 - > arch/arm/mach-exynos/include/mach/map.h | 1 - > 2 files changed, 6 deletions(-) Looks good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 i2c tree
Hi Wolfram,
After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "of_irq_get_byname" [drivers/i2c/i2c-core.ko] undefined!
Caused by commit
efb6a10b761e ("i2c: allow specifying separate wakeup interrupt in device
tree")
I have used the i2c tree from next-20150824 for today.
--
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/
