[GIT PULL] pwm: Changes for v3.9-rc1
Hi Linus,
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://gitorious.org/linux-pwm/linux-pwm.git tags/for-3.9-rc1
for you to fetch changes up to 30f786170352b8264bc7b61c2482713e54accec8:
pwm: twl: Use to_twl() instead of container_of() (2013-02-17 11:27:07 +0100)
Thanks,
Thierry
pwm: Changes for v3.9-rc1
A new driver has been added to support the PWM mode of the timer counter
blocks found on Atmel AT91 SoCs. The VT8500 driver now supports changing
the PWM signal polarity and the TI drivers (EHRPWM and ECAP) gained
suspend and resume functionality.
User drivers can now query the core for whether access to a PWM device
will sleep (if the PWM chip is on a slow bus such as I2C or SPI).
The pwm-backlight driver now handles the backlight BL_CORE_FBBLANK state
in addition to the FB layer's blanking states.
To round things off, a few fixes and cleanups are also included.
Alexandre Courbot (1):
pwm-backlight: handle BL_CORE_FBBLANK state
Boris BREZILLON (1):
pwm: atmel: add Timer Counter Block PWM driver
Florian Vaussard (2):
pwm: Add pwm_can_sleep() as exported API to users
pwm: Add can_sleep property to drivers
Johannes Thumshirn (1):
pwm: twl: Use to_twl() instead of container_of()
Peter Ujfalusi (1):
pwm_backlight: Validate dft_brightness in main probe function
Philip Avinash (2):
pwm: pwm-tiehrpwm: Low power sleep support
pwm: pwm-tiecap: Low power sleep support
Philip, Avinash (1):
pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
Stephen Warren (1):
pwm: tegra: assume CONFIG_OF
Thierry Reding (2):
pwm: Make Kconfig entries more consistent
pwm: Export pwm_{set,get}_chip_data()
Tony Prisk (2):
pwm: vt8500: Register write busy test performed incorrectly
pwm: vt8500: Add polarity support
.../devicetree/bindings/pwm/atmel-tcb-pwm.txt | 18 +
.../devicetree/bindings/pwm/vt8500-pwm.txt | 9 +-
drivers/pwm/Kconfig| 18 +-
drivers/pwm/Makefile | 1 +
drivers/pwm/core.c | 14 +
drivers/pwm/pwm-atmel-tcb.c| 445 +
drivers/pwm/pwm-tegra.c| 4 +-
drivers/pwm/pwm-tiecap.c | 53 +++
drivers/pwm/pwm-tiehrpwm.c | 93 -
drivers/pwm/pwm-twl-led.c | 1 +
drivers/pwm/pwm-twl.c | 10 +-
drivers/pwm/pwm-vt8500.c | 87 +++-
drivers/video/backlight/pwm_bl.c | 20 +-
include/linux/pwm.h| 10 +
14 files changed, 741 insertions(+), 42 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel-tcb.c
pgpQfuBvEEqXl.pgp
Description: PGP signature
Re: [PATCH] Media: remove incorrect __exit markups
Hi Dmitry
On Sun, 24 Feb 2013, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifically disables sysfs bind/unbind
> attributes.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/media/i2c/adp1653.c | 4 ++--
> drivers/media/i2c/smiapp/smiapp-core.c | 4 ++--
> drivers/media/platform/soc_camera/omap1_camera.c | 4 ++--
> drivers/media/radio/radio-si4713.c | 4 ++--
> drivers/media/rc/ir-rx51.c | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
[snip]
> diff --git a/drivers/media/platform/soc_camera/omap1_camera.c
> b/drivers/media/platform/soc_camera/omap1_camera.c
> index 39a77f0..5f548ac 100644
> --- a/drivers/media/platform/soc_camera/omap1_camera.c
> +++ b/drivers/media/platform/soc_camera/omap1_camera.c
> @@ -1677,7 +1677,7 @@ exit:
> return err;
> }
>
> -static int __exit omap1_cam_remove(struct platform_device *pdev)
> +static int omap1_cam_remove(struct platform_device *pdev)
> {
> struct soc_camera_host *soc_host = to_soc_camera_host(>dev);
> struct omap1_cam_dev *pcdev = container_of(soc_host,
> @@ -1709,7 +1709,7 @@ static struct platform_driver omap1_cam_driver = {
> .name = DRIVER_NAME,
> },
> .probe = omap1_cam_probe,
> - .remove = __exit_p(omap1_cam_remove),
> + .remove = omap1_cam_remove,
> };
>
> module_platform_driver(omap1_cam_driver);
This looks correct, but don't we also have to remove __init from
omap1_cam_probe()? Or would that be a separate patch?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio-blk: emit udev event when device is resized
On 02/22/2013 03:02 AM, Milos Vyletel wrote:
> When virtio-blk device is resized from host (using block_resize from QEMU)
> emit
> KOBJ_CHANGE uevent to notify guest about such change. This allows user to have
> custom udev rules which would take whatever action if such event occurs. As a
> proof of concept I've created simple udev rule that automatically resize
> filesystem on virtio-blk device.
>
> ACTION=="change", KERNEL=="vd*", \
> ENV{RESIZE}=="1", \
> ENV{ID_FS_TYPE}=="ext[3-4]", \
> RUN+="/sbin/resize2fs /dev/%k"
> ACTION=="change", KERNEL=="vd*", \
> ENV{RESIZE}=="1", \
> ENV{ID_FS_TYPE}=="LVM2_member", \
> RUN+="/sbin/pvresize /dev/%k"
>
> Signed-off-by: Milos Vyletel
> ---
> drivers/block/virtio_blk.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 8ad21a2..5990382 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -539,6 +539,8 @@ static void virtblk_config_changed_work(struct
> work_struct *work)
> struct virtio_device *vdev = vblk->vdev;
> struct request_queue *q = vblk->disk->queue;
> char cap_str_2[10], cap_str_10[10];
> + char event[] = "RESIZE=1";
> + char *envp[] = { event, NULL };
event is not used again. Why not just
char *envp[] = { "RESIZE=1", NULL };
> u64 capacity, size;
>
> mutex_lock(>config_lock);
> @@ -568,6 +570,7 @@ static void virtblk_config_changed_work(struct
> work_struct *work)
>
> set_capacity(vblk->disk, capacity);
> revalidate_disk(vblk->disk);
> + kobject_uevent_env(_to_dev(vblk->disk)->kobj, KOBJ_CHANGE, envp);
> done:
> mutex_unlock(>config_lock);
> }
>
I tried the following with your automatically resize udev rules.
(qemu) block_resize vd0 500
Check the fs size in guest, it is 500Mb
(qemu) block_resize vd0 1200
Check the fs size in guest, it is still 500Mb
Can you try resizing multiple times? Does it work?
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Fwd: Cpu hotplug causes stutter on AMD platform, how can I disable it?
On Sun, 2013-02-24 at 22:59 +0100, Mario Giammarco wrote: > I have searched on internet and I see that is a problem common to > several AMD platforms. > Even in Microsoft Windows several people have the same problem and > they solved it disabling cool on bios. It seems that some amd > cpus on power saving cut off also HT bus blocking data from pcie bus > (!?!) > I have tried too and infact disabling cool improves a lot the problem. > But I would like to find a better solution, can I disable cpu hotplug? > Have you heard of this bug before? I haven't, but likely others have. Hm.. if BIOS is shutting down your CPUs, I suspect that trying to ignore that in the kernel would be the mother of all bad ideas :) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tools: hv: Fix how ifcfg-* file is created
- Original Message - > On Sun, Jan 13, Tomas Hozza wrote: > > > -# IPADDR=ipaddr1 > > -# IPADDR_1=ipaddr2 > > -# IPADDR_x=ipaddry (where y = x + 1) > > +# IPADDR0=ipaddr1 > > +# IPADDR1=ipaddr2 > > +# IPADDRx=ipaddry (where y = x + 1) > > Before this change it was IPADDR=, now its IPADDR0=. > Furthermore, IPADDR_n was changed to IPADDRn. >From initscripts (ifcfg-* part) documentation: Base items: NAME= Most important for PPP. Only used in front ends. DEVICE=PPP devices where it is the "logical name")> IPADDRn= PREFIXn= Network prefix. It is used for all configurations except aliases and ippp devices. It takes precedence over NETMASK when both PREFIX and NETMASK are set. NETMASKn= Subnet mask; just useful for aliases and ippp devices. For all other configurations, use PREFIX instead. The "n" is expected to be consecutive positive integers starting from 0. It can be omitted if there is only one address being configured. So I think this explains a lot. In hyperv KVP daemon source there is no logic to determine if we are going to set more than SINGLE IP address to the interface. Therefore we have to set the first one as IPADDR0. This is completely OK and in compliance with the documentation. > Does that match what the tools consuming the ifcfg-* files expect? Since the current format looks the same as described in documentation I assume tools consuming ifcfg-* files expect exactly this. I also checked scripts handling those ifcfg-* files and they did not expect it to be IPADDR_n for some "n". We also tested the daemon and it worked just fine. > Why did it work before this change? For single IPADDR this should work just fine and it is expected to. But did you try also to set more than just a single IP address to the interface? Regards, Tomas Hozza -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtc: add devm_rtc_device_{register,unregister}()
These functios allows the driver core to automatically clean up
any allocation made by rtc drivers. Thus, it simplifies the error
paths.
Signed-off-by: Jingoo Han
---
drivers/rtc/class.c | 72 +++
include/linux/rtc.h |6
2 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 9b742d3..bd3c8ca 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -259,6 +259,78 @@ void rtc_device_unregister(struct rtc_device *rtc)
}
EXPORT_SYMBOL_GPL(rtc_device_unregister);
+static void devm_rtc_device_release(struct device *dev, void *res)
+{
+ struct rtc_device *rtc = *(struct rtc_device **)res;
+
+ rtc_device_unregister(rtc);
+}
+
+static int devm_rtc_device_match(struct device *dev, void *res, void *data)
+{
+ struct rtc **r = res;
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+/**
+ * devm_rtc_device_register - resource managed rtc_device_register()
+ * @name: the name of the device
+ * @dev: the device to register
+ * @ops: the rtc operations structure
+ * @owner: the module owner
+ *
+ * Managed rtc_device_register(). The rtc_device returned from this function
+ * are automatically freed on driver detach. See rtc_device_register()
+ * for more information.
+ */
+
+struct rtc_device *devm_rtc_device_register(const char *name,
+ struct device *dev,
+ const struct rtc_class_ops *ops,
+ struct module *owner)
+{
+ struct rtc_device **ptr, *rtc;
+
+ ptr = devres_alloc(devm_rtc_device_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ rtc = rtc_device_register(name, dev, ops, owner);
+ if (!IS_ERR(rtc)) {
+ *ptr = rtc;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return rtc;
+}
+EXPORT_SYMBOL_GPL(devm_rtc_device_register);
+
+/**
+ * devm_rtc_device_unregister - resource managed devm_rtc_device_unregister()
+ * @dev: the device to unregister
+ * @rtc: the RTC class device to unregister
+ *
+ * Deallocated a rtc allocated with devm_rtc_device_register(). Normally this
+ * function will not need to be called and the resource management code will
+ * ensure that the resource is freed.
+ */
+void devm_rtc_device_unregister(struct device *dev, struct rtc_device *rtc)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_rtc_device_release,
+ devm_rtc_device_match, rtc);
+ if (rc != 0)
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(devm_rtc_device_unregister);
+
static int __init rtc_init(void)
{
rtc_class = class_create(THIS_MODULE, "rtc");
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 580b24c..d955768 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -133,7 +133,13 @@ extern struct rtc_device *rtc_device_register(const char
*name,
struct device *dev,
const struct rtc_class_ops *ops,
struct module *owner);
+extern struct rtc_device *devm_rtc_device_register(const char *name,
+ struct device *dev,
+ const struct rtc_class_ops *ops,
+ struct module *owner);
extern void rtc_device_unregister(struct rtc_device *rtc);
+extern void devm_rtc_device_unregister(struct device *dev,
+ struct rtc_device *rtc);
extern int rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm);
extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 02/15] sched: set initial load avg of new forked task
On 02/24/2013 06:57 PM, Preeti U Murthy wrote: >> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> > index 26058d0..1452e14 100644 >> > --- a/kernel/sched/core.c >> > +++ b/kernel/sched/core.c >> > @@ -1559,6 +1559,7 @@ static void __sched_fork(struct task_struct *p) >> > #if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED) >> >p->se.avg.runnable_avg_period = 0; >> >p->se.avg.runnable_avg_sum = 0; >> > + p->se.avg.decay_count = 0; >> > #endif >> > #ifdef CONFIG_SCHEDSTATS >> >memset(>se.statistics, 0, sizeof(p->se.statistics)); >> > @@ -1646,6 +1647,8 @@ void sched_fork(struct task_struct *p) >> >p->sched_reset_on_fork = 0; >> >} >> > > I think the following comment will help here. > /* All forked tasks are assumed to have full utilization to begin with */ looks fine. -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/3] mfd: syscon: Removed support for unloading
On Mon, Feb 25, 2013 at 10:53:42AM +0400, Alexander Shiyan wrote: > > On Sat, Feb 23, 2013 at 04:51:19PM -0700, Stephen Warren wrote: > > > On 02/22/2013 10:28 PM, Alexander Shiyan wrote: > > > >> On 02/22/2013 10:15 PM, Alexander Shiyan wrote: > > > >>> The driver can be used in various subsystems and therefore should not > > > >>> be unloaded when it is defined in the kernel configuration, so remove > > > >>> support for unloading it. > > > >> > > > >> Why not fix the clients to module_get() at the appropriate times; then > > > >> you could still allow unloading, couldn't you? > > > > > > > > I has explain this before. > > > > > > If multiple people have asked this, perhaps it'd be a good idea to > > > include the answer in the commit description. > > > > > > > Driver defined as "bool" and loaded via postcore_initcall. > > > > > > Being defined as a "bool" sounds like a reasonable reason that no > > > remove() is required. > > > > No, it is not - I can still unbind the device from driver via sysfs. Now > > what will happen is resources are leaked and won't be available when > > trying to bin (via sysfs) again. > > > > This patch is broken. > > I will try to resolve the dispute. > Initially, the first part of the patch (this) was an attempt to prevent the > unloading > (unregister) of the driver (not the device), ie remove module_exit call. > The patch also removes the code to remove the device. Inclusion in this patch > of the code was a mistake. Because of this, people are confused about the > terms, > including me. > Code, relating to the removal of the device should be moved to the third > patch. > Since all moved to using the managed resources, it should not have any > questions. > > About uloading (unregister) driver: As far i understand "__exit" section is > completely discarded when kernel compiled without module support. > But where is this call (module_exit) is placing in case "bool" driver and > kernel is compiled with module support? Fixme please. In both cases __exit code goes to .exit.text section which is either discarded (code is compiled into the kernel) or kept (code is built as a module). Still, because the device can forcibly be unbound from the driver, all these changes are pretty useless for the stated purpose. All in all, it seems to me that this code should not be a driver at all, but rather rolled into regmap infrastructure and be part of it's initialization process. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] W1: w1-gpio - fix incorrect __init/__exit markups
We should not be using __init/__exit markups on probe() and remove()
methods unless platform_device_probe() is used, because other methods
allow unbinding device through sysfs and these methods should not be
discarded.
Signed-off-by: Dmitry Torokhov
---
Paatch #4 was adjusted according to Ville's comments.
drivers/w1/masters/w1-gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 85b363a..799dafd 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -72,7 +72,7 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
return 0;
}
-static int __init w1_gpio_probe(struct platform_device *pdev)
+static int w1_gpio_probe(struct platform_device *pdev)
{
struct w1_bus_master *master;
struct w1_gpio_platform_data *pdata;
@@ -158,7 +158,7 @@ static int __init w1_gpio_probe(struct platform_device
*pdev)
return err;
}
-static int __exit w1_gpio_remove(struct platform_device *pdev)
+static int w1_gpio_remove(struct platform_device *pdev)
{
struct w1_bus_master *master = platform_get_drvdata(pdev);
struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
@@ -210,7 +210,7 @@ static struct platform_driver w1_gpio_driver = {
.of_match_table = of_match_ptr(w1_gpio_dt_ids),
},
.probe = w1_gpio_probe,
- .remove = __exit_p(w1_gpio_remove),
+ .remove = w1_gpio_remove,
.suspend = w1_gpio_suspend,
.resume = w1_gpio_resume,
};
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] W1: w1-gpio - guard DT IDs with CONFIG_OF
This fixes the following warning:
CC drivers/w1/masters/w1-gpio.o
drivers/w1/masters/w1-gpio.c:50:28: warning: ‘w1_gpio_dt_ids’ defined but not
used [-Wunused-variable]
Also provide stub for w1_gpio_probe_dt() if device tree support is
disabled.
Signed-off-by: Dmitry Torokhov
---
drivers/w1/masters/w1-gpio.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index c45b9ae..aa97a96 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -47,6 +47,8 @@ static u8 w1_gpio_read_bit(void *data)
return gpio_get_value(pdata->pin) ? 1 : 0;
}
+#ifdef CONFIG_OF
+
static struct of_device_id w1_gpio_dt_ids[] = {
{ .compatible = "w1-gpio" },
{}
@@ -72,6 +74,15 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
return 0;
}
+#else
+
+static inline int w1_gpio_probe_dt(struct platform_device *pdev)
+{
+ return -ENOSYS;
+}
+
+#endif
+
static int w1_gpio_probe(struct platform_device *pdev)
{
struct w1_bus_master *master;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] W1: w1-gpio - rework handling of platform data
The platform data in the dveice structure does not belong to the driver
and so it should not be trying to alter it, but instead use a local pointer
and populate it with a local copy in case we are dealing with device tree
setup.
Also allow mixed setups where platform data coexists with device tree and
prefer kernel-supplied data (it may be easier to fiddle in kernel structure
before committing final result to device tree).
Signed-off-by: Dmitry Torokhov
---
drivers/w1/masters/w1-gpio.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index aa97a96..465ce52 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -55,30 +55,34 @@ static struct of_device_id w1_gpio_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, w1_gpio_dt_ids);
-static int w1_gpio_probe_dt(struct platform_device *pdev)
+static struct w1_gpio_platform_data *
+w1_gpio_probe_dt(struct platform_device *pdev)
{
- struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct w1_gpio_platform_data *pdata;
struct device_node *np = pdev->dev.of_node;
+ if (!np)
+ return ERR_PTR(-ENOENT);
+
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
if (of_get_property(np, "linux,open-drain", NULL))
pdata->is_open_drain = 1;
pdata->pin = of_get_gpio(np, 0);
pdata->ext_pullup_enable_pin = of_get_gpio(np, 1);
- pdev->dev.platform_data = pdata;
- return 0;
+ return pdata;
}
#else
-static inline int w1_gpio_probe_dt(struct platform_device *pdev)
+static inline struct w1_gpio_platform_data *
+w1_gpio_probe_dt(struct platform_device *pdev)
{
- return -ENOSYS;
+ return NULL;
}
#endif
@@ -94,19 +98,17 @@ static int w1_gpio_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl))
dev_warn(>dev, "unable to select pin group\n");
- if (of_have_populated_dt()) {
- err = w1_gpio_probe_dt(pdev);
- if (err < 0) {
- dev_err(>dev, "Failed to parse DT\n");
- return err;
- }
- }
-
- pdata = pdev->dev.platform_data;
+ pdata = dev_get_platdata(>dev);
+ if (!pdata)
+ pdata = w1_gpio_probe_dt(pdev);
if (!pdata) {
dev_err(>dev, "No configuration data\n");
return -ENXIO;
+ } else if (IS_ERR(pdata)) {
+ err = PTR_ERR(pdata);
+ dev_err(>dev, "Failed to parse DT\n");
+ return err;
}
master = kzalloc(sizeof(struct w1_bus_master), GFP_KERNEL);
@@ -172,7 +174,7 @@ static int w1_gpio_probe(struct platform_device *pdev)
static int w1_gpio_remove(struct platform_device *pdev)
{
struct w1_bus_master *master = platform_get_drvdata(pdev);
- struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ const struct w1_gpio_platform_data *pdata = master->data;
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(0);
@@ -190,7 +192,9 @@ static int w1_gpio_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int w1_gpio_suspend(struct device *dev)
{
- const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct w1_bus_master *master = platform_get_drvdata(pdev);
+ const struct w1_gpio_platform_data *pdata = master->data;
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(0);
@@ -200,7 +204,9 @@ static int w1_gpio_suspend(struct device *dev)
static int w1_gpio_resume(struct device *dev)
{
- const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct w1_bus_master *master = platform_get_drvdata(pdev);
+ const struct w1_gpio_platform_data *pdata = master->data;
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(1);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] W1: w1-gpio - switch to using dev_pm_ops
Signed-off-by: Dmitry Torokhov
---
drivers/w1/masters/w1-gpio.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 799dafd..c45b9ae 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -176,11 +176,10 @@ static int w1_gpio_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-
-static int w1_gpio_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int w1_gpio_suspend(struct device *dev)
{
- struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(0);
@@ -188,31 +187,28 @@ static int w1_gpio_suspend(struct platform_device *pdev,
pm_message_t state)
return 0;
}
-static int w1_gpio_resume(struct platform_device *pdev)
+static int w1_gpio_resume(struct device *dev)
{
- struct w1_gpio_platform_data *pdata = pdev->dev.platform_data;
+ const struct w1_gpio_platform_data *pdata = dev_get_platdata(dev);
if (pdata->enable_external_pullup)
pdata->enable_external_pullup(1);
return 0;
}
-
-#else
-#define w1_gpio_suspendNULL
-#define w1_gpio_resume NULL
#endif
+static SIMPLE_DEV_PM_OPS(w1_gpio_pm_ops, w1_gpio_suspend, w1_gpio_resume);
+
static struct platform_driver w1_gpio_driver = {
.driver = {
.name = "w1-gpio",
.owner = THIS_MODULE,
+ .pm = _gpio_pm_ops,
.of_match_table = of_match_ptr(w1_gpio_dt_ids),
},
.probe = w1_gpio_probe,
.remove = w1_gpio_remove,
- .suspend = w1_gpio_suspend,
- .resume = w1_gpio_resume,
};
module_platform_driver(w1_gpio_driver);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] W1: w1-gpio - switch to using managed resources (devm)
This simplifies error unwinding and device teardown.
Signed-off-by: Dmitry Torokhov
---
drivers/w1/masters/w1-gpio.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 465ce52..464b1a8 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -111,25 +111,27 @@ static int w1_gpio_probe(struct platform_device *pdev)
return err;
}
- master = kzalloc(sizeof(struct w1_bus_master), GFP_KERNEL);
+ master = devm_kzalloc(>dev,
+ sizeof(struct w1_bus_master), GFP_KERNEL);
if (!master) {
dev_err(>dev, "Out of memory\n");
return -ENOMEM;
}
- err = gpio_request(pdata->pin, "w1");
+ err = devm_gpio_request(>dev, pdata->pin, "w1");
if (err) {
dev_err(>dev, "gpio_request (pin) failed\n");
- goto free_master;
+ return err;
}
if (gpio_is_valid(pdata->ext_pullup_enable_pin)) {
- err = gpio_request_one(pdata->ext_pullup_enable_pin,
- GPIOF_INIT_LOW, "w1 pullup");
+ err = devm_gpio_request_one(>dev,
+ pdata->ext_pullup_enable_pin,
+ GPIOF_INIT_LOW, "w1 pullup");
if (err < 0) {
- dev_err(>dev, "gpio_request_one "
- "(ext_pullup_enable_pin) failed\n");
- goto free_gpio;
+ dev_err(>dev,
+ "gpio_request_one (ext_pullup_enable_pin)
failed\n");
+ return err;
}
}
@@ -147,7 +149,7 @@ static int w1_gpio_probe(struct platform_device *pdev)
err = w1_add_master_device(master);
if (err) {
dev_err(>dev, "w1_add_master device failed\n");
- goto free_gpio_ext_pu;
+ return err;
}
if (pdata->enable_external_pullup)
@@ -159,16 +161,6 @@ static int w1_gpio_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, master);
return 0;
-
- free_gpio_ext_pu:
- if (gpio_is_valid(pdata->ext_pullup_enable_pin))
- gpio_free(pdata->ext_pullup_enable_pin);
- free_gpio:
- gpio_free(pdata->pin);
- free_master:
- kfree(master);
-
- return err;
}
static int w1_gpio_remove(struct platform_device *pdev)
@@ -183,8 +175,6 @@ static int w1_gpio_remove(struct platform_device *pdev)
gpio_set_value(pdata->ext_pullup_enable_pin, 0);
w1_remove_master_device(master);
- gpio_free(pdata->pin);
- kfree(master);
return 0;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re[2]: [PATCH v5 1/3] mfd: syscon: Removed support for unloading
> On Sat, Feb 23, 2013 at 04:51:19PM -0700, Stephen Warren wrote: > > On 02/22/2013 10:28 PM, Alexander Shiyan wrote: > > >> On 02/22/2013 10:15 PM, Alexander Shiyan wrote: > > >>> The driver can be used in various subsystems and therefore should not > > >>> be unloaded when it is defined in the kernel configuration, so remove > > >>> support for unloading it. > > >> > > >> Why not fix the clients to module_get() at the appropriate times; then > > >> you could still allow unloading, couldn't you? > > > > > > I has explain this before. > > > > If multiple people have asked this, perhaps it'd be a good idea to > > include the answer in the commit description. > > > > > Driver defined as "bool" and loaded via postcore_initcall. > > > > Being defined as a "bool" sounds like a reasonable reason that no > > remove() is required. > > No, it is not - I can still unbind the device from driver via sysfs. Now > what will happen is resources are leaked and won't be available when > trying to bin (via sysfs) again. > > This patch is broken. I will try to resolve the dispute. Initially, the first part of the patch (this) was an attempt to prevent the unloading (unregister) of the driver (not the device), ie remove module_exit call. The patch also removes the code to remove the device. Inclusion in this patch of the code was a mistake. Because of this, people are confused about the terms, including me. Code, relating to the removal of the device should be moved to the third patch. Since all moved to using the managed resources, it should not have any questions. About uloading (unregister) driver: As far i understand "__exit" section is completely discarded when kernel compiled without module support. But where is this call (module_exit) is placing in case "bool" driver and kernel is compiled with module support? Fixme please. Thanks. ---
Re: [PATCH] s390/dis: Fix invalid array size
On Mon, Feb 25, 2013 at 03:45:45AM +0530, Syam Sidhardhan wrote: > We are using sizeof operator for an array given as function argument, > which is incorrect. > > Signed-off-by: Syam Sidhardhan > --- > arch/s390/kernel/dis.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/s390/kernel/dis.c b/arch/s390/kernel/dis.c > index c50665f..3ad5e95 100644 > --- a/arch/s390/kernel/dis.c > +++ b/arch/s390/kernel/dis.c > @@ -1711,10 +1711,10 @@ int insn_to_mnemonic(unsigned char *instruction, char > buf[8]) > if (!insn) > return -ENOENT; > if (insn->name[0] == '\0') > - snprintf(buf, sizeof(buf), "%s", > + snprintf(buf, 8, "%s", >long_insn_name[(int) insn->name[1]]); Thanks, applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] drivers: phy: add generic PHY framework
Hi, On Sunday 24 February 2013 04:14 AM, Rob Landley wrote: On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. Given that this has a separately selectable config option, I'm guessing that it's useful all by itself even in the absence of a driver using Not really. It has to be thought of like a bridge that connects the device (can be USB/SATA/..) and the PHY. The PHY driver will register the PHY in this framework and the device controller driver can obtain a reference to this PHY from this framework. this phy? (Or it gives user visibility to the phy buried in an E1000 or SATA drive or some such?) The PHY and the device are generally independent entities and there has to be a way to bind them in-order for the device controller to use the PHY. For e.g., MUSB in OMAP4 uses a PHY which is different from PHY in OMAP3 and it's going to be different from a PHY used in other SoCs. So in-order for MUSB to use the correct PHY, there has to be a framework that maintains the list of PHY and returns the correct PHY when a device controller driver requests for it. So whenever the PHY driver gets probed, it registers itself with this framework and then the MUSB can get the reference to the PHY from this framework. The use of this framework is more prevalent when there are multiple MUSB controllers each using a different PHY in a single SoC. This holds true for other device controllers as well. +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. I've usually heard the word "transciever" used to describe these. hmm.. IMO there is a thin line differentiating "transceiver" and "PHY" and can be used interchangeably. Since it's been referred as "PHY" in data sheets and TRMs, I preferred to call it PHY. +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. Given that a PHY is a chip (random example http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY), you seem to be saying that software should manifest a piece of hardware out of thin air through sheer willpower. I'm pretty sure I've misunderstood this phrasing. +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc); +struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize? There is actually difference between allocating/initializing and binding. Binding is to bind the device controller with the PHY. My previous explanation might help to clarify it. +6. Destroying the PHY I've run drivers like that. I try not to, though. +7. Current Status + +Currently only USB in OMAP is made to use this framework. However using the +USB PHY library cannot be completely removed because it is intertwined with +OTG. Once we move OTG out of PHY completely, using the old PHY library can be +completely removed. SATA in OMAP will also more likely use this new framework +and we should have a patch for it soon. Does this paragraph belong in the documentation? (Git commit, sure, but I've seen a lot of stale paragraphs like these hang around a surprisingly long time.) hmm.. there are a few others who raised concern on having this paragraph. I've planned to remove it in my next version. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: too many timer retries happen when do local timer swtich with broadcast timer
Thomas, 2013/2/23 Thomas Gleixner : > On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote: >> On Fri, Feb 22, 2013 at 03:03:02PM +, Thomas Gleixner wrote: >> > On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote: >> > > On Fri, Feb 22, 2013 at 12:07:30PM +, Thomas Gleixner wrote: >> > > > Now we could make use of that and avoid going deep idle just to come >> > > > back right away via the IPI. Unfortunately the notification thingy has >> > > > no return value, but we can fix that. >> > > > >> > > > To confirm that theory, could you please try the hack below and add >> > > > some instrumentation (trace_printk)? >> > > >> > > Applied, and it looks like that's exactly why the warning triggers, at >> > > least >> > > on the platform I am testing on which is a dual-cluster ARM testchip. >> > > >> > > There is a still time window though where the CPU (the IPI target) can >> > > get >> > > back to idle (tick_broadcast_pending still not set) before the CPU >> > > target of >> > > the broadcast has a chance to run tick_handle_oneshot_broadcast (and set >> > > tick_broadcast_pending), or am I missing something ? >> > >> > Well, the tick_broadcast_pending bit is uninteresting if the >> > force_broadcast bit is set. Because if that bit is set we know for >> > sure, that we got woken with the cpu which gets the broadcast timer >> > and raced back to idle before the broadcast handler managed to >> > send the IPI. >> >> Gah, my bad sorry, I mixed things up. I thought >> >> tick_check_broadcast_pending() >> >> was checking against the tick_broadcast_pending mask not >> >> tick_force_broadcast_mask > > Yep, that's a misnomer. I just wanted to make sure that my theory is > correct. I need to think about the real solution some more. I have applied your patch and tested, there is NO warning at all then. I think your theory is correct. > > We have two alternatives: > > 1) Make the clockevents_notify function have a return value. > > 2) Add something like the hack I gave you with a proper name. > > The latter has the beauty, that we just need to modify the platform > independent idle code instead of going down to every callsite of the > clockevents_notify thing. I prefer the solution 2). > > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Mon, Feb 25, 2013 at 4:06 PM, Dave Airlie wrote: > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH wrote: >> Hi Ben, >> >> My Macbook Pro Retina fails to resume properly on 3.8. I tracked this >> down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: >> move link training helpers into core as display methods) >> >> Anything I can try to help solve this? >> >> Note, I'm using the Intel driver as the main controller for this laptop, >> well, I think I am, my xorg log is attached. > > No you are using the nvidia, the efi always boots nvidia enabled now. > > Cool, might have to lend Ben my retina to see if he can reproduce. btw I just tested my drm-next tree on mine and it resumed the display fine, something oopsed a few seconds later that I haven't tracked down git://git.freedesktop.org/~airlied/linux drm-next I'll be sending it to Linus this evening or tomorrow morning, once I fix my tree. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cpuset: use cgroup_name() in cpuset_print_task_mems_allowed()
Use cgroup_name() instead of cgrp->dentry->name. This makes the code
simpler.
While at it, remove cpuset_name and make cpuset_nodelist a local variable
to cpuset_print_task_mems_allowed().
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 4f9dfe4..ace5bfc 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -265,17 +265,6 @@ static DEFINE_MUTEX(cpuset_mutex);
static DEFINE_MUTEX(callback_mutex);
/*
- * cpuset_buffer_lock protects both the cpuset_name and cpuset_nodelist
- * buffers. They are statically allocated to prevent using excess stack
- * when calling cpuset_print_task_mems_allowed().
- */
-#define CPUSET_NAME_LEN(128)
-#defineCPUSET_NODELIST_LEN (256)
-static char cpuset_name[CPUSET_NAME_LEN];
-static char cpuset_nodelist[CPUSET_NODELIST_LEN];
-static DEFINE_SPINLOCK(cpuset_buffer_lock);
-
-/*
* CPU / memory hotplug is handled asynchronously.
*/
static struct workqueue_struct *cpuset_propagate_hotplug_wq;
@@ -2592,6 +2581,8 @@ int cpuset_mems_allowed_intersects(const struct
task_struct *tsk1,
return nodes_intersects(tsk1->mems_allowed, tsk2->mems_allowed);
}
+#define CPUSET_NODELIST_LEN(256)
+
/**
* cpuset_print_task_mems_allowed - prints task's cpuset and mems_allowed
* @task: pointer to task_struct of some task.
@@ -2602,24 +2593,19 @@ int cpuset_mems_allowed_intersects(const struct
task_struct *tsk1,
*/
void cpuset_print_task_mems_allowed(struct task_struct *tsk)
{
- struct dentry *dentry;
+/* Statically allocated to prevent using excess stack. */
+ static char cpuset_nodelist[CPUSET_NODELIST_LEN];
+ static DEFINE_SPINLOCK(cpuset_buffer_lock);
- dentry = task_cs(tsk)->css.cgroup->dentry;
- spin_lock(_buffer_lock);
+ struct cgroup *cgrp = task_cs(tsk)->css.cgroup;
- if (!dentry) {
- strcpy(cpuset_name, "/");
- } else {
- spin_lock(>d_lock);
- strlcpy(cpuset_name, (const char *)dentry->d_name.name,
- CPUSET_NAME_LEN);
- spin_unlock(>d_lock);
- }
+ spin_lock(_buffer_lock);
nodelist_scnprintf(cpuset_nodelist, CPUSET_NODELIST_LEN,
tsk->mems_allowed);
printk(KERN_INFO "%s cpuset=%s mems_allowed=%s\n",
- tsk->comm, cpuset_name, cpuset_nodelist);
+ tsk->comm, cgroup_name(cgrp), cpuset_nodelist);
+
spin_unlock(_buffer_lock);
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] cgroup: add cgroup_name() API
cgroup_name() returns the name of a cgroup and it must be called with
rcu_read_lock() held.
This will be used by cpuset.
Signed-off-by: Li Zefan
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 14 ++
2 files changed, 15 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 7f21bad..70676eb 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -426,6 +426,7 @@ int cgroup_rm_cftypes(struct cgroup_subsys *ss, struct
cftype *cfts);
int cgroup_is_removed(const struct cgroup *cgrp);
+char *cgroup_name(const struct cgroup *cgrp);
int cgroup_path(const struct cgroup *cgrp, char *buf, int buflen);
int cgroup_task_count(const struct cgroup *cgrp);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index eb3c280..abbb097 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1778,6 +1778,20 @@ static struct file_system_type cgroup_fs_type = {
static struct kobject *cgroup_kobj;
/**
+ * cgroup_name - get the name of a cgroup
+ * @cgrp: the cgroup in question
+ *
+ * Must be called with rcu_read_lock() held.
+ */
+char *cgroup_name(const struct cgroup *cgrp)
+{
+ if (!cgrp->parent)
+ return "/";
+ else
+ return rcu_dereference(cgrp->name)->name;
+}
+
+/**
* cgroup_path - generate the path of a cgroup
* @cgrp: the cgroup in question
* @buf: the buffer to write the path into
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] cgroup: fix cgroup_path() vs rename() race
rename() will change dentry->d_name. The result of this race can
be worse than seeing partially rewritten name, but we might access
a stale pointer because rename() will re-allocate memory to hold
a longer name.
As accessing dentry->name must be protected by dentry->d_lock or
parent inode's i_mutex, while on the other hand cgroup-path() can
be called with some irq-safe spinlocks held, we can't generate
cgroup path using dentry->d_name.
Alternatively we make a copy of dentry->d_name and save it in
cgrp->name when a cgroup is created, and update cgrp->name at
rename().
v3: use kfree_rcu() instead of synchronize_rcu() in user-visible path
v2: make cgrp->name RCU safe.
Signed-off-by: Li Zefan
---
block/blk-cgroup.h | 2 -
include/linux/cgroup.h | 17 +
kernel/cgroup.c| 101 -
3 files changed, 91 insertions(+), 29 deletions(-)
diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
index 2459730..e2e3404 100644
--- a/block/blk-cgroup.h
+++ b/block/blk-cgroup.h
@@ -216,9 +216,7 @@ static inline int blkg_path(struct blkcg_gq *blkg, char
*buf, int buflen)
{
int ret;
- rcu_read_lock();
ret = cgroup_path(blkg->blkcg->css.cgroup, buf, buflen);
- rcu_read_unlock();
if (ret)
strncpy(buf, "", buflen);
return ret;
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 900af59..7f21bad 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -150,6 +150,11 @@ enum {
CGRP_CPUSET_CLONE_CHILDREN,
};
+struct cgroup_name {
+ struct rcu_head rcu_head;
+ char name[0];
+};
+
struct cgroup {
unsigned long flags;/* "unsigned long" so bitops work */
@@ -172,6 +177,18 @@ struct cgroup {
struct cgroup *parent; /* my parent */
struct dentry *dentry; /* cgroup fs entry, RCU protected */
+ /*
+* This is a copy of dentry->d_name, and it's needed because
+* we can't use dentry->d_name in cgroup_path().
+*
+* You must acquire rcu_read_lock() to access cgrp->name, and
+* the only place that can change it is rename(), which is
+* protected by parent dir's i_mutex.
+*
+* The name of the root cgroup is "/", and @name == NULL.
+*/
+ struct cgroup_name __rcu *name;
+
/* Private pointers for each registered subsystem */
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index b5c6432..eb3c280 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -860,6 +860,17 @@ static struct inode *cgroup_new_inode(umode_t mode, struct
super_block *sb)
return inode;
}
+static struct cgroup_name *cgroup_alloc_name(struct dentry *dentry)
+{
+ struct cgroup_name *name;
+
+ name = kmalloc(sizeof(*name) + dentry->d_name.len + 1, GFP_KERNEL);
+ if (!name)
+ return NULL;
+ strcpy(name->name, dentry->d_name.name);
+ return name;
+}
+
static void cgroup_free_fn(struct work_struct *work)
{
struct cgroup *cgrp = container_of(work, struct cgroup, free_work);
@@ -890,6 +901,7 @@ static void cgroup_free_fn(struct work_struct *work)
simple_xattrs_free(>xattrs);
ida_simple_remove(>root->cgroup_ida, cgrp->id);
+ kfree(rcu_dereference_raw(cgrp->name));
kfree(cgrp);
}
@@ -1771,49 +1783,49 @@ static struct kobject *cgroup_kobj;
* @buf: the buffer to write the path into
* @buflen: the length of the buffer
*
- * Called with cgroup_mutex held or else with an RCU-protected cgroup
- * reference. Writes path of cgroup into buf. Returns 0 on success,
- * -errno on error.
+ * Writes path of cgroup into buf. Returns 0 on success, -errno on error.
+ *
+ * We can't generate cgroup path using dentry->d_name, as accessing
+ * dentry->name must be protected by irq-unsafe dentry->d_lock or parent
+ * inode's i_mutex, while on the other hand cgroup_path() can be called
+ * with some irq-safe spinlocks held.
*/
int cgroup_path(const struct cgroup *cgrp, char *buf, int buflen)
{
- struct dentry *dentry = cgrp->dentry;
+ int ret = -ENAMETOOLONG;
char *start;
- rcu_lockdep_assert(rcu_read_lock_held() || cgroup_lock_is_held(),
- "cgroup_path() called without proper locking");
-
- if (cgrp == dummytop) {
- /*
-* Inactive subsystems have no dentry for their root
-* cgroup
-*/
+ if (!cgrp->parent) {
strcpy(buf, "/");
return 0;
}
start = buf + buflen - 1;
-
*start = '\0';
- for (;;) {
- int len = dentry->d_name.len;
+ rcu_read_lock();
+ while (cgrp->parent) {
+ struct cgroup_name *cname = rcu_dereference(cgrp->name);
+ char *name;
+ int len;
+
+
Re: too many timer retries happen when do local timer swtich with broadcast timer
On Saturday 23 February 2013 12:22 AM, Thomas Gleixner wrote: On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote: On Fri, Feb 22, 2013 at 03:03:02PM +, Thomas Gleixner wrote: On Fri, 22 Feb 2013, Lorenzo Pieralisi wrote: On Fri, Feb 22, 2013 at 12:07:30PM +, Thomas Gleixner wrote: Now we could make use of that and avoid going deep idle just to come back right away via the IPI. Unfortunately the notification thingy has no return value, but we can fix that. To confirm that theory, could you please try the hack below and add some instrumentation (trace_printk)? Applied, and it looks like that's exactly why the warning triggers, at least on the platform I am testing on which is a dual-cluster ARM testchip. I too confirm that the warnings cause is same. There is a still time window though where the CPU (the IPI target) can get back to idle (tick_broadcast_pending still not set) before the CPU target of the broadcast has a chance to run tick_handle_oneshot_broadcast (and set tick_broadcast_pending), or am I missing something ? Well, the tick_broadcast_pending bit is uninteresting if the force_broadcast bit is set. Because if that bit is set we know for sure, that we got woken with the cpu which gets the broadcast timer and raced back to idle before the broadcast handler managed to send the IPI. Gah, my bad sorry, I mixed things up. I thought tick_check_broadcast_pending() was checking against the tick_broadcast_pending mask not tick_force_broadcast_mask Yep, that's a misnomer. I just wanted to make sure that my theory is correct. I need to think about the real solution some more. We have two alternatives: 1) Make the clockevents_notify function have a return value. 2) Add something like the hack I gave you with a proper name. The latter has the beauty, that we just need to modify the platform independent idle code instead of going down to every callsite of the clockevents_notify thing. I agree that 2 is better alternative to avoid multiple changes. Whichever alternative you choose, will be happy to test it :) Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] f_pos in readdir() (was Re: [RFC][PATCH] vfs: always protect diretory file->fpos with inode mutex)
>> We can fix this bug in each filesystem, but can't we just make sure i_mutex >> is >> acquired in lseek(), read(), write() and readdir() for directory file >> operations? >> >> (the patch is for demonstration only) > > No. This is a very massive overkill. If anything, we want to *reduce* the > amount of time we hold ->i_mutex in that area. > > There are several bugs mixed here: > * disappearing exclusion between readdir and lseek for directories. > Bad, since offset validation suddenly needs to be redone every time we look > at ->f_pos in ->readdir() instances *and* since ->readdir() itself updates > position, often by file->f_pos += something. > * write(2) doing "get a copy of f_pos, try and fail ->write(), > put that copy back". With no locking whatsoever. What we get is a f_pos > value reverting to what it used to be at some random earlier point. Makes > life really nasty for everything that updates ->f_pos, obviously. > * read(2) doing the same, *and* some directories apparently having > ->read() now. > > ->readdir() part of that would be the simplest one - we need to stop messing > with ->f_pos and just pass an address of its copy, like we do for ->read() > et.al. Preserving the method prototype is not worth it and this particular > method has needed an overhaul of calling conventions for many reasons. > > The issue with write(2) and friends is potentially nastier. I'm looking > at the ->f_pos users right now, and while the majority are ->readdir() > and ->llseek() instances, there's some stuff beyond that. Some of that is > done with struct file opened kernel-side and not accessible to userland; > those are safe (and often really ugly - see drivers/media/pci/cx25821/ > hits for f_pos). Some are simply wrong - e.g. dev_mem_read() > (in drivers/net/wireless/ti/wlcore/debugfs.c) ignores *ppos value and uses > file->f_pos instead; wrong behaviour for ->read() instance. I'm about > 20% through the list; so far everything seems to be possible to deal with > (especially if we add a couple of helpers for common lseek variants and > use existing generic_file_llseek_size()), so it might turn out to be > not a serious issue, but it's a potential minefield. Hell knows... > > As for ->readdir(), I'd like to resurrect an old proposal to change the ABI > of that sucker. Quoting the thread from 4 years ago: > > As for the locking... I toyed with one idea for a while: instead of passing > a callback and one of many completely different structs, how about a common > *beginning* of a struct, with callback stored in it along with several > common fields? Namely, > * count of filldir calls already made > * pointer to file in question > * "are we done" flag > And instead of calling filldir(buf, ...) ->readdir() would call one of several > helpers: > * readdir_emit(buf, ...) - obvious > * readdir_relax(buf) - called in a spot convenient for dropping > and retaking lock; returns whether we need to do revalidation. > * readdir_eof(buf) - end of directory > * maybe readdir_dot() and readdir_dotdot() - those are certainly > common enough > That's the obvious flagday stuff, but since we need to give serious beating > to most of the instances anyway... Might as well consider something in > that direction. > > > Back then it didn't go anywhere, but if we really go for change of calling > conventions (passing a pointer to copy of ->f_pos), it would make a lot of > sense, IMO. Note that ->i_mutex contention could be seriously relieved that > way - e.g. ext* would just call readdir_relax() at the block boundaries, > since those locations are always valid there, etc. > So there will be no lock to protect f_pos in read/write/llseek in your proposal. Do we need to care about reading/writing fpos in 32 bit machine is not atomic? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Mon, Feb 25, 2013 at 3:52 PM, Greg KH wrote: > Hi Ben, > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked this > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: > move link training helpers into core as display methods) > > Anything I can try to help solve this? > > Note, I'm using the Intel driver as the main controller for this laptop, > well, I think I am, my xorg log is attached. No you are using the nvidia, the efi always boots nvidia enabled now. Cool, might have to lend Ben my retina to see if he can reproduce. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 02/15] sched: set initial load avg of new forked task
On 02/24/2013 06:57 PM, Preeti U Murthy wrote:
> Hi Alex,
>
> On 02/20/2013 11:50 AM, Alex Shi wrote:
>> On 02/18/2013 01:07 PM, Alex Shi wrote:
>>> New task has no runnable sum at its first runnable time, so its
>>> runnable load is zero. That makes burst forking balancing just select
>>> few idle cpus to assign tasks if we engage runnable load in balancing.
>>>
>>> Set initial load avg of new forked task as its load weight to resolve
>>> this issue.
>>>
>>
>> patch answering PJT's update here. that merged the 1st and 2nd patches
>> into one. other patches in serial don't need to change.
>>
>> =
>> From 89b56f2e5a323a0cb91c98be15c94d34e8904098 Mon Sep 17 00:00:00 2001
>> From: Alex Shi
>> Date: Mon, 3 Dec 2012 17:30:39 +0800
>> Subject: [PATCH 01/14] sched: set initial value of runnable avg for new
>> forked task
>>
>> We need initialize the se.avg.{decay_count, load_avg_contrib} for a
>> new forked task.
>> Otherwise random values of above variables cause mess when do new task
>> enqueue:
>> enqueue_task_fair
>> enqueue_entity
>> enqueue_entity_load_avg
>>
>> and make forking balancing imbalance since incorrect load_avg_contrib.
>>
>> set avg.decay_count = 0, and avg.load_avg_contrib = se->load.weight to
>> resolve such issues.
>>
>> Signed-off-by: Alex Shi
>> ---
>> kernel/sched/core.c | 3 +++
>> kernel/sched/fair.c | 4
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 26058d0..1452e14 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1559,6 +1559,7 @@ static void __sched_fork(struct task_struct *p)
>> #if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
>> p->se.avg.runnable_avg_period = 0;
>> p->se.avg.runnable_avg_sum = 0;
>> +p->se.avg.decay_count = 0;
>> #endif
>> #ifdef CONFIG_SCHEDSTATS
>> memset(>se.statistics, 0, sizeof(p->se.statistics));
>> @@ -1646,6 +1647,8 @@ void sched_fork(struct task_struct *p)
>> p->sched_reset_on_fork = 0;
>> }
>>
> I think the following comment will help here.
> /* All forked tasks are assumed to have full utilization to begin with */
>> +p->se.avg.load_avg_contrib = p->se.load.weight;
>> +
>> if (!rt_prio(p->prio))
>> p->sched_class = _sched_class;
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 81fa536..cae5134 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1509,6 +1509,10 @@ static inline void enqueue_entity_load_avg(struct
>> cfs_rq *cfs_rq,
>> * We track migrations using entity decay_count <= 0, on a wake-up
>> * migration we use a negative decay count to track the remote decays
>> * accumulated while sleeping.
>> + *
>> + * When enqueue a new forked task, the se->avg.decay_count == 0, so
>> + * we bypass update_entity_load_avg(), use avg.load_avg_contrib initial
>> + * value: se->load.weight.
>
> I disagree with the comment.update_entity_load_avg() gets called for all
> forked tasks.
> enqueue_task_fair->update_entity_load_avg() during the second
> iteration.But __update_entity_load_avg() in update_entity_load_avg()
>
When goes 'enqueue_task_fair->update_entity_load_avg()' during the
second iteration. the se is changed.
That is different se.
--
Thanks Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
resume fails to light display on Macbook Pro Retina on 3.8-rc1
Hi Ben,
My Macbook Pro Retina fails to resume properly on 3.8. I tracked this
down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp:
move link training helpers into core as display methods)
Anything I can try to help solve this?
Note, I'm using the Intel driver as the main controller for this laptop,
well, I think I am, my xorg log is attached.
And sorry for not reporting this sooner, it took me a long time to
bisect down, there were other resume and boot issues on the bisect trail
leading to this, the full log is below.
thanks,
greg k-h
git bisect start
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect bad 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [dadfab4873256d2145640c0ce468fcbfb48977fe] Merge tag 'firewire-updates'
of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
git bisect good dadfab4873256d2145640c0ce468fcbfb48977fe
# bad: [992956189de58cae9f2be40585bc25105cd7c5ad] efi: Fix the build with user
namespaces enabled.
git bisect bad 992956189de58cae9f2be40585bc25105cd7c5ad
# skip: [2b8318881ddbcb67c5e8d2178b4228474944] Merge tag 'fbdev-for-3.8' of
git://gitorious.org/linux-omap-dss2/linux
git bisect skip 2b8318881ddbcb67c5e8d2178b4228474944
# good: [da22f22e91f0d14d996c7258101575a5a06ddf85] ssb: add
ssb_chipco_gpio_pull{up,down}
git bisect good da22f22e91f0d14d996c7258101575a5a06ddf85
# good: [bb523fc08d4a4a726c7555be7800735685888b3c] drm/i915: convert
PIPE_CLK_SEL to transcoder
git bisect good bb523fc08d4a4a726c7555be7800735685888b3c
# good: [d3e4ea017a414a19ab11a10b52e80a0c8b3f1670] [media] em28xx-cards: fix a
warning
git bisect good d3e4ea017a414a19ab11a10b52e80a0c8b3f1670
# good: [3fcb6eb4063ab4eef05601c266afa2af667c8e1f] video: exynos_dp: remove
redundant parameters
git bisect good 3fcb6eb4063ab4eef05601c266afa2af667c8e1f
# good: [c5b005ab7091c9ef4ca9b47569a8e27e54588933] drbd: use bitmap_parse
instead of __bitmap_parse
git bisect good c5b005ab7091c9ef4ca9b47569a8e27e54588933
# skip: [c13e69b2f0e1e2da41a175c7e9215659842cbef9] Merge tag 'upstream-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
git bisect skip c13e69b2f0e1e2da41a175c7e9215659842cbef9
# good: [c8241969b44438c9335b59d375b627214bc36483] drm/i915: pass adjusted_mode
to intel_choose_pipe_bpp_dither(), again
git bisect good c8241969b44438c9335b59d375b627214bc36483
# skip: [c5258190c2ae664cdf367417a2a25e5fa4104322] Merge branch 'next' of
git://git.monstr.eu/linux-2.6-microblaze
git bisect skip c5258190c2ae664cdf367417a2a25e5fa4104322
# good: [24ebb37e6515d999bb27f5f8de6ff30faa7479f5] HID: i2c-hid: change I2C name
git bisect good 24ebb37e6515d999bb27f5f8de6ff30faa7479f5
# good: [189e11731aa858597095fbe1e6d243bad26bd96b] x86: pvclock: add note about
rdtsc barriers
git bisect good 189e11731aa858597095fbe1e6d243bad26bd96b
# skip: [75e300c8ba5864367634d946c729d8fd05c1cbc2] Merge tag 'for-v3.8' of
git://git.infradead.org/users/cbou/linux-pstore
git bisect skip 75e300c8ba5864367634d946c729d8fd05c1cbc2
# good: [08ff32352d6ff7083533dc1c25618d42f92ec28e] mlx4: 64-byte CQE/EQE support
git bisect good 08ff32352d6ff7083533dc1c25618d42f92ec28e
# skip: [e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f] Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
git bisect skip e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
# good: [fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5] RDMA/nes: Fix for sending
fpdus in order to hardware
git bisect good fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5
# good: [4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8] Merge remote-tracking branch
'regulator/topic/stub' into regulator-next
git bisect good 4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8
# good: [5028ea04c8a8a67fe73f18f5f34386730c9c1bf2] OMAPDSS: Remove acb and acbi
fields from omap_dss_device
git bisect good 5028ea04c8a8a67fe73f18f5f34386730c9c1bf2
# good: [986836503e49ccf7e84b813715d344964ec93566] Merge branch 'drbd-8.4_ed6'
into for-3.8-drivers-drbd-8.4_ed6
git bisect good 986836503e49ccf7e84b813715d344964ec93566
# bad: [9add1ac3dd256ad12e266f8403daf928be19953f] Merge branch 'drm-next-3.8'
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad 9add1ac3dd256ad12e266f8403daf928be19953f
# good: [1f2285d462c02ef9b82ee9c553a31884c23994f0] drm/nouveau/clk: fix crystal
frequency retrieval on nv25
git bisect good 1f2285d462c02ef9b82ee9c553a31884c23994f0
# bad: [bd3b49f25a3eae2d91432247b7565489120b6bcf] drm: tegra: Add maintainers
entry
git bisect bad bd3b49f25a3eae2d91432247b7565489120b6bcf
# bad: [6c8e4633d351f6f794c8a5c03f19e8d5a25f9639] drm/nouveau/dp: move core
link training calls to common code
git bisect bad 6c8e4633d351f6f794c8a5c03f19e8d5a25f9639
# good: [b6caea505879c4a606cf364442fd1f06f6c40e30] drm/nouveau/bios: implement
BIT 'U' table (and subtable) parsing in core
git bisect good
[PATCH v3] backlight: add new LP8788 backlight driver
TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight driver
and current sinks.
This patch enables LP8788 backlight module.
(Brightness mode)
The brightness is controlled by PWM input or I2C register.
All modes are supported in the driver.
(Platform data)
Configurable data can be defined in the platform side.
name : backlight driver name. (default: "lcd-backlight")
initial_brightness: initial value of backlight brightness
bl_mode : brightness control by PWM or lp8788 register
dim_mode : dimming mode selection
full_scale: full scale current setting
rise_time : brightness ramp up step time
fall_time : brightness ramp down step time
pwm_pol : PWM polarity setting when bl_mode is PWM based
period_ns : platform specific PWM period value. unit is nano.
The default values are set in case no platform data is defined.
Patch v3.
Use generic PWM polarity enum type instead of LP8788 private data type.
: 'lp8788_bl_pwm_polartiy' is replaced with 'pwm_polarity' enum type.
Relocate the register description.
Use prefix, '_SHIFT' for the bit shift arithmetic of the registers.
Fix wrong coding style on comment.
Use capital letters for PWM description except the code.
Use PAGE_SIZE on the sysfs read operation.
Patch v2.
Use generic PWM functions rather than lp8788 platform data function calls.
Add configurable PWM period in the platform data.
Replace module_init() and module_exit() with module_platform_driver().
Patch v1.
Initial patch
Signed-off-by: Milo(Woogyom) Kim
---
drivers/video/backlight/Kconfig |6 +
drivers/video/backlight/Makefile|1 +
drivers/video/backlight/lp8788_bl.c | 333 +++
include/linux/mfd/lp8788.h | 24 +--
4 files changed, 345 insertions(+), 19 deletions(-)
create mode 100644 drivers/video/backlight/lp8788_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index be27b55..db10d01 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -384,6 +384,12 @@ config BACKLIGHT_LP855X
This supports TI LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
backlight driver.
+config BACKLIGHT_LP8788
+ tristate "Backlight driver for TI LP8788 MFD"
+ depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788
+ help
+ This supports TI LP8788 backlight driver.
+
config BACKLIGHT_OT200
tristate "Backlight driver for ot200 visualisation device"
depends on BACKLIGHT_CLASS_DEVICE && CS5535_MFGPT && GPIO_CS5535
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 4606c21..96c4d62 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_BACKLIGHT_LM3630)+= lm3630_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
+obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_MAX8925)+= max8925_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
diff --git a/drivers/video/backlight/lp8788_bl.c
b/drivers/video/backlight/lp8788_bl.c
new file mode 100644
index 000..4bb8b4f
--- /dev/null
+++ b/drivers/video/backlight/lp8788_bl.c
@@ -0,0 +1,333 @@
+/*
+ * TI LP8788 MFD - backlight driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim
+ *
+ * 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
+
+/* Register address */
+#define LP8788_BL_CONFIG 0x96
+#define LP8788_BL_EN BIT(0)
+#define LP8788_BL_PWM_INPUT_EN BIT(5)
+#define LP8788_BL_FULLSCALE_SHIFT 2
+#define LP8788_BL_DIM_MODE_SHIFT 1
+#define LP8788_BL_PWM_POLARITY_SHIFT 6
+
+#define LP8788_BL_BRIGHTNESS 0x97
+
+#define LP8788_BL_RAMP 0x98
+#define LP8788_BL_RAMP_RISE_SHIFT 4
+
+#define MAX_BRIGHTNESS 127
+#define DEFAULT_BL_NAME"lcd-backlight"
+
+struct lp8788_bl_config {
+ enum lp8788_bl_ctrl_mode bl_mode;
+ enum lp8788_bl_dim_mode dim_mode;
+ enum lp8788_bl_full_scale_current full_scale;
+ enum lp8788_bl_ramp_step rise_time;
+ enum lp8788_bl_ramp_step fall_time;
+ enum pwm_polarity pwm_pol;
+};
+
+struct lp8788_bl {
+ struct lp8788 *lp;
+ struct backlight_device *bl_dev;
+ struct lp8788_backlight_platform_data *pdata;
+ enum lp8788_bl_ctrl_mode mode;
+ struct pwm_device *pwm;
+};
+
+struct
[PATCH RESEND 2/3] e1000e: fix runtime power management transitions
This patch removes redundant actions from driver and fixes its interaction
with actions in pci-bus runtime power management code.
It removes pci_save_state() from __e1000_shutdown() for normal adapters,
PCI bus callbacks pci_pm_*() will do all this for us. Now __e1000_shutdown()
switches to D3-state only quad-port adapters, because they needs quirk for
clearing false-positive error from downsteam pci-e port.
pci_save_state() now called after clearing bus-master bit, thus __e1000_resume()
and e1000_io_slot_reset() must set it back after restoring configuration space.
This patch set get_link_status before calling pm_runtime_put() in e1000_open()
to allow e1000_idle() get real link status and schedule first runtime suspend.
This patch also enables wakeup for device if management mode is enabled
(like for WoL) as result pci_prepare_to_sleep() would setup wakeup without
special actions like custom 'enable_wakeup' sign.
Signed-off-by: Konstantin Khlebnikov
Acked-by: Rafael J. Wysocki
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/netdev.c | 78 ++--
1 file changed, 18 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 1799021..2954cc7 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4303,6 +4303,7 @@ static int e1000_open(struct net_device *netdev)
netif_start_queue(netdev);
adapter->idle_check = true;
+ hw->mac.get_link_status = true;
pm_runtime_put(>dev);
/* fire a link status change interrupt to start the watchdog */
@@ -5887,8 +5888,7 @@ release:
return retval;
}
-static int __e1000_shutdown(struct pci_dev *pdev, bool *enable_wake,
- bool runtime)
+static int __e1000_shutdown(struct pci_dev *pdev, bool runtime)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
@@ -5912,10 +5912,6 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake,
}
e1000e_reset_interrupt_capability(adapter);
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
-
status = er32(STATUS);
if (status & E1000_STATUS_LU)
wufc &= ~E1000_WUFC_LNKC;
@@ -5971,13 +5967,6 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake,
ew32(WUFC, 0);
}
- *enable_wake = !!wufc;
-
- /* make sure adapter isn't asleep if manageability is enabled */
- if ((adapter->flags & FLAG_MNG_PT_ENABLED) ||
- (hw->mac.ops.check_mng_mode(hw)))
- *enable_wake = true;
-
if (adapter->hw.phy.type == e1000_phy_igp_3)
e1000e_igp3_phy_powerdown_workaround_ich8lan(>hw);
@@ -5988,26 +5977,6 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake,
pci_clear_master(pdev);
- return 0;
-}
-
-static void e1000_power_off(struct pci_dev *pdev, bool sleep, bool wake)
-{
- if (sleep && wake) {
- pci_prepare_to_sleep(pdev);
- return;
- }
-
- pci_wake_from_d3(pdev, wake);
- pci_set_power_state(pdev, PCI_D3hot);
-}
-
-static void e1000_complete_shutdown(struct pci_dev *pdev, bool sleep,
-bool wake)
-{
- struct net_device *netdev = pci_get_drvdata(pdev);
- struct e1000_adapter *adapter = netdev_priv(netdev);
-
/* The pci-e switch on some quad port adapters will report a
* correctable error when the MAC transitions from D0 to D3. To
* prevent this we need to mask off the correctable errors on the
@@ -6021,12 +5990,13 @@ static void e1000_complete_shutdown(struct pci_dev
*pdev, bool sleep,
pcie_capability_write_word(us_dev, PCI_EXP_DEVCTL,
(devctl & ~PCI_EXP_DEVCTL_CERE));
- e1000_power_off(pdev, sleep, wake);
+ pci_save_state(pdev);
+ pci_prepare_to_sleep(pdev);
pcie_capability_write_word(us_dev, PCI_EXP_DEVCTL, devctl);
- } else {
- e1000_power_off(pdev, sleep, wake);
}
+
+ return 0;
}
#ifdef CONFIG_PCIEASPM
@@ -6084,9 +6054,7 @@ static int __e1000_resume(struct pci_dev *pdev)
if (aspm_disable_flag)
e1000e_disable_aspm(pdev, aspm_disable_flag);
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- pci_save_state(pdev);
+ pci_set_master(pdev);
e1000e_set_interrupt_capability(adapter);
if (netif_running(netdev)) {
@@ -6152,14 +6120,8 @@ static int __e1000_resume(struct pci_dev *pdev)
static int e1000_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
- int retval;
-
[PATCH RESEND 3/3] e1000e: fix accessing to suspended device
This patch fixes some annoying messages like 'Error reading PHY register' and
'Hardware Erorr' and saves several seconds on reboot.
Signed-off-by: Konstantin Khlebnikov
Acked-by: Rafael J. Wysocki
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 13 +
drivers/net/ethernet/intel/e1000e/netdev.c |2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 2c18137..f91a8f3 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "e1000.h"
@@ -2229,7 +2230,19 @@ static int e1000e_get_ts_info(struct net_device *netdev,
return 0;
}
+static int e1000e_ethtool_begin(struct net_device *netdev)
+{
+ return pm_runtime_get_sync(netdev->dev.parent);
+}
+
+static void e1000e_ethtool_complete(struct net_device *netdev)
+{
+ pm_runtime_put_sync(netdev->dev.parent);
+}
+
static const struct ethtool_ops e1000_ethtool_ops = {
+ .begin = e1000e_ethtool_begin,
+ .complete = e1000e_ethtool_complete,
.get_settings = e1000_get_settings,
.set_settings = e1000_set_settings,
.get_drvinfo= e1000_get_drvinfo,
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 2954cc7..948b86ff 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4663,6 +4663,7 @@ static void e1000_phy_read_status(struct e1000_adapter
*adapter)
(adapter->hw.phy.media_type == e1000_media_type_copper)) {
int ret_val;
+ pm_runtime_get_sync(>pdev->dev);
ret_val = e1e_rphy(hw, MII_BMCR, >bmcr);
ret_val |= e1e_rphy(hw, MII_BMSR, >bmsr);
ret_val |= e1e_rphy(hw, MII_ADVERTISE, >advertise);
@@ -4673,6 +4674,7 @@ static void e1000_phy_read_status(struct e1000_adapter
*adapter)
ret_val |= e1e_rphy(hw, MII_ESTATUS, >estatus);
if (ret_val)
e_warn("Error reading PHY register\n");
+ pm_runtime_put_sync(>pdev->dev);
} else {
/* Do not read PHY registers if link is not up
* Set values to typical power-on defaults
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 1/3] e1000e: fix pci-device enable-counter balance
This patch removes redundant and unbalanced pci_disable_device() from
__e1000_shutdown(). pci_clear_master() is enough, device can go into
suspended state with elevated enable_cnt.
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Signed-off-by: Konstantin Khlebnikov
Acked-by: Rafael J. Wysocki
Cc: e1000-de...@lists.sourceforge.net
Cc: Jeff Kirsher
Cc: Bruce Allan
---
drivers/net/ethernet/intel/e1000e/netdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index a177b8b..1799021 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5986,7 +5986,7 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool
*enable_wake,
*/
e1000e_release_hw_control(adapter);
- pci_disable_device(pdev);
+ pci_clear_master(pdev);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 0/3] e1000e: return runtime-pm back to work
here some fixes for e1000e driver from: https://lkml.org/lkml/2013/2/4/185 The rest patches from that patchset already committed. --- Konstantin Khlebnikov (3): e1000e: fix pci-device enable-counter balance e1000e: fix runtime power management transitions e1000e: fix accessing to suspended device drivers/net/ethernet/intel/e1000e/ethtool.c | 13 drivers/net/ethernet/intel/e1000e/netdev.c | 82 +++ 2 files changed, 34 insertions(+), 61 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] slub: correctly bootstrap boot caches
Hello, Christoph. On Sun, Feb 24, 2013 at 12:35:22AM +, Christoph Lameter wrote: > On Sat, 23 Feb 2013, JoonSoo Kim wrote: > > > With flushing, deactivate_slab() occur and it has some overhead to > > deactivate objects. > > If my patch properly fix this situation, it is better to use mine > > which has no overhead. > > Well this occurs during boot and its not that performance critical. Hmm... Yes, this is not performance critical place, but why do we use a sub-optimal solution? And flushing is abstration for complicated logic, so I think that my raw implemntation is better for understanding. But, I have no objection to merge Glauber's one if you think that is better. Thanks. > > -- > 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/
linux-next: Tree for Feb 23
Hi all, Please do not add any work destined for v3.10 to your -next included branches until after Linus has release v3.9-rc1. Changes since 20130222: The metag tree gained a conflict against Linus' tree. The kbuild tree gained a build failure so I used the version from next-20130222. The drm tree still has its build failure for which I applied a patch. The watchdog tree gained a conflict against Linus' tree. The akpm tree gained a conflict against the vfs tree and lost lots of patches that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 216 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9e2d59a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal) Merging fixes/master (d287b87 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arm-current/fixes (7c4e9ce ARM: 7643/1: sched: correct update_sched_clock()) Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. CONFIG_HAS_DMA) Merging powerpc-merge/merge (eda8eeb powerpc/mm: Fix hash computation function) Merging sparc/master (f9fd348 sparc32: refactor smp boot) Merging net/master (62ed839 gianfar: fix compile fail for NET_POLL=y due to struct packing) Merging ipsec/master (85dfb74 af_key: initialize satype in key_notify_policy_flush()) Merging sound-current/for-linus (602b3e0 Merge tag 'asoc-v3.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing a device) Merging wireless/master (dc4a787 brcmfmac: fix missing unlock on error in brcmf_notify_vif_event()) Merging driver-core.current/driver-core-linus (949db15 Linux 3.8-rc5) Merging tty.current/tty-linus (8b5628a Merge tag 'virt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging usb.current/usb-linus (74e1a2a Merge tag 'usb-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging staging.current/staging-linus (8b5628a Merge tag 'virt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging char-misc.current/char-misc-linus (7ed214a Merge tag 'char-misc-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc) Merging input-current/for-linus (171fb58 Input: ALPS - update documentation for recent touchpad driver mods) Merging md-current/for-linus (0ecfa11 md: protect against crash upon fsync on ro array) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied strings are nul-terminated) CONFLICT (content): Merge conflict in drivers/crypto/omap-sham.c CONFLICT (content): Merge conflict in crypto/ctr.c CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/crypto/fsl-sec4.txt Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (084a0ec x86: add
Re: [PATCH 0/8] correct load_balance()
On Thu, Feb 14, 2013 at 02:48:33PM +0900, Joonsoo Kim wrote: > Commit 88b8dac0 makes load_balance() consider other cpus in its group. > But, there are some missing parts for this feature to work properly. > This patchset correct these things and make load_balance() robust. > > Others are related to LBF_ALL_PINNED. This is fallback functionality > when all tasks can't be moved as cpu affinity. But, currently, > if imbalance is not large enough to task's load, we leave LBF_ALL_PINNED > flag and 'redo' is triggered. This is not our intention, so correct it. > > These are based on v3.8-rc7. > > Joonsoo Kim (8): > sched: change position of resched_cpu() in load_balance() > sched: explicitly cpu_idle_type checking in rebalance_domains() > sched: don't consider other cpus in our group in case of NEWLY_IDLE > sched: clean up move_task() and move_one_task() > sched: move up affinity check to mitigate useless redoing overhead > sched: rename load_balance_tmpmask to load_balance_cpu_active > sched: prevent to re-select dst-cpu in load_balance() > sched: reset lb_env when redo in load_balance() > > kernel/sched/core.c |9 +++-- > kernel/sched/fair.c | 107 > +-- > 2 files changed, 67 insertions(+), 49 deletions(-) Hello, Ingo and Peter. Could you review this patch set? Please let me know what I should do for merging this? Thanks. > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI: Add sysfs links from memory device to memblocks
Hi Toshi,
2013/02/23 4:42, Toshi Kani wrote:
> In order to eject a memory device object represented as "PNP0C80:%d"
> in sysfs, its associated memblocks (system/memory/memory%d) need to
> be off-lined. However, there is no user friendly way to correlate
> between a memory device object and its memblocks in sysfs.
>
> This patch creates sysfs links to memblocks under a memory device
> object so that a user can easily checks and manipulates its memblocks
> in sysfs.
>
> For example, when PNP0C80:05 is associated with memory8 and memory9,
> the following two links are created under PNP0C80:05. This allows
> a user to access memory8/9 directly from PNP0C80:05.
>
># ll /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C80:05
>lrwxrwxrwx. memory8 -> ../../../system/memory/memory8
>lrwxrwxrwx. memory9 -> ../../../system/memory/memory9
>
> Signed-off-by: Toshi Kani
> ---
> This patch applies on top of the Rafael's patch below.
> https://patchwork.kernel.org/patch/2153261/
>
> ---
> drivers/acpi/acpi_memhotplug.c | 54
>
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 3b3abbc..d6226b3 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -28,6 +28,7 @@
>*/
>
> #include
> +#include
> #include
>
> #include "internal.h"
> @@ -168,6 +169,53 @@ static int acpi_memory_check_device(struct
> acpi_memory_device *mem_device)
> return 0;
> }
>
> +static void acpi_setup_mem_blk_links(struct acpi_memory_device *mem_device,
> + struct acpi_memory_info *info, bool add_links)
> +{
> + struct memory_block *mem_blk = NULL;
> + struct mem_section *mem_sect;
> + unsigned long start_pfn, end_pfn, pfn;
> + unsigned long section_nr;
> + int ret;
> +
> + start_pfn = PFN_DOWN(info->start_addr);
> + end_pfn = PFN_UP(info->start_addr + info->length-1);
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + section_nr = pfn_to_section_nr(pfn);
> +
> + if (!present_section_nr(section_nr))
> + continue;
> +
> + mem_sect = __nr_to_section(section_nr);
> +
> + /* skip if the same memblock */
> + if (mem_blk)
> + if ((section_nr >= mem_blk->start_section_nr) &&
> + (section_nr <= mem_blk->end_section_nr))
> + continue;
> +
> + mem_blk = find_memory_block_hinted(mem_sect, mem_blk);
NULL pointer check is needed.
Thank,
Yasuaki Ishimatsu
> +
> + if (add_links) {
> + ret = sysfs_create_link_nowarn(
> + _device->device->dev.kobj,
> + _blk->dev.kobj,
> + kobject_name(_blk->dev.kobj));
> + if (ret && ret != -EEXIST)
> + dev_err(_device->device->dev,
> + "Failed to create sysfs link %s\n",
> + kobject_name(_blk->dev.kobj));
> + } else {
> + sysfs_remove_link(_device->device->dev.kobj,
> + kobject_name(_blk->dev.kobj));
> + }
> + }
> +
> + if (mem_blk)
> + kobject_put(_blk->dev.kobj);
> +}
> +
> static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
> {
> int result, num_enabled = 0;
> @@ -207,6 +255,9 @@ static int acpi_memory_enable_device(struct
> acpi_memory_device *mem_device)
> continue;
> }
>
> + /* Create sysfs links to its mem_blk devices */
> + acpi_setup_mem_blk_links(mem_device, info, true);
> +
> if (!result)
> info->enabled = 1;
> /*
> @@ -241,6 +292,9 @@ static int acpi_memory_remove_memory(struct
> acpi_memory_device *mem_device)
> /* The kernel does not use this memory block */
> continue;
>
> + /* Remove sysfs links to its mem_blk devices */
> + acpi_setup_mem_blk_links(mem_device, info, false);
> +
> if (!info->enabled)
> /*
>* The kernel uses this memory block, but it may be not
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] ima: "remove enforce checking duplication" merge fix
Commit "750943a ima: remove enforce checking duplication" combined
the 'in IMA policy' and 'enforcing file integrity' checks. For
the non-file, kernel module verification, a specific check for
'enforcing file integrity' was not added. This patch adds the
check.
Signed-off-by: Mimi Zohar
---
security/integrity/ima/ima_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 5127afc..5b14a09 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -284,7 +284,8 @@ int ima_module_check(struct file *file)
{
if (!file) {
#ifndef CONFIG_MODULE_SIG_FORCE
- if (ima_appraise & IMA_APPRAISE_MODULES)
+ if ((ima_appraise & IMA_APPRAISE_MODULES) &&
+ (ima_appraise & IMA_APPRAISE_ENFORCE))
return -EACCES; /* INTEGRITY_UNKNOWN */
#endif
return 0; /* We rely on module signature checking */
--
1.8.1.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] block: fix part_pack_uuid() build error
Commit "85865c1 ima: add policy support for file system uuid"
introduced a CONFIG_BLOCK dependency. This patch defines a
wrapper called blk_part_pack_uuid(), which returns -EINVAL,
when CONFIG_BLOCK is not defined.
security/integrity/ima/ima_policy.c:538:4: error: implicit declaration
of function 'part_pack_uuid' [-Werror=implicit-function-declaration]
Changelog v2:
- Reference commit number in patch description
Changelog v1:
- rename ima_part_pack_uuid() to blk_part_pack_uuid()
- resolve scripts/checkpatch.pl warnings
Changelog v0:
- fix UUID scripts/Lindent msgs
Reported-by: Randy Dunlap
Reported-by: David Rientjes
Signed-off-by: Mimi Zohar
Acked-by: David Rientjes
Acked-by: Randy Dunlap
Cc: Jens Axboe
---
include/linux/genhd.h | 10 ++
security/integrity/ima/ima_policy.c | 11 ++-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 79b8bba..9f3c275 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -231,6 +231,12 @@ static inline void part_pack_uuid(const u8 *uuid_str, u8
*to)
}
}
+static inline int blk_part_pack_uuid(const u8 *uuid_str, u8 *to)
+{
+ part_pack_uuid(uuid_str, to);
+ return 0;
+}
+
static inline int disk_max_parts(struct gendisk *disk)
{
if (disk->flags & GENHD_FL_EXT_DEVT)
@@ -718,6 +724,10 @@ static inline dev_t blk_lookup_devt(const char *name, int
partno)
return devt;
}
+static inline int blk_part_pack_uuid(const u8 *uuid_str, u8 *to)
+{
+ return -EINVAL;
+}
#endif /* CONFIG_BLOCK */
#endif /* _LINUX_GENHD_H */
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index b27535a..399433a 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -176,7 +176,7 @@ static bool ima_match_rules(struct ima_rule_entry *rule,
&& rule->fsmagic != inode->i_sb->s_magic)
return false;
if ((rule->flags & IMA_FSUUID) &&
- memcmp(rule->fsuuid, inode->i_sb->s_uuid, sizeof(rule->fsuuid)))
+ memcmp(rule->fsuuid, inode->i_sb->s_uuid, sizeof(rule->fsuuid)))
return false;
if ((rule->flags & IMA_UID) && !uid_eq(rule->uid, cred->uid))
return false;
@@ -530,14 +530,15 @@ static int ima_parse_rule(char *rule, struct
ima_rule_entry *entry)
ima_log_string(ab, "fsuuid", args[0].from);
if (memchr_inv(entry->fsuuid, 0x00,
- sizeof(entry->fsuuid))) {
+ sizeof(entry->fsuuid))) {
result = -EINVAL;
break;
}
- part_pack_uuid(args[0].from, entry->fsuuid);
- entry->flags |= IMA_FSUUID;
- result = 0;
+ result = blk_part_pack_uuid(args[0].from,
+ entry->fsuuid);
+ if (!result)
+ entry->flags |= IMA_FSUUID;
break;
case Opt_uid:
ima_log_string(ab, "uid", args[0].from);
--
1.8.1.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] bug fixes for Linus
Both of these patches are bug fixes for patches, which were upstreamed in this open window. The first patch addresses a merge issue. The second patch addresses a CONFIG_BLOCK dependency. thanks, Mimi Mimi Zohar (2): ima: "remove enforce checking duplication" merge fix block: fix part_pack_uuid() build error include/linux/genhd.h | 10 ++ security/integrity/ima/ima_main.c | 3 ++- security/integrity/ima/ima_policy.c | 11 ++- 3 files changed, 18 insertions(+), 6 deletions(-) -- 1.8.1.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv6 4/8] zswap: add to mm/
Hello, Seth. Here comes minor comments. On Wed, Feb 20, 2013 at 04:04:44PM -0600, Seth Jennings wrote: > zswap is a thin compression backend for frontswap. It receives > pages from frontswap and attempts to store them in a compressed > memory pool, resulting in an effective partial memory reclaim and > dramatically reduced swap device I/O. > > Additionally, in most cases, pages can be retrieved from this > compressed store much more quickly than reading from tradition > swap devices resulting in faster performance for many workloads. > > This patch adds the zswap driver to mm/ > > Signed-off-by: Seth Jennings > --- > mm/Kconfig | 15 ++ > mm/Makefile | 1 + > mm/zswap.c | 665 > > 3 files changed, 681 insertions(+) > create mode 100644 mm/zswap.c > > diff --git a/mm/Kconfig b/mm/Kconfig > index 25b8f38..f9f35b7 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -470,3 +470,18 @@ config PGTABLE_MAPPING > > You can check speed with zsmalloc benchmark[1]. > [1] https://github.com/spartacus06/zsmalloc > + > +config ZSWAP > + bool "In-kernel swap page compression" > + depends on FRONTSWAP && CRYPTO > + select CRYPTO_LZO > + select ZSMALLOC > + default n > + help > + Zswap is a backend for the frontswap mechanism in the VMM. > + It receives pages from frontswap and attempts to store them > + in a compressed memory pool, resulting in an effective > + partial memory reclaim. In addition, pages and be retrieved > + from this compressed store much faster than most tradition > + swap devices resulting in reduced I/O and faster performance > + for many workloads. > diff --git a/mm/Makefile b/mm/Makefile > index 0f6ef0a..1e0198f 100644 > --- a/mm/Makefile > +++ b/mm/Makefile > @@ -32,6 +32,7 @@ obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o > obj-$(CONFIG_BOUNCE) += bounce.o > obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o > obj-$(CONFIG_FRONTSWAP) += frontswap.o > +obj-$(CONFIG_ZSWAP) += zswap.o > obj-$(CONFIG_HAS_DMA)+= dmapool.o > obj-$(CONFIG_HUGETLBFS) += hugetlb.o > obj-$(CONFIG_NUMA) += mempolicy.o > diff --git a/mm/zswap.c b/mm/zswap.c > new file mode 100644 > index 000..d3b4943 > --- /dev/null > +++ b/mm/zswap.c > @@ -0,0 +1,665 @@ > +/* > + * zswap.c - zswap driver file > + * > + * zswap is a backend for frontswap that takes pages that are in the > + * process of being swapped out and attempts to compress them and store > + * them in a RAM-based memory pool. This results in a significant I/O > + * reduction on the real swap device and, in the case of a slow swap > + * device, can also improve workload performance. > + * > + * Copyright (C) 2012 Seth Jennings > + * > + * 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. > +*/ > + > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > +* statistics > +**/ > +/* Number of memory pages used by the compressed pool */ > +static atomic_t zswap_pool_pages = ATOMIC_INIT(0); > +/* The number of compressed pages currently stored in zswap */ > +static atomic_t zswap_stored_pages = ATOMIC_INIT(0); > + > +/* > + * The statistics below are not protected from concurrent access for > + * performance reasons so they may not be a 100% accurate. However, > + * they do provide useful information on roughly how many times a > + * certain event is occurring. > +*/ > +static u64 zswap_pool_limit_hit; > +static u64 zswap_reject_compress_poor; > +static u64 zswap_reject_zsmalloc_fail; > +static u64 zswap_reject_kmemcache_fail; > +static u64 zswap_duplicate_entry; > + > +/* > +* tunables > +**/ > +/* Enable/disable zswap (disabled by default, fixed at boot for now) */ > +static bool zswap_enabled; > +module_param_named(enabled, zswap_enabled, bool, 0); > + > +/* Compressor to be used by zswap (fixed at boot for now) */ > +#define ZSWAP_COMPRESSOR_DEFAULT "lzo" > +static char *zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT; > +module_param_named(compressor, zswap_compressor, charp, 0); > + > +/* The maximum percentage of memory that the compressed pool can occupy */ > +static unsigned int zswap_max_pool_percent = 20; >
Re: [PATCH] perf report: Add option to collapse undesired parts of call graph
On Fri, Jan 11, 2013 at 02:27:36AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 07, 2012 at 02:30:44AM -0500, Greg Price escreveu:
> > If an application has an expensive function implemented with a large
> > tree of calls to helper functions, the default call-graph presentation
> > will be dominated by the many different call-chains within that
> > function. By treating the function as a black box, we can collect the
> > call-chains leading into the function and compactly identify what to
> > blame for expensive calls.
>
> Looks like an interesting feature, will review this soon,
Hi Arnaldo,
Have you had a chance to look at this yet?
Cheers,
Greg
> > For example, in this report the callers of garbage_collect() are
> > scattered across the tree:
> > $ perf report -d ruby 2>- | grep -m10 ^[^#]*[a-z]
> > 22.03% ruby [.] gc_mark
> >--- gc_mark
> > |--59.40%-- mark_keyvalue
> > | st_foreach
> > | gc_mark_children
> > | |--99.75%-- rb_gc_mark
> > | | rb_vm_mark
> > | | gc_mark_children
> > | | gc_marks
> > | | |--99.00%-- garbage_collect
> >
> > If we make garbage_collect() a black box, its callers are coalesced:
> > $ perf report --blackbox garbage_collect -d ruby 2>- | grep -m10 ^[^#]*[a-z]
> > 72.92% ruby [.] garbage_collect
> >--- garbage_collect
> >vm_xmalloc
> > |--47.08%-- ruby_xmalloc
> > | st_insert2
> > | rb_hash_aset
> > | |--98.45%-- features_index_add
> > | | rb_provide_feature
> > | | rb_require_safe
> > | | vm_call_method
> >
> > Cc: Peter Zijlstra
> > Cc: Paul Mackerras
> > Cc: Ingo Molnar
> > Cc: Arnaldo Carvalho de Melo
> > Cc: Jiri Olsa
> > Cc: David Ahern
> > Signed-off-by: Greg Price
> > ---
> > tools/perf/builtin-report.c | 17 +++--
> > tools/perf/builtin-top.c| 3 +--
> > tools/perf/util/map.h | 4 +++-
> > tools/perf/util/session.c | 29 ++---
> > tools/perf/util/session.h | 5 +
> > 5 files changed, 42 insertions(+), 16 deletions(-)
> >
> > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> > index a61725d..3bbda35 100644
> > --- a/tools/perf/builtin-report.c
> > +++ b/tools/perf/builtin-report.c
> > @@ -70,7 +70,7 @@ static int perf_report__add_branch_hist_entry(struct
> > perf_tool *tool,
> > if ((sort__has_parent || symbol_conf.use_callchain)
> > && sample->callchain) {
> > err = machine__resolve_callchain(machine, evsel, al->thread,
> > -sample, );
> > +sample, , al);
> > if (err)
> > return err;
> > }
> > @@ -141,7 +141,7 @@ static int perf_evsel__add_hist_entry(struct perf_evsel
> > *evsel,
> >
> > if ((sort__has_parent || symbol_conf.use_callchain) &&
> > sample->callchain) {
> > err = machine__resolve_callchain(machine, evsel, al->thread,
> > -sample, );
> > +sample, , al);
> > if (err)
> > return err;
> > }
> > @@ -607,6 +607,8 @@ int cmd_report(int argc, const char **argv, const char
> > *prefix __maybe_unused)
> > "Default: fractal,0.5,callee", _callchain_opt,
> > callchain_default_opt),
> > OPT_BOOLEAN('G', "inverted", _callchain,
> > "alias for inverted call graph"),
> > + OPT_STRING(0, "blackbox", _pattern, "regex",
> > + "functions to treat as black boxes in call graphs,
> > collapsing callees"),
> > OPT_STRING('d', "dsos", _conf.dso_list_str, "dso[,dso...]",
> >"only consider symbols in these dsos"),
> > OPT_STRING('c', "comms", _conf.comm_list_str, "comm[,comm...]",
> > @@ -687,6 +689,17 @@ int cmd_report(int argc, const char **argv, const char
> > *prefix __maybe_unused)
> >
> > }
> >
> > + if (blackbox_pattern) {
> > + int err = regcomp(_regex, blackbox_pattern,
> > REG_EXTENDED);
> > + if (err) {
> > + char buf[BUFSIZ];
> > + regerror(err, _regex, buf, sizeof(buf));
> > + pr_err("Invalid blackbox regex: %s\n%s",
> > blackbox_pattern, buf);
> > + goto error;
> > + }
> > + have_blackbox = 1;
> > + }
> > +
> > if (strcmp(report.input_name, "-") != 0)
> > setup_browser(true);
> > else {
> > diff --git a/tools/perf/builtin-top.c
Re: [PATCH RFC] pwm: add sysfs interface
On Tue, Feb 19, 2013 at 03:27:41PM +0100, Lars Poeschel wrote:
> +static int pwmchip_export(struct pwm_chip *chip)
> +{
> + int status;
> + struct device *dev;
> +
> + mutex_lock(_lock);
> + dev = device_create(_class, chip->dev, MKDEV(0, 0), chip,
> + "pwmchip%d", chip->base);
> + if (!IS_ERR(dev))
> + status = sysfs_create_group(>kobj, _attr_group);
> + else
> + status = PTR_ERR(dev);
You can't create sysfs files after the device has been exposed to
userspace. Please use the default group functionality for the class,
which fixes this problem.
thanks,
greg k-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: [PATCH RFC] pwm: add sysfs interface
On Tue, Feb 19, 2013 at 03:27:41PM +0100, Lars Poeschel wrote: > From: Lars Poeschel > > This adds a simple sysfs interface to the pwm subsystem. It is > heavily inspired by the gpio sysfs interface. > > /sys/class/pwm > /export ... asks the kernel to export a PWM to userspace > /unexport ... to return a PWM to the kernel > /pwmN ... for each exported PWM #N > /duty_ns ... r/w, length of duty portion > /period_ns ... r/w, length of the pwm period > /polarity ... r/w, normal(0) or inverse(1) polarity >only created if driver supports it > /run ... r/w, write 1 to start and 0 to stop the pwm > /pwmchipN ... for each pwmchip; #N is its first PWM > /base ... (r/o) same as N > /ngpio ... (r/o) number of PWM; numbered N .. MAX_PWMS You have to document this all in the Documentation/ABI/ directory for sysfs files. Please do that in your next version of this patch. thanks, greg k-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: [PATCH] cpufreq: highbank: do not initialize array with a loop
On Sun, Feb 24, 2013 at 10:31 PM, Emilio López wrote:
> As uninitialized array members will be initialized to zero, we can
> avoid using a for loop by setting a value to it.
>
> Signed-off-by: Emilio López
> ---
> Note that I don't own any device using this driver, it has only been compile
> tested, but it shouldn't cause any issues.
>
> drivers/cpufreq/highbank-cpufreq.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/highbank-cpufreq.c
> b/drivers/cpufreq/highbank-cpufreq.c
> index 66e3a71..30d4ae1 100644
> --- a/drivers/cpufreq/highbank-cpufreq.c
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -28,13 +28,9 @@
>
> static int hb_voltage_change(unsigned int freq)
> {
> - int i;
> - u32 msg[HB_CPUFREQ_IPC_LEN];
> + u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE};
>
> - msg[0] = HB_CPUFREQ_CHANGE_NOTE;
> msg[1] = freq / 100;
I think this can also be part of the definition of array, isn't it?
So it would be something like:
u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 100};
> - for (i = 2; i < HB_CPUFREQ_IPC_LEN; i++)
> - msg[i] = 0;
>
> return pl320_ipc_transmit(msg);
> }
> --
> 1.8.2.rc0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the vfs tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/sysfs/bin.c between commit 496ad9aa8ef4 ("new helper: file_inode
(file)") from the vfs tree and commit "hlist: drop the node parameter
from iterators" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/sysfs/bin.c
index 2ce9a5d,f186e27..000
--- a/fs/sysfs/bin.c
+++ b/fs/sysfs/bin.c
@@@ -468,8 -467,8 +467,8 @@@ void unmap_bin_file(struct sysfs_diren
mutex_lock(_bin_lock);
- hlist_for_each_entry(bb, tmp, _sd->s_bin_attr.buffers, list) {
+ hlist_for_each_entry(bb, _sd->s_bin_attr.buffers, list) {
- struct inode *inode = bb->file->f_path.dentry->d_inode;
+ struct inode *inode = file_inode(bb->file);
unmap_mapping_range(inode->i_mapping, 0, 0, 1);
}
pgp9lzxz_dIiS.pgp
Description: PGP signature
[PATCH] SPI: spi-ppc4xx - remove incorrect __exit markup
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: Dmitry Torokhov
---
drivers/spi/spi-ppc4xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-ppc4xx.c b/drivers/spi/spi-ppc4xx.c
index 7a85f22..027b474 100644
--- a/drivers/spi/spi-ppc4xx.c
+++ b/drivers/spi/spi-ppc4xx.c
@@ -560,7 +560,7 @@ free_master:
return ret;
}
-static int __exit spi_ppc4xx_of_remove(struct platform_device *op)
+static int spi_ppc4xx_of_remove(struct platform_device *op)
{
struct spi_master *master = dev_get_drvdata(>dev);
struct ppc4xx_spi *hw = spi_master_get_devdata(master);
@@ -583,7 +583,7 @@ MODULE_DEVICE_TABLE(of, spi_ppc4xx_of_match);
static struct platform_driver spi_ppc4xx_of_driver = {
.probe = spi_ppc4xx_of_probe,
- .remove = __exit_p(spi_ppc4xx_of_remove),
+ .remove = spi_ppc4xx_of_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
--
1.7.11.7
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Regulator: db8500-prcmu - remove incorrect __exit markup
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: Dmitry Torokhov
---
drivers/regulator/db8500-prcmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index 219d162..a53c11a 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -528,7 +528,7 @@ static int db8500_regulator_probe(struct platform_device
*pdev)
return 0;
}
-static int __exit db8500_regulator_remove(struct platform_device *pdev)
+static int db8500_regulator_remove(struct platform_device *pdev)
{
int i;
@@ -553,7 +553,7 @@ static struct platform_driver db8500_regulator_driver = {
.owner = THIS_MODULE,
},
.probe = db8500_regulator_probe,
- .remove = __exit_p(db8500_regulator_remove),
+ .remove = db8500_regulator_remove,
};
static int __init db8500_regulator_init(void)
--
1.7.11.7
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 09/15] sched: add power aware scheduling in fork/exec/wake
On Mon, 2013-02-25 at 10:23 +0800, Alex Shi wrote: > One of problem is the how to decide the criteria of the burst? If we set > 5 waking up/ms is burst, we will lose 4 waking up/ms. > another problem is the burst detection cost, we need tracking a period > history info of the waking up, better on whole group. but that give the > extra cost in burst. > > solution candidates: > https://lkml.org/lkml/2013/1/21/316 > After talk with MikeG, I remove the runnable load avg in performance > load balance. One thing you could try is to make criteria depend on avg_idle. It will slam to 2*migration_cost when a wakeup arrives after an ~extended idle. You could perhaps extend it to cover new task wakeup as well, and use that transition to invalidate history, switch to instantaneous until fresh history can accumulate. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Media: remove incorrect __exit markups
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: Dmitry Torokhov
---
drivers/media/i2c/adp1653.c | 4 ++--
drivers/media/i2c/smiapp/smiapp-core.c | 4 ++--
drivers/media/platform/soc_camera/omap1_camera.c | 4 ++--
drivers/media/radio/radio-si4713.c | 4 ++--
drivers/media/rc/ir-rx51.c | 4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index df16380..ef75abe 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -447,7 +447,7 @@ free_and_quit:
return ret;
}
-static int __exit adp1653_remove(struct i2c_client *client)
+static int adp1653_remove(struct i2c_client *client)
{
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct adp1653_flash *flash = to_adp1653_flash(subdev);
@@ -476,7 +476,7 @@ static struct i2c_driver adp1653_i2c_driver = {
.pm = _pm_ops,
},
.probe = adp1653_probe,
- .remove = __exit_p(adp1653_remove),
+ .remove = adp1653_remove,
.id_table = adp1653_id_table,
};
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 83c7ed7..cae4f46 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2833,7 +2833,7 @@ static int smiapp_probe(struct i2c_client *client,
sensor->src->pads, 0);
}
-static int __exit smiapp_remove(struct i2c_client *client)
+static int smiapp_remove(struct i2c_client *client)
{
struct v4l2_subdev *subdev = i2c_get_clientdata(client);
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
@@ -2881,7 +2881,7 @@ static struct i2c_driver smiapp_i2c_driver = {
.pm = _pm_ops,
},
.probe = smiapp_probe,
- .remove = __exit_p(smiapp_remove),
+ .remove = smiapp_remove,
.id_table = smiapp_id_table,
};
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c
b/drivers/media/platform/soc_camera/omap1_camera.c
index 39a77f0..5f548ac 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1677,7 +1677,7 @@ exit:
return err;
}
-static int __exit omap1_cam_remove(struct platform_device *pdev)
+static int omap1_cam_remove(struct platform_device *pdev)
{
struct soc_camera_host *soc_host = to_soc_camera_host(>dev);
struct omap1_cam_dev *pcdev = container_of(soc_host,
@@ -1709,7 +1709,7 @@ static struct platform_driver omap1_cam_driver = {
.name = DRIVER_NAME,
},
.probe = omap1_cam_probe,
- .remove = __exit_p(omap1_cam_remove),
+ .remove = omap1_cam_remove,
};
module_platform_driver(omap1_cam_driver);
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index 1507c9d..8ae8442d 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -328,7 +328,7 @@ exit:
}
/* radio_si4713_pdriver_remove - remove the device */
-static int __exit radio_si4713_pdriver_remove(struct platform_device *pdev)
+static int radio_si4713_pdriver_remove(struct platform_device *pdev)
{
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
struct radio_si4713_device *rsdev = container_of(v4l2_dev,
@@ -350,7 +350,7 @@ static struct platform_driver radio_si4713_pdriver = {
.name = "radio-si4713",
},
.probe = radio_si4713_pdriver_probe,
- .remove = __exit_p(radio_si4713_pdriver_remove),
+ .remove = radio_si4713_pdriver_remove,
};
module_platform_driver(radio_si4713_pdriver);
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8ead492..31b955b 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -464,14 +464,14 @@ static int lirc_rx51_probe(struct platform_device *dev)
return 0;
}
-static int __exit lirc_rx51_remove(struct platform_device *dev)
+static int lirc_rx51_remove(struct platform_device *dev)
{
return lirc_unregister_driver(lirc_rx51_driver.minor);
}
struct platform_driver lirc_rx51_platform_driver = {
.probe = lirc_rx51_probe,
- .remove = __exit_p(lirc_rx51_remove),
+ .remove = lirc_rx51_remove,
.suspend= lirc_rx51_suspend,
.resume = lirc_rx51_resume,
.driver = {
--
1.7.11.7
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: [PATCH] acerhdf: Fix fan activation with new thermal governor
On Sun, 2013-02-24 at 15:34 +0100, Borislav Petkov wrote:
> On Sun, Feb 24, 2013 at 12:42:55PM +0100, Peter Feuerer wrote:
> > Please test my last patch with the 4 trip points ;) - even if you
> > don't really like it, it is working great! - And to be honest, I still
> > prefer this solution!
>
> Ok, I remember everything now - had to add some debug output to see what
> the stepwise governor hands us down.
>
> Btw, Zhang, is there any way we can tell the upper layer to not
> poll trips and temps for this driver? I mean, ->get_trip_type and
> ->get_trip_temp get called every polling interval and the data it
> receives back each time is static and don't change so polling the same
> values each time for this driver doesn't make any sense.
>
the reason we keep on calling it because the thermal zone trip point
info may be changed at runtime.
> Can we pass trip points and temperature levels upon registration time
> instead?
>
no, but we can cache it in the thermal layer, and do update when
necessary.
> @Peter: I took your patch, removed one trip point and added comments so
> that we don't forget why we do what we do. Please take a look - it works
> fine here.
>
> --
> From 1827ed71ff1b73a83d81d21f9dd167fe8e0d4198 Mon Sep 17 00:00:00 2001
> From: Peter Feuerer
> Date: Sun, 24 Feb 2013 15:04:17 +0100
> Subject: [PATCH] acerhdf: Fix fan activation with new thermal governor
>
> After recent thermal subsys rework, acerhdf couldn't cope with the
> stepwise governor since it had only one trip point and this didn't fit
> into the stepwise scheme.
why? I do not think the stepwise scheme will break it. If it happens, we
should fix stepwise governor instead.
> Therefore, add two more trip points - an
> active one where we turn on the fan, and a critical one.
>
I think you add a passive trip point and a critical one here.
> However, we still need to flatten out peaks of turning the fan on
> and off in acerhdf_set_cur_state because stepwise looks also at the
> direction the temperature is going and applies respective policy. This
> results in short bursts of interchanging on and off which are really
> annoying.
>
> So, we keep the old logic where we turn on the fan only if we exceed
> 'fanon' temperature and leave it on until we go under 'fanoff'. Document
> this behavior while at it.
>
has anybody checked if the patch at lkml.org/lkml/2012/12/30/47 fixes
the problem, without any other patch?
thanks,
rui
> Signed-off-by: Peter Feuerer
> Signed-off-by: Borislav Petkov
> ---
> drivers/platform/x86/acerhdf.c | 30 ++
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
> index f94467c05225..b06cdb099e6a 100644
> --- a/drivers/platform/x86/acerhdf.c
> +++ b/drivers/platform/x86/acerhdf.c
> @@ -400,7 +400,13 @@ static int acerhdf_get_trip_type(struct
> thermal_zone_device *thermal, int trip,
>enum thermal_trip_type *type)
> {
> if (trip == 0)
> + *type = THERMAL_TRIP_PASSIVE;
> + else if (trip == 1)
> *type = THERMAL_TRIP_ACTIVE;
> + else if (trip == 2)
> + *type = THERMAL_TRIP_CRITICAL;
> + else
> + WARN_ONCE(1, "%s: Funny trip point %d\n", KBUILD_MODNAME, trip);
>
> return 0;
> }
> @@ -409,7 +415,13 @@ static int acerhdf_get_trip_temp(struct
> thermal_zone_device *thermal, int trip,
>unsigned long *temp)
> {
> if (trip == 0)
> + *temp = 0;
> + else if (trip == 1)
> *temp = fanon;
> + else if (trip == 2)
> + *temp = ACERHDF_TEMP_CRIT;
> + else
> + WARN_ONCE(1, "%s: Funny trip point %d\n", KBUILD_MODNAME, trip);
>
> return 0;
> }
> @@ -459,7 +471,9 @@ static int acerhdf_get_cur_state(struct
> thermal_cooling_device *cdev,
> return 0;
> }
>
> -/* change current fan state - is overwritten when running in kernel mode */
> +/*
> + * Change current fan state - is overwritten when running in kernel mode
> + */
> static int acerhdf_set_cur_state(struct thermal_cooling_device *cdev,
>unsigned long state)
> {
> @@ -480,15 +494,23 @@ static int acerhdf_set_cur_state(struct
> thermal_cooling_device *cdev,
> goto err_out;
> }
>
> + /*
> + * We need to flatten out the on-off peaks we get from the stepwise
> + * governor into the wider span between fanoff and fanon because
> + * otherwise we turn on/off the fan in short bursts, everytime the
> + * thermal zone decides to throttle and this is annoying.
> + */
> if (state == 0) {
> /* turn fan off only if below fanoff temperature */
> if ((cur_state == ACERHDF_FAN_AUTO) &&
> - (cur_temp < fanoff))
> + (cur_temp <= fanoff))
> acerhdf_change_fanstate(ACERHDF_FAN_OFF);
>
Re: [PATCH] acerhdf: Fix fan activation with new thermal governor
On Sun, 2013-02-24 at 13:09 +0100, Borislav Petkov wrote: > On Sun, Feb 24, 2013 at 12:42:55PM +0100, Peter Feuerer wrote: > > Hi Boris, > > > > thanks for your best wishes in the last mail, I'm feeling little better now. > > Nice :) > > > Please test my last patch with the 4 trip points ;) - even if you > > don't really like it, it is working great! - And to be honest, I still > > prefer this solution! > > Right, but 4 trip points for this simple driver is a bit of a overkill, > don't you think? If we want to be really accurate, we'd only need two, > think of three temperature intervals here: > > 0 - temp <= fanon > 1 - fanon =< temp < crit > 2 - temp >= crit > > I need to go stare at it a bit more. > actually, I still do not understand how the two active trip points mechanism work. say, act1 = 50C, act2=60C when the temperature goes up to 50C, will the fan be turned on or not? thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scripts/package/Makefile: compare objtree with srctree instead of test KBUILD_OUTPUT
KBUILD_OUTPUT is always empty here, so it is useless to test it. But while use O=.., objtree and srctree will be different. I compare them instead. Signed-off-by: Bin Wang --- scripts/package/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/package/Makefile b/scripts/package/Makefile index 87bf080..d7b3285 100644 --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -36,7 +36,7 @@ $(objtree)/kernel.spec: $(MKSPEC) $(srctree)/Makefile $(CONFIG_SHELL) $(MKSPEC) > $@ rpm-pkg rpm: $(objtree)/kernel.spec FORCE - @if test -n "$(KBUILD_OUTPUT)"; then \ + @if test "$(objtree)" != "$(srctree)"; then \ echo "Building source + binary RPM is not possible outside the"; \ echo "kernel source tree. Don't set KBUILD_OUTPUT, or use the"; \ echo "binrpm-pkg target instead."; \ -- 1.8.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] scripts/package/Makefile: compare objtree with srctree instead of test KBUILD_OUTPUT
KBUILD_OUTPUT is always empty here, so it is useless to test it. But while use O=.., objtree and srctree will be different. I compare them instead. --- scripts/package/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/package/Makefile b/scripts/package/Makefile index 87bf080..d7b3285 100644 --- a/scripts/package/Makefile +++ b/scripts/package/Makefile @@ -36,7 +36,7 @@ $(objtree)/kernel.spec: $(MKSPEC) $(srctree)/Makefile $(CONFIG_SHELL) $(MKSPEC) > $@ rpm-pkg rpm: $(objtree)/kernel.spec FORCE - @if test -n "$(KBUILD_OUTPUT)"; then \ + @if test "$(objtree)" != "$(srctree)"; then \ echo "Building source + binary RPM is not possible outside the"; \ echo "kernel source tree. Don't set KBUILD_OUTPUT, or use the"; \ echo "binrpm-pkg target instead."; \ -- 1.8.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] acerhdf: Fix fan activation with new thermal governor
On Sun, 2013-02-24 at 12:42 +0100, Peter Feuerer wrote: > Hi Boris, > > thanks for your best wishes in the last mail, I'm feeling little better now. > > Borislav Petkov writes: > > > On Sat, Feb 23, 2013 at 08:20:10PM +0100, Borislav Petkov wrote: > >> From: Borislav Petkov > >> > >> The new step_wise thermal governor wasn't able to handle the one-trip > >> point design of acerhdf where we want to turn off the fan if we go under > >> the 'fanoff' temperature and to turn it on only after exceeding the > >> 'fanon' temperature. > >> > >> Do that by looking at the current fan state and return the temperature > >> accordingly. > >> > >> Suggested-by: Zhang Rui > >> Cc: Peter Feuerer > >> Cc: Andreas Mohr > >> Cc: Alexander Lam > >> Signed-off-by: Borislav Petkov > > > > Ok, ignore this one for now - the suspend/resume path doesn't pan out > > somehow, need to do some more handholding here. > > Please test my last patch with the 4 trip points ;) - even if you don't > really like it, it is working great! - And to be honest, I still prefer this > solution! > well, the 4 trip points do not make sense, at least the passive trip point is a no op as we have no passive cooling device binded with it. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ima: "remove enforce checking duplication" merge fix
On Sun, 24 Feb 2013, Mimi Zohar wrote: > Commit "750943a ima: remove enforce checking duplication" combined > the 'in IMA policy' and 'enforcing file integrity' checks. For > the non-file, kernel module verification, a specific check for > 'enforcing file integrity' was not added. This patch adds the > check. > Where did you post 2/2 ? -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block: fix part_pack_uuid() build error
On Sun, 24 Feb 2013, Mimi Zohar wrote: > Fix a build error when CONFIG_BLOCK is not enabled, by defining > a wrapper called blk_part_pack_uuid(). The wrapper returns > -EINVAL, when CONFIG_BLOCK is not defined. Please indicate which tree your patches are intended for, also noting specific regression details if any (e.g. which commit introduced it). -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] acerhdf: Fix fan activation with new thermal governor
On Sun, 2013-02-24 at 12:28 +0100, Borislav Petkov wrote: > On Sat, Feb 23, 2013 at 08:20:10PM +0100, Borislav Petkov wrote: > > From: Borislav Petkov > > > > The new step_wise thermal governor wasn't able to handle the one-trip > > point design of acerhdf where we want to turn off the fan if we go under > > the 'fanoff' temperature and to turn it on only after exceeding the > > 'fanon' temperature. > > > > Do that by looking at the current fan state and return the temperature > > accordingly. > > > > Suggested-by: Zhang Rui > > Cc: Peter Feuerer > > Cc: Andreas Mohr > > Cc: Alexander Lam > > Signed-off-by: Borislav Petkov > > Ok, ignore this one for now - the suspend/resume path doesn't pan out > somehow, need to do some more handholding here. > hmm, this reminds me that we should do a thermal_zone_device_update() for each registered thermal zone when resuming from system suspend. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 fix PATCH 2/2] acpi, movablemem_map: Make whatever nodes the kernel resides in un-hotpluggable.
On 02/24/2013 03:26 AM, Rob Landley wrote: On 02/20/2013 05:00:56 AM, Tang Chen wrote: There could be several memory ranges in the node in which the kernel resides. When using movablemem_map=acpi, we may skip one range that have memory reserved by memblock. But if it is too small, then the kernel will fail to boot. So, make the whole node which the kernel resides in un-hotpluggable. Then the kernel has enough memory to use. Reported-by: H Peter Anvin Signed-off-by: Tang Chen Docs part Acked-by: Rob Landley (with minor non-blocking snark). Hi Rob, Thanks for ack. :) @@ -1673,6 +1675,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. satisfied. So the administrator should be careful that the amount of movablemem_map areas are not too large. Otherwise kernel won't have enough memory to start. + NOTE: We don't stop users specifying the node the + kernel resides in as hotpluggable so that this + option can be used as a workaround of firmware + bugs. I usually see workaround "for", not "of". And your whitespace is inconsistent on that last line. And I'm now kind of curious what such a workaround would accomplish, but I'm suspect it's obvious to people who wind up needing it. SFAIK, this is more useful when debugging. MTD_Partition= [MTD] Format: ,,, diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c index b8028b2..79836d0 100644 --- a/arch/x86/mm/srat.c +++ b/arch/x86/mm/srat.c @@ -166,6 +166,9 @@ handle_movablemem(int node, u64 start, u64 end, u32 hotpluggable) * for other purposes, such as for kernel image. We cannot prevent * kernel from using these memory, so we need to exclude these memory * even if it is hotpluggable. + * Furthermore, to ensure the kernel has enough memory to boot, we make + * all the memory on the node which the kernel resides in + * un-hotpluggable. */ Can you hot-unplug half a node? (Do you have a choice with the granularity here?) No, we cannot hot-plug/hot-unplug half a node. But we can offline some of the memory, not all the memory on one node. :) Here, hotplug means finally you will physically remove the hardware device from the system while the system is running. So there is no such thing like hotplug half a node, I think. :) 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: [PATCHv5 7/8] zswap: add swap page writeback support
Hi Seth,
On Wed, Feb 13, 2013 at 12:38:50PM -0600, Seth Jennings wrote:
> This patch adds support for evicting swap pages that are currently
> compressed in zswap to the swap device. This functionality is very
> important and make zswap a true cache in that, once the cache is full
> or can't grow due to memory pressure, the oldest pages can be moved
> out of zswap to the swap device so newer pages can be compressed and
> stored in zswap.
>
> This introduces a good amount of new code to guarantee coherency.
> Most notably, and LRU list is added to the zswap_tree structure,
> and refcounts are added to each entry to ensure that one code path
> doesn't free then entry while another code path is operating on it.
>
> Signed-off-by: Seth Jennings
In this time, I didn't review the code in detail yet but it seems
resolve of all review point in previous interation. Thanks!
But unfortunately, I couldn't find anything related to tmppage handling
so I'd like to ask.
The reason of tmppage is temporal buffer to keep compressed data during
writeback to avoid unnecessary compressing again when we retry?
Is it really critical about performance? What's the wrong if we remove
tmppage handling?
zswap_frontswap_store
retry:
get_cpu_var(zswap_dstmem);
zswap_com_op(COMPRESS)
zs_malloc()
if (!handle) {
put_cpu_var(zswap_dstmem);
if (retry > MAX_RETRY)
goto error_nomem;
zswap_flush_entries()
goto retry;
}
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[rebased-again][PATCH 0/4] acpi: do some changes for numa info
just do some trivial changes to make acpi's numa info operation more cleaner. ChangeLog v3->v4 1.fix srat_disabled function spotted by Yasuaki Ishimatsu v2->v3 1. rebase on linux-next 2. bring back lost Makefile changes spotted by David Rientjes spotted by Yasuaki Ishimatsu v1->v2 1. fix-up several coding issues 2. finish srat.c change spotted by David Rientjes Li Guang (4) acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c numa: avoid export acpi_numa variable acpi: add clock_domain field to acpi_srat_cpu_affinity remove include asm/acpi.h in process_driver.c arch/x86/include/asm/acpi.h | 2 +- arch/x86/kernel/acpi/Makefile | 1 + arch/x86/kernel/acpi/srat.c | 299 + arch/x86/mm/Makefile| 1 - arch/x86/mm/numa.c | 2 +- arch/x86/mm/srat.c | 278 - arch/x86/xen/enlighten.c| 2 +- drivers/acpi/processor_driver.c | 1 - include/acpi/actbl1.h | 2 +- 9 files changed, 296 insertions(+), 292 deletions(-) create mode 100644 arch/x86/kernel/acpi/srat.c delete mode 100644 arch/x86/mm/srat.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[rebased-again][PATCH 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
srat table should present only on acpi domain,
seems mm/ is not the right place for it.
Reviewed-by: Yasuaki Ishimatsu
Signed-off-by: liguang
---
arch/x86/kernel/acpi/Makefile |1 +
arch/x86/kernel/acpi/srat.c | 284 +
arch/x86/mm/Makefile |1 -
arch/x86/mm/srat.c| 284 -
4 files changed, 285 insertions(+), 285 deletions(-)
create mode 100644 arch/x86/kernel/acpi/srat.c
delete mode 100644 arch/x86/mm/srat.c
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 163b225..98cea92 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_ACPI) += boot.o
obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup_$(BITS).o
+obj-$(CONFIG_ACPI_NUMA)+= srat.o
ifneq ($(CONFIG_ACPI_PROCESSOR),)
obj-y += cstate.o
diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
new file mode 100644
index 000..459c391
--- /dev/null
+++ b/arch/x86/kernel/acpi/srat.c
@@ -0,0 +1,284 @@
+/*
+ * ACPI 3.0 based NUMA setup
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int acpi_numa __initdata;
+
+static __init int setup_node(int pxm)
+{
+ return acpi_map_pxm_to_node(pxm);
+}
+
+static __init void bad_srat(void)
+{
+ printk(KERN_ERR "SRAT: SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
+
+/* Callback for SLIT parsing */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++)
+ for (j = 0; j < slit->locality_count; j++)
+ numa_set_distance(pxm_to_node(i), pxm_to_node(j),
+ slit->entry[slit->locality_count * i + j]);
+}
+
+/* Callback for Proximity Domain -> x2APIC mapping */
+void __init
+acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
+{
+ int pxm, node;
+ int apic_id;
+
+ if (srat_disabled())
+ return;
+ if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
+ bad_srat();
+ return;
+ }
+ if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+ return;
+ pxm = pa->proximity_domain;
+ apic_id = pa->apic_id;
+ if (!apic->apic_id_valid(apic_id)) {
+ printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
+pxm, apic_id);
+ return;
+ }
+ node = setup_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u
skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
+ set_apicid_to_node(apic_id, node);
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
+ pxm, apic_id, node);
+}
+
+/* Callback for Proximity Domain -> LAPIC mapping */
+void __init
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
+{
+ int pxm, node;
+ int apic_id;
+
+ if (srat_disabled())
+ return;
+ if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
+ bad_srat();
+ return;
+ }
+ if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+ return;
+ pxm = pa->proximity_domain_lo;
+ if (acpi_srat_revision >= 2)
+ pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
+ node = setup_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (get_uv_system_type() >= UV_X2APIC)
+ apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
+ else
+ apic_id = pa->apic_id;
+
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u
skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
+
+ set_apicid_to_node(apic_id, node);
+ node_set(node, numa_nodes_parsed);
+
Re: [rebased][PATCH 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
在 2013-02-22五的 12:57 -0800，David Rientjes写道：
> On Fri, 22 Feb 2013, liguang wrote:
>
> > srat table should present only on acpi domain,
> > seems mm/ is not the right place for it.
> >
> > Reviewed-by: Yasuaki Ishimatsu
> > Signed-off-by: liguang
>
> This is not rebased, it does not have 4819e14ff31e ("acpi, movablemem_map:
> Set numa_nodes_hotplug nodemask when using SRAT info.") but does have
> f7c24b7e1c41 ("acpi, memory-hotplug: support getting hotplug info from
> SRAT"), so I don't know how you're generating these patches.
>
> You're also not sending this to any maintainer who would merge it, so
> please run scripts/get_maintainer.pl on it.
my linux-next repo will not always be latest for inconvenient network
service.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 06/15] sched: log the cpu utilization at rq
On 02/20/2013 11:22 PM, Peter Zijlstra wrote: > On Wed, 2013-02-20 at 22:33 +0800, Alex Shi wrote: >>> You don't actually compute the rq utilization, you only compute the >>> utilization as per the fair class, so if there's significant RT >> activity >>> it'll think the cpu is under-utilized, whihc I think will result in >> the >>> wrong thing. >> >> yes. A bit complicit to resolve this. Any suggestions on this, guys? > > Shouldn't be too hard seeing as we already track cpu utilization for ! > fair usage; see rq::rt_avg and scale_rt_power. > added them in periodic balancing, thanks! -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 09/15] sched: add power aware scheduling in fork/exec/wake
On 02/25/2013 01:51 AM, Preeti U Murthy wrote: > Hi, > > On 02/24/2013 02:57 PM, Alex Shi wrote: >> On 02/22/2013 04:54 PM, Peter Zijlstra wrote: >>> On Thu, 2013-02-21 at 22:40 +0800, Alex Shi wrote: > The name is a secondary issue, first you need to explain why you think > nr_running is a useful metric at all. > > You can have a high nr_running and a low utilization (a burst of > wakeups, each waking a process that'll instantly go to sleep again), or > low nr_running and high utilization (a single process cpu bound > process). It is true in periodic balance. But in fork/exec/waking timing, the incoming processes usually need to do something before sleep again. >>> >>> You'd be surprised, there's a fair number of workloads that have >>> negligible runtime on wakeup. >> >> will appreciate if you like introduce some workload. :) >> BTW, do you has some idea to handle them? >> Actually, if tasks is just like transitory, it is also hard to catch >> them in balance, like 'cyclitest -t 100' on my 4 LCPU laptop, vmstat >> just can catch 1 or 2 tasks very second. >>> I use nr_running to measure how the group busy, due to 3 reasons: 1, the current performance policy doesn't use utilization too. >>> >>> We were planning to fix that now that its available. >> >> I had tried, but failed on aim9 benchmark. As a result I give up to use >> utilization in performance balance. >> Some trying and talking in the thread. >> https://lkml.org/lkml/2013/1/6/96 >> https://lkml.org/lkml/2013/1/22/662 >>> 2, the power policy don't care load weight. >>> >>> Then its broken, it should very much still care about weight. >> >> Here power policy just use nr_running as the criteria to check if it's >> eligible for power aware balance. when do balancing the load weight is >> still the key judgment. >> >>> 3, I tested some benchmarks, kbuild/tbench/hackbench/aim7 etc, some benchmark results looks clear bad when use utilization. if my memory right, the hackbench/aim7 both looks bad. I had tried many ways to engage utilization into this balance, like use utilization only, or use utilization * nr_running etc. but still can not find a way to recover the lose. But with nr_running, the performance seems doesn't lose much with power policy. >>> >>> You're failing to explain why utilization performs bad and you don't >>> explain why nr_running is better. That things work simply isn't good >> >> Um, let me try to explain again, The utilisation need much time to >> accumulate itself(345ms). Whenever with or without load weight, many >> bursting tasks just give a minimum weight to the carrier CPU at the >> first few ms. So, it is too easy to do a incorrect distribution here and >> need migration on later periodic balancing. > > Why can't this be attacked in *either* of the following ways: > > 1.Attack this problem at the source, by ensuring that the utilisation is > accumulated faster by making the update window smaller. It is a double blade sword. Small period will response quickly, but loses lots of history record. A extreme short period is just same as current instant utilization. > > 2.Balance on nr->running only if you detect burst wakeups. > Alex, you had released a patch earlier which could detect this right? Yes, the patch is here: https://lkml.org/lkml/2013/1/11/45 One of problem is the how to decide the criteria of the burst? If we set 5 waking up/ms is burst, we will lose 4 waking up/ms. another problem is the burst detection cost, we need tracking a period history info of the waking up, better on whole group. but that give the extra cost in burst. solution candidates: https://lkml.org/lkml/2013/1/21/316 After talk with MikeG, I remove the runnable load avg in performance load balance. Using nr_running as instant utilization may narrow the power policy suitable situation. -- consider for power consumption, a light but cpu intensive task will cost much more power than a heavy load but run occasionally task. And it fit all my benchmarks aim7/hackbench/kbuild/cyclitest/netperf etc. > Instead of balancing on nr_running all the time, why not balance on it > only if burst wakeups are detected. By doing so you ensure that > nr_running as a metric for load balancing is used when it is right to do > so and the reason to use it also gets well documented. > > Regards > Preeti U Murthy > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] vfio powerpc: enabled on powernv platform
On Mon, Feb 11, 2013 at 03:16:43PM -0700, Alex Williamson wrote: > > Why do these all return long (vs int)? Is this a POWER-ism? On ppc64 the compiler tends to generate slightly shorter code with longs than with ints. The reason is that with ints the compiler has to put in "extend sign word" instructions to convert 64-bit values from arithmetic instructions to values in the 32-bit range. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib: devres: Fix misplaced #endif
A misplaced #endif causes link errors related to pcim_*() functions. This is because pcim_*() functions are related to CONFIG_PCI option, however these are not related to CONFIG_HAS_IOPORT option. Therefore, when CONFIG_PCI is enabled and CONFIG_HAS_IOPORT is not enabled, it makes link errors related to pcim_*() functions as below: drivers/ata/libata-sff.c:3233: undefined reference to `pcim_iomap_regions' drivers/ata/libata-sff.c:3238: undefined reference to `pcim_iomap_table' drivers/built-in.o: In function `ata_pci_sff_init_host': drivers/ata/libata-sff.c:2318: undefined reference to `pcim_iomap_regions' drivers/ata/libata-sff.c:2329: undefined reference to `pcim_iomap_table Signed-off-by: Jingoo Han --- Changes since v1: - Added more detailed commit message lib/devres.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/devres.c b/lib/devres.c index 88ad759..8235331 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -227,6 +227,7 @@ void devm_ioport_unmap(struct device *dev, void __iomem *addr) devm_ioport_map_match, (void *)addr)); } EXPORT_SYMBOL(devm_ioport_unmap); +#endif /* CONFIG_HAS_IOPORT */ #ifdef CONFIG_PCI /* @@ -432,4 +433,3 @@ void pcim_iounmap_regions(struct pci_dev *pdev, int mask) } EXPORT_SYMBOL(pcim_iounmap_regions); #endif /* CONFIG_PCI */ -#endif /* CONFIG_HAS_IOPORT */ -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib: devres: Fix misplaced #endif
On Saturday, February 23, 2013 6:44 AM, Andrew Morton wrote: > > On Fri, 22 Feb 2013 14:39:40 +0900 > Jingoo Han wrote: > > > A misplaced #endif causes link errors related to pcim_*() functions. > > > > --- a/lib/devres.c > > +++ b/lib/devres.c > > @@ -227,6 +227,7 @@ void devm_ioport_unmap(struct device *dev, void __iomem > > *addr) > >devm_ioport_map_match, (void *)addr)); > > } > > EXPORT_SYMBOL(devm_ioport_unmap); > > +#endif /* CONFIG_HAS_IOPORT */ > > > > #ifdef CONFIG_PCI > > /* > > @@ -432,4 +433,3 @@ void pcim_iounmap_regions(struct pci_dev *pdev, int > > mask) > > } > > EXPORT_SYMBOL(pcim_iounmap_regions); > > #endif /* CONFIG_PCI */ > > -#endif /* CONFIG_HAS_IOPORT */ > > More details needed, please. This code is pretty old and it's > surprising that errors are popping up now. OK, I will add more detailed commit message. Thank you. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: remove MIGRATE_ISOLATE check in hotpath
Hi Andrew, Sorry for late reply and I totally missed it. :( On Tue, Jan 15, 2013 at 03:36:25PM -0800, Andrew Morton wrote: > On Tue, 15 Jan 2013 09:16:46 +0900 > Minchan Kim wrote: > > > Now mm several functions test MIGRATE_ISOLATE and some of those > > are hotpath but MIGRATE_ISOLATE is used only if we enable > > CONFIG_MEMORY_ISOLATION(ie, CMA, memory-hotplug and memory-failure) > > which are not common config option. So let's not add unnecessary > > overhead and code when we don't enable CONFIG_MEMORY_ISOLATION. > > ugh. Better than nothing, I guess. > > There remain call sites which do open-coded > > get_pageblock_migratetype(page) != MIGRATE_ISOLATE > > (undo_isolate_page_range() is one). Wanna clean these up as well? Oops, Sure. > > > > > ... > > > > @@ -683,7 +683,7 @@ static void free_one_page(struct zone *zone, struct > > page *page, int order, > > zone->pages_scanned = 0; > > > > __free_one_page(page, zone, order, migratetype); > > - if (unlikely(migratetype != MIGRATE_ISOLATE)) > > + if (unlikely(!is_migrate_isolate(migratetype))) > > __mod_zone_freepage_state(zone, 1 << order, migratetype); > > spin_unlock(>lock); > > } > > The code both before and after this patch is assuming that the > migratetype in free_one_page is likely to be MIGRATE_ISOLATE. Seems > wrong. If CONFIG_MEMORY_ISOLATION=n this ends up doing > if(unlikely(true)) which is harmless-but-amusing. >From the beginning of [2139cbe627, cma: fix counting of isolated pages], it was wrong. We can't make sure it's very likely. If it is called by order-0 page free path, it is but if it is called by high order page free path, we can't. So I think it would be better to remove unlikley. They are trivial patch so send it now or send it after you release first mmotm after finishing merge window? Andrew, Which is better? > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty vt: fix character insertion overflow
Commit 81732c3b2f (tty vt: Fix line garbage in virtual console on
command line edition) broke insert_char() in multiple ways. Then
commit b1a925f44a (tty vt: Fix a regression in command line edition)
partially fixed it. However, the buffer being moved is still too large
and overflowing beyond the end of the current line, corrupting existing
characters on the next line.
Example test case:
echo -e "abc\nde\x1b[A\x1b[4h \x1b[4l\x1b[B"
Expected result:
ab c
de
Current result:
ab c
e
Needless to say that this is very annoying when inserting words in the
middle of paragraphs with certain text editors.
Signed-off-by: Nicolas Pitre
Cc: Jean-François Moine
Cc: Greg Kroah-Hartman
Cc:
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1a27280..6c4abea 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -539,7 +539,7 @@ static void insert_char(struct vc_data *vc, unsigned int nr)
{
unsigned short *p = (unsigned short *) vc->vc_pos;
- scr_memmovew(p + nr, p, (vc->vc_cols - vc->vc_x) * 2);
+ scr_memmovew(p + nr, p, (vc->vc_cols - vc->vc_x - nr) * 2);
scr_memsetw(p, vc->vc_video_erase_char, nr * 2);
vc->vc_need_wrap = 0;
if (DO_UPDATE(vc))
[PATCH 1/7] perf, x86: Reduce lbr_sel_map size
From: "Yan, Zheng"
The index of lbr_sel_map is bit value of perf branch_sample_type.
By using bit shift as index, we can reduce lbr_sel_map size.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 4 +++
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 50 ++
include/uapi/linux/perf_event.h| 42 +
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index e50c8fb..72143e1 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -421,6 +421,10 @@ struct x86_pmu {
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
};
+enum {
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 9f4bf09..eef87e0 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -69,10 +69,6 @@ static enum {
#define LBR_FROM_FLAG_INTX (1ULL << 62)
#define LBR_FROM_FLAG_ABORT(1ULL << 61)
-#define for_each_branch_sample_type(x) \
- for ((x) = PERF_SAMPLE_BRANCH_USER; \
-(x) < PERF_SAMPLE_BRANCH_MAX; (x) <<= 1)
-
/*
* x86control flow change classification
* x86control flow changes include branches, interrupts, traps, faults
@@ -400,14 +396,14 @@ static int intel_pmu_setup_hw_lbr_filter(struct
perf_event *event)
{
struct hw_perf_event_extra *reg;
u64 br_type = event->attr.branch_sample_type;
- u64 mask = 0, m;
- u64 v;
+ u64 mask = 0, v;
+ int i;
- for_each_branch_sample_type(m) {
- if (!(br_type & m))
+ for (i = 0; i < PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE; i++) {
+ if (!(br_type & (1U << i)))
continue;
- v = x86_pmu.lbr_sel_map[m];
+ v = x86_pmu.lbr_sel_map[i];
if (v == LBR_NOT_SUPP)
return -EOPNOTSUPP;
@@ -653,33 +649,33 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
/*
* Map interface branch filters onto LBR filters
*/
-static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_REL_JMP
- | LBR_IND_JMP | LBR_FAR,
+static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_REL_JMP
+ | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include REL_JMP+IND_JMP to get CALL branches
*/
- [PERF_SAMPLE_BRANCH_ANY_CALL] =
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] =
LBR_REL_CALL | LBR_IND_CALL | LBR_REL_JMP | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include IND_JMP to capture IND_CALL
*/
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL | LBR_IND_JMP,
};
-static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_FAR,
- [PERF_SAMPLE_BRANCH_ANY_CALL] = LBR_REL_CALL | LBR_IND_CALL
- | LBR_FAR,
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL,
+static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] = LBR_REL_CALL | LBR_IND_CALL
+ | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL,
};
/* core */
diff --git a/include/uapi/linux/perf_event.h
[PATCH 6/7] perf, x86: Use LBR call stack to get user callchain
From: "Yan, Zheng"
Try enabling the LBR call stack feature if event request recording
callchain. Try utilizing the LBR call stack to get user callchain
in case of there is no frame pointer.
This patch also adds a cpu pmu attribute to enable/disable this
feature.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 127 +
arch/x86/kernel/cpu/perf_event.h | 7 ++
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 +
include/linux/perf_event.h | 6 ++
kernel/events/core.c | 11 ++-
6 files changed, 126 insertions(+), 48 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 80e6a04..2f148cb 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -393,36 +393,49 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
+ }
+ /*
+* check that PEBS LBR correction does not conflict with
+* whatever the user is asking with attr->branch_sample_type
+*/
+ if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format < 2) {
+ u64 *br_type = >attr.branch_sample_type;
+
+ if (has_branch_stack(event)) {
+ if (!precise_br_compat(event))
+ return -EOPNOTSUPP;
+
+ /* branch_sample_type is compatible */
+
+ } else {
+ /*
+* user did not specify branch_sample_type
+*
+* For PEBS fixups, we capture all
+* the branches at the priv level of the
+* event.
+*/
+ *br_type = PERF_SAMPLE_BRANCH_ANY;
+
+ if (!event->attr.exclude_user)
+ *br_type |= PERF_SAMPLE_BRANCH_USER;
+
+ if (!event->attr.exclude_kernel)
+ *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
+ }
+ } else if ((event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) &&
+ !has_branch_stack(event) &&
+ x86_pmu.attr_lbr_callstack &&
+ !event->attr.exclude_user &&
+ (event->attach_state & PERF_ATTACH_TASK)) {
/*
-* check that PEBS LBR correction does not conflict with
-* whatever the user is asking with attr->branch_sample_type
+* user did not specify branch_sample_type,
+* try using the LBR call stack facility to
+* record call chains of user program.
*/
- if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format
< 2) {
- u64 *br_type = >attr.branch_sample_type;
-
- if (has_branch_stack(event)) {
- if (!precise_br_compat(event))
- return -EOPNOTSUPP;
-
- /* branch_sample_type is compatible */
-
- } else {
- /*
-* user did not specify branch_sample_type
-*
-* For PEBS fixups, we capture all
-* the branches at the priv level of the
-* event.
-*/
- *br_type = PERF_SAMPLE_BRANCH_ANY;
-
- if (!event->attr.exclude_user)
- *br_type |= PERF_SAMPLE_BRANCH_USER;
-
- if (!event->attr.exclude_kernel)
- *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
- }
- }
+ event->attr.branch_sample_type =
+ PERF_SAMPLE_BRANCH_USER |
+ PERF_SAMPLE_BRANCH_CALL_STACK;
}
/*
@@ -1794,10 +1807,34 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+static ssize_t get_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, 40, "%d\n", x86_pmu.attr_lbr_callstack);
+}
+
+static ssize_t set_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long val = simple_strtoul(buf, NULL, 0);
+
+ if (x86_pmu.attr_lbr_callstack != !!val) {
+ if (val && !x86_pmu_has_lbr_callstack())
+ return
[PATCH 7/7] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
"Zero length call" uses the attribute of the call instruction to push
the immediate instruction pointer on to the stack and then pops off
that address into a register. This is accomplished without any matching
return instruction. It confuses the hardware and make the recorded call
stack incorrect. Try fixing the call stack by discarding zero length
call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 0cebb01..4795cfc 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -94,7 +94,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -111,13 +112,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -647,6 +650,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate();
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] perf, x86: Introduce x86 special perf event context
From: "Yan, Zheng"
The x86 special perf event context is named x86_perf_event_context,
We can enlarge it later to store PMU special data.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 12
arch/x86/kernel/cpu/perf_event.h | 4
include/linux/perf_event.h | 5 +
kernel/events/core.c | 28 ++--
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index bda813e..55ab79d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1737,6 +1737,17 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
+{
+ struct perf_event_context *ctx;
+
+ ctx = kzalloc(sizeof(struct x86_perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static ssize_t get_attr_rdpmc(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -1824,6 +1835,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.flush_branch_stack = x86_pmu_flush_branch_stack,
+ .event_context_alloc= x86_pmu_event_context_alloc,
};
void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 544e31c..a8c1232 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -428,6 +428,10 @@ enum {
PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
+struct x86_perf_event_context {
+ struct perf_event_context ctx;
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 92fca05..1a98087 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -269,6 +269,11 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Allocate PMU special perf event context
+*/
+ void *(*event_context_alloc)(struct perf_event_context *parent_ctx);
};
/**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 19a2973..0110046 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2721,13 +2721,20 @@ static void __perf_event_init_context(struct
perf_event_context *ctx)
}
static struct perf_event_context *
-alloc_perf_context(struct pmu *pmu, struct task_struct *task)
+alloc_perf_context(struct pmu *pmu, struct task_struct *task,
+ struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
- ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
- if (!ctx)
- return NULL;
+ if (pmu->event_context_alloc) {
+ ctx = pmu->event_context_alloc(parent_ctx);
+ if (IS_ERR(ctx))
+ return ctx;
+ } else {
+ ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ }
__perf_event_init_context(ctx);
if (task) {
@@ -2813,10 +2820,11 @@ retry:
++ctx->pin_count;
raw_spin_unlock_irqrestore(>lock, flags);
} else {
- ctx = alloc_perf_context(pmu, task);
- err = -ENOMEM;
- if (!ctx)
+ ctx = alloc_perf_context(pmu, task, NULL);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
goto errout;
+ }
err = 0;
mutex_lock(>perf_event_mutex);
@@ -7135,9 +7143,9 @@ inherit_task_group(struct perf_event *event, struct
task_struct *parent,
* child.
*/
- child_ctx = alloc_perf_context(event->pmu, child);
- if (!child_ctx)
- return -ENOMEM;
+ child_ctx = alloc_perf_context(event->pmu, child, parent_ctx);
+ if (IS_ERR(child_ctx))
+ return PTR_ERR(child_ctx);
child->perf_event_ctxp[ctxn] = child_ctx;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 7 ++-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89 ++
include/uapi/linux/perf_event.h| 2 +-
4 files changed, 75 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 72143e1..544e31c 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -422,7 +422,10 @@ struct x86_pmu {
};
enum {
- PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
+
+ PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
#define x86_add_quirk(func_) \
@@ -640,6 +643,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 141b1b3..b3566bb 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2219,7 +2219,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_extra_regs, nehalem_hw_cache_extra_regs,
sizeof(hw_cache_extra_regs));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_westmere_event_constraints;
x86_pmu.enable_all = intel_pmu_nhm_enable_all;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index eef87e0..ce9e50d17 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -39,6 +39,7 @@ static enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -49,6 +50,7 @@ static enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -74,24 +76,25 @@ static enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in
[PATCH 4/7] perf, x86: Save/resotre LBR stack during context switch
From: "Yan, Zheng"
When the LBR call stack is enabled, it is necessary to save/restore
the stack on context switch. The solution is saving/restoring the
stack to/from task's perf event context. If task has no perf event
context, just flush the stack on context switch.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 18 +++--
arch/x86/kernel/cpu/perf_event.h | 13 +++-
arch/x86/kernel/cpu/perf_event_intel.c | 13 ++--
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 108 ++---
include/linux/perf_event.h | 6 +-
kernel/events/core.c | 64 ++---
6 files changed, 168 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 55ab79d..fc69269 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1737,6 +1737,13 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void x86_pmu_branch_stack_sched(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ if (x86_pmu.branch_stack_sched)
+ x86_pmu.branch_stack_sched(ctx, sched_in);
+}
+
static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
@@ -1745,6 +1752,9 @@ static void *x86_pmu_event_context_alloc(struct
perf_event_context *parent_ctx)
if (!ctx)
return ERR_PTR(-ENOMEM);
+ if (parent_ctx)
+ intel_pmu_lbr_init_context(ctx, parent_ctx);
+
return ctx;
}
@@ -1802,12 +1812,6 @@ static const struct attribute_group
*x86_pmu_attr_groups[] = {
NULL,
};
-static void x86_pmu_flush_branch_stack(void)
-{
- if (x86_pmu.flush_branch_stack)
- x86_pmu.flush_branch_stack();
-}
-
void perf_check_microcode(void)
{
if (x86_pmu.check_microcode)
@@ -1834,7 +1838,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
.event_idx = x86_pmu_event_idx,
- .flush_branch_stack = x86_pmu_flush_branch_stack,
+ .branch_stack_sched = x86_pmu_branch_stack_sched,
.event_context_alloc= x86_pmu_event_context_alloc,
};
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index a8c1232..0a7527d9 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -377,7 +377,6 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
void(*check_microcode)(void);
- void(*flush_branch_stack)(void);
/*
* Intel Arch Perfmon v2+
@@ -408,6 +407,8 @@ struct x86_pmu {
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
const int *lbr_sel_map; /* lbr_select mappings */
boollbr_double_abort; /* duplicated abort records
*/
+ void(*branch_stack_sched)(struct perf_event_context *ctx,
+ bool sched_in);
/*
* Extra registers for events
@@ -430,6 +431,12 @@ enum {
struct x86_perf_event_context {
struct perf_event_context ctx;
+
+ u64 lbr_from[MAX_LBR_ENTRIES];
+ u64 lbr_to[MAX_LBR_ENTRIES];
+ u64 lbr_stack_gen;
+ int lbr_callstack_users;
+ bool lbr_stack_saved;
};
#define x86_add_quirk(func_) \
@@ -627,8 +634,12 @@ void intel_pmu_pebs_disable_all(void);
void intel_ds_init(void);
+void intel_pmu_lbr_init_context(struct perf_event_context *child_ctx,
+ struct perf_event_context *parent_ctx);
void intel_pmu_lbr_reset(void);
+void intel_pmu_lbr_sched(struct perf_event_context *ctx, bool sched_in);
+
void intel_pmu_lbr_enable(struct perf_event *event);
void intel_pmu_lbr_disable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index b3566bb..716f7d9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1814,16 +1814,11 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
}
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_branch_stack_sched(struct perf_event_context *ctx,
+bool sched_in)
{
- /*
-* Intel LBR does not tag entries with the
-* PID of the current task, then we need to
-* flush it on ctxsw
-* For now, we simply reset it
-*/
if (x86_pmu.lbr_nr)
- intel_pmu_lbr_reset();
+ intel_pmu_lbr_sched(ctx, sched_in);
}
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1889,7 +1884,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting
[PATCH V3 0/7] perf, x86: Haswell LBR call stack support
From: "Yan, Zheng" Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. When the feature is enabled, function call will be collected as normal, but as return instructions are executed the last captured branch record is popped from the on-chip LBR registers. The LBR call stack facility can help perf to get call chains of progam without frame pointer. When perf tool requests PERF_SAMPLE_CALLCHAIN + PERF_SAMPLE_BRANCH_USER, this feature is dynamically enabled by default. This feature can be disabled/enabled through an attribute file in the cpu pmu sysfs directory. The LBR call stack has following known limitations 1. Zero length calls are not filtered out by hardware 2. Exception handing such as setjmp/longjmp will have calls/returns not match 3. Pushing different return address onto the stack will have calls/returns not match These patches are based upon Andi's linux-misc hsw/pmu5 Available from https://github.com/ukernel/linux.git hws/pmu5 Regards Yan, Zheng --- Changes since v1 - not expose PERF_SAMPLE_BRANCH_CALL_STACK to user space - save/restore LBR stack on context switch for all sampling branch modes - reduce lbr_sel_map size Changes since v2 - only enable LBR call stack when user requests sampling user callchain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] perf, core: Pass perf_sample_data to perf_callchain()
From: "Yan, Zheng"
New Intel CPU can record call chains by using existing last branch
record facility. perf_callchain_user() can make use of the call
chains recorded by hardware in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/arm/kernel/perf_event.c | 4 ++--
arch/powerpc/perf/callchain.c| 4 ++--
arch/sparc/kernel/perf_event.c | 4 ++--
arch/x86/kernel/cpu/perf_event.c | 4 ++--
include/linux/perf_event.h | 3 ++-
kernel/events/callchain.c| 8 +---
kernel/events/core.c | 2 +-
kernel/events/internal.h | 3 ++-
8 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f9e8657..5b0c49f 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -566,8 +566,8 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp - 1;
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct frame_tail __user *tail;
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 74d1e78..b379ebc 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -482,8 +482,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
}
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
if (current_is_64bit())
perf_callchain_user_64(entry, regs);
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index b5c38fa..cba0306 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1785,8 +1785,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
} while (entry->nr < PERF_MAX_STACK_DEPTH);
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
perf_callchain_store(entry, regs->tpc);
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index fc69269..80e6a04 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1968,8 +1968,8 @@ perf_callchain_user32(struct pt_regs *regs, struct
perf_callchain_entry *entry)
}
#endif
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct stack_frame frame;
const void __user *fp;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f4a1c95..b0da133 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -714,7 +714,8 @@ extern void perf_event_fork(struct task_struct *tsk);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
-extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs);
+extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs,
+ struct perf_sample_data *data);
extern void perf_callchain_kernel(struct perf_callchain_entry *entry, struct
pt_regs *regs);
static inline void perf_callchain_store(struct perf_callchain_entry *entry,
u64 ip)
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c772061..bd7138a 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -30,7 +30,8 @@ __weak void perf_callchain_kernel(struct perf_callchain_entry
*entry,
}
__weak void perf_callchain_user(struct perf_callchain_entry *entry,
- struct pt_regs *regs)
+ struct pt_regs *regs,
+ struct perf_sample_data *data)
{
}
@@ -154,7 +155,8 @@ put_callchain_entry(int rctx)
}
struct perf_callchain_entry *
-perf_callchain(struct perf_event *event, struct pt_regs *regs)
+perf_callchain(struct perf_event *event, struct pt_regs *regs,
+ struct perf_sample_data *data)
{
int rctx;
struct perf_callchain_entry *entry;
@@ -195,7 +197,7 @@ perf_callchain(struct perf_event *event, struct pt_regs
*regs)
goto exit_put;
perf_callchain_store(entry, PERF_CONTEXT_USER);
- perf_callchain_user(entry, regs);
+ perf_callchain_user(entry, regs, data);
}
}
diff --git a/kernel/events/core.c
[PATCH V2] backlight: ams369fg06: convert ams369fg06 to dev_pm_ops
Instead of using legacy suspend/resume methods, using newer dev_pm_ops
structure allows better control over power management.
Signed-off-by: Jingoo Han
---
Changes since v1:
- Remove unnecessary ifdefs.
drivers/video/backlight/ams369fg06.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/video/backlight/ams369fg06.c
b/drivers/video/backlight/ams369fg06.c
index d29e494..068194b 100644
--- a/drivers/video/backlight/ams369fg06.c
+++ b/drivers/video/backlight/ams369fg06.c
@@ -535,12 +535,12 @@ static int ams369fg06_remove(struct spi_device *spi)
return 0;
}
-#if defined(CONFIG_PM)
-static int ams369fg06_suspend(struct spi_device *spi, pm_message_t mesg)
+#ifdef CONFIG_PM_SLEEP
+static int ams369fg06_suspend(struct device *dev)
{
- struct ams369fg06 *lcd = spi_get_drvdata(spi);
+ struct ams369fg06 *lcd = dev_get_drvdata(dev);
- dev_dbg(>dev, "lcd->power = %d\n", lcd->power);
+ dev_dbg(dev, "lcd->power = %d\n", lcd->power);
/*
* when lcd panel is suspend, lcd panel becomes off
@@ -549,19 +549,19 @@ static int ams369fg06_suspend(struct spi_device *spi,
pm_message_t mesg)
return ams369fg06_power(lcd, FB_BLANK_POWERDOWN);
}
-static int ams369fg06_resume(struct spi_device *spi)
+static int ams369fg06_resume(struct device *dev)
{
- struct ams369fg06 *lcd = spi_get_drvdata(spi);
+ struct ams369fg06 *lcd = dev_get_drvdata(dev);
lcd->power = FB_BLANK_POWERDOWN;
return ams369fg06_power(lcd, FB_BLANK_UNBLANK);
}
-#else
-#define ams369fg06_suspend NULL
-#define ams369fg06_resume NULL
#endif
+static SIMPLE_DEV_PM_OPS(ams369fg06_pm_ops, ams369fg06_suspend,
+ ams369fg06_resume);
+
static void ams369fg06_shutdown(struct spi_device *spi)
{
struct ams369fg06 *lcd = spi_get_drvdata(spi);
@@ -573,12 +573,11 @@ static struct spi_driver ams369fg06_driver = {
.driver = {
.name = "ams369fg06",
.owner = THIS_MODULE,
+ .pm = _pm_ops,
},
.probe = ams369fg06_probe,
.remove = ams369fg06_remove,
.shutdown = ams369fg06_shutdown,
- .suspend= ams369fg06_suspend,
- .resume = ams369fg06_resume,
};
module_spi_driver(ams369fg06_driver);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] backlight: ams369fg06: convert ams369fg06 to dev_pm_ops
On Saturday, February 23, 2013 6:26 AM, Andrew Morton wrote:
>
> On Fri, 22 Feb 2013 19:42:59 +0900
> Jingoo Han wrote:
>
> > Instead of using legacy suspend/resume methods, using newer dev_pm_ops
> > structure allows better control over power management.
> >
> > ...
> >
> > @@ -571,12 +571,13 @@ static struct spi_driver ams369fg06_driver = {
> > .driver = {
> > .name = "ams369fg06",
> > .owner = THIS_MODULE,
> > +#ifdef CONFIG_PM
> > + .pm = _pm_ops,
> > +#endif
> > },
> > .probe = ams369fg06_probe,
> > .remove = ams369fg06_remove,
> > .shutdown = ams369fg06_shutdown,
>
> Are the ifdefs needed? There's various macro trickery in pm.h to clean
> this up - the rtc drivers use it.
OK, you're right.
I will remove unnecessary '#ifdef CONFIG_PM'.
Thank you for your comment.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] f2fs updates for v3.9 merge window
Hi Linus, Please pull for v3.9. Thanks, The following changes since commit 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39: Linux 3.8-rc7 (2013-02-09 08:20:39 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git tags/f2fs-for-3.9 for you to fetch changes up to 7dd690c82029ed34aafdb58ce7463cdead69abb5: f2fs: avoid build warning (2013-02-12 07:28:55 +0900) f2fs for v3.9 [Major bug fixes] o Store device file information correctly o Fix -EIO handling with respect to power-off-recovery o Allocate blocks with global locks o Fix wrong calculation of the SSR cost [Cleanups] o Get rid of fake on-stack dentries [Enhancement] o Support (un)freeze_fs o Enhance the f2fs_gc flow o Support 32-bit binary execution on 64-bit kernel Al Viro (4): f2fs: init_dent_inode() should take qstr f2fs: switch new_inode_page() from dentry to qstr f2fs: switch init_inode_metadata() to passing parent and name separately f2fs: get rid of fake on-stack dentries Alejandro Martinez Ruiz (1): f2fs: fix disable_ext_identify option spelling Changman Lee (5): f2fs: save device node number into f2fs_inode f2fs: add un/freeze_fs into super_operations f2fs: stop repeated checking if cp is needed f2fs: remove repeated F2FS_SET_SB_DIRT call f2fs: remove unnecessary gc option check and balance_fs Jaegeuk Kim (8): f2fs: prevent checkpoint once any IO failure is detected f2fs: cover global locks for reserve_new_block f2fs: remove the use of page_cache_release f2fs: avoid balanc_fs during evict_inode f2fs: clarify and enhance the f2fs_gc flow f2fs: fix calculation of max. gc cost in the SSR case Merge branch 'f2fs' of git://git.kernel.org/.../viro/vfs into dev f2fs: avoid build warning Namjae Jeon (8): f2fs: avoid redundant call to has_not_enough_free_secs in f2fs_gc f2fs: reorganize code for ra_node_page f2fs: fix typo mistake for data_version description f2fs: name gc task as per the block device f2fs: mark gc_thread as NULL when thread creation is failed f2fs: make an accessor to get sections for particular block type f2fs: optimize the return condition for has_not_enough_free_secs f2fs: add compat_ioctl to provide backward compatability majianpeng (4): f2fs: clean up the add_orphan_inode func f2fs: add device name in debugfs f2fs: use F2FS_BLKSIZE to judge bloksize and page_cache_size f2fs: when check superblock failed, try to check another superblock fs/f2fs/checkpoint.c | 63 +++--- fs/f2fs/debug.c | 4 +- fs/f2fs/dir.c| 29 ++-- fs/f2fs/f2fs.h | 44 ++ fs/f2fs/file.c | 35 --- fs/f2fs/gc.c | 124 ++- fs/f2fs/gc.h | 21 - fs/f2fs/inode.c | 53 +- fs/f2fs/node.c | 20 - fs/f2fs/recovery.c | 16 +++ fs/f2fs/segment.c| 29 fs/f2fs/segment.h| 23 +++--- fs/f2fs/super.c | 92 +- 13 files changed, 292 insertions(+), 261 deletions(-) -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
Re: [PATCH] infiniband-diags/saquery.c: switchinfo support added
On Sun, 24 Feb 2013 10:22:47 +0200 "Husam Kahalah" wrote: > Thank you for your time, I have the following notes: > I plan to add support for more records other than switchInfoRecord like > smInfo, multipath, nodeInfo That would be great! > I plan also to add component filter to those records attributes in the same > way that pathInfo and MCR were implemented, this is the reason why I started > adding attributes to query_params structure > I'am not talking about RID(record identifier) attributes only, but also > about other attributes that may differ between records. > If it is available to add to query_params structure in that way let me know > , otherwise I will add just RID attributes in the suggested way. > I am not against adding fields to query_params. However, we have a standard way to specify the RID components like LID which should be followed. If you need new components to be specified for new attributes it is fine to add them to query_params. That said, any components which already have options should be overloaded; for example MultiPathRecord.SL should use the --sl option. Does this make sense? Thanks, Ira > > -Original Message- > From: Ira Weiny > To: Ira Weiny > Cc: "Husam Kahalah" , linux-r...@vger.kernel.org, > linux-kernel@vger.kernel.org > Date: Thu, 21 Feb 2013 10:33:44 -0800 > Subject: Re: [PATCH] infiniband-diags/saquery.c: switchinfo support added > > On Thu, 21 Feb 2013 10:09:00 -0800 > Ira Weiny wrote: > > [snip] > > > > + ib_net16_t swir_lid; > > > > We don't need this field or lid option. Other records simply have an > optional parameter to specify the lid. > > > > The usage should be: > > > > SwitchRecord [lid] > > > > Sorry I meant "SwitchInfoRecord" or SWIR. > > Ira > > [snip] > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ira Weiny Member of Technical Staff Lawrence Livermore National Lab 925-423-8008 wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the watchdog tree with Linus' tree
Hi Wim,
Today's linux-next merge of the watchdog tree got a conflict in
drivers/rtc/rtc-stmp3xxx.c between commit c8a6046e1e0b ("drivers/rtc: use
of_match_ptr() macro") from Linus' tree and commit e02f5cf6b648 ("rtc:
stmp3xxx: add wdt-accessor function") from the watchdog tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/rtc/rtc-stmp3xxx.c
index b2a8ed9,cc9a9b6..000
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@@ -26,7 -26,8 +26,9 @@@
#include
#include
#include
+#include
+ #include
+ #include
#include
pgpWvPdhODIai.pgp
Description: PGP signature
[GIT PULL] VFIO updates for v3.9-rc1
Hi Linus, Please pull for v3.9-rc1. Thanks, Alex The following changes since commit 323a72d83c9b2963bd1e46c8e6963e468d4658d7: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-02-13 12:21:07 -0800) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v3.9-rc1 for you to fetch changes up to d65530fbc799e4036d4d3da4ab6e9fa6d8c4a447: drivers/vfio: remove depends on CONFIG_EXPERIMENTAL (2013-02-24 09:59:44 -0700) VFIO for 3.9-rc1 - Fixes PCIe v1 extended capability support - Cleans up read/write access functions - Fix Removal test to properly wait until devices are unused - Enable pcieport driver usage for non-accessible devices w/in groups - Extensions for PCI VGA support Alex Williamson (7): vfio-pci: Enable PCIe extended capabilities on v1 vfio-pci: Cleanup read/write functions vfio-pci: Cleanup BAR access vfio: Protect vfio_dev_present against device_del vfio: whitelist pcieport vfio-pci: Manage user power state transitions vfio-pci: Add support for VGA region access Kees Cook (1): drivers/vfio: remove depends on CONFIG_EXPERIMENTAL drivers/vfio/pci/Kconfig| 10 ++ drivers/vfio/pci/vfio_pci.c | 75 ++ drivers/vfio/pci/vfio_pci_config.c | 52 +-- drivers/vfio/pci/vfio_pci_private.h | 19 +-- drivers/vfio/pci/vfio_pci_rdwr.c| 281 drivers/vfio/vfio.c | 35 ++--- include/uapi/linux/vfio.h | 9 ++ 7 files changed, 254 insertions(+), 227 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kexec: Use min_t to simplify logic
On Sun, Feb 24, 2013 at 10:37:21PM +0800, Zhang Yanfei wrote:
> From: Zhang Yanfei
>
> This is just a tweak: using min_t to simplify logic of variable
> assignments.
>
> v2:
> - Rewrite patch description as Simon suggested.
> - Fix an inappropriate if test introduced by v1. Thanks Simon.
Hi Zhang,
thanks for the update.
Signed-off-by: Simon Horman
> Cc: "Eric W. Biederman"
> Cc: Andrew Morton
> Cc: Simon Horman
> Signed-off-by: Zhang Yanfei
> ---
> kernel/kexec.c | 22 ++
> 1 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 2436ffc..effd655 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -822,13 +822,8 @@ static int kimage_load_normal_segment(struct kimage
> *image,
> /* Start with a clear page */
> clear_page(ptr);
> ptr += maddr & ~PAGE_MASK;
> - mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
> - if (mchunk > mbytes)
> - mchunk = mbytes;
> -
> - uchunk = mchunk;
> - if (uchunk > ubytes)
> - uchunk = ubytes;
> + mchunk = min_t(size_t, mbytes, PAGE_SIZE - (maddr &
> ~PAGE_MASK));
> + uchunk = min_t(size_t, ubytes, mchunk);
>
> result = copy_from_user(ptr, buf, uchunk);
> kunmap(page);
> @@ -874,13 +869,9 @@ static int kimage_load_crash_segment(struct kimage
> *image,
> }
> ptr = kmap(page);
> ptr += maddr & ~PAGE_MASK;
> - mchunk = PAGE_SIZE - (maddr & ~PAGE_MASK);
> - if (mchunk > mbytes)
> - mchunk = mbytes;
> -
> - uchunk = mchunk;
> - if (uchunk > ubytes) {
> - uchunk = ubytes;
> + mchunk = min_t(size_t, mbytes, PAGE_SIZE - (maddr &
> ~PAGE_MASK));
> + uchunk = min_t(size_t, ubytes, mchunk);
> + if (mchunk > uchunk) {
> /* Zero the trailing part of the page */
> memset(ptr + uchunk, 0, mchunk - uchunk);
> }
> @@ -1461,8 +1452,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
> r = vsnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
>
> - if (r + vmcoreinfo_size > vmcoreinfo_max_size)
> - r = vmcoreinfo_max_size - vmcoreinfo_size;
> + r = min_t(size_t, r, vmcoreinfo_max_size - vmcoreinfo_size);
>
> memcpy(_data[vmcoreinfo_size], buf, r);
>
> --
> 1.7.1
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
igb: NULL pointer dereference
On Linus' current tree I get the the oops below. I realize I'm still using the deprecated max_vfs= module option, but this isn't a very compatible or friendly migration path. I'm using an 82576 PF as an interface for connecting an iscsi root disk and I also use the VF off this interface for misc virtual machine assignment. Suggestions welcome on migrating to sysfs based sr-iov enabling from an initramfs without bouncing the PF interface, but I think the below needs to be fixed regardless. git bisected to: commit fa44f2f185f7f9da19d331929bb1b56c1ccd1d93 Author: Greg Rose Date: Thu Jan 17 01:03:06 2013 -0800 igb: Enable SR-IOV configuration via PCI sysfs interface Implement callback in the driver for the new PCI bus driver interface that allows the user to enable/disable SR-IOV virtual functions in a device via the sysfs interface. Signed-off-by: Greg Rose Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Thanks, Alex [4.831907] igb: Intel(R) Gigabit Ethernet Network Driver - version 4.1.2-k [4.838868] igb: Copyright (c) 2007-2012 Intel Corporation. [4.844710] igb :01:00.0: Maximum of 7 VFs per PF, using max [4.850768] igb :01:00.0: Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface. [4.872310] systemd[1]: Starting dracut initqueue hook... Startin[4.877937] BUG: unable to handle kernel NULL pointer dereference at 0048 [4.887143] IP: [] igb_reset+0xcd/0x460 [igb] [4.893175] PGD 0 [4.895267] Oops: 0002 [#1] SMP [4.898666] Modules linked in: igb(+) ptp usb_storage pps_core iscsi_tcp be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi [4.918125] CPU 2 [4.919959] Pid: 207, comm: systemd-udevd Not tainted 3.8.0-rc3+ #278 LENOVO 4157CTO/LENOVO [4.928541] RIP: 0010:[] [] igb_reset+0xcd/0x460 [igb] [4.937039] RSP: 0018:880367f63b38 EFLAGS: 00010246 [4.942409] RAX: 00ff RBX: 880367020800 RCX: 0001 [4.949601] RDX: RSI: 0202 RDI: 880367020800 [4.956803] RBP: 880367f63b58 R08: 88036814d408 R09: 0007 [4.964004] R10: 813eea13 R11: 000f R12: 880367020d68 [4.971205] R13: 880371267000 R14: 0040 R15: 88036702 [4.978398] FS: 7fdebfc3b840() GS:88037fc8() knlGS: [4.986549] CS: 0010 DS: ES: CR0: 80050033 [4.992369] CR2: 0048 CR3: 000367df3000 CR4: 07e0 [4.999649] DR0: DR1: DR2: [5.006893] DR3: DR6: 0ff0 DR7: 0400 [5.014136] Process systemd-udevd (pid: 207, threadinfo 880367f62000, task 880367fa) [5.023108] Stack: [5.025280] 880371267000 880371267098 880371267000 0001 [5.033327] 880367f63bd8 a01593e5 880371267098 880367020d68 [5.041400] 0002 880367020800 0004 88037136 [5.049451] Call Trace: [5.052050] [] igb_probe+0x855/0xde0 [igb] [5.058023] [] local_pci_probe+0x4b/0x80 [5.063925] [] pci_device_probe+0x111/0x120 [5.070082] [] driver_probe_device+0x8b/0x390 [5.076375] [] __driver_attach+0xab/0xb0 [5.082303] [] ? driver_probe_device+0x390/0x390 [5.088736] [] bus_for_each_dev+0x55/0x90 [5.094458] [] driver_attach+0x1e/0x20 [5.099921] [] bus_add_driver+0x1a0/0x290 [5.105691] [] ? 0xa017 [5.110937] [] ? 0xa017 [5.116305] [] driver_register+0x77/0x170 [5.122287] [] ? 0xa017 [5.127786] [] __pci_register_driver+0x4b/0x50 [5.134004] [] igb_init_module+0x4f/0x1000 [igb] [5.140565] [] do_one_initcall+0x12a/0x180 [5.146321] [] load_module+0x1a8a/0x20c0 [5.152020] [] ? ddebug_proc_open+0xc0/0xc0 [5.157914] [] sys_init_module+0xd7/0x120 [5.163639] [] system_call_fastpath+0x16/0x1b [5.169702] Code: 83 e9 10 45 85 c9 89 8b 14 08 00 00 74 4d 31 c9 66 0f 1f 44 00 00 48 63 d1 83 c1 01 48 8d 14 52 48 c1 e2 05 48 03 93 98 0e 00 00 <83> 62 48 08 3b 8b 94 0e 00 00 72 df 48 89 df e8 2f da ff ff 48 [5.192637] RIP [] igb_reset+0xcd/0x460 [igb] g dracut initque[5.198783] RSP [5.203660] CR2: 0048 ue hook... [5.207169] ---[ end trace 494789df673e4a4c ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 EDAC 03/13] ghes: add the needed hooks for EDAC error report
On Fri, 2013-02-22 at 05:57 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 22 Feb 2013 05:50:21 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Fri, 22 Feb 2013 08:45:11 +0800
> > Huang Ying escreveu:
> >
> > > On Thu, 2013-02-21 at 09:04 -0300, Mauro Carvalho Chehab wrote:
> > > > Em Thu, 21 Feb 2013 09:26:07 +0800
> > > > Huang Ying escreveu:
> > > >
> >
> > > > There is also an advantage on taking this approach: this patch can have
> > > > just
> > > > the ghes changes, and will still compile fine, as CONFIG_EDAC_GHES is
> > > > not
> > > > defined yet. So, the patch becomes is simpler and easier to review.
> > >
> > > Thanks for your explanation. I agree to keep this in header file.
> > >
> > > My original suggestion is that it may be better to move this from ghes.h
> > > to some place like "ghes_edac.h", because these functions are
> > > implemented in "ghes_edac.c" instead of ghes.c.
> > >
> >
> > Ah! Well, I considered a separate header when writing this patch, but
> > adding
> > another header for just 3 functions where the parameters are more related to
> > ghes than with ghes_edac seemed overkill to me.
> >
> > IMO, a single comment at the header pointing to ghes_edac.c would improve
> > it.
> >
> ...
> > +/* From drivers/edac/ghes_acpi.h */
>
> ...with is obviously wrong.
>
> Mental note to myself: never hack too early in the morning before drinking a
> cup of coffee.
>
> Anyway, fixed on the patch below. Could you please ack?
>
> Regards,
> Mauro.
>
>
> [PATCH EDAC] ghes: add the needed hooks for EDAC error report
>
> In order to allow reporting errors via EDAC, add hooks for:
>
> 1) register an EDAC driver;
> 2) unregister an EDAC driver;
> 3) report errors via EDAC.
>
> As the EDAC driver will need to access the ghes structure, adds it
> as one of the parameters for ghes_do_proc.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Huang Ying
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 6d0e146..d668a8a 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -409,7 +409,8 @@ static void ghes_clear_estatus(struct ghes *ghes)
> ghes->flags &= ~GHES_TO_CLEAR;
> }
>
> -static void ghes_do_proc(const struct acpi_hest_generic_status *estatus)
> +static void ghes_do_proc(struct ghes *ghes,
> + const struct acpi_hest_generic_status *estatus)
> {
> int sev, sec_sev;
> struct acpi_hest_generic_data *gdata;
> @@ -421,6 +422,8 @@ static void ghes_do_proc(const struct
> acpi_hest_generic_status *estatus)
>CPER_SEC_PLATFORM_MEM)) {
> struct cper_sec_mem_err *mem_err;
> mem_err = (struct cper_sec_mem_err *)(gdata+1);
> + ghes_edac_report_mem_error(ghes, sev, mem_err);
> +
> #ifdef CONFIG_X86_MCE
> apei_mce_report_mem_error(sev == GHES_SEV_CORRECTED,
> mem_err);
> @@ -639,7 +642,7 @@ static int ghes_proc(struct ghes *ghes)
> if (ghes_print_estatus(NULL, ghes->generic, ghes->estatus))
> ghes_estatus_cache_add(ghes->generic, ghes->estatus);
> }
> - ghes_do_proc(ghes->estatus);
> + ghes_do_proc(ghes, ghes->estatus);
> out:
> ghes_clear_estatus(ghes);
> return 0;
> @@ -732,7 +735,7 @@ static void ghes_proc_in_irq(struct irq_work *irq_work)
> estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
> len = apei_estatus_len(estatus);
> node_len = GHES_ESTATUS_NODE_LEN(len);
> - ghes_do_proc(estatus);
> + ghes_do_proc(estatus_node->ghes, estatus);
> if (!ghes_estatus_cached(estatus)) {
> generic = estatus_node->generic;
> if (ghes_print_estatus(NULL, generic, estatus))
> @@ -821,6 +824,7 @@ static int ghes_notify_nmi(unsigned int cmd, struct
> pt_regs *regs)
> estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool,
> node_len);
> if (estatus_node) {
> + estatus_node->ghes = ghes;
> estatus_node->generic = ghes->generic;
> estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
> memcpy(estatus, ghes->estatus, len);
> @@ -899,6 +903,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
> ghes = NULL;
> goto err;
> }
> +
> + rc = ghes_edac_register(ghes, _dev->dev);
> + if (rc < 0)
> + goto err;
> +
> switch (generic->notify.type) {
> case ACPI_HEST_NOTIFY_POLLED:
> ghes->timer.function = ghes_poll_func;
> @@ -911,13 +920,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
> if (acpi_gsi_to_irq(generic->notify.vector, >irq)) {
> pr_err(GHES_PFX "Failed to map
Re: [PATCH] iommu: making IOMMU sysfs nodes API public
On Thu, Feb 21, 2013 at 09:11:13PM -0700, Alex Williamson wrote: > On Fri, 2013-02-22 at 11:04 +1100, David Gibson wrote: > > On Tue, Feb 19, 2013 at 01:11:51PM -0700, Alex Williamson wrote: > > > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote: > > > > On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote: > > > > > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote: > > [snip] > > > > > Adding the window size to sysfs seems more readily convenient, > > > > > but is it so hard for userspace to open the files and call a couple > > > > > ioctls to get far enough to call IOMMU_GET_INFO? I'm unconvinced the > > > > > clutter in sysfs more than just a quick fix. Thanks, > > > > > > > > And finally, as Alexey points out, isn't the point here so we know how > > > > much rlimit to give qemu? Using ioctls we'd need a special tool just > > > > to check the dma window sizes, which seems a bit hideous. > > > > > > Is it more hideous that using iommu groups to report a vfio imposed > > > restriction? Are a couple open files and a handful of ioctls worse than > > > code to parse directory entries and the future maintenance of an > > > unrestricted grab bag of sysfs entries? > > > > The fact that the memory is locked is a vfio restriction, but the > > actual dma window size is, genuinely, a property of the group. > > A group is an association of devices based on isolation and visibility. > The dma window happens to be associated with a group on your platform, > but that's not always the case. It's certainly an iommu driver specific group property, but a group property nonetheless. > This is why I was hoping something in > sysfs already reported the dma window so that we could point to it > rather than creating an interface where it doesn't really belong. Alas, no. There's been no reason to expose PEs previously. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature
Re: [GIT PULL] KVM updates for the 3.9 merge window
On Wed, Feb 20, 2013 at 5:17 PM, Marcelo Tosatti wrote: > > Please pull from > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.9-1 > > to receive the KVM updates for the 3.9 merge window [..] Ok, particularly the s390 people should check me resolution of the conflicts, since they include the renaming of IOINT_VIR to IRQIO_VIR. But the uapi header file move should be couble-checked by people who use this too. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: s3c2410: check for NULL pinctrl handle
Hi, On Monday 25 of February 2013 00:16:49 Heiko Stübner wrote: > Am Sonntag, 24. Februar 2013, 23:39:44 schrieb Linus Walleij: > > On Sun, Feb 24, 2013 at 6:00 PM, Tomasz Figa wrote: > > >> > Note that we are talking here about a temporary solution. The > > >> > legacy > > >> > DT- based pin configuration will go away after all the DT-enabled > > >> > platforms using this driver get migrated to pin control and so > > >> > will > > >> > the need to check if pin control is available. > > >> > > >> So use AUXDATA, and you get a pdata for that driver? > > > > > > Hmm, and then have some platform data passed statically and some > > > parsed > > > from device tree? > > > > This is done by several in-tree drivers today. It is even necessary > > for > > things like machine-specific callbacks. > > > > > Not even saying that we are going towards getting rid of > > > auxdata, not adding further dependencies for it. > > > > The other option is to do the non-temporary solution you are > > referring to below... > > > > > Sorry, but this sounds more broken to me than checking the return > > > value > > > of devm_pinctrl_get_select_default for NULL in the driver. > > > > Both are bad solution, auxdata is less bad than trying to check > > struct pinctrl * handles for non-NULL, which has *never* been a > > good thing to do and should never have been merged in the first > > place. > > > > (Maybe I ACKed that, then I was doing something stupid.) > > > > > Still, all the platforms relying on the legacy DT GPIO support > > > should > > > have been already migrated to pin control, so ideally instead of > > > "fixing" the drivers to continue supporting the deprecated method, > > > such > > > platforms should be fixed. > > > > I agree. > > Fine by me ... I'll work on a pinctrl driver for s3c24xx then :-) Good. I belive that pinctrl-samsung driver can be easily used for s3c24xx, with minor modifications to remove some assumptions that are true for all the newer Samsung SoCs. I'm currently working (in my free time) on pinctrl driver for s3c64xx (as a part of my DT-enablement work), so possibly some of the code I will create may be useful for s3c24xx as well. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 kbuild tree
Hi Michal,
After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
scripts/link-vmlinux.sh: line 135: .: .config: file not found
Presumably caused by commit 03b25b47e0f4 ("scripts/link-vmlinux.sh:
source variables from KCONFIG_CONFIG").
I have used the kbuild tree from next-20130222 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpK4s2ijDqeA.pgp
Description: PGP signature
Re: [PATCH v2 2/3] freezer: do not send a fake signal to a PF_DUMPCORE thread
On Sunday, February 24, 2013 07:36:56 PM Oleg Nesterov wrote:
> A coredumping thread can't be frozen anyway but the fake signal sent
> by freeze_task() can confuse dump_write/wait_for_dump_helpers/etc
> and interrupt the coredump.
>
> We are going to make the do_coredump() paths freezable but the fake
> TIF_SIGPENDING doesn't help, it only makes sense when we assume that
> the target can return to user-mode and call get_signal_to_deliver().
>
> Change freeze_task() to check PF_DUMPCORE along with PF_KTHREAD. We
> need to recheck PF_DUMPCORE under ->siglock to avoid the race with
> zap_threads() which can set this flag right before we take the lock.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Rafael J. Wysocki
> ---
> kernel/freezer.c | 19 ---
> 1 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index c38893b..595afab 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -85,14 +85,21 @@ bool __refrigerator(bool check_kthr_stop)
> }
> EXPORT_SYMBOL(__refrigerator);
>
> -static void fake_signal_wake_up(struct task_struct *p)
> +static bool fake_signal_wake_up(struct task_struct *p)
> {
> unsigned long flags;
> + bool ret = false;
> +
> + if (p->flags & (PF_KTHREAD | PF_DUMPCORE))
> + return ret;
>
> if (lock_task_sighand(p, )) {
> - signal_wake_up(p, 0);
> + ret = !(p->flags & PF_DUMPCORE);
> + if (ret)
> + signal_wake_up(p, 0);
> unlock_task_sighand(p, );
> }
> + return ret;
> }
>
> /**
> @@ -100,8 +107,8 @@ static void fake_signal_wake_up(struct task_struct *p)
> * @p: task to send the request to
> *
> * If @p is freezing, the freeze request is sent either by sending a fake
> - * signal (if it's not a kernel thread) or waking it up (if it's a kernel
> - * thread).
> + * signal (if it's not a kernel thread or a coredumping thread) or waking
> + * it up otherwise.
> *
> * RETURNS:
> * %false, if @p is not freezing or already frozen; %true, otherwise
> @@ -116,9 +123,7 @@ bool freeze_task(struct task_struct *p)
> return false;
> }
>
> - if (!(p->flags & PF_KTHREAD))
> - fake_signal_wake_up(p);
> - else
> + if (!fake_signal_wake_up(p))
> wake_up_state(p, TASK_INTERRUPTIBLE);
>
> spin_unlock_irqrestore(_lock, flags);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: s3c2410: check for NULL pinctrl handle
Am Sonntag, 24. Februar 2013, 23:39:44 schrieb Linus Walleij: > On Sun, Feb 24, 2013 at 6:00 PM, Tomasz Figa wrote: > >> > Note that we are talking here about a temporary solution. The legacy > >> > DT- based pin configuration will go away after all the DT-enabled > >> > platforms using this driver get migrated to pin control and so will > >> > the need to check if pin control is available. > >> > >> So use AUXDATA, and you get a pdata for that driver? > > > > Hmm, and then have some platform data passed statically and some parsed > > from device tree? > > This is done by several in-tree drivers today. It is even necessary for > things like machine-specific callbacks. > > > Not even saying that we are going towards getting rid of > > auxdata, not adding further dependencies for it. > > The other option is to do the non-temporary solution you are > referring to below... > > > Sorry, but this sounds more broken to me than checking the return value > > of devm_pinctrl_get_select_default for NULL in the driver. > > Both are bad solution, auxdata is less bad than trying to check > struct pinctrl * handles for non-NULL, which has *never* been a > good thing to do and should never have been merged in the first > place. > > (Maybe I ACKed that, then I was doing something stupid.) > > > Still, all the platforms relying on the legacy DT GPIO support should > > have been already migrated to pin control, so ideally instead of > > "fixing" the drivers to continue supporting the deprecated method, such > > platforms should be fixed. > > I agree. Fine by me ... I'll work on a pinctrl driver for s3c24xx then :-) Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: imx-dma: Remove redundant NULL check before kfree
kfree on NULL pointer is a no-op. Signed-off-by: Syam Sidhardhan --- drivers/dma/imx-dma.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c index 70b8975..0988583 100644 --- a/drivers/dma/imx-dma.c +++ b/drivers/dma/imx-dma.c @@ -859,8 +859,7 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_cyclic( desc = list_first_entry(>ld_free, struct imxdma_desc, node); - if (imxdmac->sg_list) - kfree(imxdmac->sg_list); + kfree(imxdmac->sg_list); imxdmac->sg_list = kcalloc(periods + 1, sizeof(struct scatterlist), GFP_KERNEL); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: return real error codes when pinctrl is not included
Am Sonntag, 24. Februar 2013, 23:42:32 schrieb Linus Walleij: > On Sun, Feb 24, 2013 at 11:34 PM, Heiko Stübner wrote: > > [Me] > > > >> This make me suspect that you have this ugly patch in some > >> private repo and I will be seeing it again and again :-( > > > > All my s3c24xx work is done is my spare time, so I have to confess I came > > up with this "ugly patch" all by myself when working on dt support for > > my machine and stumbling upon the described problem with the pin > > configuration. > > > > So, as it is obviously wrong, I also won't hold onto it. > > > > In any case, thanks for the thorough explanation, which I probably won't > > forget anytime soon. > > Hm, maybe I have come across as too harsh and then I feel bad about > that :-( > > I really want spare-time contributors, they are often more valueable > in addition to the corporate ones since they provide an outside view > of things. Just to ease your mind, it didn't sound to harsh and my mail wasn't meant to criticize (hopefully it didn't sound that way) - I am very much grateful for the explanation. Writing a pinctrl driver for the s3c24xx arches is still on my list, so my understanding of pinctrl (above knowing of its existence) is not very broad yet. With your explanation, in retrospect I can understand the ugliness of the patch now :-) as it goes against a core principle. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: return real error codes when pinctrl is not included
Am Sonntag, 24. Februar 2013, 01:40:58 schrieb Linus Walleij: > On Sat, Feb 23, 2013 at 6:56 PM, Heiko Stübner wrote: > > Currently the fallback functions when pinctrl is not being built do > > return either NULL or 0, either no pinctrl handle or no error, > > making them fail silently. > > > > All drivers using pinctrl do only test for error conditions, which > > made for example the i2c-s3c2410 driver fail on a devicetree based > > machine without pinctrl, as the conditional > > > > if (IS_ERR(i2c->pctrl) && s3c24xx_i2c_parse_dt_gpio(i2c)) > > > > did not reach the second part to initialize the gpios from dt. > > > > Therefore let the fallback pinctrl functions return -ENOTSUPP > > or the equivalent ERR_PTR to indicate that pinctrl is not supported. > > NAK. > > You are abusing IS_ERR(i2c->pctrl) to check if pinctrl is available > on the system which is *NOT* the intended usecase and that is > why your code fails. > > So I discussed the *exact* same thing with Tomasz and Pratyush a > while back in a private thread, which teaches me to probably not > waste time on responding to anything unless it's public. > > This make me suspect that you have this ugly patch in some > private repo and I will be seeing it again and again :-( All my s3c24xx work is done is my spare time, so I have to confess I came up with this "ugly patch" all by myself when working on dt support for my machine and stumbling upon the described problem with the pin configuration. So, as it is obviously wrong, I also won't hold onto it. In any case, thanks for the thorough explanation, which I probably won't forget anytime soon. Heiko > Here is an excerpt of that conversation: > > -8<---8<--8<--- > --- > > On Mon, Dec 24, 2012 at 12:26 PM, Prathyush K wrote: > > Exynos5250 does not yet support pinctrl so CONFIG_PINCTRL is not defined. > > > > The i2c-s3c2410 driver calls 'devm_pinctrl_get_select_default' which > > returns NULL. > > While checking for error, we use IS_ERR and not IS_ERR_OR_NULL inside the > > driver. > > This was causing the i2c hdmi phy to fail. > > > > I checked the other i2c drivers and realized, no-one is actually checking > > for IS_ERR_OR_NULL. > > > > Even ./Documentation/pinctrl.txt says: > > /* Setup */ > > p = devm_pinctrl_get(); > > if (IS_ERR(p)) > > > > I think the consumer.h should be modified to return an error and not just > > NULL if CONFIG_PINCTRL is not defined. > > No. That is not the idea with compile-out stubs. > > The idea is not to check at runtime whether you have this or that > framework enabled, if you need this framework for the driver to work > it should be depends on PINCTRL in Kconfig for the driver so it's > non-optional. This seems to be the case here? > > The stubs are for the case where pinctrl is optional for the driver(s) on > the system, for example if one driver is used on many diverse systems, > some which have pinctrl and some which does not. > > We cannot have a shared driver, like drivers/tty/serial/amba-pl011.c > fail on RealView just because the U300 need pins when using the > same driver, that would be unmanageable. > > Your reasoning above can only work in a world where e.g. all systems > using that driver have pinctrl. And then you can just depend on it in > Kconfig and problem is solved. > > On Thu, Dec 27, 2012 at 10:58 AM, Tomasz Figa wrote: > > I think that devm_pinctrl_get stub, as well as other pinctrl stubs, > > should not return NULL, but rather a reasonable error code. > > No. It is perfectly valid to not implement pinctrl on a system. > And the driver stubs should then work without pins being controlled > (for example as if they were set up at boot time by some bootloader, > or ROM.) > > If the driver does not work without pinctrl it should have > depends on PINCTRL in Kconfig. > > On Thu, Jan 17, 2013 at 9:50 AM, Tomasz Figa wrote: > >> If the driver does not work without pinctrl it should have > >> depends on PINCTRL in Kconfig. > > > > What about drivers that support several pin configuration methods? > > The platforms that use some other method shall call > pinctrl_provide_dummies() in their machine set-up code. > > Then they will get dummy regulators that appear to work > but does nothing. > > Then they shall be converted to use pinctrl proper. > > On Thu, Jan 17, 2013 at 3:05 PM, Tomasz Figa wrote: > > We have a bunch of drivers that should try pin control and if it is not > > supported on given platform then it should fall back to legacy > > configuration method (like cfg_gpio() callback passed through platform > > data). > > > > From what you are saying, it seems like there is no way to check if pin > > control is supported on platform we are running on. > > No we never saw that usecase before :-) > > It's very hard to say whether pinctrl is available or not as well, > as drivers can be deferred. > > In
Re: [git pull] signal.git
On Sat, 2013-02-23 at 18:56 -0800, Linus Torvalds wrote: > Ok, in the meantime I had merged the parisc and powerpc trees, which > had their own fixes in this area: powerpc added the transactional > memory support for power8 (which impacted signal save/restore), and > parisc had some fixes to the routines you then removed in favor of > generic ones. I compiled and booted it on parisc. Everything seems to be OK, at least on our pa8800 systems. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] s3c-adc-battery: Fix possible NULL pointer dereference
Check for (bat == NULL) has to be done before accessing bat
Signed-off-by: Syam Sidhardhan
---
drivers/power/s3c_adc_battery.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/power/s3c_adc_battery.c b/drivers/power/s3c_adc_battery.c
index d2ca989..5948ce0 100644
--- a/drivers/power/s3c_adc_battery.c
+++ b/drivers/power/s3c_adc_battery.c
@@ -145,14 +145,17 @@ static int s3c_adc_bat_get_property(struct power_supply
*psy,
int new_level;
int full_volt;
- const struct s3c_adc_bat_thresh *lut = bat->pdata->lut_noac;
- unsigned int lut_size = bat->pdata->lut_noac_cnt;
+ const struct s3c_adc_bat_thresh *lut;
+ unsigned int lut_size;
if (!bat) {
dev_err(psy->dev, "no battery infos ?!\n");
return -EINVAL;
}
+ lut = bat->pdata->lut_noac;
+ lut_size = bat->pdata->lut_noac_cnt;
+
if (bat->volt_value < 0 || bat->cur_value < 0 ||
jiffies_to_msecs(jiffies - bat->timestamp) >
BAT_POLL_INTERVAL) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the metag tree with Linus' tree
Hi James,
Today's linux-next merge of the metag tree got a conflict in
mm/page_alloc.c between commit 22b751c3d037 ("mm: rename page struct
field helpers") from Linus' tree and commit 373d4d099761 ("taint: add
explicit flag to show whether lock dep is still OK") from the metag tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/page_alloc.c
index e9075fd,4c99cb7..000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -332,8 -319,8 +332,8 @@@ static void bad_page(struct page *page
dump_stack();
out:
/* Leave bad fields for debug, except PageBuddy could make trouble */
- reset_page_mapcount(page); /* remove PageBuddy */
+ page_mapcount_reset(page); /* remove PageBuddy */
- add_taint(TAINT_BAD_PAGE);
+ add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
}
/*
pgpdOvVdrr4En.pgp
Description: PGP signature
Re: [PATCH] pinctrl: return real error codes when pinctrl is not included
On Sun, Feb 24, 2013 at 11:34 PM, Heiko Stübner wrote: > [Me] >> This make me suspect that you have this ugly patch in some >> private repo and I will be seeing it again and again :-( > > All my s3c24xx work is done is my spare time, so I have to confess I came up > with this "ugly patch" all by myself when working on dt support for my machine > and stumbling upon the described problem with the pin configuration. > > So, as it is obviously wrong, I also won't hold onto it. > > In any case, thanks for the thorough explanation, which I probably won't > forget anytime soon. Hm, maybe I have come across as too harsh and then I feel bad about that :-( I really want spare-time contributors, they are often more valueable in addition to the corporate ones since they provide an outside view of things. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: s3c2410: check for NULL pinctrl handle
On Sun, Feb 24, 2013 at 6:00 PM, Tomasz Figa wrote: >> > Note that we are talking here about a temporary solution. The legacy >> > DT- based pin configuration will go away after all the DT-enabled >> > platforms using this driver get migrated to pin control and so will >> > the need to check if pin control is available. >> >> So use AUXDATA, and you get a pdata for that driver? > > Hmm, and then have some platform data passed statically and some parsed > from device tree? This is done by several in-tree drivers today. It is even necessary for things like machine-specific callbacks. > Not even saying that we are going towards getting rid of > auxdata, not adding further dependencies for it. The other option is to do the non-temporary solution you are referring to below... > Sorry, but this sounds more broken to me than checking the return value of > devm_pinctrl_get_select_default for NULL in the driver. Both are bad solution, auxdata is less bad than trying to check struct pinctrl * handles for non-NULL, which has *never* been a good thing to do and should never have been merged in the first place. (Maybe I ACKed that, then I was doing something stupid.) > Still, all the platforms relying on the legacy DT GPIO support should have > been already migrated to pin control, so ideally instead of "fixing" the > drivers to continue supporting the deprecated method, such platforms > should be fixed. I agree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: please clean up
Hi all, As your work is merged by upstream trees, please clean up your linux-next included branches. A big thanks to those who already do this in a timely fashion. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpaaDtRS04nC.pgp Description: PGP signature
