Re: radeon causing sleeping function called from invalid context
On (02/07/13 22:53), Andreas Bombe wrote: > On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote: > > On (01/12/13 20:27), Dave Jones wrote: > > > BUG: sleeping function called from invalid context at mm/slub.c:925 > > > in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg > > > INFO: lockdep is turned off. > > > Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49 > > > Call Trace: > > > [] __might_sleep+0x141/0x200 > > > [] kmem_cache_alloc_trace+0x4b/0x2a0 > > > [] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm] > > > [] radeon_move_blit.isra.4+0xf8/0x160 [radeon] > > > [] radeon_bo_move+0xb0/0x1f0 [radeon] > > > [] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm] > > > [] ? get_parent_ip+0x11/0x50 > > > [] ttm_bo_move_buffer+0x127/0x140 [ttm] > > > [] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm] > > > [] ttm_bo_validate+0xa2/0x120 [ttm] > > > [] radeon_bo_list_validate+0x75/0x90 [radeon] > > > [] radeon_cs_ioctl+0x582/0x950 [radeon] > > > [] drm_ioctl+0x4d3/0x580 [drm] > > > [] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon] > > > [] do_vfs_ioctl+0x99/0x5a0 > > > [] ? file_has_perm+0x97/0xb0 > > > [] ? rcu_eqs_exit+0x65/0xb0 > > > [] sys_ioctl+0x91/0xb0 > > > [] tracesys+0xdd/0xe2 > > > > > > > I see lots of these [mostly from page fault], the following one (quick and > > dirty) works for me. > > Is that patch or any other fix being picked up? It's over three weeks > now and I'm still seeing those BUGs with the latest 3.8-rc. > None that I'm aware of. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Thermal: Create sensor level APIs
On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote:
> This patch creates sensor level APIs, in the
> generic thermal framework.
>
> A Thermal sensor is a piece of hardware that can report
> temperature of the spot in which it is placed. A thermal
> sensor driver reads the temperature from this sensor
> and reports it out. This kind of driver can be in
> any subsystem. If the sensor needs to participate
> in platform thermal management, the corresponding
> driver can use the APIs introduced in this patch, to
> register(or unregister) with the thermal framework.
>
> Signed-off-by: Durgadoss R
> ---
> drivers/thermal/thermal_sys.c | 280
> +
> include/linux/thermal.h | 29 +
> 2 files changed, 309 insertions(+)
>
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 0a1bf6b..cb94497 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -44,13 +44,16 @@ MODULE_LICENSE("GPL");
>
> static DEFINE_IDR(thermal_tz_idr);
> static DEFINE_IDR(thermal_cdev_idr);
> +static DEFINE_IDR(thermal_sensor_idr);
> static DEFINE_MUTEX(thermal_idr_lock);
>
> static LIST_HEAD(thermal_tz_list);
> +static LIST_HEAD(thermal_sensor_list);
> static LIST_HEAD(thermal_cdev_list);
> static LIST_HEAD(thermal_governor_list);
>
> static DEFINE_MUTEX(thermal_list_lock);
> +static DEFINE_MUTEX(sensor_list_lock);
> static DEFINE_MUTEX(thermal_governor_lock);
>
> static struct thermal_governor *__find_governor(const char *name)
> @@ -423,6 +426,103 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> #define to_thermal_zone(_dev) \
> container_of(_dev, struct thermal_zone_device, device)
>
> +#define to_thermal_sensor(_dev) \
> + container_of(_dev, struct thermal_sensor, device)
> +
> +static ssize_t
> +sensor_name_show(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + return sprintf(buf, "%s\n", ts->name);
> +}
> +
> +static ssize_t
> +sensor_temp_show(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + int ret;
> + long val;
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + ret = ts->ops->get_temp(ts, );
> +
> + return ret ? ret : sprintf(buf, "%ld\n", val);
> +}
> +
> +static ssize_t
> +hyst_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + int indx, ret;
> + long val;
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> + return -EINVAL;
> +
> + ret = ts->ops->get_hyst(ts, indx, );
> +
> + return ret ? ret : sprintf(buf, "%ld\n", val);
> +}
> +
> +static ssize_t
> +hyst_store(struct device *dev, struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + int indx, ret;
> + long val;
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + if (!ts->ops->set_hyst)
> + return -EPERM;
> +
> + if (!sscanf(attr->attr.name, "threshold%d_hyst", ))
> + return -EINVAL;
> +
> + if (kstrtol(buf, 10, ))
> + return -EINVAL;
> +
> + ret = ts->ops->set_hyst(ts, indx, val);
> +
> + return ret ? ret : count;
> +}
> +
> +static ssize_t
> +threshold_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + int indx, ret;
> + long val;
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + if (!sscanf(attr->attr.name, "threshold%d", ))
> + return -EINVAL;
> +
> + ret = ts->ops->get_threshold(ts, indx, );
> +
> + return ret ? ret : sprintf(buf, "%ld\n", val);
> +}
> +
> +static ssize_t
> +threshold_store(struct device *dev, struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + int indx, ret;
> + long val;
> + struct thermal_sensor *ts = to_thermal_sensor(dev);
> +
> + if (!ts->ops->set_threshold)
> + return -EPERM;
> +
> + if (!sscanf(attr->attr.name, "threshold%d", ))
> + return -EINVAL;
> +
> + if (kstrtol(buf, 10, ))
> + return -EINVAL;
> +
> + ret = ts->ops->set_threshold(ts, indx, val);
> +
> + return ret ? ret : count;
> +}
> +
> static ssize_t
> type_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> @@ -707,6 +807,10 @@ static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
> static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
> static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
>
> +/* Thermal sensor attributes */
> +static DEVICE_ATTR(sensor_name, 0444, sensor_name_show, NULL);
> +static DEVICE_ATTR(temp_input, 0444, sensor_temp_show, NULL);
> +
> /* sys I/F for cooling device */
> #define to_cooling_device(_dev) \
>
Re: [PATCHv3 0/8] Thermal Framework Enhancements
Hi, Durga, thanks for your continuous effort on this. comment in line. thanks, rui On Tue, 2013-02-05 at 16:16 +0530, Durgadoss R wrote: > This patch set is a v3 of the previous versions submitted here: > [v2]: http://lwn.net/Articles/531720/ > [v1]: https://lkml.org/lkml/2012/12/18/108 > [RFC]:https://patchwork.kernel.org/patch/1758921/ > > This patch set is based on Rui's -next tree, and is > tested on a Core-i5 and an Atom netbook. > > Changes since v2: > * Reworked the map sysfs attributes in patch [5/8] > * Dropped configuration for maximum sensors and >cooling devices, through Kconfig. > * Added __remove_trip_attr method > * Renamed __clean_map_entry to __remove_map_entry >for consistency in naming. > Changes Since v1: > * Removed kobject creation for thermal_trip and thermal_map >nodes as per Greg-KH's comments. > * Added ABI Documentation under 'testing'. > * Modified the GET_INDEX macro to be more linux-like, thanks >to Joe Perches. > * Added get_[sensor/cdev]_by_name APIs to thermal.h > > This series contains 8 patches: > Patch 1/8: Creates new sensor level APIs > Patch 2/8: Creates new zone level APIs. The existing tzd structure is >kept as such for clarity and compatibility purposes. > Patch 3/8: Creates functions to add/remove a cdev to/from a zone. The >existing tcd structure need not be modified. > Patch 4/8: Adds sensorX_trip_[active/passive/hot/critical] sysfs nodes, > under /sys/class/thermal/zoneY/. This exposes various trip >points for sensorX present in zoneY. > Patch 5/8: Adds mapY_* sysfs node. These attributes represent >the binding relationship between a sensor and a cdev, >within a zone. > Patch 6/8: Creates Documentation for the new APIs. A new file is >created for clarity. Final goal is to merge with the existing >file or refactor the files, as whatever seems appropriate. > Patch 7/8: Add ABI documentation for sysfs interfaces introduced in this > patch. > Patch 8/8: A dummy driver that can be used for testing. This is not for merge. > > Durgadoss R (8): > Thermal: Create sensor level APIs > Thermal: Create zone level APIs > Thermal: Add APIs to bind cdev to new zone structure > Thermal: Add trip point sysfs nodes for sensor > Thermal: Create Thermal map sysfs attributes for a zone > Thermal: Add Documentation to new APIs > Thermal: Add ABI Documentation for sysfs interfaces > Thermal: Dummy driver used for testing > > Documentation/ABI/testing/sysfs-class-thermal | 137 > Documentation/thermal/sysfs-api2.txt | 247 ++ > drivers/thermal/Kconfig |5 + > drivers/thermal/Makefile |2 + > drivers/thermal/thermal_sys.c | 994 > + > drivers/thermal/thermal_test.c| 324 > include/linux/thermal.h | 123 ++- > 7 files changed, 1831 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-thermal > create mode 100644 Documentation/thermal/sysfs-api2.txt > create mode 100644 drivers/thermal/thermal_test.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: tegra: Unify tegra{20,30,114}_init_early()
Hi,
On Fri, Feb 08, 2013 at 09:29:31AM +0200, Hiroshi Doyu wrote:
> @@ -56,18 +56,21 @@ int tegra_cpu_disable(unsigned int cpu)
> return cpu == 0 ? -EPERM : 0;
> }
>
> -#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> -extern void tegra20_hotplug_shutdown(void);
> -void __init tegra20_hotplug_init(void)
> +void __init tegra_hotplug_init(void)
> {
> - tegra_hotplug_shutdown = tegra20_hotplug_shutdown;
> -}
> + switch (tegra_chip_id) {
> +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> + case TEGRA20:
> + tegra_hotplug_shutdown = tegra20_hotplug_shutdown;
> + break;
> #endif
> -
> -#ifdef CONFIG_ARCH_TEGRA_3x_SOC
> -extern void tegra30_hotplug_shutdown(void);
> -void __init tegra30_hotplug_init(void)
> -{
> - tegra_hotplug_shutdown = tegra30_hotplug_shutdown;
> -}
> +#if defined(CONFIG_ARCH_TEGRA_3x_SOC)
how about using:
#if IS_BUILTIN(CONFIG_ARCH_TEGRA_3x_SOC)
instead ?
> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
> index 4ffae54..970ebd5 100644
> --- a/arch/arm/mach-tegra/sleep.h
> +++ b/arch/arm/mach-tegra/sleep.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2010-2012, NVIDIA Corporation. All rights reserved.
> + * Copyright (c) 2010-2013, NVIDIA Corporation. All rights reserved.
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms and conditions of the GNU General Public License,
> @@ -124,11 +124,11 @@ int tegra_sleep_cpu_finish(unsigned long);
> void tegra_disable_clean_inv_dcache(void);
>
> #ifdef CONFIG_HOTPLUG_CPU
> -void tegra20_hotplug_init(void);
> -void tegra30_hotplug_init(void);
> +void tegra20_hotplug_shutdown(void);
> +void tegra30_hotplug_shutdown(void);
aren't these two called only by tegra_hotplug_init() now ? That means
they don't need to be exposed.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 7/7] spi: spi-fsl-spi: Add support for gpio chipselects for GRLIB type cores
On 2013-02-07 17:08, Anton Vorontsov wrote:
On Thu, Feb 07, 2013 at 02:12:11PM +0100, Andreas Larsson wrote:
struct fsl_spi_reg *reg_base;
- int retval;
+ int retval, desel;
We don't usually place variable declarations on the same line, unless the
variables are closely related.
u32 hw_mode;
struct spi_mpc8xxx_cs *cs = spi->controller_state;
@@ -456,12 +456,45 @@ static int fsl_spi_setup(struct spi_device *spi)
return retval;
}
+ if (mpc8xxx_spi->type == TYPE_GRLIB) {
+ if (gpio_is_valid(spi->cs_gpio)) {
<- You can place the 'int desel;' here, limiting the visibility for it.
Thanks for the feedback!
I'll put that in v3. This last patch needs to wait for the other
patchset I mentioned anyway.
Cheers,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
On Thu, Feb 7, 2013 at 5:22 PM, Alexey Brodkin
wrote:
> On 02/07/2013 09:16 PM, Grant Likely wrote:
>>
>> On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin
>> wrote:
>>>
>>> On 02/07/2013 08:44 PM, Grant Likely wrote:
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using ioread16/iowrite16 on the
data port results in the correct behaviour. It also means that LE
support in the current driver is broken.
>>>
>>>
>>> That matches my earlier note when I wrote that for correct work on LE
>>> (note
>>> I'm on ARC, not PPC/MB) I needed to use "io{read|write}16" in
>>> "ace_data{in|out}_le16".
>>>
>>> With original "io{read|write}16be" instead data was corrupted.
>>
>>
>> In which case your bug-fix patch should drop the
>> ace_datain_le16/ace_dataout_le16 variants entirely and use the be16
>> ones for both (renaming appropriately).
>>
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
> Sorry, do you mean to replace original lines:
> ===
>
> static void ace_datain_be16(struct ace_device *ace)
> {
> int i = ACE_FIFO_SIZE / 2;
> u16 *dst = ace->data_ptr;
> while (i--)
> *dst++ = in_le16(ace->baseaddr + 0x40);
> ace->data_ptr = dst;
>
> }
>
> static void ace_dataout_be16(struct ace_device *ace)
> {
> int i = ACE_FIFO_SIZE / 2;
> u16 *src = ace->data_ptr;
> while (i--)
> ioread16(*src++, ace->baseaddr + 0x40);
> ace->data_ptr = src;
> }
> ===
>
> with something like:
> ===
> static void ace_datain_16(struct ace_device *ace)
>
> {
> int i = ACE_FIFO_SIZE / 2;
> u16 *dst = ace->data_ptr;
> while (i--)
> *dst++ = in_le16(ace->baseaddr + 0x40);
> ace->data_ptr = dst;
> }
>
> static void ace_dataout_16(struct ace_device *ace)
>
> {
> int i = ACE_FIFO_SIZE / 2;
> u16 *src = ace->data_ptr;
> while (i--)
> iowrite16(*src++, ace->baseaddr + 0x40);
> ace->data_ptr = src;
> }
Ummm, I think you finger fumbled that because the above doesn't make sense.
I think that your original patch should be applied as-is first. It is
just a mechanical replacement of the ppc accessors with ioread/iowrite
variants. Nothing controversial there.
I was suggesting to use a second patch to drop
ace_datain_le16/ace_dataout_le16 and rename
ace_datain_be16/ace_dataout_be16 to ace_datain_16/ace_dataout_16.\,
and in that same patch you can switch the read loop to use
ioread16_rep/iowrite16_rep.
*However*... I think my first analysis is actually wrong for the BE
case. The current BE code works using ioread16() for the data port
which does a swap, but ioread16_rep() doesn't swap . I hadn't gone an
actually looked at how the _rep variants are implemented. (Thanks for
your help Ben). That means ioread16_rep will work fine for LE, but
we're still stuck with the slow loop on BE.
So, craft your bug fix for the LE case to use _rep variants for
ace_{datain,dataout}_le16() but don't change the BE support yet.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: davinci_wdt: update to devm_* API
Update the code to use devm_* API so that driver
core will manage resources.
Signed-off-by: Kumar, Anil
---
This patch applies on top of v3.8-rc6.
Tested on da850 EVM.
Changes for V2:
- Use return -EADDRNOTAVAIL in case of devm_request_and_ioremap() fail.
- Use devm_clk_get() instead of clk_get().
- Revert back the change for *dev.
- Removes static type for "wdt_mem" structure as it is used only
inside the function now.
:100644 100644 e8e8724... 7df1fdc... M drivers/watchdog/davinci_wdt.c
drivers/watchdog/davinci_wdt.c | 29 ++---
1 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index e8e8724..7df1fdc 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -69,7 +69,6 @@ static unsigned long wdt_status;
#define WDT_REGION_INITED 2
#define WDT_DEVICE_INITED 3
-static struct resource *wdt_mem;
static void __iomem*wdt_base;
struct clk *wdt_clk;
@@ -201,10 +200,11 @@ static struct miscdevice davinci_wdt_miscdev = {
static int davinci_wdt_probe(struct platform_device *pdev)
{
- int ret = 0, size;
+ int ret = 0;
struct device *dev = >dev;
+ struct resource *wdt_mem;
- wdt_clk = clk_get(dev, NULL);
+ wdt_clk = devm_clk_get(dev, NULL);
if (WARN_ON(IS_ERR(wdt_clk)))
return PTR_ERR(wdt_clk);
@@ -221,43 +221,26 @@ static int davinci_wdt_probe(struct platform_device *pdev)
return -ENOENT;
}
- size = resource_size(wdt_mem);
- if (!request_mem_region(wdt_mem->start, size, pdev->name)) {
- dev_err(dev, "failed to get memory region\n");
- return -ENOENT;
- }
-
- wdt_base = ioremap(wdt_mem->start, size);
+ wdt_base = devm_request_and_ioremap(dev, wdt_mem);
if (!wdt_base) {
- dev_err(dev, "failed to map memory region\n");
- release_mem_region(wdt_mem->start, size);
- wdt_mem = NULL;
- return -ENOMEM;
+ dev_err(dev, "ioremap failed\n");
+ return -EADDRNOTAVAIL;
}
ret = misc_register(_wdt_miscdev);
if (ret < 0) {
dev_err(dev, "cannot register misc device\n");
- release_mem_region(wdt_mem->start, size);
- wdt_mem = NULL;
} else {
set_bit(WDT_DEVICE_INITED, _status);
}
- iounmap(wdt_base);
return ret;
}
static int davinci_wdt_remove(struct platform_device *pdev)
{
misc_deregister(_wdt_miscdev);
- if (wdt_mem) {
- release_mem_region(wdt_mem->start, resource_size(wdt_mem));
- wdt_mem = NULL;
- }
-
clk_disable_unprepare(wdt_clk);
- clk_put(wdt_clk);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ARM: tegra: Restore USB/PCIE info in new DT board file
Mainly for the compatibility for the existing driver.
This would be removed once new USB/PCIE DT supports come.
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/tegra.c | 92 ++-
1 file changed, 90 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 62ae39a..82fea64 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -30,9 +32,63 @@
#include "common.h"
#include "iomap.h"
+#ifdef USB_EHCI_TEGRA
+static struct tegra_ulpi_config tegra_ehci2_ulpi_phy_config = {
+ .reset_gpio = -1,
+ .clk = "cdev2",
+};
+
+static struct tegra_ehci_platform_data tegra_ehci_pdata[] = {
+ {
+ .operating_mode = TEGRA_USB_OTG,
+ .power_down_on_bus_suspend = 1,
+ .vbus_gpio = -1,
+ },
+ {
+ .operating_mode = TEGRA_USB_HOST,
+ .power_down_on_bus_suspend = 1,
+ .vbus_gpio = -1,
+ .phy_config = _ehci2_ulpi_phy_config,
+ },
+ {
+ .operating_mode = TEGRA_USB_HOST,
+ .power_down_on_bus_suspend = 1,
+ .vbus_gpio = -1,
+ },
+};
+
static struct of_dev_auxdata tegra_auxdata_lookup[] __initdata = {
- {},
+ OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xc500, "tegra-ehci.0",
_ehci_pdata[0]),
+ OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xc5004000, "tegra-ehci.1",
_ehci_pdata[1]),
+ OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC5008000, "tegra-ehci.2",
_ehci_pdata[2]),
+ {}
};
+#else
+#define tegra_auxdata_lookup NULL
+#endif
+
+#if defined(CONFIG_TEGRA_PCI) && defined(CONFIG_ARCH_TEGRA_2x_SOC)
+static void __init trimslice_init(void)
+{
+ int err;
+
+ err = tegra_pcie_init(true, true);
+ if (err)
+ pr_err("%s failed: %d\n", __func__, err);
+}
+static void __init harmony_init(void)
+{
+ harmony_pcie_init();
+}
+static void __init paz00_init(void)
+{
+ tegra_paz00_wifikill_init();
+}
+#else
+#define trimslice_init NULL
+#define harmony_init NULL
+#define paz00_init NULL
+#endif
static void __init tegra_dt_init(void)
{
@@ -40,6 +96,38 @@ static void __init tegra_dt_init(void)
tegra_auxdata_lookup, NULL);
}
+static void __init tegra_dt_init_late(void)
+{
+ int i;
+ struct {
+ const char *name;
+ void (*init)(void);
+ } board[] = {
+ {
+ .name = "compulab,trimslice",
+ .init = trimslice_init,
+ },
+ {
+ .name = "nvidia,harmony",
+ .init = harmony_init,
+ },
+ {
+ .name = "compal,paz00",
+ .init = paz00_init
+ },
+ };
+
+ tegra_init_late();
+
+ for (i = 0; i < ARRAY_SIZE(board); i++) {
+ if (of_machine_is_compatible(board[i].name)) {
+ if (board[i].init)
+ board[i].init();
+ break;
+ }
+ }
+}
+
static const char * const tegra_dt_board_compat[] = {
"nvidia,tegra20",
"nvidia,tegra30",
@@ -54,7 +142,7 @@ DT_MACHINE_START(TEGRA_DT, "NVIDIA Tegra SoC (Flattened
Device Tree)")
.init_irq = tegra_dt_init_irq,
.init_time = clocksource_of_init,
.init_machine = tegra_dt_init,
- .init_late = tegra_init_late,
+ .init_late = tegra_dt_init_late,
.restart= tegra_assert_system_reset,
.dt_compat = tegra_dt_board_compat,
MACHINE_END
--
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 v3 00/10] spi/pxa2xx: add Intel Lynxpoint SPI controller support
Hi Mark/Grant, On Mon, Feb 04, 2013 at 05:45:49PM +0800, Mark Brown wrote: > On Fri, Feb 01, 2013 at 12:22:47PM +0200, Mika Westerberg wrote: > > > Mark, thank you for applying patches 1-4/10. Is there anything you want me > > to do for the rest of the patches in order to get those merged? > > I stopped at patch 4 mostly because it's very large but also because you > said you were hoping for an ack from Linus. It is large because I had to break out the private PXA DMA implementation from the driver and I'm not sure if it can be split into a smaller patches. The series has been tested on PXA by Lu Cao at Marvell and Linus W acked the DMA patches. Do you think you could take this for 3.9 or is there anything (besides the one patch being large) preventhing this? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ARM: tegra: Unify board-dt-tegra{20,30}.c to tegra.c
Refactored that Tegra{20,30,114} use the same board file.
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/Makefile |5 ++--
.../arm/mach-tegra/{board-dt-tegra30.c => tegra.c} | 27 ++--
2 files changed, 15 insertions(+), 17 deletions(-)
rename arch/arm/mach-tegra/{board-dt-tegra30.c => tegra.c} (71%)
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 1a08ecd..ee866337 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -27,9 +27,8 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_CPU_FREQ) += cpu-tegra.o
obj-$(CONFIG_TEGRA_PCI)+= pcie.o
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-dt-tegra20.o
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= board-dt-tegra30.o
-obj-$(CONFIG_ARCH_TEGRA_114_SOC) += board-dt-tegra30.o
+obj-y += tegra.o
+
ifeq ($(CONFIG_CPU_IDLE),y)
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += cpuidle-tegra114.o
endif
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c
b/arch/arm/mach-tegra/tegra.c
similarity index 71%
rename from arch/arm/mach-tegra/board-dt-tegra30.c
rename to arch/arm/mach-tegra/tegra.c
index 82cd85c..62ae39a 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -1,14 +1,7 @@
/*
- * arch/arm/mach-tegra/board-dt-tegra30.c
- *
- * NVIDIA Tegra30 device tree board support
+ * NVIDIA Tegra SoC device tree board support
*
* Copyright (C) 2011, 2013, NVIDIA Corporation
- *
- * Derived from:
- *
- * arch/arm/mach-tegra/board-dt-tegra20.c
- *
* Copyright (C) 2010 Secret Lab Technologies, Ltd.
* Copyright (C) 2010 Google, Inc.
*
@@ -37,25 +30,31 @@
#include "common.h"
#include "iomap.h"
-static void __init tegra30_dt_init(void)
+static struct of_dev_auxdata tegra_auxdata_lookup[] __initdata = {
+ {},
+};
+
+static void __init tegra_dt_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+tegra_auxdata_lookup, NULL);
}
-static const char *tegra30_dt_board_compat[] = {
+static const char * const tegra_dt_board_compat[] = {
+ "nvidia,tegra20",
"nvidia,tegra30",
"nvidia,tegra114",
NULL
};
-DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30/114 (Flattened Device Tree)")
+DT_MACHINE_START(TEGRA_DT, "NVIDIA Tegra SoC (Flattened Device Tree)")
.smp= smp_ops(tegra_smp_ops),
.map_io = tegra_map_common_io,
.init_early = tegra_init_early,
.init_irq = tegra_dt_init_irq,
.init_time = clocksource_of_init,
- .init_machine = tegra30_dt_init,
+ .init_machine = tegra_dt_init,
.init_late = tegra_init_late,
.restart= tegra_assert_system_reset,
- .dt_compat = tegra30_dt_board_compat,
+ .dt_compat = tegra_dt_board_compat,
MACHINE_END
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: tegra: Unify board-dt-tegra{30,114}.c
Refactored that Tegra114 uses board-dt-tegra30.
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/Makefile|2 +-
arch/arm/mach-tegra/board-dt-tegra114.c | 46 ---
arch/arm/mach-tegra/board-dt-tegra30.c |3 +-
3 files changed, 3 insertions(+), 48 deletions(-)
delete mode 100644 arch/arm/mach-tegra/board-dt-tegra114.c
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f6b46ae..1a08ecd 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_TEGRA_PCI) += pcie.o
obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= board-dt-tegra20.o
obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= board-dt-tegra30.o
-obj-$(CONFIG_ARCH_TEGRA_114_SOC) += board-dt-tegra114.o
+obj-$(CONFIG_ARCH_TEGRA_114_SOC) += board-dt-tegra30.o
ifeq ($(CONFIG_CPU_IDLE),y)
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += cpuidle-tegra114.o
endif
diff --git a/arch/arm/mach-tegra/board-dt-tegra114.c
b/arch/arm/mach-tegra/board-dt-tegra114.c
deleted file mode 100644
index 08e8294..000
--- a/arch/arm/mach-tegra/board-dt-tegra114.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * NVIDIA Tegra114 device tree board support
- *
- * Copyright (C) 2013 NVIDIA Corporation
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include
-#include
-#include
-
-#include
-
-#include "board.h"
-#include "common.h"
-
-static void __init tegra114_dt_init(void)
-{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
-
-static const char * const tegra114_dt_board_compat[] = {
- "nvidia,tegra114",
- NULL,
-};
-
-DT_MACHINE_START(TEGRA114_DT, "NVIDIA Tegra114 (Flattened Device Tree)")
- .smp= smp_ops(tegra_smp_ops),
- .map_io = tegra_map_common_io,
- .init_early = tegra_init_early,
- .init_irq = tegra_dt_init_irq,
- .init_time = clocksource_of_init,
- .init_machine = tegra114_dt_init,
- .init_late = tegra_init_late,
- .restart= tegra_assert_system_reset,
- .dt_compat = tegra114_dt_board_compat,
-MACHINE_END
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c
b/arch/arm/mach-tegra/board-dt-tegra30.c
index 63f8139..82cd85c 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -44,10 +44,11 @@ static void __init tegra30_dt_init(void)
static const char *tegra30_dt_board_compat[] = {
"nvidia,tegra30",
+ "nvidia,tegra114",
NULL
};
-DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
+DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30/114 (Flattened Device Tree)")
.smp= smp_ops(tegra_smp_ops),
.map_io = tegra_map_common_io,
.init_early = tegra_init_early,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] ARM: tegra: Unify tegra{20,30,114}_init_early()
Refactored tegra{20,30,114}_init_early() so that we have the unified
tegra_init_early().
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/board-dt-tegra114.c |2 +-
arch/arm/mach-tegra/board-dt-tegra20.c |2 +-
arch/arm/mach-tegra/board-dt-tegra30.c |4 ++--
arch/arm/mach-tegra/board.h |4 +---
arch/arm/mach-tegra/common.c| 26 ++
arch/arm/mach-tegra/hotplug.c | 31 +--
arch/arm/mach-tegra/sleep.h | 10 +-
7 files changed, 29 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-tegra/board-dt-tegra114.c
b/arch/arm/mach-tegra/board-dt-tegra114.c
index 085d636..08e8294 100644
--- a/arch/arm/mach-tegra/board-dt-tegra114.c
+++ b/arch/arm/mach-tegra/board-dt-tegra114.c
@@ -36,7 +36,7 @@ static const char * const tegra114_dt_board_compat[] = {
DT_MACHINE_START(TEGRA114_DT, "NVIDIA Tegra114 (Flattened Device Tree)")
.smp= smp_ops(tegra_smp_ops),
.map_io = tegra_map_common_io,
- .init_early = tegra114_init_early,
+ .init_early = tegra_init_early,
.init_irq = tegra_dt_init_irq,
.init_time = clocksource_of_init,
.init_machine = tegra114_dt_init,
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
index a0edf25..fca18e9 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -145,7 +145,7 @@ static const char *tegra20_dt_board_compat[] = {
DT_MACHINE_START(TEGRA_DT, "nVidia Tegra20 (Flattened Device Tree)")
.map_io = tegra_map_common_io,
.smp= smp_ops(tegra_smp_ops),
- .init_early = tegra20_init_early,
+ .init_early = tegra_init_early,
.init_irq = tegra_dt_init_irq,
.init_time = clocksource_of_init,
.init_machine = tegra_dt_init,
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c
b/arch/arm/mach-tegra/board-dt-tegra30.c
index bf68567..63f8139 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -3,7 +3,7 @@
*
* NVIDIA Tegra30 device tree board support
*
- * Copyright (C) 2011 NVIDIA Corporation
+ * Copyright (C) 2011, 2013, NVIDIA Corporation
*
* Derived from:
*
@@ -50,7 +50,7 @@ static const char *tegra30_dt_board_compat[] = {
DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
.smp= smp_ops(tegra_smp_ops),
.map_io = tegra_map_common_io,
- .init_early = tegra30_init_early,
+ .init_early = tegra_init_early,
.init_irq = tegra_dt_init_irq,
.init_time = clocksource_of_init,
.init_machine = tegra30_dt_init,
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 86851c8..60431de 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -26,9 +26,7 @@
void tegra_assert_system_reset(char mode, const char *cmd);
-void __init tegra20_init_early(void);
-void __init tegra30_init_early(void);
-void __init tegra114_init_early(void);
+void __init tegra_init_early(void);
void __init tegra_map_common_io(void);
void __init tegra_init_irq(void);
void __init tegra_dt_init_irq(void);
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 5449a3f..f0315c9 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -94,7 +94,7 @@ static void __init tegra_init_cache(void)
}
-static void __init tegra_init_early(void)
+void __init tegra_init_early(void)
{
tegra_cpu_reset_handler_init();
tegra_apb_io_init();
@@ -102,31 +102,9 @@ static void __init tegra_init_early(void)
tegra_init_cache();
tegra_pmc_init();
tegra_powergate_init();
+ tegra_hotplug_init();
}
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
-void __init tegra20_init_early(void)
-{
- tegra_init_early();
- tegra20_hotplug_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
-void __init tegra30_init_early(void)
-{
- tegra_init_early();
- tegra30_hotplug_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_TEGRA_114_SOC
-void __init tegra114_init_early(void)
-{
- tegra_init_early();
-}
-#endif
-
void __init tegra_init_late(void)
{
tegra_powergate_debugfs_init();
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a599f6e..9bcecb8 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -1,8 +1,7 @@
/*
- *
* Copyright (C) 2002 ARM Ltd.
* All Rights Reserved
- * Copyright (c) 2010, 2012 NVIDIA Corporation. All rights reserved.
+ * Copyright (c) 2010, 2012-2013, NVIDIA Corporation. All rights reserved.
*
* 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
@@ -15,6 +14,7 @@
#include
Re: [PATCH] dw_dmac: add support for Lynxpoint DMA controllers
On Fri, Feb 8, 2013 at 12:55 PM, Andy Shevchenko wrote: > Shall I resend it? Naah!! Vinod can manage it, i believe :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dw_dmac: add support for Lynxpoint DMA controllers
On Fri, Feb 8, 2013 at 6:28 AM, Viresh Kumar wrote: > On Thu, Feb 7, 2013 at 10:35 PM, Andy Shevchenko > wrote: >> On Thu, Feb 7, 2013 at 5:39 PM, Viresh Kumar wrote: >>> On 7 February 2013 21:06, Andy Shevchenko >>> wrote: From: Mika Westerberg ... Signed-off-by: Andy Shevchenko >>> >>> Looks like Mika is Author and you have your signed-off :) >> >> In this literally small and clear patch it doesn't matter who is who. > > I believe it doesn't matter how small or big is the patch, but the author > should > be there in SOBs too.. True. > >> However for sake of equity I could add Mika's signed-off-by as well. >> >> It should be: >> Signed-off-by: Mika Westerberg > > Thanks. Shall I resend it? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd:rtsx: Fix issue that booting OS with SD card inserted
From: Wei WANG
Realtek card reader supports both SD and MS card. According to the
settings of rtsx MFD driver, SD host will be probed before MS host.
If we boot/reboot Linux with SD card inserted, the resetting flow of SD
card will succeed, and the following resetting flow of MS is sure to fail.
Then MS upper-level driver will ask rtsx driver to turn power off. This
request leads to the result that the following SD commands fail and SD card
can't be accessed again.
In this commit, Realtek's SD and MS host driver will check whether the card
that upper driver requesting is the one existing in the slot. If not, Realtek's
host driver will refuse the operation to make sure the exlusive accessing
at the same time.
Signed-off-by: Wei WANG
---
drivers/memstick/host/rtsx_pci_ms.c |7 +++
drivers/mfd/rtsx_pcr.c | 30 ++
drivers/mmc/host/rtsx_pci_sdmmc.c | 18 ++
include/linux/mfd/rtsx_pci.h|2 ++
4 files changed, 57 insertions(+)
diff --git a/drivers/memstick/host/rtsx_pci_ms.c
b/drivers/memstick/host/rtsx_pci_ms.c
index f5ddb82..64a779c 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -426,6 +426,9 @@ static void rtsx_pci_ms_request(struct memstick_host *msh)
dev_dbg(ms_dev(host), "--> %s\n", __func__);
+ if (rtsx_pci_card_exclusive_check(host->pcr, RTSX_MS_CARD))
+ return;
+
schedule_work(>handle_req);
}
@@ -441,6 +444,10 @@ static int rtsx_pci_ms_set_param(struct memstick_host *msh,
dev_dbg(ms_dev(host), "%s: param = %d, value = %d\n",
__func__, param, value);
+ err = rtsx_pci_card_exclusive_check(host->pcr, RTSX_MS_CARD);
+ if (err)
+ return err;
+
switch (param) {
case MEMSTICK_POWER:
if (value == MEMSTICK_POWER_ON)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 822237e..481a98a 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -708,6 +708,25 @@ int rtsx_pci_card_power_off(struct rtsx_pcr *pcr, int card)
}
EXPORT_SYMBOL_GPL(rtsx_pci_card_power_off);
+int rtsx_pci_card_exclusive_check(struct rtsx_pcr *pcr, int card)
+{
+ unsigned int cd_mask[] = {
+ [RTSX_SD_CARD] = SD_EXIST,
+ [RTSX_MS_CARD] = MS_EXIST
+ };
+
+ if (!pcr->ms_pmos) {
+ /* When using single PMOS, accessing card is not permitted
+* if the existing card is not the designated one.
+*/
+ if (pcr->card_exist & (~cd_mask[card]))
+ return -EIO;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_card_exclusive_check);
+
int rtsx_pci_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
{
if (pcr->ops->switch_output_voltage)
@@ -784,6 +803,9 @@ static void rtsx_pci_card_detect(struct work_struct *work)
card_inserted = pcr->ops->cd_deglitch(pcr);
card_detect = card_inserted | card_removed;
+
+ pcr->card_exist |= card_inserted;
+ pcr->card_exist &= ~card_removed;
}
mutex_unlock(>pcr_mutex);
@@ -976,6 +998,14 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
return err;
}
+ /* No CD interrupt if probing driver with card inserted.
+* So we need to initialize pcr->card_exist here.
+*/
+ if (pcr->ops->cd_deglitch)
+ pcr->card_exist = pcr->ops->cd_deglitch(pcr);
+ else
+ pcr->card_exist = rtsx_pci_readl(pcr, RTSX_BIPR) & CARD_EXIST;
+
return 0;
}
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index f93f100..f981f7d 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -678,12 +678,19 @@ static void sdmmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
struct mmc_command *cmd = mrq->cmd;
struct mmc_data *data = mrq->data;
unsigned int data_size = 0;
+ int err;
if (host->eject) {
cmd->error = -ENOMEDIUM;
goto finish;
}
+ err = rtsx_pci_card_exclusive_check(host->pcr, RTSX_SD_CARD);
+ if (err) {
+ cmd->error = err;
+ goto finish;
+ }
+
mutex_lock(>pcr_mutex);
rtsx_pci_start_run(pcr);
@@ -901,6 +908,9 @@ static void sdmmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
if (host->eject)
return;
+ if (rtsx_pci_card_exclusive_check(host->pcr, RTSX_SD_CARD))
+ return;
+
mutex_lock(>pcr_mutex);
rtsx_pci_start_run(pcr);
@@ -1073,6 +1083,10 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
if (host->eject)
return -ENOMEDIUM;
+ err = rtsx_pci_card_exclusive_check(host->pcr,
Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
On Thu, Feb 7, 2013 at 11:05 PM, Arnd Bergmann wrote: > On Thursday 07 February 2013, Grant Likely wrote: >> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin > Of course, as long as the driver is only ever used to access > the same non-removable block device and you don't change > the driver, it does not matter at all whether you swap bytes > on the data port or not, because they are swapped on both > read and write, and it's just storage. Only if you try to > read the device with a "correct" driver, you will see a problem > if it was written with a "wrong" driver. It's actually a removable compact flash card interface. I know that the current big-endian support code is correct because my laptop doesn't complain about the data. :-) g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fat: eliminate iterations in fat_search_long and __fat_readdir in case of EOD
Namjae Jeon writes: >> And did this work correctly about f_pos for readdir? > Yes, sure. f_pos is work correctly about each directory entry. because > after name[0] == 0x00, there are no allocated directory entires. >> >> I'm not thinking about f_pos deeply though, it may have something >> wrong. Because it stops at middle of cluster. > Plz See the below descirption about name[0] in FAT spec. > - > If DIR_Name[0] == 0x00, then the directory entry is free (same as for > 0xE5), and there are no allocated directory entries after this one > (all of the DIR_Name[0] bytes in all of the entries after this one are > also set to 0). > The special 0 value, rather than the 0xE5 value, indicates to FAT file > system driver code that the rest of the entries in this directory do > not need to be examined because they are all free. > --- > > I think that lookuping entry till the end of cluster is not needed. > Let me know your opinion. I know it though. There is seek() and broken drivers adds entries after name[0] == 0. I think we don't need to care much about broken drivers though. Even if so, kernel should not be crash, and corrupts fs more. > And Would you tell me your opinion about fat exportfs ? Ah, I was thinking I did. But it seems I didn't actually. Can you post full of series? So, I can review and probably we can start to test it. Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: initialize runtime to non-zero on cfs bw set
If cfs_rq->runtime_remaining is <= 0 then either - cfs_rq is throttled and waiting for quota redistribution, or - cfs_rq is currently executing and will be throttled on put_prev_entity, or - cfs_rq is not throttled and has not executed since its quota was set (runtime_remaining is set to 0 on cfs bandwidth reconfiguration). It is obvious that the last case is rather an exception from the rule "runtime_remaining<=0 iff cfs_rq is throttled or will be throttled as soon as it finishes its execution". Moreover, it can lead to a task hang as follows. If put_prev_task is called immediately after first pick_next_task after quota was set, "immediately" meaning rq->clock in both functions is the same, then the corresponding cfs_rq will be throttled. Besides being unfair (the cfs_rq has not executed in fact), the quota refilling timer can be idle at that time and it won't be activated on put_prev_task because update_curr calls account_cfs_rq_runtime, which activates the timer, only if delta_exec is strictly positive. As a result we can get a task "running" inside a throttled cfs_rq which will probably never be unthrottled. To avoid the problem, the patch makes tg_set_cfs_bandwidth initialize runtime_remaining of each cfs_rq to 1 instead of 0 so that the cfs_rq will be throttled only if it has executed for some positive number of nanoseconds. -- Several times we had our customers encountered such hangs inside a VM (seems something is wrong or rather different in time accounting there). Analyzing crash dumps revealed that hung tasks were running inside cfs_rq's, which had the following setup cfs_rq->throttled=1 cfs_rq->runtime_enabled=1 cfs_rq->runtime_remaining=0 cfs_rq->tg->cfs_bandwidth.idle=1 cfs_rq->tg->cfs_bandwidth.timer_active=0 which conforms pretty nice to the explanation given above. Signed-off-by: Vladimir Davydov --- kernel/sched/core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 26058d0..c7a078f 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7686,7 +7686,7 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota) raw_spin_lock_irq(>lock); cfs_rq->runtime_enabled = runtime_enabled; - cfs_rq->runtime_remaining = 0; + cfs_rq->runtime_remaining = 1; if (cfs_rq->throttled) unthrottle_cfs_rq(cfs_rq); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] perf annotate: Make it to be able to skip unannotatable symbols
Hi Arnaldo,
On Mon, 4 Feb 2013 22:12:47 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 07, 2013 at 06:02:14PM +0900, Namhyung Kim escreveu:
>> From: Namhyung Kim
>>
>> Add --skip-missing option for skipping symbols that cannot be used for
>> annotation. It's the case of kernel symbols that user doesn't have a
>> vmlinux image file.
>>
>> Signed-off-by: Namhyung Kim
>> ---
>> tools/perf/builtin-annotate.c | 17 +++--
>
> You forgot to add the entry in the man page...
Arghh... resending..
-8<---
>From 797a62666d6098aaeda816279fa9181473762dc6 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Thu, 7 Feb 2013 17:37:03 +0900
Subject: [PATCH v2 7/7] perf annotate: Make it to be able to skip unannotatable
symbols
Add --skip-missing option for skipping symbols that cannot be used for
annotation. It's the case of kernel symbols that user doesn't have a
vmlinux image file.
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-annotate.txt | 3 +++
tools/perf/builtin-annotate.c | 17 +++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-annotate.txt
b/tools/perf/Documentation/perf-annotate.txt
index e5e1d06efc37..5ad07ef417f0 100644
--- a/tools/perf/Documentation/perf-annotate.txt
+++ b/tools/perf/Documentation/perf-annotate.txt
@@ -90,6 +90,9 @@ OPTIONS
--objdump=::
Path to objdump binary.
+--skip-missing::
+ Skip symbols that cannot be annotated.
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-report[1]
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 68e3a16abd3d..2e6961ea3184 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -37,6 +37,7 @@ struct perf_annotate {
bool force, use_tui, use_stdio, use_gtk;
bool full_paths;
bool print_line;
+ bool skip_missing;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -139,11 +140,21 @@ find_next:
}
if (use_browser == 2) {
- hist_entry__gtk_annotate(he, evidx, NULL);
- return;
+ int ret;
+
+ ret = hist_entry__gtk_annotate(he, evidx, NULL);
+ if (!ret || !ann->skip_missing)
+ return;
+
+ /* skip missing symbols */
+ nd = rb_next(nd);
} else if (use_browser == 1) {
key = hist_entry__tui_annotate(he, evidx, NULL);
switch (key) {
+ case -1:
+ if (!ann->skip_missing)
+ return;
+ /* fall through */
case K_RIGHT:
next = rb_next(nd);
break;
@@ -288,6 +299,8 @@ int cmd_annotate(int argc, const char **argv, const char
*prefix __maybe_unused)
"print matching source lines (may be slow)"),
OPT_BOOLEAN('P', "full-paths", _paths,
"Don't shorten the displayed pathnames"),
+ OPT_BOOLEAN(0, "skip-missing", _missing,
+ "Skip symbols that cannot be annotated"),
OPT_STRING('C', "cpu", _list, "cpu", "list of cpus to
profile"),
OPT_STRING(0, "symfs", _conf.symfs, "directory",
"Look for files with symbols relative to this directory"),
--
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: gpio-sch GPIO_SYSFS access
On 02/07/2013 08:40 PM, Darren Hart wrote:
>
>
> On 02/07/2013 02:09 AM, Linus Walleij wrote:
>> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>>
>>> Is it that some other driver has claimed these GPIO lines? If so, how do
>>> I determine which one?
>>
>> Yes I think that could be it, the driver would need to call
>> gpio_export() for it to also be accessible in sysfs.
>>
>> Configure in debugfs and check the file "gpio" in debugfs
>> to figure out the client.
>>
>> Yours,
>> Linus Walleij
>>
>
> I found gpio_export() as you suggested above and instrumented it. What I
> found was that it was not getting called at all. As I understand it,
> calling gpiochip_export() should make the gpiochip# appear in
> /sys/class/gpio and then I should be able to configure which lines are
> exported via the /sys/class/gpio/export file.
>
> I haven't yet found how gpio-pch differs from gpio-sch that causes the
> gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
> patch gpio-sch with a request and export loop:
>
> $ git diff drivers/gpio/gpio-sch.c
> diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
> index 8cadf4d..79783c1 100644
> --- a/drivers/gpio/gpio-sch.c
> +++ b/drivers/gpio/gpio-sch.c
> @@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
> static int __devinit sch_gpio_probe(struct platform_device *pdev)
> {
> struct resource *res;
> - int err, id;
> + int err, id, gpio;
>
> id = pdev->id;
> if (!id)
> @@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
> platform_device *p
> if (err < 0)
> goto err_sch_gpio_core;
>
> + /* DEBUG: export all the core GPIOS */
> + for (gpio = sch_gpio_core.base;
> +gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
> + gpio_request(gpio, "gpio-sch");
> + gpio_export(gpio, true);
> + }
> +
> err = gpiochip_add(_gpio_resume);
> if (err < 0)
> goto err_sch_gpio_resume;
>
> + /* DEBUG: export all the resume GPIOS */
> + for (gpio = sch_gpio_resume.base;
> +gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
> + gpio_request(gpio, "gpio-sch");
> + gpio_export(gpio, true);
> + }
> +
> return 0;
>
> err_sch_gpio_resume:
>
>
> With this both the gpiochip# and gpio# entries appear in sysfs. However,
> unlike those for the gpio-pch lines, these report an error in the sysfs
> interface:
>
> /sys/class/gpio# ls *
> ls: gpio0: No such file or directory
>
Well, this happens when the driver in question gets removed by another
driver. In this case the mfd/lpc_sch.c driver fails reading some PCI
config after it has added the gpio-pch device to a list:
lpc_sch :00:1f.0: Decode of the WDT I/O range disabled
It then proceeds to remove all the devices it added - including gpio-pch.c.
Dragging Samuel in as his name is on some of the commits, maybe he can
help here.
Samuel, does it make sense for CONFIG_GPIO_SCH to require
CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
There is no SCH as I understand things. Can these be decoupled?
I should note that if I just refuse to remove the gpio-sch with -EBUSY,
the gpiochip files show up in /sys:
# ls /sys/class/gpio/
export gpiochip0gpiochip244 gpiochip5unexport
and debugfs/gpio shows the sch gpio ranges:
GPIOs 0-4,platform/sch_gpio.33158,sch_gpio_core:
GPIOs 5-13, platform/sch_gpio.33158, sch_gpio_resume:
GPIOs 244-255, :02:00.2:
Unfortunatley, they still fail to export:
# echo 0 > /sys/class/gpio/export
gpio_export: gpio0 status -2
export_store: status -2
sh: write error: No such file or directory
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux 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/
Re: [PATCHv5,RESEND 8/8] drm: tegra: Add gr2d device
On Wed, Feb 06, 2013 at 01:23:17PM -0800, Terje Bergström wrote:
> On 05.02.2013 01:54, Thierry Reding wrote:
> > On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergström wrote:
> >> Yeah, it's actually working around the host1x duplicate naming.
> >> host1x_syncpt_get takes struct host1x as parameter, but that's different
> >> host1x than in this code.
> >
> > So maybe a better way would be to rename the DRM host1x after all. If it
> > avoids the need for workarounds such as this I think it justifies the
> > additional churn.
>
> Ok, I'll include that. Do you have a preference for the name? Something
> like "host1x_drm" might work?
Yes, that sounds good.
> >>> Also, how useful is it to create a context? Looking at the gr2d
> >>> implementation for .open_channel(), it will return the same channel to
> >>> whichever userspace process requests them. Can you explain why it is
> >>> necessary at all? From the name I would have expected some kind of
> >>> context switching to take place when different applications submit
> >>> requests to the same client, but that doesn't seem to be the case.
> >>
> >> Hardware context switching will be a later submit, and it'll actually
> >> create a new structure. Hardware context might live longer than the
> >> process that created it, so they'll need to be separate.
> >
> > Why would it live longer than the process? Isn't the whole purpose of
> > the context to keep per-process state? What use is that state if the
> > process dies?
>
> Hardware context has to be kept alive for as long as there's a job
> running from that process. If an app sends 10 jobs to 2D channel, and
> dies immediately, there's no sane way for host1x to remove the jobs from
> queue. The jobs will keep on running and kernel will need to track them.
Okay, I understand now. There was one additional thing that I wanted to
point out, but the context is gone now. I'll go through the patch again
and reply there.
> > I fail to see how dma_buf would require a separate mem_mgr_type. Can we
> > perhaps postpone this to a later point and just go with CMA as the only
> > alternative for now until we have an actual working implementation that
> > we can use this for?
>
> Each submit refers to a number of buffers. Some of them are the streams,
> some are textures or other input/output buffers. Each of these buffers
> might be passed as a GEM handle, or (when implemented) as a dma_buf fd.
> Thus we need a field to tell host1x which API to call to handle that handle.
Understood.
> I think we can leave out the code for managing the type until we
> actually have separate memory managers. That'd make GEM handles
> effectively of type 0, as we don't set it.
I think that's a good idea. Let's start simple for now and who knows
what else will have changed by the time we get to implement dma_buf.
Maybe Lucas will have finished his work on the allocator and we will
need to synchronize with that anyway.
> +static int gr2d_submit(struct host1x_drm_context *context,
> + struct tegra_drm_submit_args *args,
> + struct drm_device *drm,
> + struct drm_file *file_priv)
> +{
> + struct host1x_job *job;
> + int num_cmdbufs = args->num_cmdbufs;
> + int num_relocs = args->num_relocs;
> + int num_waitchks = args->num_waitchks;
> + struct tegra_drm_cmdbuf __user *cmdbufs =
> + (void * __user)(uintptr_t)args->cmdbufs;
> + struct tegra_drm_reloc __user *relocs =
> + (void * __user)(uintptr_t)args->relocs;
> + struct tegra_drm_waitchk __user *waitchks =
> + (void * __user)(uintptr_t)args->waitchks;
> >>>
> >>> No need for all the uintptr_t casts.
> >>
> >> Will try to remove - but I do remember getting compiler warnings without
> >> them.
> >
> > I think you shouldn't even have to cast to void * first. Just cast to
> > the target type directly. I don't see why the compiler should complain.
>
> This is what I get without them:
>
> drivers/gpu/host1x/drm/gr2d.c:108:3: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> drivers/gpu/host1x/drm/gr2d.c:110:3: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> drivers/gpu/host1x/drm/gr2d.c:112:3: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-c
>
> The problem is that the fields are __u64's and can't be cast directly
> into 32-bit pointers.
Alright.
> >> That's the security firewall. It walks through each submit, and ensures
> >> that each register write that writes an address, goes through the host1x
> >> reloc mechanism. This way user space cannot ask 2D to write to arbitrary
> >> memory locations.
> >
> > I see. Can this be made more generic? Perhaps adding a table of valid
> > registers to the device and use a generic function to iterate over that
> > instead of having to provide the same function for each
Re: [PATCH] vmalloc: Remove alloc_map from vmap_block.
On Fri, Feb 08, 2013 at 12:37:13PM +0900, Chanho Min wrote: > >I started looking for workloads to profile but then lost interest. > >The current code can theoretically end up walking through a lot of > >partially used blocks if a string of allocations never fit any of > >them. The number of these blocks depends on previous allocations that > >leave them unusable for future allocations and whether any other > >vmalloc/vmap user recently flushed them all. So it's painful to think > >about it and hard to impossible to pin down should this ever actually > >result in a performance problem. > > vm_map_ram() is allowed to be called by external kernel module. > I profiled some kernel module as bellow perf log. Its mapping behavior > was most of the workload. yes, we can improve its inefficient mapping. > But, This shows the allocation bitmap has the potential to cause significant > overhead. No question that you can find a scenario where this bitmap becomes expensive. And I don't think we should leave the code as is, because it really is a waste of time for cpus and readers of the code. The question is whether we put the bitmap to good use and implement partial block recycling, or keep with the current allocation model but make it a little less expensive. Nobody actually seems interested in implementing partial block recycling and we do have multiple patches to ditch the bitmap. I think we should probably merge the patch that we have and save some wasted cycles, that doesn't prevent anyone from improving the algorithm later on. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] eventfd: implementation of EFD_MASK flag
On 08/02/13 07:36, Andy Lutomirski wrote: On 08/02/13 02:03, Andy Lutomirski wrote: There may be some advantage to adding (later on, if needed) an option to change the flags set in: + if (waitqueue_active(>wqh)) + wake_up_locked_poll(>wqh, + (unsigned long)ctx->mask.events); (i.e. to allow the second parameter to omit some bits that were already signaled.) Allowing write to write a bigger struct in the future won't break anything. I think I don't follow. Either the second parameter is supposed to be *newly* signaled events, in which case the events that were already signaled in the past should be ommitted, or it is meant to be *all* signaled events, in which case the current implementation is OK. I defer to the experts here. But I suspect that if you want to perfectly emulate sockets, you may need to vary what you specify. (IIRC tcp sockets report an EPOLLIN edge every time data is received even if the receive buffer wasn't empty.) Hm. That sounds like leaking protocol implementation details to the user. That's a bad design IMO and should not be encouraged. Anyway, I have implemented your other suggestions. Btw, one thing I am not sure about is how to submit improved patches to the ML. Should I use the same patch name? Doesn't that cause confusion? Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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,RESEND 4/8] gpu: host1x: Add debug support
On Wed, Feb 06, 2013 at 12:58:19PM -0800, Terje Bergström wrote:
> On 05.02.2013 01:15, Thierry Reding wrote:
> > On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergström wrote:
> >> This is used by debugfs code to direct to debugfs, and
> >> nvhost_debug_dump() to send via printk.
> >
> > Yes, that was precisely my point. Why bother providing the same data via
> > several output methods. debugfs is good for showing large amounts of
> > data such as register dumps or a tabular representation of syncpoints
> > for instance.
> >
> > If, however, you want to interactively show debug information using
> > printk the same format isn't very useful and something more reduced is
> > often better.
>
> debugfs is there to be able to get a reliable dump of host1x state
> (f.ex. no lines intermixed with other output).
>
> printk output is there because often we get just UART logs from failure
> cases, and having as much information as possible in the logs speeds up
> debugging.
>
> Both of them need to output the values of sync points, and the channel
> state. Dumping all of that consists of a lot of code, and I wouldn't
> want to duplicate that for two output formats.
I'm still not convinced, but I think I could live with it. =)
> >> I have another suggestion. In downstream I removed the decoding part and
> >> I just print out a string of hex. That removes quite a bit bunch of code
> >> from kernel. It makes the debug output also more compact.
> > I don't know. I think if you use in-kernel debugging facilities such as
> > debugfs or printk, then the output should be self-explanatory. However I
> > do see the usefulness of having a binary dump that can be decoded in
> > userspace. But I think if we want to go that way we should make that a
> > separate interface. USB provides something like that, which can then be
> > fed to libpcap or wireshark to capture and analyze USB traffic. If done
> > properly you get replay functionality for free. I don't know what infra-
> > structure exists to help with implementing something similar.
>
> It's not actually binary. I think I misrepresented the suggestion.
>
> I'm suggesting that we'd display only the contents of command FIFO and
> contents of gathers (i.e. all opcodes) in hex format, not decoded. All
> other text would remain as is, so syncpt values, etc would be readable
> by a glance.
>
> The user space tool can then take the streams and decode them if needed.
>
> We've noticed that the decoded opcodes format can be very long and
> sometimes takes a minute to dump out via a slow console. The hex output
> is much more compact and faster to dump.
>
> Actual tracing or wireshark kind of capability would come via decoding
> the ftrace log. When enabled, everything that is written to the channel,
> is also written to ftrace.
Okay, I'll have to take a closer look at ftrace since I've never used it
before. It sounds like extra infrastructure won't be necessary then.
> +static void show_channel_word(struct output *o, int *state, int *count,
> +u32 addr, u32 val, struct host1x_cdma *cdma)
> +{
> +static int start_count, dont_print;
> >>>
> >>> What if two processes read debug information at the same time?
> >>
> >> show_channels() acquires cdma.lock, so that shouldn't happen.
> >
> > Okay. Another solution would be to pass around a debug context which
> > keeps track of the variables. But if we opt for a more involved dump
> > interface as discussed above this will no longer be relevant.
>
> Actually, debugging process needs cdma.lock, because it goes through the
> cdma queue. Also command FIFO dumping is something that must be done by
> a single thread at a time.
>
> > Okay. In the context of a channel dump interface this may not be
> > relevant anymore. Can you think of any issue that wouldn't be detectable
> > or debuggable by analyzing a binary dump of the data within a channel?
> > I'm asking because at that point we wouldn't be able to access any of
> > the in-kernel data structures but would have to rely on the data itself
> > for diagnostics. IOMMU virtual addresses won't be available and so on.
>
> In many cases, looking at syncpt values, and channel state
> (active/waiting on a syncpt, etc) gives an indication on what is the
> current state of hardware. But, very often problems are ripple effects
> on something that happened earlier and the job that caused the problem
> has already been freed and is not visible in the dump.
>
> To get a full history, we need often need the ftrace log.
So that's already covered. Great!
Thierry
pgpcnj7iSskoz.pgp
Description: PGP signature
Re: [PATCHv3 4/4] arm: Add generic timer broadcast support
Mark, On Thursday 07 February 2013 10:47 PM, Mark Rutland wrote: [..] I believe the patch below will fix this for Tegra and any other platforms where broadcast is required in low power states. From the Stephan's crash the issue is pretty clear and your patch make sense. Some how I didn't manage to reproduce the issue on my board and hence assumed everything is just fine. Will have a look at it later why it didn't explode since it was so obvious. Sorry for the noise. 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: [PATCH RESEND] ARM: sched: correct update_sched_clock()
Hello, Russell. On Wed, Feb 06, 2013 at 04:33:55PM +, Russell King - ARM Linux wrote: > On Wed, Feb 06, 2013 at 10:33:53AM +0100, Linus Walleij wrote: > > On Wed, Feb 6, 2013 at 6:21 AM, Joonsoo Kim wrote: > > > > > If we want load epoch_cyc and epoch_ns atomically, > > > we should update epoch_cyc_copy first of all. > > > This notify reader that updating is in progress. > > > > If you think the patch is finished, put it into Russell's patch tracker: > > http://www.arm.linux.org.uk/developer/patches/ > > Yea, this patch looks like the right thing... and yes, into the patch > system please. I try to put it into patch tracker, but I fail to put it. I use following command. git send-email --to patc...@arm.linux.org.uk 0001-ARM-sched-correct~ Am I wrong? Could you teach me how to put patch into your patch tracker? I already read "help" on your website, but I can't find any stuff for "git send-email". Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] asm-generic: io: Fix ioread16/32be and iowrite16/32be
On Thu, Feb 7, 2013 at 3:18 PM, Michal Simek wrote:
> Fix ioreadXXbe and iowriteXXbe functions which did
> additional little endian conversion on native big endian systems.
> Using be_to_cpu (cpu_to_be) conversions with __raw_read/write
> functions have resolved it.
>
> Signed-off-by: Michal Simek
> CC: Benjamin Herrenschmidt
> CC: Arnd Bergmann
> CC: Geert Uytterhoeven
> CC: Will Deacon
> CC: linux-a...@vger.kernel.org
I have one question (see below). Apart from that:
Acked-by: Geert Uytterhoeven
> -#define ioread16be(addr) be16_to_cpu(ioread16(addr))
> +#define ioread16be(addr) __be16_to_cpu(__raw_readw(addr))
Why did you change it to the __beX_to_cpu variant with underscores?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 4/4] arm: Add generic timer broadcast support
On Thursday 07 February 2013 10:21 PM, Stephen Warren wrote: On 02/07/2013 04:40 AM, Santosh Shilimkar wrote: [...] Stephan, Do we have crash log seen on Tegra ? Which tegra CPUIDLE driver is being used when crash is seen ? The crash log is below. It's simply because td->evt->broadcast is NULL because it wasn't ever set. Thanks for the log. Its clear from the log that broadcast event wasn't set. 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: [PATCH v3] usb: phy: moving all PHY API definitions to usb/phy directory
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Stephen Warren > Sent: Thursday, February 07, 2013 10:26 PM > To: kishon > Cc: Venu Byravarasu; ba...@ti.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; linux-...@vger.kernel.org > Subject: Re: [PATCH v3] usb: phy: moving all PHY API definitions to usb/phy > directory > > On 02/07/2013 06:38 AM, kishon wrote: > > On Thursday 07 February 2013 05:02 PM, Venu Byravarasu wrote: > >> As drivers/usb/otg/otg.c contains most of the PHY related APIs which > >> are not OTG specific, moving them to more logical place under > >> drivers/usb/phy. > > >> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile > >> index b13faa1..886be13 100644 > >> --- a/drivers/usb/phy/Makefile > >> +++ b/drivers/usb/phy/Makefile > >> @@ -4,6 +4,7 @@ > >> > >> ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG > >> > >> +obj-$(CONFIG_USB_COMMON)+= phy.o > > > > I think we should have a separate config for PHYs. There might be > > controllers which dont need separate PHY. But we can have that as a > > separate patch later since we might want to change the Kconfig of other > > UDC drivers. Thanks Kishon for review comments. Agree to your comments that we can add a new config for PHY & push it in a separate patch. > > >> +/* > >> + * phy.c -- USB PHY utility code > >> + * > >> + * Copyright (C) 2004 Texas Instruments > > > > You can update this to 2013. > > I'm not sure if anyone other that TI can do that? > > >> +EXPORT_SYMBOL_GPL(usb_bind_phy); > >> + > >> + > > > > Unnecessary spaces here. > Will remove them in next patch update. > Thanks for the review. It was very difficult to find you review comments > since you quoted the entire patch rather than just the few pieces you > were commenting on... > > > You might want to do this patch after applying *[PATCH] usb: otg: use > > try_module_get in all usb_get_phy functions and add missing module_put* > > by Marc. > > Venu, please make sure you include the changes in that patch in your > Tegra USB/PHY driver rework too, before you post it upstream. Sure Stephen, thanks for your comments. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 1/1] eventfd: implementation of EFD_MASK flag
On Thu, Feb 7, 2013 at 9:26 PM, Martin Sustrik wrote: > Hi Andy, > > > On 08/02/13 02:03, Andy Lutomirski wrote: >> >> There may be some >> advantage to adding (later on, if needed) an option to change the >> flags set in: >> >> + if (waitqueue_active(>wqh)) >> + wake_up_locked_poll(>wqh, >> + (unsigned long)ctx->mask.events); >> >> (i.e. to allow the second parameter to omit some bits that were >> already signaled.) Allowing write to write a bigger struct in the >> future won't break anything. > > > I think I don't follow. Either the second parameter is supposed to be > *newly* signaled events, in which case the events that were already signaled > in the past should be ommitted, or it is meant to be *all* signaled events, > in which case the current implementation is OK. I defer to the experts here. But I suspect that if you want to perfectly emulate sockets, you may need to vary what you specify. (IIRC tcp sockets report an EPOLLIN edge every time data is received even if the receive buffer wasn't empty.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
Il 08/02/2013 05:05, Rusty Russell ha scritto:
> Paolo Bonzini writes:
>> The virtqueue_add_buf function has two limitations:
>>
>> 1) it requires the caller to provide all the buffers in a single call;
>>
>> 2) it does not support chained scatterlists: the buffers must be
>> provided as an array of struct scatterlist.
>>
>> Because of these limitations, virtio-scsi has to copy each request into
>> a scatterlist internal to the driver. It cannot just use the one that
>> was prepared by the upper SCSI layers.
>
> Hi Paulo,
>
> Note that you've defined your problem in terms of your solution
> here. For clarity:
Good catch. :)
> The problem: we want to prepend and append to a scatterlist. We can't
> append, because the chained scatterlist implementation requires
> an element to be appended to join two scatterlists together.
>
> The solution: fix scatterlists by introducing struct sg_ring:
> struct sg_ring {
> struct list_head ring;
> unsigned int nents;
> unsigned int orig_nents; /* do we want to replace sg_table? */
> struct scatterlist *sg;
> };
>
> The workaround: make virtio accept multiple scatterlists for a single
> buffer.
>
> There's nothing wrong with your workaround, but if other subsystems have
> the same problem we do, perhaps we should consider a broader solution?
Do they? Given the resistance you have had on the topic, perhaps they
don't (though I agree that chained scatterlist are horrible).
But I'll add a note on this to the commit message and why the workaround
is IMHO acceptable.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fat: eliminate iterations in fat_search_long and __fat_readdir in case of EOD
2013/2/7, OGAWA Hirofumi : > Namjae Jeon writes: > >> From: Namjae Jeon >> >> When doing lookups via fat_search_long(), we can stop checking for >> further entries if we detect End of Directory, i.e. if (de->name[0] == >> 0x00).The current code traverses the cluster chain of a directory until a >> hit >> is found or till the last cluster for that directory, ignoring the EOD >> mark. Fix this. >> >> Likewise,when readdir(3) is called, we can stop checking for further >> entries in __fat_readdir() when we hit EOD. > Hi OGAWA. > Don't we need to change fat_get_short_entry()? Yes, We need to change here. Thanks for review! > And did this work correctly about f_pos for readdir? Yes, sure. f_pos is work correctly about each directory entry. because after name[0] == 0x00, there are no allocated directory entires. > > I'm not thinking about f_pos deeply though, it may have something > wrong. Because it stops at middle of cluster. Plz See the below descirption about name[0] in FAT spec. - If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0). The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free. --- I think that lookuping entry till the end of cluster is not needed. Let me know your opinion. And Would you tell me your opinion about fat exportfs ? Thanks! > > Thanks. > -- > OGAWA Hirofumi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On Fri, Feb 08, 2013 at 10:39:13AM +0530, Viresh Kumar wrote:
> On 8 February 2013 04:37, Rafael J. Wysocki wrote:
> > BTW, there still are locking problems in linux-next. Why do we need
> > to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(),
> > in particular?
> I thought a bit more and realized there is no such limitation on
> cpufreq_driver->ops about calling routines which can sleep. And thus
> we shoudln't
> have locks around any of these. I have got a patch for it, that i
> would fold-back into
> the original patch that introduced locking fixes (attached too for testing):
Tested this patch on top of linux-pm.git/bleeding-edge
Now everything seems to be alright.
> From: Viresh Kumar
> Date: Fri, 8 Feb 2013 10:35:31 +0530
> Subject: [PATCH] cpufreq: Remove unnecessary locking
>
> I have placed some locks intentionally around calls to driver->ops
> (init/exit),
> which look to be wrong as these calls can call routines that potentially
> sleep.
>
> Lets remove these locks.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5d8a422..04aab05 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>
> if (ret) {
> pr_debug("setting policy failed\n");
> - spin_lock_irqsave(_driver_lock, flags);
> if (driver->exit)
> driver->exit(policy);
> - spin_unlock_irqrestore(_driver_lock, flags);
> }
> return ret;
>
> @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif)
> init_completion(>kobj_unregister);
> INIT_WORK(>update, handle_update);
>
> - spin_lock_irqsave(_driver_lock, flags);
> /* call driver. From then on the cpufreq must be able
>* to accept all calls to ->verify and ->setpolicy for this CPU
>*/
> ret = driver->init(policy);
> if (ret) {
> pr_debug("initialization failed\n");
> - spin_unlock_irqrestore(_driver_lock, flags);
> goto err_set_policy_cpu;
> }
> - spin_unlock_irqrestore(_driver_lock, flags);
>
> /* related cpus should atleast have policy->cpus */
> cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
> @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> wait_for_completion(cmp);
> pr_debug("wait complete\n");
>
> - spin_lock_irqsave(_driver_lock, flags);
> if (driver->exit)
> driver->exit(data);
> - spin_unlock_irqrestore(_driver_lock, flags);
>
> free_cpumask_var(data->related_cpus);
> free_cpumask_var(data->cpus);
Tested-by: Artem Savkov
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 2/3] mmc: davinci_mmc: add DT support
Hi Mark,
On Thu, Feb 07, 2013 at 16:16:56, Mark Rutland wrote:
> Hello,
>
> I have a couple of comments on the dt bindings and the way it's parsed.
>
Thanks for your review comments.
> On Thu, Feb 07, 2013 at 07:57:04AM +, Manjunathappa, Prakash wrote:
> > Adds device tree support for davinci_mmc. Also add binding documentation.
> > Tested in non-dma PIO mode and without GPIO card_detect/write_protect
> > option because of dependencies on EDMA and GPIO module DT support.
> >
> > Signed-off-by: Manjunathappa, Prakash
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: davinci-linux-open-sou...@linux.davincidsp.com
> > Cc: devicetree-disc...@lists.ozlabs.org
> > Cc: c...@laptop.org
> > Cc: Sekhar Nori
> > Cc: mpor...@ti.com
> > ---
> > Since v1:
> > Modified DT parse function to take default values and accomodate controller
> > version in compatible field.
> >
> > .../devicetree/bindings/mmc/davinci_mmc.txt| 30
> > drivers/mmc/host/davinci_mmc.c | 70
> > +++-
> > 2 files changed, 99 insertions(+), 1 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> > b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> > new file mode 100644
> > index 000..6717ab1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
> > @@ -0,0 +1,30 @@
> > +* TI Highspeed MMC host controller for DaVinci
> > +
> > +The Highspeed MMC Host Controller on TI DaVinci family
> > +provides an interface for MMC, SD and SDIO types of memory cards.
> > +
> > +This file documents the properties used by the davinci_mmc driver.
> > +
> > +Required properties:
> > +- compatible:
> > + Should be "ti,davinci-mmc-da830": for da830, da850, dm365
> > + Should be "ti,davinci-mmc-dm355": for dm355, dm644x
> > +
> > +Optional properties:
> > +- bus-width: Number of data lines, can be <4>, or <8>, default <1>
> > +- max-frequency: Maximum operating clock frequency, default 25MHz.
> > +- mmc-cap-mmc-highspeed: Indicates support for MMC in high speed mode
> > +- mmc-cap-sd-highspeed: Indicates support for SD in high speed mode
>
> I thought the last two were derivable from max-frequency?
>
Yes, but I see below comment that it doesnot support MMC/SD.
arch/arm/mach-davinci/devices.c: davinci_setup_mmc
"
* FIXME dm6441 (no MMC/SD), dm357 (one), and dm335 (two) are
* not handled right here ...
*/"
I was wondering how do we support such platforms, so I thought it is necessary
to have these. But I see that on da850-evm even on skipping above flags EVM is
able
to detect card, does it mean there is no way to specify "no SD/MMC" capability?
I will remove these and decide highspeed capability based on max-frequency.
> https://lkml.org/lkml/2012/10/15/231
>
> [...]
>
> > +static struct davinci_mmc_config
> > + *mmc_parse_pdata(struct platform_device *pdev)
> > {
> > + struct device_node *np;
> > struct davinci_mmc_config *pdata = pdev->dev.platform_data;
> > + const struct of_device_id *match =
> > + of_match_device(of_match_ptr(davinci_mmc_dt_ids), >dev);
> > + u32 data;
> > +
> > + np = pdev->dev.of_node;
> > + if (!np)
> > + return pdata;
> > +
> > + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata) {
> > + dev_err(>dev, "Failed to allocate memory for struct
> > davinci_mmc_config\n");
> > + goto nodata;
> > + }
> > +
> > + if (match->data)
> > + pdata->version = (u8)((int)match->data);
> > +
> > + of_property_read_u32(np, "max-frequency", >max_freq);
> > + if (!pdata->max_freq)
> > + dev_info(>dev, "'max-frequency' property not specified,
> > defaulting to 25MHz\n");
> > +
> > + if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
> > + pdata->caps |= MMC_CAP_MMC_HIGHSPEED;
> > + if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
> > + pdata->caps |= MMC_CAP_SD_HIGHSPEED;
>
> If these aren't derivable from max-frequency, you could use
> of_property_read_bool to make this clearer.
>
Correct, I will decide these based on max-frequency.
> > +
> > + of_property_read_u32(np, "bus-width", );
> > + switch (data) {
> > + case 0:
>
> Judging by the binding doc, should this be 1 rather than 0?
>
By default driver comes up in 4 bit mode when bus-width is not specified.
Bus-width is set to 1 bit for invalid bus-widths. Below are the cases
when bus-width 0 or 4, bus-width is set to 4bit mode
When bus-width is 8, bus-width is set to 8 bit mode
I thought that if somebody specifies bus-width as 2, 3, 5, 6, 7..., then
it should be defaulted to 1 bit mode, so I specified it as 1 bit in binding doc.
But I feel that a person who is editing dts file will not make such a mistake.
I will change
Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
On Fri, Feb 8, 2013 at 12:05 AM, Arnd Bergmann wrote:
>> The same is true for the data port. A BE read does the right thing on
>> a BE platform, and LE read on a LE platform. (again, this is all about
>> bus attachment). However, the difference is what is then done with the
>> data.
>
> Well, except that we cannot use the ioread16be_rep function,
ioread16_rep
> which is made for the case where the bus does not swap.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.8-rc6-nohz4
On Thu, 2013-02-07 at 19:14 +, Christoph Lameter wrote: > On Thu, 7 Feb 2013, Frederic Weisbecker wrote: > > > Not with hrtick. > > hrtick? Did we not already try that a couple of years back and it turned > out that the overhead of constantly reprogramming a timer via the PCI bus > was causing too much of a performance regression? Yup. -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 2/5] arcmsr: Support Hibernation
Please ignore the last mails with checkpatch file. Thanks, -Original Message- From: NickCheng [mailto:nick.ch...@areca.com.tw] Sent: Friday, February 08, 2013 2:03 PM To: 'linux-s...@vger.kernel.org' Cc: 'linux-kernel@vger.kernel.org'; 'j...@kernel.org'; 黃清隆 Subject: [PATCH 2/5] arcmsr: Support Hibernation From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arcmsr: Modify ARC-1214 Inband Messages Behavior
From: Nick Cheng Modify ARC-1214 inband messages behavior to make up for HW seldom malfunction. Signed-off-by: Nick Cheng --- patch5 Description: Binary data
[PATCH 2/5] arcmsr: Support Hibernation
From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- patch2 Description: Binary data
[PATCH 3/5] arcmsr: Support MSI and MSI-X
From: Nick Cheng Support MSI or MSI-X for whole series of RAID controllers. Meanwhile correct the register access as iowrite32/ioread32 Signed-off-by: Nick Cheng --- patch3 Description: Binary data
[PATCH 4/5] arcmsr: Support a New RAID Model, ARC-1214
From: Nick Cheng Add a New RAID Model, ARC-1214, which can support 8 SATA HDs at most, so far. Signed-off-by: Nick Cheng --- checkpatch4 Description: Binary data
[PATCH 5/5] arcmsr: Modify ARC-1214 Inband Messages Behavior
From: Nick Cheng Modify ARC-1214 inband messages behavior to make up for HW seldom malfunction. Signed-off-by: Nick Cheng --- checkpatch5 Description: Binary data
[PATCH 3/5] arcmsr: Support MSI and MSI-X
From: Nick Cheng Support MSI or MSI-X for whole series of RAID controllers. Meanwhile correct the register access as iowrite32/ioread32 Signed-off-by: Nick Cheng --- checkpatch3 Description: Binary data
[PATCH 2/5] arcmsr: Support Hibernation
From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- checkpatch2 Description: Binary data
Re: [BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
On 7 February 2013 06:11, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: cpufreq: Move sysfs_remove_link() from under a spinlock > > Commit 73bf0fc "cpufreq: Don't remove sysfs link for policy->cpu" > attempted to fix a bug in __cpufreq_remove_dev() by avoiding to > remove the link to the "cpufreq" directory for policy->cpu, but it > rearranged the code in such a way that sysfs_remove_link() ended up > under a spinlock, which caused complaints about sleeping in atomic > context to be emitted into the kernel log during system suspend. > > To fix this, revert commit 73bf0fc partially and move the > sysfs_remove_link() in question to a separate block executed for > cpus > 1 outside of the spinlock. > > Signed-off-by: Rafael J. Wysocki BTW, i have dropped this patch completely as i got another lock fixing patch :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next build conflict between modules and metag trees (LOCKDEP_NOW_UNRELIABLE)
Hi Vineet,
On Fri, 8 Feb 2013 10:46:24 +0530 Vineet Gupta
wrote:
>
> On Thursday 07 February 2013 04:46 PM, James Hogan wrote:
> >
> > The metag architecture tree adds an add_taint(TAINT_DIE) like other
> > architectures do, and the modules-next tree adds the
> > LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously
> > misses arch/metag since it doesn't exist yet), causing a compile error
> > on metag in -next when the two are merged together.
> >
> > Is it okay for me to merge your commit 373d4d0 ("taint: add explicit
> > flag to show whether lock dep is still OK.") in modules-next into the
> > base of the metag tree and expect it not to be rebased, so that I can
> > then squash the fix into the metag tree?
> >
> > The only commits this would include are:
> > $ git log --oneline linus/master..373d4d0
> > 373d4d0 taint: add explicit flag to show whether lock dep is still OK.
> > 64748a2 module: printk message when module signature fail taints kernel.
>
> Being in the same situation as metag (ARC Port), what's the recommended
> practice
> here - do we simply cherry-pick these changes into our tree - or do we merge
> the
> "other" tree on top - ofcourse with premise that "other" tree will not rebase.
Merging is better, as then the commits only exist once when your tree
gets merged back into Linus' tree. However, such a merge should explain
why it is being done. Assuming that the thing you merge does not get
rebased - which in this case, Rusty has said it won;t be.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpRRP2QDrAUA.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the nfsd tree
03.02.2013 18:41, J. Bruce Fields пишет:
On Sat, Feb 02, 2013 at 07:57:19AM -0500, J. Bruce Fields wrote:
On Sat, Feb 02, 2013 at 01:04:03PM +1100, Stephen Rothwell wrote:
Hi,
After merging the nfsd tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/nfs/dns_resolve.c: In function 'nfs_dns_resolver_cache_init':
fs/nfs/dns_resolve.c:375:4: error: 'struct cache_detail' has no member named
'cache_upcall'
fs/nfs/dns_resolve.c:375:35: warning: left-hand operand of comma expression has
no effect [-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
fs/nfs/dns_resolve.c:375:35: warning: value computed is not used
[-Wunused-value]
Caused by commit aab982cb5dfb ("SUNRPC: remove cache_detail->cache_upcall
callback").
Yes, I knew why we'd introduced cache_upcall, so I'm not sure how I
overlooked that. It must have slipped through testing because I didn't
set CONFIG_NFS_USE_KERNEL_DNS.
We may just be able to revert that patch I can take care of that by
tomorrow.
Stanislav, any objections to this?
The only objection is that I've sent you the patch set witch fixes all these
problems already:
"[PATCH v2 0/6] SUNRPC: rework cache upcall to avoid NFSd root". :)
The only reason why I removed cache_upcall at all was that all it's users (except NFS DNS cache - my mistake) just call sunrpc_cache_pipe_upcall and thus these
wrapper looked redundant to me.
Second patch set leaves cache_upcall only for NFS DNS cache (since this upcall
is not just a wrapper around sunrpc_cache_pipe_upcall).
And second patch set implies the first one will be dropped.
I can, actually, send one more (incremental this time) patch set to fix the
problem, if you wish.
But it's up to you, what to commit, Bruce.
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: davinci_wdt: update to devm_* API
On Thu, Feb 07, 2013 at 09:02:15, Kumar, Anil wrote:
> Update the code to use devm_* API so that driver
> core will manage resources.
>
> Signed-off-by: Kumar, Anil
> ---
> This patch applies on top of v3.8-rc6.
>
> Tested on da850 EVM.
>
> :100644 100644 e8e8724... 6ad76a3... Mdrivers/watchdog/davinci_wdt.c
> drivers/watchdog/davinci_wdt.c | 34 +-
> 1 files changed, 9 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
> index e8e8724..6ad76a3 100644
> --- a/drivers/watchdog/davinci_wdt.c
> +++ b/drivers/watchdog/davinci_wdt.c
> @@ -69,7 +69,6 @@ static unsigned long wdt_status;
> #define WDT_REGION_INITED 2
> #define WDT_DEVICE_INITED 3
>
> -static struct resource *wdt_mem;
> static void __iomem *wdt_base;
> struct clk *wdt_clk;
>
> @@ -201,10 +200,10 @@ static struct miscdevice davinci_wdt_miscdev = {
>
> static int davinci_wdt_probe(struct platform_device *pdev)
> {
> - int ret = 0, size;
> - struct device *dev = >dev;
> + int ret = 0;
> + static struct resource *wdt_mem;
>
> - wdt_clk = clk_get(dev, NULL);
> + wdt_clk = clk_get(>dev, NULL);
> if (WARN_ON(IS_ERR(wdt_clk)))
> return PTR_ERR(wdt_clk);
>
> @@ -213,49 +212,34 @@ static int davinci_wdt_probe(struct platform_device
> *pdev)
> if (heartbeat < 1 || heartbeat > MAX_HEARTBEAT)
> heartbeat = DEFAULT_HEARTBEAT;
>
> - dev_info(dev, "heartbeat %d sec\n", heartbeat);
> + dev_info(>dev, "heartbeat %d sec\n", heartbeat);
>
> wdt_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (wdt_mem == NULL) {
> - dev_err(dev, "failed to get memory region resource\n");
> + dev_err(>dev, "failed to get memory region resource\n");
> return -ENOENT;
> }
>
> - size = resource_size(wdt_mem);
> - if (!request_mem_region(wdt_mem->start, size, pdev->name)) {
> - dev_err(dev, "failed to get memory region\n");
> - return -ENOENT;
> - }
> -
> - wdt_base = ioremap(wdt_mem->start, size);
> + wdt_base = devm_request_and_ioremap(>dev, wdt_mem);
> if (!wdt_base) {
> - dev_err(dev, "failed to map memory region\n");
> - release_mem_region(wdt_mem->start, size);
> - wdt_mem = NULL;
> + dev_err(>dev, "ioremap failed\n");
> return -ENOMEM;
> }
>
> ret = misc_register(_wdt_miscdev);
> if (ret < 0) {
> - dev_err(dev, "cannot register misc device\n");
> - release_mem_region(wdt_mem->start, size);
> - wdt_mem = NULL;
> + dev_err(>dev, "cannot register misc device\n");
> } else {
> set_bit(WDT_DEVICE_INITED, _status);
> + return ret;
No need of return "ret" as it is retuning "ret" just below.
I will fix it in V2.
> }
>
> - iounmap(wdt_base);
> return ret;
> }
>
> static int davinci_wdt_remove(struct platform_device *pdev)
> {
> misc_deregister(_wdt_miscdev);
> - if (wdt_mem) {
> - release_mem_region(wdt_mem->start, resource_size(wdt_mem));
> - wdt_mem = NULL;
> - }
> -
> clk_disable_unprepare(wdt_clk);
> clk_put(wdt_clk);
>
> --
> 1.7.4.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On 8 February 2013 05:03, Rafael J. Wysocki wrote:
> I should have done that before, sorry about it.
np
> Can you please rework this series on top of linux-pm.git/pm-cpufreq and
> try to avoid introducing new issues this time?
Sorry for this. I didn't got any such issues on my system and i tried to think
as widely as possible. But still just a human with some mistakes :)
> If this works, we'll rebase all of the other new material on top of it,
> if possible.
To make your life a bit easy, i have got all cpufreq patches, that you & me
have got for 3.9, rebased over pm-cpufreq and these are:
f3843e0 cpufreq: exynos: simplify .init() for setting policy->cpus
7ea6658 cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
6002fd0 cpufreq/x86: Add P-state driver for sandy bridge.
bcfe254 cpufreq_stats: do not remove sysfs files if frequency table is
not present
6c82b96 cpufreq: Do not track governor name for scaling drivers with
internal governors.
2a6df07 cpufreq: Only call cpufreq_out_of_sync() for driver that
implement cpufreq_driver.target()
0893112 cpufreq: Retrieve current frequency from scaling drivers with
internal governors
e034e73 cpufreq: Fix locking issues
003da79 cpufreq: Create a macro for unlock_policy_rwsem{read,write}
0092c75 cpufreq: Remove unused HOTPLUG_CPU code
34d5833 cpufreq: governors: Fix WARN_ON() for multi-policy platforms
e1ee7c8 cpufreq: Convert the cpufreq_driver_lock to use RCU
e076b60 cpufreq: Convert the cpufreq_driver_lock to a rwlock
6d919f9 cpufreq: ondemand: Replace down_differential tuner with adj_up_threshold
80dd878 cpufreq / stats: Get rid of CPUFREQ_STATDEVICE_ATTR
a7e183d cpufreq: Don't check cpu_online(policy->cpu)
9db0116 cpufreq: add imx6q-cpufreq driver
I have pushed them in for-rafael branch in my repo. Look carefully at
the first two patches,
they were not present in your latest repo.
This was the exynos patch i was talking about:
f3843e0 cpufreq: exynos: simplify .init() for setting policy->cpus
I don't know if you dropped this one or what ?
7ea6658 cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] eventfd: implementation of EFD_MASK flag
Hi Andy, On 08/02/13 02:03, Andy Lutomirski wrote: There may be some advantage to adding (later on, if needed) an option to change the flags set in: + if (waitqueue_active(>wqh)) + wake_up_locked_poll(>wqh, + (unsigned long)ctx->mask.events); (i.e. to allow the second parameter to omit some bits that were already signaled.) Allowing write to write a bigger struct in the future won't break anything. I think I don't follow. Either the second parameter is supposed to be *newly* signaled events, in which case the events that were already signaled in the past should be ommitted, or it is meant to be *all* signaled events, in which case the current implementation is OK. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: tegra: Add missing spinlock for hclk and pclk
On Thursday 07 February 2013 10:07 PM, Peter De Schrijver wrote: The hclk and pclk clocks are controlled by the same register. Hence a lock is required to avoid corruption. Signed-off-by: Peter De Schrijver Reviewed-by: Prashant Gaikwad --- drivers/clk/tegra/clk-tegra20.c | 11 +++ drivers/clk/tegra/clk-tegra30.c | 11 +++ 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c index 5d41569..4612b2e 100644 --- a/drivers/clk/tegra/clk-tegra20.c +++ b/drivers/clk/tegra/clk-tegra20.c @@ -194,6 +194,7 @@ static void __iomem *clk_base; static void __iomem *pmc_base; static DEFINE_SPINLOCK(pll_div_lock); +static DEFINE_SPINLOCK(sysrate_lock); #define TEGRA_INIT_DATA_MUX(_name, _con_id, _dev_id, _parents, _offset, \ _clk_num, _regs, _gate_flags, _clk_id) \ @@ -768,19 +769,21 @@ static void tegra20_super_clk_init(void) /* HCLK */ clk = clk_register_divider(NULL, "hclk_div", "sclk", 0, - clk_base + CLK_SYSTEM_RATE, 4, 2, 0, NULL); + clk_base + CLK_SYSTEM_RATE, 4, 2, 0, + _lock); clk = clk_register_gate(NULL, "hclk", "hclk_div", CLK_SET_RATE_PARENT, clk_base + CLK_SYSTEM_RATE, 7, - CLK_GATE_SET_TO_DISABLE, NULL); + CLK_GATE_SET_TO_DISABLE, _lock); clk_register_clkdev(clk, "hclk", NULL); clks[hclk] = clk; /* PCLK */ clk = clk_register_divider(NULL, "pclk_div", "hclk", 0, - clk_base + CLK_SYSTEM_RATE, 0, 2, 0, NULL); + clk_base + CLK_SYSTEM_RATE, 0, 2, 0, + _lock); clk = clk_register_gate(NULL, "pclk", "pclk_div", CLK_SET_RATE_PARENT, clk_base + CLK_SYSTEM_RATE, 3, - CLK_GATE_SET_TO_DISABLE, NULL); + CLK_GATE_SET_TO_DISABLE, _lock); clk_register_clkdev(clk, "pclk", NULL); clks[pclk] = clk; diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c index d169ef0..c5415ce 100644 --- a/drivers/clk/tegra/clk-tegra30.c +++ b/drivers/clk/tegra/clk-tegra30.c @@ -275,6 +275,7 @@ static DEFINE_SPINLOCK(clk_out_lock); static DEFINE_SPINLOCK(pll_div_lock); static DEFINE_SPINLOCK(cml_lock); static DEFINE_SPINLOCK(pll_d_lock); +static DEFINE_SPINLOCK(sysrate_lock); #define TEGRA_INIT_DATA_MUX(_name, _con_id, _dev_id, _parents, _offset, \ _clk_num, _regs, _gate_flags, _clk_id) \ @@ -1348,19 +1349,21 @@ static void __init tegra30_super_clk_init(void) /* HCLK */ clk = clk_register_divider(NULL, "hclk_div", "sclk", 0, - clk_base + SYSTEM_CLK_RATE, 4, 2, 0, NULL); + clk_base + SYSTEM_CLK_RATE, 4, 2, 0, + _lock); clk = clk_register_gate(NULL, "hclk", "hclk_div", CLK_SET_RATE_PARENT, clk_base + SYSTEM_CLK_RATE, 7, - CLK_GATE_SET_TO_DISABLE, NULL); + CLK_GATE_SET_TO_DISABLE, _lock); clk_register_clkdev(clk, "hclk", NULL); clks[hclk] = clk; /* PCLK */ clk = clk_register_divider(NULL, "pclk_div", "hclk", 0, - clk_base + SYSTEM_CLK_RATE, 0, 2, 0, NULL); + clk_base + SYSTEM_CLK_RATE, 0, 2, 0, + _lock); clk = clk_register_gate(NULL, "pclk", "pclk_div", CLK_SET_RATE_PARENT, clk_base + SYSTEM_CLK_RATE, 3, - CLK_GATE_SET_TO_DISABLE, NULL); + CLK_GATE_SET_TO_DISABLE, _lock); clk_register_clkdev(clk, "pclk", NULL); clks[pclk] = clk; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: tegra: local arrays should be static
On Thursday 07 February 2013 10:00 PM, Peter De Schrijver wrote:
cclk_g_parents, cclk_lp_parents and sclk_parents are only accessed from within
clk-tegra30.c. Declare them static to avoid namespace polution.
Signed-off-by: Peter De Schrijver
Reviewed-by: Prashant Gaikwad
---
drivers/clk/tegra/clk-tegra30.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index a163812..d169ef0 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1249,16 +1249,16 @@ static void __init tegra30_pmc_clk_init(void)
}
-const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
-"pll_p_cclkg", "pll_p_out4_cclkg",
-"pll_p_out3_cclkg", "unused", "pll_x" };
-const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
- "pll_p_cclklp", "pll_p_out4_cclklp",
- "pll_p_out3_cclklp", "unused", "pll_x",
- "pll_x_out0" };
-const char *sclk_parents[] = { "clk_m", "pll_c_out1", "pll_p_out4",
- "pll_p_out3", "pll_p_out2", "unused",
- "clk_32k", "pll_m_out1" };
+static const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+ "pll_p_cclkg", "pll_p_out4_cclkg",
+ "pll_p_out3_cclkg", "unused", "pll_x" };
+static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+"pll_p_cclklp", "pll_p_out4_cclklp",
+"pll_p_out3_cclklp", "unused", "pll_x",
+"pll_x_out0" };
+static const char *sclk_parents[] = { "clk_m", "pll_c_out1", "pll_p_out4",
+ "pll_p_out3", "pll_p_out2", "unused",
+ "clk_32k", "pll_m_out1" };
static void __init tegra30_super_clk_init(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: tegra: Implement locking for super clock
On Thursday 07 February 2013 09:54 PM, Peter De Schrijver wrote:
Although tegra_clk_register_super_mux() has a lock parameter, the lock is not
actually used by the code. Fixed with this patch.
Signed-off-by: Peter De Schrijver
Reviewed-by: Prashant Gaikwad
---
drivers/clk/tegra/clk-super.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/tegra/clk-super.c b/drivers/clk/tegra/clk-super.c
index 7ad48a8..2fd924d 100644
--- a/drivers/clk/tegra/clk-super.c
+++ b/drivers/clk/tegra/clk-super.c
@@ -73,7 +73,12 @@ static int clk_super_set_parent(struct clk_hw *hw, u8 index)
{
struct tegra_clk_super_mux *mux = to_clk_super_mux(hw);
u32 val, state;
+ int err = 0;
u8 parent_index, shift;
+ unsigned long flags = 0;
+
+ if (mux->lock)
+ spin_lock_irqsave(mux->lock, flags);
val = readl_relaxed(mux->reg);
state = val & SUPER_STATE_MASK;
@@ -92,8 +97,10 @@ static int clk_super_set_parent(struct clk_hw *hw, u8 index)
(index == mux->pllx_index))) {
parent_index = clk_super_get_parent(hw);
if ((parent_index == mux->div2_index) ||
- (parent_index == mux->pllx_index))
- return -EINVAL;
+ (parent_index == mux->pllx_index)) {
+ err = -EINVAL;
+ goto out;
+ }
val ^= SUPER_LP_DIV2_BYPASS;
writel_relaxed(val, mux->reg);
@@ -107,7 +114,12 @@ static int clk_super_set_parent(struct clk_hw *hw, u8
index)
writel_relaxed(val, mux->reg);
udelay(2);
- return 0;
+
+out:
+ if (mux->lock)
+ spin_unlock_irqrestore(mux->lock, flags);
+
+ return err;
}
const struct clk_ops tegra_clk_super_ops = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next build conflict between modules and metag trees (LOCKDEP_NOW_UNRELIABLE)
On Thursday 07 February 2013 04:46 PM, James Hogan wrote:
> Hi Rusty,
>
> The metag architecture tree adds an add_taint(TAINT_DIE) like other
> architectures do, and the modules-next tree adds the
> LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously
> misses arch/metag since it doesn't exist yet), causing a compile error
> on metag in -next when the two are merged together.
>
> Is it okay for me to merge your commit 373d4d0 ("taint: add explicit
> flag to show whether lock dep is still OK.") in modules-next into the
> base of the metag tree and expect it not to be rebased, so that I can
> then squash the fix into the metag tree?
>
> The only commits this would include are:
> $ git log --oneline linus/master..373d4d0
> 373d4d0 taint: add explicit flag to show whether lock dep is still OK.
> 64748a2 module: printk message when module signature fail taints kernel.
>
> Thanks
> James
>
Being in the same situation as metag (ARC Port), what's the recommended practice
here - do we simply cherry-pick these changes into our tree - or do we merge the
"other" tree on top - ofcourse with premise that "other" tree will not rebase.
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/6] kernel: implement queue spinlock API
On Thu, Feb 7, 2013 at 9:03 PM, Paul E. McKenney wrote: > Right... For spinlocks that -don't- disable irqs, you need to deal with > the possibility that a CPU gets interrupted while spinning, and the > interrupt handler also tries to acquire a queued lock. One way to deal > with this is to have a node per CPUxirq. Of course, if interrupts > handlers always disable irqs when acquiring a spinlock, then you only > need CPUx2. The simple solution would be to do like I proposed in my faster queue spinlock proposal, have one function for process context lock acquisitions, another for bh-disabled acquisitions, and just say that hardirqs can't use the queue spinlocks (I don't expect we have any locks taken from hardirq context where contention might be an issue ?) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On 8 February 2013 04:37, Rafael J. Wysocki wrote:
> BTW, there still are locking problems in linux-next. Why do we need
> to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(),
> in particular?
I thought a bit more and realized there is no such limitation on
cpufreq_driver->ops about calling routines which can sleep. And thus
we shoudln't
have locks around any of these. I have got a patch for it, that i
would fold-back into
the original patch that introduced locking fixes (attached too for testing):
From: Viresh Kumar
Date: Fri, 8 Feb 2013 10:35:31 +0530
Subject: [PATCH] cpufreq: Remove unnecessary locking
I have placed some locks intentionally around calls to driver->ops (init/exit),
which look to be wrong as these calls can call routines that potentially sleep.
Lets remove these locks.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5d8a422..04aab05 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
if (ret) {
pr_debug("setting policy failed\n");
- spin_lock_irqsave(_driver_lock, flags);
if (driver->exit)
driver->exit(policy);
- spin_unlock_irqrestore(_driver_lock, flags);
}
return ret;
@@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev,
struct subsys_interface *sif)
init_completion(>kobj_unregister);
INIT_WORK(>update, handle_update);
- spin_lock_irqsave(_driver_lock, flags);
/* call driver. From then on the cpufreq must be able
* to accept all calls to ->verify and ->setpolicy for this CPU
*/
ret = driver->init(policy);
if (ret) {
pr_debug("initialization failed\n");
- spin_unlock_irqrestore(_driver_lock, flags);
goto err_set_policy_cpu;
}
- spin_unlock_irqrestore(_driver_lock, flags);
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
@@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif
wait_for_completion(cmp);
pr_debug("wait complete\n");
- spin_lock_irqsave(_driver_lock, flags);
if (driver->exit)
driver->exit(data);
- spin_unlock_irqrestore(_driver_lock, flags);
free_cpumask_var(data->related_cpus);
free_cpumask_var(data->cpus);
0001-cpufreq-Remove-unnecessary-locking.patch
Description: Binary data
Re: [RFC PATCH 1/6] kernel: implement queue spinlock API
On Thu, Feb 07, 2013 at 08:36:43PM -0800, Paul E. McKenney wrote: > On Thu, Feb 07, 2013 at 07:48:33PM -0800, Michel Lespinasse wrote: > > On Thu, Feb 7, 2013 at 4:40 PM, Paul E. McKenney > > wrote: > > > On Thu, Feb 07, 2013 at 04:03:54PM -0800, Eric Dumazet wrote: > > >> It adds yet another memory write to store the node pointer in the > > >> lock... > > >> > > >> I suspect it's going to increase false sharing. > > > > > > On the other hand, compared to straight MCS, it reduces the need to > > > pass the node address around. Furthermore, the node pointer is likely > > > to be in the same cache line as the lock word itself, and finally > > > some architectures can do a double-pointer store. > > > > > > Of course, it might well be slower, but it seems like it is worth > > > giving it a try. > > > > Right. Another nice point about this approach is that there needs to > > be only one node per spinning CPU, so the node pointers (both tail and > > next) might be replaced with CPU identifiers, which would bring the > > spinlock size down to the same as with the ticket spinlock (which in > > turns makes it that much more likely that we'll have atomic stores of > > that size). > > Good point! I must admit that this is one advantage of having the > various _irq spinlock acquisition primitives disable irqs before > spinning. ;-) Right... For spinlocks that -don't- disable irqs, you need to deal with the possibility that a CPU gets interrupted while spinning, and the interrupt handler also tries to acquire a queued lock. One way to deal with this is to have a node per CPUxirq. Of course, if interrupts handlers always disable irqs when acquiring a spinlock, then you only need CPUx2. Thanx, 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/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM if PF_NO_MEMCG_OOM is set
Michal, thank you very much but it just didn't work and broke everything :( This happened: Problem started to occur really often immediately after booting the new kernel, every few minutes for one of my users. But everything other seems to work fine so i gave it a try for a day (which was a mistake). I grabbed some data for you and go to sleep: http://watchdog.sk/lkml/memcg-bug-4.tar.gz Few hours later i was woke up from my sweet sweet dreams by alerts smses - Apache wasn't working and our system failed to restart it. When i observed the situation, two apache processes (of that user as above) were still running and it wasn't possible to kill them by any way. I grabbed some data for you: http://watchdog.sk/lkml/memcg-bug-5.tar.gz Then I logged to the console and this was waiting for me: http://watchdog.sk/lkml/error.jpg Finally i rebooted into different kernel, wrote this e-mail and go to my lovely bed ;) __ > Od: "Michal Hocko" > Komu: azurIt > Dátum: 06.02.2013 17:00 > Predmet: [PATCH for 3.2.34] memcg: do not trigger OOM if PF_NO_MEMCG_OOM is > set > > CC: linux-kernel@vger.kernel.org, linux...@kvack.org, "cgroups mailinglist" > , "KAMEZAWA Hiroyuki" > , "Johannes Weiner" >On Wed 06-02-13 15:22:19, Michal Hocko wrote: >> On Wed 06-02-13 15:01:19, Michal Hocko wrote: >> > On Wed 06-02-13 02:17:21, azurIt wrote: >> > > >5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I >> > > >mentioned in a follow up email. Here is the full patch: >> > > >> > > >> > > Here is the log where OOM, again, killed MySQL server [search for >> > > "(mysqld)"]: >> > > http://www.watchdog.sk/lkml/oom_mysqld6 >> > >> > [...] >> > WARNING: at mm/memcontrol.c:2409 T.1149+0x2d9/0x610() >> > Hardware name: S5000VSA >> > gfp_mask:4304 nr_pages:1 oom:0 ret:2 >> > Pid: 3545, comm: apache2 Tainted: GW3.2.37-grsec #1 >> > Call Trace: >> > [] warn_slowpath_common+0x7a/0xb0 >> > [] warn_slowpath_fmt+0x46/0x50 >> > [] ? mem_cgroup_margin+0x73/0xa0 >> > [] T.1149+0x2d9/0x610 >> > [] ? blk_finish_plug+0x18/0x50 >> > [] mem_cgroup_cache_charge+0xc4/0xf0 >> > [] add_to_page_cache_locked+0x4f/0x140 >> > [] add_to_page_cache_lru+0x22/0x50 >> > [] filemap_fault+0x252/0x4f0 >> > [] __do_fault+0x78/0x5a0 >> > [] handle_pte_fault+0x84/0x940 >> > [] ? vma_prio_tree_insert+0x30/0x50 >> > [] ? vma_link+0x88/0xe0 >> > [] handle_mm_fault+0x138/0x260 >> > [] do_page_fault+0x13d/0x460 >> > [] ? do_mmap_pgoff+0x3dc/0x430 >> > [] page_fault+0x1f/0x30 >> > ---[ end trace 8817670349022007 ]--- >> > apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, >> > oom_score_adj=0 >> > apache2 cpuset=uid mems_allowed=0 >> > Pid: 3545, comm: apache2 Tainted: GW3.2.37-grsec #1 >> > Call Trace: >> > [] dump_header+0x7e/0x1e0 >> > [] ? find_lock_task_mm+0x2f/0x70 >> > [] oom_kill_process+0x85/0x2a0 >> > [] out_of_memory+0xe5/0x200 >> > [] pagefault_out_of_memory+0xbd/0x110 >> > [] mm_fault_error+0xb6/0x1a0 >> > [] do_page_fault+0x3ee/0x460 >> > [] ? do_mmap_pgoff+0x3dc/0x430 >> > [] page_fault+0x1f/0x30 >> > >> > The first trace comes from the debugging WARN and it clearly points to >> > a file fault path. __do_fault pre-charges a page in case we need to >> > do CoW (copy-on-write) for the returned page. This one falls back to >> > memcg OOM and never returns ENOMEM as I have mentioned earlier. >> > However, the fs fault handler (filemap_fault here) can fallback to >> > page_cache_read if the readahead (do_sync_mmap_readahead) fails >> > to get page to the page cache. And we can see this happening in >> > the first trace. page_cache_read then calls add_to_page_cache_lru >> > and eventually gets to add_to_page_cache_locked which calls >> > mem_cgroup_cache_charge_no_oom so we will get ENOMEM if oom should >> > happen. This ENOMEM gets to the fault handler and kaboom. >> > >> > So the fix is really much more complex than I thought. Although >> > add_to_page_cache_locked sounded like a good place it turned out to be >> > not in fact. >> > >> > We need something more clever appaerently. One way would be not misusing >> > __GFP_NORETRY for GFP_MEMCG_NO_OOM and give it a real flag. We have 32 >> > bits for those flags in gfp_t so there should be some room there. >> > Or we could do this per task flag, same we do for NO_IO in the current >> > -mm tree. >> > The later one seems easier wrt. gfp_mask passing horror - e.g. >> > __generic_file_aio_write doesn't pass flags and it can be called from >> > unlocked contexts as well. >> >> Ouch, PF_ flags space seem to be drained already because >> task_struct::flags is just unsigned int so there is just one bit left. I >> am not sure this is the best use for it. This will be a real pain! > >OK, so this something that should help you without any risk of false >OOMs. I do not believe that something like that would be accepted >upstream because it is really heavy. We will need to
Re: [console_unlock] WARNING: at kernel/sched/clock.c:219 sched_clock_cpu()
Hello Fengguang On Fri, Feb 8, 2013 at 10:06 AM, Fengguang Wu wrote: > [0.00] Console: colour VGA+ 80x25 > [0.00] [ cut here ] > [0.00] WARNING: at /c/kernel-tests/src/linux/kernel/sched/clock.c:219 > sched_clock_cpu+0x65/0x140() > [0.00] Hardware name: Bochs > [0.00] Modules linked in: > [0.00] Pid: 0, comm: swapper Not tainted 3.8.0-rc6-mm1-00539-g83b324c > #39 > [0.00] Call Trace: > [0.00] [] warn_slowpath_common+0x87/0xb0 > [0.00] [] ? sched_clock_cpu+0x65/0x140 > [0.00] [] ? sched_clock_cpu+0x65/0x140 > [0.00] [] warn_slowpath_null+0x22/0x30 > [0.00] [] sched_clock_cpu+0x65/0x140 > [0.00] [] __console_unlock+0x39/0x490 > [0.00] [] ? printk+0x3d/0x3f > [0.00] [] console_unlock+0xd/0x20 > [0.00] [] con_init+0x1fb/0x20e > [0.00] [] console_init+0x12/0x20 > [0.00] [] start_kernel+0x258/0x35f > [0.00] [] ? repair_env_string+0x51/0x51 > [0.00] [] i386_start_kernel+0x12c/0x12f > [0.00] ---[ end trace e006f8c3d589c9a1 ]--- > Can you please try the following fix? --- a/kernel/printk.c Fri Feb 8 12:31:18 2013 +++ b/kernel/printk.c Fri Feb 8 12:51:42 2013 @@ -2053,6 +2053,7 @@ static bool __console_unlock(void) return false; } + local_irq_save(flags); console_may_schedule = 0; cur_cpu = smp_processor_id(); /* @@ -2062,6 +2063,7 @@ static bool __console_unlock(void) end_time = sched_clock_cpu(cur_cpu) + max_interrupt_disabled_duration() / 2; + local_irq_restore(flags); /* flush buffered message fragment immediately to console */ console_cont_flush(text, sizeof(text)); again: -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Improve CLKSRC_OF matching
On Thu, 2013-02-07 at 13:09 -0600, Rob Herring wrote: > From: Rob Herring > > In the recently added support for OF based clocksource init, a device node > will be matched twice. We can fix this by passing the device node to the > init functions and removing the match functions within the init functions. > > This is based on arm-soc for-next branch and commit "of: fix incorrect > return value of of_find_matching_node_and_match()" in my DT for-next > branch. > > Rob > > Rob Herring (4): > clocksource: pass DT node pointer to init functions > clocksource: bcm2835: use the device_node pointer passed to init > clocksource: vt8500: use the device_node pointer passed to init > clocksource: tegra20: use the device_node pointer passed to init > > drivers/clocksource/bcm2835_timer.c | 12 +- > drivers/clocksource/clksrc-of.c |4 +- > drivers/clocksource/tegra20_timer.c | 70 > ++- > drivers/clocksource/vt8500_timer.c | 14 +-- > 4 files changed, 31 insertions(+), 69 deletions(-) > Looks fine, although I didn't get a CC for the vt8500 patch so I had to go hunting for it :) For patches 1 & 3: Acked-by: Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: gpio-sch GPIO_SYSFS access
On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
>
> Yes I think that could be it, the driver would need to call
> gpio_export() for it to also be accessible in sysfs.
>
> Configure in debugfs and check the file "gpio" in debugfs
> to figure out the client.
>
> Yours,
> Linus Walleij
>
I found gpio_export() as you suggested above and instrumented it. What I
found was that it was not getting called at all. As I understand it,
calling gpiochip_export() should make the gpiochip# appear in
/sys/class/gpio and then I should be able to configure which lines are
exported via the /sys/class/gpio/export file.
I haven't yet found how gpio-pch differs from gpio-sch that causes the
gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
patch gpio-sch with a request and export loop:
$ git diff drivers/gpio/gpio-sch.c
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 8cadf4d..79783c1 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
static int __devinit sch_gpio_probe(struct platform_device *pdev)
{
struct resource *res;
- int err, id;
+ int err, id, gpio;
id = pdev->id;
if (!id)
@@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
platform_device *p
if (err < 0)
goto err_sch_gpio_core;
+ /* DEBUG: export all the core GPIOS */
+ for (gpio = sch_gpio_core.base;
+gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
+ gpio_request(gpio, "gpio-sch");
+ gpio_export(gpio, true);
+ }
+
err = gpiochip_add(_gpio_resume);
if (err < 0)
goto err_sch_gpio_resume;
+ /* DEBUG: export all the resume GPIOS */
+ for (gpio = sch_gpio_resume.base;
+gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
+ gpio_request(gpio, "gpio-sch");
+ gpio_export(gpio, true);
+ }
+
return 0;
err_sch_gpio_resume:
With this both the gpiochip# and gpio# entries appear in sysfs. However,
unlike those for the gpio-pch lines, these report an error in the sysfs
interface:
/sys/class/gpio# ls *
ls: gpio0: No such file or directory
ls: gpio1: No such file or directory
ls: gpio10: No such file or directory
ls: gpio11: No such file or directory
ls: gpio12: No such file or directory
ls: gpio13: No such file or directory
ls: gpio2: No such file or directory
ls: gpio3: No such file or directory
ls: gpio4: No such file or directory
ls: gpio5: No such file or directory
ls: gpio6: No such file or directory
ls: gpio7: No such file or directory
ls: gpio8: No such file or directory
ls: gpio9: No such file or directory
ls: gpiochip0: No such file or directory
ls: gpiochip5: No such file or directory
exportunexport
gpiochip244:
base label ngpio power subsystem uevent
Clearly I'm still missing something. I've read through gpio.txt a couple
times and each time piece a bit more together. I'll do that again, but I
still suspect I'm missing something fundamental here. In particular, I
still don't understand how the gpio-pch and gpio-sch drivers are create
such different results.
Ultimately what I'm looking to do is configure a new board such that 8
of the gpio-sch lines are configured as buttons and LEDs which are
physically attached to the board (4 of each). I was hoping to use this
interface to understand the ins and outs (haha) of the GPIO subsystem.
Ultimately I believe I need either a "platform-device" or possibly an
ACPI DSDT from the firmware to properly describe the GPIO lines and
their direction. Ultimately, these should be driven by the gpio-keys and
gpio-led drivers - at least that's my current understanding.
Any help clarifying some of this would be greatly appreciated.
Thanks for the time!
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux 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/
Re: [RFC PATCH 1/6] kernel: implement queue spinlock API
On Thu, Feb 07, 2013 at 07:48:33PM -0800, Michel Lespinasse wrote: > On Thu, Feb 7, 2013 at 4:40 PM, Paul E. McKenney > wrote: > > On Thu, Feb 07, 2013 at 04:03:54PM -0800, Eric Dumazet wrote: > >> It adds yet another memory write to store the node pointer in the > >> lock... > >> > >> I suspect it's going to increase false sharing. > > > > On the other hand, compared to straight MCS, it reduces the need to > > pass the node address around. Furthermore, the node pointer is likely > > to be in the same cache line as the lock word itself, and finally > > some architectures can do a double-pointer store. > > > > Of course, it might well be slower, but it seems like it is worth > > giving it a try. > > Right. Another nice point about this approach is that there needs to > be only one node per spinning CPU, so the node pointers (both tail and > next) might be replaced with CPU identifiers, which would bring the > spinlock size down to the same as with the ticket spinlock (which in > turns makes it that much more likely that we'll have atomic stores of > that size). Good point! I must admit that this is one advantage of having the various _irq spinlock acquisition primitives disable irqs before spinning. ;-) Thanx, 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/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
On Tue, Feb 05 2013, Michal Hocko wrote: > On Tue 05-02-13 10:09:57, Greg Thelen wrote: >> On Tue, Feb 05 2013, Michal Hocko wrote: >> >> > On Tue 05-02-13 08:48:23, Greg Thelen wrote: >> >> On Tue, Feb 05 2013, Michal Hocko wrote: >> >> >> >> > On Tue 05-02-13 15:49:47, azurIt wrote: >> >> > [...] >> >> >> Just to be sure - am i supposed to apply this two patches? >> >> >> http://watchdog.sk/lkml/patches/ >> >> > >> >> > 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I >> >> > mentioned in a follow up email. Here is the full patch: >> >> > --- >> >> > From f2bf8437d5b9bb38a95a432bf39f32c584955171 Mon Sep 17 00:00:00 2001 >> >> > From: Michal Hocko >> >> > Date: Mon, 26 Nov 2012 11:47:57 +0100 >> >> > Subject: [PATCH] memcg: do not trigger OOM from add_to_page_cache_locked >> >> > >> >> > memcg oom killer might deadlock if the process which falls down to >> >> > mem_cgroup_handle_oom holds a lock which prevents other task to >> >> > terminate because it is blocked on the very same lock. >> >> > This can happen when a write system call needs to allocate a page but >> >> > the allocation hits the memcg hard limit and there is nothing to reclaim >> >> > (e.g. there is no swap or swap limit is hit as well and all cache pages >> >> > have been reclaimed already) and the process selected by memcg OOM >> >> > killer is blocked on i_mutex on the same inode (e.g. truncate it). >> >> > >> >> > Process A >> >> > [] do_truncate+0x58/0xa0 # takes i_mutex >> >> > [] do_last+0x250/0xa30 >> >> > [] path_openat+0xd7/0x440 >> >> > [] do_filp_open+0x49/0xa0 >> >> > [] do_sys_open+0x106/0x240 >> >> > [] sys_open+0x20/0x30 >> >> > [] system_call_fastpath+0x18/0x1d >> >> > [] 0x >> >> > >> >> > Process B >> >> > [] mem_cgroup_handle_oom+0x241/0x3b0 >> >> > [] T.1146+0x5ab/0x5c0 >> >> > [] mem_cgroup_cache_charge+0xbe/0xe0 >> >> > [] add_to_page_cache_locked+0x4c/0x140 >> >> > [] add_to_page_cache_lru+0x22/0x50 >> >> > [] grab_cache_page_write_begin+0x8b/0xe0 >> >> > [] ext3_write_begin+0x88/0x270 >> >> > [] generic_file_buffered_write+0x116/0x290 >> >> > [] __generic_file_aio_write+0x27c/0x480 >> >> > [] generic_file_aio_write+0x76/0xf0 # takes >> >> > ->i_mutex >> >> > [] do_sync_write+0xea/0x130 >> >> > [] vfs_write+0xf3/0x1f0 >> >> > [] sys_write+0x51/0x90 >> >> > [] system_call_fastpath+0x18/0x1d >> >> > [] 0x >> >> >> >> It looks like grab_cache_page_write_begin() passes __GFP_FS into >> >> __page_cache_alloc() and mem_cgroup_cache_charge(). Which makes me >> >> think that this deadlock is also possible in the page allocator even >> >> before getting to add_to_page_cache_lru. no? >> > >> > I am not that familiar with VFS but i_mutex is a high level lock AFAIR >> > and it shouldn't be called from the pageout path so __page_cache_alloc >> > should be safe. >> >> I wasn't clear, sorry. My concern is not that pageout() grabs i_mutex. >> My concern is that __page_cache_alloc() will invoke the oom killer and >> select a victim which wants i_mutex. This victim will deadlock because >> the oom killer caller already holds i_mutex. > > That would be true for the memcg oom because that one is blocking but > the global oom just puts the allocator into sleep for a while and then > the allocator should back off eventually (unless this is NOFAIL > allocation). I would need to look closer whether this is really the case > - I haven't seen that allocator code path for a while... I think the page allocator can loop forever waiting for an oom victim to terminate even without NOFAIL. Especially if the oom victim wants a resource exclusively held by the allocating thread (e.g. i_mutex). It looks like the same deadlock you describe is also possible (though more rare) without memcg. If the looping thread is an eligible oom victim (i.e. not oom disabled, not an kernel thread, etc) then the page allocator can return NULL in so long as NOFAIL is not used. So any allocator which is able to call the oom killer and is not oom disabled (kernel thread, etc) is already exposed to the possibility of page allocator failure. So if the page allocator could detect the deadlock, then it could safely return NULL. Maybe after looping N times without forward progress the page allocator should consider failing unless NOFAIL is given. Switching back to the memcg oom situation, can we similarly return NULL if memcg oom kill has been tried a reasonable number of times. Simply failing the memcg charge with ENOMEM seems easier to support than exceeding limit (Kame's loan patch). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: add support for Lynxpoint DMA controllers
On Thu, Feb 7, 2013 at 10:35 PM, Andy Shevchenko wrote: > On Thu, Feb 7, 2013 at 5:39 PM, Viresh Kumar wrote: >> On 7 February 2013 21:06, Andy Shevchenko >> wrote: >>> From: Mika Westerberg >>> >>> Intel Lynxpoint PCH Low Power Subsystem has DMA controller to support >>> general >>> purpose serial buses like SPI, I2C, and HSUART. This controller is >>> enumerated >>> from ACPI namespace with ACPI ID INTL9C60. >>> >>> Signed-off-by: Andy Shevchenko >> >> Looks like Mika is Author and you have your signed-off :) > > In this literally small and clear patch it doesn't matter who is who. I believe it doesn't matter how small or big is the patch, but the author should be there in SOBs too.. > However for sake of equity I could add Mika's signed-off-by as well. > > It should be: > Signed-off-by: Mika Westerberg Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/49] ARM: ux500: Add supply for the L3G4200D Gyroscope
On Thu, Feb 07, 2013 at 16:36:03 +0100, Linus Walleij wrote:
> On Wed, Feb 6, 2013 at 11:53 AM, Lee Jones wrote:
>
> > This patch lists the L3G4200D Gyroscope as a consumer of the
> > AB8500 VAUX1 regulator.
> >
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/mach-ux500/board-mop500-regulators.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/mach-ux500/board-mop500-regulators.c
> > b/arch/arm/mach-ux500/board-mop500-regulators.c
> > index dbbeb20..097cf65 100644
> > --- a/arch/arm/mach-ux500/board-mop500-regulators.c
> > +++ b/arch/arm/mach-ux500/board-mop500-regulators.c
> > @@ -73,6 +73,8 @@ static struct regulator_consumer_supply
> > ab8500_vaux1_consumers[] = {
> > REGULATOR_SUPPLY("avdd", "3-005d"),
> > /* Synaptics RMI4 Touchscreen device */
> > REGULATOR_SUPPLY("vdd", "3-004b"),
> > + /* L3G4200D Gyroscope device */
> > + REGULATOR_SUPPLY("vdd", "l3g4200d"),
>
> Hmmm isn't this an I2C device? Better check with Srinidhi about that
> device name.
Yes, it is. If you want to maintain consistency in the above table, it should be
rather..
REGULATOR_SUPPLY("vdd", "2-0068")
srinidhi
>
> 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] watchdog: davinci_wdt: update to devm_* API
On Fri, Feb 08, 2013 at 09:49:27, Nori, Sekhar wrote:
> On 2/8/2013 8:05 AM, Kumar, Anil wrote:
> > On Thu, Feb 07, 2013 at 23:20:48, Nori, Sekhar wrote:
> >> On 2/7/2013 9:02 AM, Kumar, Anil wrote:
>
> >>> Update the code to use devm_* API so that driver
> >>> core will manage resources.
>
> >>> Signed-off-by: Kumar, Anil
>
> >>> diff --git a/drivers/watchdog/davinci_wdt.c
> >>> b/drivers/watchdog/davinci_wdt.c
>
> >>> @@ -201,10 +200,10 @@ static struct miscdevice davinci_wdt_miscdev = {
> >>>
> >>> static int davinci_wdt_probe(struct platform_device *pdev)
> >>> {
> >>> - int ret = 0, size;
> >>> - struct device *dev = >dev;
> >>
> >> Its not clear why you had to drop use of this variable?
> >
> > Actually, I have not found any particular need to take pointer
> > into dev and then use in the code. Rather we can directly use.
>
> No, it is good enough as-is. It will help rid your patch of unnecessary
> changes and its not really convenient to to keep reading >dev all
> the time.
>
Ok
Thanks,
Anil
Re: [GIT PULL] f2fs fixes for v3.8-rc7
2013-02-08 (금), 03:10 +, Al Viro: > On Fri, Feb 08, 2013 at 12:09:34PM +1100, Linus Torvalds wrote: > > No. > > > > You guys need to realize that I'm not talking crap like this this late. > > > > This is not major bugfixes. I already looked away once just because > > it's a new filesystem, but enough is enough. This is way way WAY too > > late to start sendign "enhancements". Seriously. > > > > Send them for the next merge window. Not just before rc7. > > BTW, for the next merge window I've got several patches to that sucker; > commits f3d9d7e..10e4e72 in vfs.git. I can send them to f2fs tree or > have them go in vfs one, but this stuff needs to be dealt with. Fake > struct dentry on stack is a bad thing with capital Hell No... Hi Al, Could you send the patches to me? I'll merge them in my tree and submit them in the next merge window. Is it OK? Thanks, -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
Re: [PATCH] watchdog: davinci_wdt: update to devm_* API
On 2/8/2013 8:05 AM, Kumar, Anil wrote:
> On Thu, Feb 07, 2013 at 23:20:48, Nori, Sekhar wrote:
>> On 2/7/2013 9:02 AM, Kumar, Anil wrote:
>>> Update the code to use devm_* API so that driver
>>> core will manage resources.
>>> Signed-off-by: Kumar, Anil
>>> diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
>>> @@ -201,10 +200,10 @@ static struct miscdevice davinci_wdt_miscdev = {
>>>
>>> static int davinci_wdt_probe(struct platform_device *pdev)
>>> {
>>> - int ret = 0, size;
>>> - struct device *dev = >dev;
>>
>> Its not clear why you had to drop use of this variable?
>
> Actually, I have not found any particular need to take pointer
> into dev and then use in the code. Rather we can directly use.
No, it is good enough as-is. It will help rid your patch of unnecessary
changes and its not really convenient to to keep reading >dev all
the time.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
(2013/02/07 21:31), Michal Hocko wrote: On Thu 07-02-13 20:01:45, KAMEZAWA Hiroyuki wrote: (2013/02/06 23:01), Michal Hocko wrote: On Wed 06-02-13 02:17:21, azurIt wrote: 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I mentioned in a follow up email. Here is the full patch: Here is the log where OOM, again, killed MySQL server [search for "(mysqld)"]: http://www.watchdog.sk/lkml/oom_mysqld6 [...] WARNING: at mm/memcontrol.c:2409 T.1149+0x2d9/0x610() Hardware name: S5000VSA gfp_mask:4304 nr_pages:1 oom:0 ret:2 Pid: 3545, comm: apache2 Tainted: GW3.2.37-grsec #1 Call Trace: [] warn_slowpath_common+0x7a/0xb0 [] warn_slowpath_fmt+0x46/0x50 [] ? mem_cgroup_margin+0x73/0xa0 [] T.1149+0x2d9/0x610 [] ? blk_finish_plug+0x18/0x50 [] mem_cgroup_cache_charge+0xc4/0xf0 [] add_to_page_cache_locked+0x4f/0x140 [] add_to_page_cache_lru+0x22/0x50 [] filemap_fault+0x252/0x4f0 [] __do_fault+0x78/0x5a0 [] handle_pte_fault+0x84/0x940 [] ? vma_prio_tree_insert+0x30/0x50 [] ? vma_link+0x88/0xe0 [] handle_mm_fault+0x138/0x260 [] do_page_fault+0x13d/0x460 [] ? do_mmap_pgoff+0x3dc/0x430 [] page_fault+0x1f/0x30 ---[ end trace 8817670349022007 ]--- apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 apache2 cpuset=uid mems_allowed=0 Pid: 3545, comm: apache2 Tainted: GW3.2.37-grsec #1 Call Trace: [] dump_header+0x7e/0x1e0 [] ? find_lock_task_mm+0x2f/0x70 [] oom_kill_process+0x85/0x2a0 [] out_of_memory+0xe5/0x200 [] pagefault_out_of_memory+0xbd/0x110 [] mm_fault_error+0xb6/0x1a0 [] do_page_fault+0x3ee/0x460 [] ? do_mmap_pgoff+0x3dc/0x430 [] page_fault+0x1f/0x30 The first trace comes from the debugging WARN and it clearly points to a file fault path. __do_fault pre-charges a page in case we need to do CoW (copy-on-write) for the returned page. This one falls back to memcg OOM and never returns ENOMEM as I have mentioned earlier. However, the fs fault handler (filemap_fault here) can fallback to page_cache_read if the readahead (do_sync_mmap_readahead) fails to get page to the page cache. And we can see this happening in the first trace. page_cache_read then calls add_to_page_cache_lru and eventually gets to add_to_page_cache_locked which calls mem_cgroup_cache_charge_no_oom so we will get ENOMEM if oom should happen. This ENOMEM gets to the fault handler and kaboom. Hmm. do we need to increase the "limit" virtually at memcg oom until the oom-killed process dies ? It may be doable by increasing stock->cache of each cpuI think kernel can offer extra virtual charge up to oom-killed process's memory usage. If we can guarantee that the overflow charges do not exceed the memory usage of the killed process then this would work. The question is, how do we find out how much we can overflow. immigrate_on_move will play some role as well as the amount of the shared memory. I am afraid this would get too complex. Nevertheless the idea is nice. Yes, that's the problem. If we don't do in correct way, resouce usage undeflow can happen. I guess we can count it per task_struct at charging page-faulted anon pages. _Or_ in other consideration, for example, we do charge 1MB per thread regardless of its memory usage. And use it as a security at OOM-killing. Implemtation will be easy but explanation may be difficult.. Thanks, -Kame Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] f2fs fixes for v3.8-rc7
Ok, I understand. I'll prepare and send patches for the next merge window with these patches together. Thanks, 2013-02-08 (금), 12:09 +1100, Linus Torvalds: > No. > > You guys need to realize that I'm not talking crap like this this late. > > This is not major bugfixes. I already looked away once just because > it's a new filesystem, but enough is enough. This is way way WAY too > late to start sendign "enhancements". Seriously. > > Send them for the next merge window. Not just before rc7. > >Linus > > On Thu, Feb 7, 2013 at 11:21 AM, Jaegeuk Kim wrote: > > Hi Linus, > > > > Here are four patches which are critical bug fixes on f2fs, three > > enhancement patches, and a number of trivial patches. > > Please pull the following tag. Sorry for the late request. > > > > Thanks, > > > > The following changes since commit > > 6abb7c25775b7fb2225ad0508236d63ca710e65f: > > > > Merge tag 'regulator-3.8-rc5' of > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator > > (2013-01-28 22:44:53 -0800) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git > > tags/f2fs-for-v3.8 > > > > for you to fetch changes up to 1efc6d3277f59b764384781c0f8dfc821f229380: > > > > f2fs: add compat_ioctl to provide backward compatability (2013-02-06 > > 17:38:59 +0900) > > > > > > f2fs fixes for v3.8 > > > > [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 > > > > [Enhancement] > > o Support (un)freeze_fs > > o Enhance the f2fs_gc flow > > o Support 32-bit binary execution on 64-bit kernel > > > > > > 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 (6): > > 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 > > > > 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/f2fs.h | 32 ++--- > > fs/f2fs/file.c | 35 --- > > fs/f2fs/gc.c | 124 > > ++- > > fs/f2fs/gc.h | 21 - > > fs/f2fs/inode.c | 53 +- > > fs/f2fs/node.c | 14 +++--- > > fs/f2fs/recovery.c | 4 +- > > fs/f2fs/segment.c| 29 > > fs/f2fs/segment.h| 23 +++--- > > fs/f2fs/super.c | 92 +- > > 12 files changed, 262 insertions(+), 232 deletions(-) > > > > -- > > Jaegeuk Kim > > Samsung > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jaegeuk Kim Samsung signature.asc Description: This is a digitally signed message part
Re: linux-next build conflict between modules and metag trees (LOCKDEP_NOW_UNRELIABLE)
James Hogan writes:
> Hi Rusty,
>
> The metag architecture tree adds an add_taint(TAINT_DIE) like other
> architectures do, and the modules-next tree adds the
> LOCKDEP_NOW_UNRELIABLE flag to all uses of add_taint (but obviously
> misses arch/metag since it doesn't exist yet), causing a compile error
> on metag in -next when the two are merged together.
>
> Is it okay for me to merge your commit 373d4d0 ("taint: add explicit
> flag to show whether lock dep is still OK.") in modules-next into the
> base of the metag tree and expect it not to be rebased, so that I can
> then squash the fix into the metag tree?
This was my fault for taking a shortcut. I should have changed the name
so the old add_taint worked still (set_taint?), then remove add_taint
after the merge.
But I won't be rebasing, so you should be fine to merge it.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
Paolo Bonzini writes:
> The virtqueue_add_buf function has two limitations:
>
> 1) it requires the caller to provide all the buffers in a single call;
>
> 2) it does not support chained scatterlists: the buffers must be
> provided as an array of struct scatterlist.
>
> Because of these limitations, virtio-scsi has to copy each request into
> a scatterlist internal to the driver. It cannot just use the one that
> was prepared by the upper SCSI layers.
Hi Paulo,
Note that you've defined your problem in terms of your solution
here. For clarity:
The problem: we want to prepend and append to a scatterlist. We can't
append, because the chained scatterlist implementation requires
an element to be appended to join two scatterlists together.
The solution: fix scatterlists by introducing struct sg_ring:
struct sg_ring {
struct list_head ring;
unsigned int nents;
unsigned int orig_nents; /* do we want to replace sg_table? */
struct scatterlist *sg;
};
The workaround: make virtio accept multiple scatterlists for a single
buffer.
There's nothing wrong with your workaround, but if other subsystems have
the same problem we do, perhaps we should consider a broader solution?
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect
> > But I've just switched to udl (instead of udlfb) and will see if I can fix > the bugs there to make it usable as a console. udl is a rewrite of udlfb > with some additional features (e.g. drm), so hopefully fixing the remaining > problems there will require less work. I may have fixed the major udl problem with being a console, patch was posted to dri-devel yesterday, and I've pushed it into -next. 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: [PATCHSET] idr: deprecate idr_remova_all() and add idr_alloc()
On Thu, Feb 7, 2013 at 5:39 AM, Tejun Heo wrote: > (If you're reading this patchset for the first time, this patchset is > an effort to improve idr interface. This posting is mostly for > collecting and routing the patches towards -mm. Please follow the > link at the end for details on each patchset.) > > Hello, Andrew. > > This patchset is combination of the following three on top of > linux-next as of 20130204 (the one before idr_removal_all() got > included). just FYI, all the drm bits are Acked-by: Dave Airlie Don't worry about attaching that to the patches though :-) 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: net: rcu warnings in ip6fl_get_first
On Thu, Feb 7, 2013 at 8:38 PM, Cong Wang wrote: > On Thu, 07 Feb 2013 at 19:32 GMT, Sasha Levin wrote: >> Hi guys, >> >> I got the following while fuzzing with trinity inside a KVM tools guest: >> >> [ 51.680236] === >> [ 51.681914] [ INFO: suspicious RCU usage. ] >> [ 51.683610] 3.8.0-rc6-next-20130206-sasha-00028-g83214f7-dirty #276 >> Tainted: GW >> [ 51.686703] --- >> [ 51.688281] net/ipv6/ip6_flowlabel.c:671 suspicious >> rcu_dereference_check() usage! >> [ 51.691345] > > It should use rcu_dereference_bh()... > > diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c > index ea42bf4..c50080f 100644 > --- a/net/ipv6/ip6_flowlabel.c > +++ b/net/ipv6/ip6_flowlabel.c > @@ -65,13 +65,13 @@ static DEFINE_SPINLOCK(ip6_fl_lock); > static DEFINE_SPINLOCK(ip6_sk_fl_lock); > > #define for_each_fl_rcu(hash, fl) \ > - for (fl = rcu_dereference(fl_ht[(hash)]); \ > + for (fl = rcu_dereference_bh(fl_ht[(hash)]);\ > fl != NULL;\ > -fl = rcu_dereference(fl->next)) > +fl = rcu_dereference_hb(fl->next)) > #define for_each_fl_continue_rcu(fl) \ > - for (fl = rcu_dereference(fl->next);\ > + for (fl = rcu_dereference_bh(fl->next); \ > fl != NULL;\ > -fl = rcu_dereference(fl->next)) > +fl = rcu_dereference_bh(fl->next)) > > #define for_each_sk_fl_rcu(np, sfl)\ > for (sfl = rcu_dereference_bh(np->ipv6_fl_list);\ Yup, that's how I fixed it locally and it was running without warnings for couple of hours now. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/6] kernel: implement queue spinlock API
On Thu, Feb 7, 2013 at 4:40 PM, Paul E. McKenney wrote: > On Thu, Feb 07, 2013 at 04:03:54PM -0800, Eric Dumazet wrote: >> It adds yet another memory write to store the node pointer in the >> lock... >> >> I suspect it's going to increase false sharing. > > On the other hand, compared to straight MCS, it reduces the need to > pass the node address around. Furthermore, the node pointer is likely > to be in the same cache line as the lock word itself, and finally > some architectures can do a double-pointer store. > > Of course, it might well be slower, but it seems like it is worth > giving it a try. Right. Another nice point about this approach is that there needs to be only one node per spinning CPU, so the node pointers (both tail and next) might be replaced with CPU identifiers, which would bring the spinlock size down to the same as with the ticket spinlock (which in turns makes it that much more likely that we'll have atomic stores of that size). -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm regression fix
Hi Linus, this one fixes a sleep while locked regression that was introduced earlier in 3.8. Dave. The following changes since commit 6bacaa9ddacb71c691d32c678d37bc59ffc71fac: Merge tag 'sound-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2013-02-07 08:43:30 +1100) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to ff7c60c580d9722f820d85c9c58ca55ecc1ee7c4: drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try (2013-02-08 10:44:31 +1000) Daniel Vetter (1): drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try drivers/gpu/drm/ttm/ttm_bo_util.c | 13 - 1 file changed, 8 insertions(+), 5 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/
[PATCH 2/2] stop_machine: dequeue work before signal completion
As checked with BUG_ON in the case of CPU_UP_PREPARE, we have to dequeue
work first for further actions, then stopper reaches sane and clear state.
Signed-off-by: Hillf Danton
---
--- a/kernel/stop_machine.c Fri Feb 8 11:22:44 2013
+++ b/kernel/stop_machine.c Fri Feb 8 11:29:40 2013
@@ -342,8 +342,12 @@ static int __cpuinit cpu_stop_cpu_callba
kthread_stop(stopper->thread);
/* drain remaining works */
spin_lock_irq(>lock);
- list_for_each_entry(work, >works, list)
+ while (!list_empty(>works)) {
+ work = list_first_entry(>works,
+ struct cpu_stop_work, list);
+ list_del_init(>list);
cpu_stop_signal_done(work->done, false);
+ }
stopper->enabled = false;
spin_unlock_irq(>lock);
/* release the stopper */
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
On 02/08/2013 04:02 AM, Ben Hutchings wrote:
On Thu, 2013-02-07 at 21:39 +0800, Freddy Xin wrote:
From: Freddy Xin
This is a resubmission.
Added "const" to ethtool_ops structure and fixed the coding style of
AX88179_BULKIN_SIZE array.
Fixed the issue that the default MTU is not 1500.
Added ax88179_change_mtu function and enabled the hardware jumbo frame function
to support an
MTU higher than 1500.
Fixed indentation and empty line coding style errors.
The _nopm version usb functions were added to access register in suspend and
resume functions.
Serveral variables allocted dynamically were removed and replaced by stack
variables.
ax88179_get_eeprom were modified from asix_get_eeprom in asix_common.
This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0
to gigabit ethernet adapters. It's based on the AX88xxx driver but
the usb commands used to access registers for AX88179 are completely different.
This driver had been verified on x86 system with AX88179/AX88178A and
Sitcomm LN-032 USB dongles.
Signed-off-by: Freddy Xin
[...]
--- /dev/null
+++ b/drivers/net/usb/ax88179_178a.c
[...]
+struct ax88179_data {
+ u16 rxctl;
+};
Should also be declared __packed, as on some architectures it may be
padded to 4 bytes.
rxctl is presumably required to be little-endian (__le16)?
+struct ax88179_int_data {
+ u16 res1;
+ u8 link;
+ u16 res2;
+ u8 status;
+ u16 res3;
+} __packed;
Same here, the u16 fields are presumably little-endian?
[...]
+struct ax88179_rx_pkt_header {
+ u8 l4_csum_err:1,
+ l3_csum_err:1,
+ l4_type:3,
+ l3_type:2,
+ ce:1;
+
+ u8 vlan_ind:3,
+ rx_ok:1,
+ pri:3,
+ bmc:1;
+
+ u16 len:13,
+ crc:1,
+ mii:1,
+ drop:1;
+} __packed;
This won't work on both big-endian systems (assuming this works on x86).
You apparently try to convert the structure in-place in
ax88179_rx_fixup() by calling le32_to_cpus(); that may work if you
define all the bitfields to be part of a u32 but it won't work with the
current definition.
[...]
+static int
+ax88179_set_features(struct net_device *net, netdev_features_t features)
+{
+ u8 tmp;
+ struct usbnet *dev = netdev_priv(net);
+ netdev_features_t changed = net->features ^ features;
+
+ if (changed & NETIF_F_TSO)
+ net->features ^= NETIF_F_TSO;
+
+ if (changed & NETIF_F_SG)
+ net->features ^= NETIF_F_SG;
Don't change net->features; the caller will do that for you.
+ if (changed & NETIF_F_IP_CSUM) {
+ ax88179_read_cmd(dev, AX_ACCESS_MAC, AX_TXCOE_CTL, 1, 1, );
+ tmp ^= AX_TXCOE_TCP | AX_TXCOE_UDP;
+ ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_TXCOE_CTL, 1, 1, );
+
+ net->features ^= NETIF_F_IP_CSUM;
+ }
[...]
Isn't tmp going to be in little-endian byte order, so this doesn't work
correctly on a big-endian system?
There are a lot of reads and writes of 16-bit registers using
ax88179_{read,write}_cmd(); maybe you should add
ax88179_{read,write}_le16() to handle this specific case.
Ben.
Thank you, Ben. I will fix bugs and test it on a big-endian system.
Freddy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] stop_machine: check work->done while handling enqueued works
The comment just above cpu_stop_signal_done() says it is uncertain that the input @done is valid, and the works enqueued through the function stop_one_cpu_nowait() do carry no done, thus we have to check if it is valid when updating work result. Signed-off-by: Hillf Danton --- --- a/kernel/stop_machine.c Thu Feb 7 20:03:10 2013 +++ b/kernel/stop_machine.c Fri Feb 8 11:07:40 2013 @@ -279,7 +279,7 @@ repeat: preempt_disable(); ret = fn(arg); - if (ret) + if (ret && done != NULL) done->ret = ret; /* restore preemption and check it's still balanced */ -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vmalloc: Remove alloc_map from vmap_block.
>I started looking for workloads to profile but then lost interest. >The current code can theoretically end up walking through a lot of >partially used blocks if a string of allocations never fit any of >them. The number of these blocks depends on previous allocations that >leave them unusable for future allocations and whether any other >vmalloc/vmap user recently flushed them all. So it's painful to think >about it and hard to impossible to pin down should this ever actually >result in a performance problem. vm_map_ram() is allowed to be called by external kernel module. I profiled some kernel module as bellow perf log. Its mapping behavior was most of the workload. yes, we can improve its inefficient mapping. But, This shows the allocation bitmap has the potential to cause significant overhead. # Overhead CommandShared Object Symbol # ... ... . # 42.74% XXTextureSc [kernel.kallsyms][k] __reg_op | --- __reg_op | |--5.39%-- 0xaf57de00 | | | --100.00%-- malloc | |--2.35%-- 0xaf57da00 | | | --100.00%-- malloc | |--2.10%-- 0xaf57ce00 | | | --100.00%-- malloc | |--1.46%-- 0xaf57c800 | | | --100.00%-- malloc | |--1.43%-- 0xaf57dc00 | | | --100.00%-- malloc | |--1.36%-- 0xaf57c200 | | | --100.00%-- malloc | |--1.34%-- 0xaf57c000 | | | --100.00%-- malloc | |--1.26%-- 0xae915400 | | | --100.00%-- malloc | |--0.80%-- 0xae914200 | | | --100.00%-- malloc | |--0.79%-- 0xaf57ca00 | | | --100.00%-- malloc | |--0.67%-- 0xaf57d000 | | | --100.00%-- malloc | |--0.52%-- 0xaf57cc00 | | | --100.00%-- malloc --80.54%-- [...] 17.39% XXTextureSc [kernel.kallsyms][k] bitmap_find_free_region | --- bitmap_find_free_region | |--99.93%-- vm_map_ram | 0x7f00097c | 0x7f00985c | | | |--99.79%-- 0x7f009948 | | | | | |--50.24%-- 0x7f00ab90 | | | 0x7f006c50 | | | 0x7f00e948 | | | 0x7f019630 | | | 0x7f00f0ac | | | 0x7f002384 | | | vfs_ioctl | | | do_vfs_ioctl | | | sys_ioctl | | | ret_fast_syscall | | | | | |--49.60%-- 0x7f00acfc | | | 0x7f006bfc | | | 0x7f018fac | | | 0x7f00f0ac | | | 0x7f002384 | | | vfs_ioctl | | | do_vfs_ioctl | | | sys_ioctl | | | ret_fast_syscall | | | malloc | | --0.16%-- [...] ... Thanks Chanho Min -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Thu, Feb 7, 2013 at 7:04 PM, Zhang Rui wrote:
> On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
>> On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
>> > This removes the driver specific sysfs support of the temperature
>> > emulation and uses the newly added core thermal framework for thermal
>> > emulation. A platform specific handler is added to support this.
>> >
>> > Signed-off-by: Amit Daniel Kachhap
>> > Acked-by: Kukjin Kim
>> > ---
>> > Changes in V2:
>> > * Added config option CONFIG_THERMAL_EMULATION instead of
>> > CONFIG_EXYNOS_THERMAL_EMUL
>> >
>> > This patchset is based on thermal maintainer next tree.
>> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
>> >
>> > Documentation/thermal/exynos_thermal_emulation |8 +-
>> > drivers/thermal/Kconfig|9 --
>> > drivers/thermal/exynos_thermal.c | 158
>> > ++--
>> > 3 files changed, 67 insertions(+), 108 deletions(-)
>> >
>> > diff --git a/Documentation/thermal/exynos_thermal_emulation
>> > b/Documentation/thermal/exynos_thermal_emulation
>> > index b73bbfb..36a3e79 100644
>> > --- a/Documentation/thermal/exynos_thermal_emulation
>> > +++ b/Documentation/thermal/exynos_thermal_emulation
>> > @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
>> > TMU's operation. User can set
>> > manually with software code and TMU will read current temperature from
>> > user value not from
>> > sensor's value.
>> >
>> > -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
>> > available.
>> > -When it's enabled, sysfs node will be created under
>> > -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
>> > +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
>> > +When it's enabled, sysfs node will be created as
>> > +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
>> >
>> > -The sysfs node, 'emulation', will contain value 0 for the initial state.
>> > When you input any
>> > +The sysfs node, 'emul_node', will contain value 0 for the initial state.
>> > When you input any
>> > temperature you want to update to sysfs node, it automatically enable
>> > emulation mode and
>> > current temperature will be changed into it.
>> > (Exynos also supports user changable delay time which would be used to
>> > delay of
>> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> > index e4cf7fb..2a79510 100644
>> > --- a/drivers/thermal/Kconfig
>> > +++ b/drivers/thermal/Kconfig
>> > @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
>> > If you say yes here you get support for TMU (Thermal Management
>> > Unit) on SAMSUNG EXYNOS series of SoC.
>> >
>> > -config EXYNOS_THERMAL_EMUL
>> > - bool "EXYNOS TMU emulation mode support"
>> > - depends on EXYNOS_THERMAL
>> > - help
>> > - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
>> > - Enable this option will be make sysfs node in exynos thermal platform
>> > - device directory to support emulation mode. With emulation mode sysfs
>> > - node, you can manually input temperature to TMU for simulation
>> > purpose.
>> > -
>> > config DB8500_THERMAL
>> > bool "DB8500 thermal management"
>> > depends on ARCH_U8500
>> > diff --git a/drivers/thermal/exynos_thermal.c
>> > b/drivers/thermal/exynos_thermal.c
>> > index 327102a..afe9c2a 100644
>> > --- a/drivers/thermal/exynos_thermal.c
>> > +++ b/drivers/thermal/exynos_thermal.c
>> > @@ -99,13 +99,13 @@
>> > #define IDLE_INTERVAL 1
>> > #define MCELSIUS 1000
>> >
>> > -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
>> > +#ifdef CONFIG_THERMAL_EMULATION
>> > #define EXYNOS_EMUL_TIME 0x57F0
>> > #define EXYNOS_EMUL_TIME_SHIFT 16
>> > #define EXYNOS_EMUL_DATA_SHIFT 8
>> > #define EXYNOS_EMUL_DATA_MASK 0xFF
>> > #define EXYNOS_EMUL_ENABLE 0x1
>> > -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
>> > +#endif /* CONFIG_THERMAL_EMULATION */
>> >
>> > /* CPU Zone information */
>> > #define PANIC_ZONE 4
>> > @@ -143,6 +143,7 @@ struct thermal_cooling_conf {
>> > struct thermal_sensor_conf {
>> > char name[SENSOR_NAME_LEN];
>> > int (*read_temperature)(void *data);
>> > + int (*write_emul_temp)(void *data, unsigned long temp);
>> > struct thermal_trip_point_conf trip_data;
>> > struct thermal_cooling_conf cooling_data;
>> > void *private_data;
>> > @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
>> > *thermal,
>> > return 0;
>> > }
>> >
>> > +/* Get temperature callback functions for thermal zone */
>> > +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
>> > + unsigned long temp)
>> > +{
>> > + void *data;
>> > + int ret = -EINVAL;
>> > +
>> > + if (!th_zone->sensor_conf) {
>> > + pr_info("Temperature sensor not initialised\n");
>> > + return -EINVAL;
>> > +
Re: [PATCH 2/2] ACPI / scan: Make container driver use struct acpi_scan_handler
On Thu, Feb 7, 2013 at 4:27 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the ACPI container driver use struct acpi_scan_handler for > representing the object used to initialize ACPI containers and remove > the ACPI driver structure used previously and the data structures > created by it, since in fact they were not used for any purpose. > > This simplifies the code and reduces the kernel's memory footprint by > avoiding the registration of a struct device_driver object with the > driver core and creation of its sysfs directory which is unnecessary. > > In addition to that, make the namespace walk callback used for > installing the notify handlers for ACPI containers more > straightforward. > > This change includes fixes from Toshi Kani. > > Signed-off-by: Rafael J. Wysocki Yes, container support should be built-in by nature. Acked-by: Yinghai Lu What is the next? dock? Hope someone with access of dock that have pcie devices could help sorting it out... Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: splice() giving unexpected EOF in 3.7.3 and 3.8-rc4+
From: Eric Wong Date: Fri, 8 Feb 2013 02:39:46 + > David Miller wrote: >> From: Eric Dumazet >> Date: Fri, 18 Jan 2013 22:13:16 -0800 >> >> > On Fri, 2013-01-18 at 21:54 -0800, Eric Dumazet wrote: >> > >> >> >> >> Hmm, this might be already fixed in net-next tree, could you try it ? >> >> >> > >> > Yes, running your program on net-next seems OK. >> > >> > David, we need the two following commits. >> >> Tossed into 'net' and queued up for -stable, thanks. > > Hi David, any update on getting these into -stable? Thanks. I submit stable patches once they have cooked upstream for a week or two. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ACPI / scan: Remove useless #ifndef and simplify container driver
Hi Rafael, 2013/02/08 9:24, Rafael J. Wysocki wrote: On Monday, February 04, 2013 12:47:31 AM Rafael J. Wysocki wrote: From: Rafael J. Wysocki The only useful thing that the ACPI container driver does is to install system notify handlers for all container and module device objects it finds in the namespace. The driver structure, acpi_container_driver, and the data structures created by its .add() callback are in fact not used by the driver, so remove them entirely. It also makes a little sense to build that driver as a module, so make it non-modular and add its initialization to the namespace scanning code. In addition to that, make the namespace walk callback used for installing the notify handlers more straightforward. As pointed out by Toshi Kani, the above changes would make acpi_eject_store() fail for containers and it is the only way to eject them currently, so patch [2/2] is an improved version of this (with Toshi's changes folded in). Patch [1/2] is just a cleanup removing a useless #ifndef from acpi_eject_store(). I confimed the patch series works well. Acked-by: Yasuaki Ishimatsu Tested-by: Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cputime: restore CPU_ACCOUNTING config defaults for PPC64
Commit abf917cd91cb ("cputime: Generic on-demand virtual cputime
accounting") inadvertantly changed the default CPU_ACCOUNTING config
for PPC64. Repair that.
Signed-off-by: Stephen Rothwell
---
init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index ed24d1b..ccd1ca5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -301,7 +301,7 @@ config VIRT_CPU_ACCOUNTING
choice
prompt "Cputime accounting"
default TICK_CPU_ACCOUNTING if !PPC64
- default VIRT_CPU_ACCOUNTING if PPC64
+ default VIRT_CPU_ACCOUNTING_NATIVE if PPC64
# Kind of a stub config for the pure tick based cputime accounting
config TICK_CPU_ACCOUNTING
--
1.8.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpyyPtLlNu3L.pgp
Description: PGP signature
Re: [PATCH v3 12/23] tty: Kick waiters _after_ the ldisc is locked
On Thu, 2013-02-07 at 16:47 +0100, Jiri Slaby wrote:
> On 02/05/2013 09:20 PM, Peter Hurley wrote:
>
> The question is obvious: why?
>
> The waiters usually don't care about ldisc.
This patch really needed a decent commit message, but this isn't a fix,
per se.
While I was auditing the ldisc hangup, I realized that when a reader is
woken from sleeping in n_tty_read() and loops back around because there
is more room in the reader's buffer (nr > 0), input_available_p() will
schedule buffer work and wait for it to complete before testing if the
tty is hung up.
This change ensures that flush_to_ldisc() sees a halted ldisc and
promptly returns. A blocking reader whose read_buf is empty is the most
likely state when a hangup occurs.
I didn't include it tty_ldisc_halt(), because tty_set_ldisc() can't kick
readers out of their i/o loops and tty_ldisc_release() has no waiters.
Even if the change is nixed, the comments should be changed; the FIXME
is from before waiting for readers to exit their i/o loops.
separate but related discussion
Another thing to note is this really does nothing to address the problem
of a slave pty being unable to read all the data written by the master,
if the master is closed with a lot of data in the tty buffer. In this
case, when the slave is hungup as a result of the master closing, it's
ldisc will be halted, preventing the tty_buffer from pushing more data.
In my opinion, this is an important fixme. Almost as important as
replacing the TTY_LDISC flag + reference count with a rwsem to get
lockdep support...
> > Signed-off-by: Peter Hurley
> > ---
> > drivers/tty/tty_ldisc.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> > index c903778..8a86a72 100644
> > --- a/drivers/tty/tty_ldisc.c
> > +++ b/drivers/tty/tty_ldisc.c
> > @@ -604,6 +604,12 @@ static bool tty_ldisc_hangup_halt(struct tty_struct
> > *tty)
> >
> > clear_bit(TTY_LDISC, >flags);
> >
> > + /* Wakeup waiters so they can discover the tty is hupping, abort
> > +* their i/o loops, and release their ldisc references
> > +*/
> > + wake_up_interruptible_poll(>write_wait, POLLOUT);
> > + wake_up_interruptible_poll(>read_wait, POLLIN);
> > +
> > if (tty->ldisc) { /* Not yet closed */
> > tty_unlock(tty);
> >
> > @@ -875,12 +881,6 @@ void tty_ldisc_hangup(struct tty_struct *tty)
> > tty_ldisc_deref(ld);
> > }
> > /*
> > -* FIXME: Once we trust the LDISC code better we can wait here for
> > -* ldisc completion and fix the driver call race
> > -*/
> > - wake_up_interruptible_poll(>write_wait, POLLOUT);
> > - wake_up_interruptible_poll(>read_wait, POLLIN);
> > - /*
> > * Shutdown the current line discipline, and reset it to
> > * N_TTY if need be.
> > *
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] cputime: Generic on-demand virtual cputime accounting
Hi Frederic, On Fri, 8 Feb 2013 14:07:49 +1100 Stephen Rothwell wrote: > > This patch has the side effect of changing the default configurations: > (This is PowerPC pseries_defconfig before/after this patch) > > @@ -119,8 +120,8 @@ > # > # CPU/Task time and stats accounting > # > -# CONFIG_TICK_CPU_ACCOUNTING is not set > -CONFIG_VIRT_CPU_ACCOUNTING=y > +CONFIG_TICK_CPU_ACCOUNTING=y > +# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > > I don't know if that was deliberate, but it was suprising. I noticed > when this patch entered next-20130207. I suspect that this is caused by the changes to init/Kconfig: diff --git a/init/Kconfig b/init/Kconfig index be8b7f5..a05f843 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -326,6 +326,9 @@ source "kernel/time/Kconfig" menu "CPU/Task time and stats accounting" +config VIRT_CPU_ACCOUNTING + bool + choice prompt "Cputime accounting" default TICK_CPU_ACCOUNTING if !PPC64 The next line of context is: default VIRT_CPU_ACCOUNTING if PPC64 Which may have needed changing as well? Indeed, changing that to VIRT_CPU_ACCOUNTING_NATIVE restores the old defaults. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpNJ9nQt0jOs.pgp Description: PGP signature
Re: [GIT PULL] f2fs fixes for v3.8-rc7
On Fri, Feb 08, 2013 at 12:09:34PM +1100, Linus Torvalds wrote: > No. > > You guys need to realize that I'm not talking crap like this this late. > > This is not major bugfixes. I already looked away once just because > it's a new filesystem, but enough is enough. This is way way WAY too > late to start sendign "enhancements". Seriously. > > Send them for the next merge window. Not just before rc7. BTW, for the next merge window I've got several patches to that sucker; commits f3d9d7e..10e4e72 in vfs.git. I can send them to f2fs tree or have them go in vfs one, but this stuff needs to be dealt with. Fake struct dentry on stack is a bad thing with capital Hell No... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] cputime: Generic on-demand virtual cputime accounting
Hi Frederic, On Mon, 28 Jan 2013 20:04:01 +0100 Frederic Weisbecker wrote: > > If we want to stop the tick further idle, we need to be > able to account the cputime without using the tick. > > Virtual based cputime accounting solves that problem by > hooking into kernel/user boundaries. > > However implementing CONFIG_VIRT_CPU_ACCOUNTING require > low level hooks and involves more overhead. But we already > have a generic context tracking subsystem that is required > for RCU needs by archs which plan to shut down the tick > outside idle. > > This patch implements a generic virtual based cputime > accounting that relies on these generic kernel/user hooks. > > There are some upsides of doing this: > > - This requires no arch code to implement CONFIG_VIRT_CPU_ACCOUNTING > if context tracking is already built (already necessary for RCU in full > tickless mode). > > - We can rely on the generic context tracking subsystem to dynamically > (de)activate the hooks, so that we can switch anytime between virtual > and tick based accounting. This way we don't have the overhead > of the virtual accounting when the tick is running periodically. > > And one downside: > > - There is probably more overhead than a native virtual based cputime > accounting. But this relies on hooks that are already set anyway. > > Signed-off-by: Frederic Weisbecker > Cc: Andrew Morton > Cc: Ingo Molnar > Cc: Li Zhong > Cc: Namhyung Kim > Cc: Paul E. McKenney > Cc: Paul Gortmaker > Cc: Peter Zijlstra > Cc: Steven Rostedt > Cc: Thomas Gleixner This patch has the side effect of changing the default configurations: (This is PowerPC pseries_defconfig before/after this patch) @@ -119,8 +120,8 @@ # # CPU/Task time and stats accounting # -# CONFIG_TICK_CPU_ACCOUNTING is not set -CONFIG_VIRT_CPU_ACCOUNTING=y +CONFIG_TICK_CPU_ACCOUNTING=y +# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y I don't know if that was deliberate, but it was suprising. I noticed when this patch entered next-20130207. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpboaKlb6XJm.pgp Description: PGP signature
RE: [PATCH V2 2/2] ARM: davinci: restart: fix wdt to machine restart with DT
Hi Sekhar,
Thanks for the review.
On Thu, Feb 07, 2013 at 23:45:53, Nori, Sekhar wrote:
>
> On 2/6/2013 9:30 AM, Kumar, Anil wrote:
> > In non DT case da8xx_register_watchdog() is called to register platform
> > device
> > "da8xx_wdt_device" by board file. But in DT case it is not called and wdt
> > device get registered via wdt DT node.
> >
> > Currently code is passing platform device "da8xx_wdt_device" in
> > "davinci_watchdog_reset" function in both DT and non DT case and that
> > leads to crash in DT boot.
> >
> > Update restart function to make it generic DaVinci machine restart
>
> s/DaVinci/da8xx. Also, subject can simply be "ARM: davinci: da850 DT:
> add support for machine reboot" since reboot never worked with DT
> before, "fix" isn't really appropriate.
ok
>
> > in case of DT and non DT boot.
> >
> > Signed-off-by: Kumar, Anil
> > ---
> > :100644 100644 2d5502d... 1df68fd... M
> > arch/arm/mach-davinci/devices-da8xx.c
> > :100644 100644 700d311... ef9f70e... M
> > arch/arm/mach-davinci/include/mach/da8xx.h
> > arch/arm/mach-davinci/devices-da8xx.c | 14 --
> > arch/arm/mach-davinci/include/mach/da8xx.h |1 -
> > 2 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> > b/arch/arm/mach-davinci/devices-da8xx.c
> > index 2d5502d..1df68fd 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -359,7 +359,7 @@ static struct resource da8xx_watchdog_resources[] = {
> > },
> > };
> >
> > -struct platform_device da8xx_wdt_device = {
> > +static struct platform_device da8xx_wdt_device = {
>
> Making of da8xx_wdt_device static should find a mention in description.
Ok,
I made da8xx_wdt_device structure static as it is used only
in file. I will update description for this.
>
> > .name = "watchdog",
> > .id = -1,
> > .num_resources = ARRAY_SIZE(da8xx_watchdog_resources),
> > @@ -368,7 +368,17 @@ struct platform_device da8xx_wdt_device = {
> >
> > void da8xx_restart(char mode, const char *cmd)
> > {
> > - davinci_watchdog_reset(_wdt_device);
> > + struct device *dev = NULL;
> > + struct platform_device *wdt_device = NULL;
>
> No need to initialize these variables here.
Ok,
I think no need to define wdt_device, can be used as
davinci_watchdog_reset(to_platform_device(dev));
>
> > +
> > + dev = bus_find_device_by_name(_bus_type, NULL, "watchdog");
> > + if (!dev) {
> > + pr_err("wdt device not found to machine reboot\n");
>
> Rather: "%s: failed to find watchdog device", __func__
ok
Thanks,
Anil
Re: [PATCH V2 2/2] thermal: exynos: Use the framework for temperature emulation support
On Mon, 2013-02-04 at 10:14 +0800, Zhang Rui wrote:
> On Sun, 2013-01-27 at 19:28 -0800, Amit Daniel Kachhap wrote:
> > This removes the driver specific sysfs support of the temperature
> > emulation and uses the newly added core thermal framework for thermal
> > emulation. A platform specific handler is added to support this.
> >
> > Signed-off-by: Amit Daniel Kachhap
> > Acked-by: Kukjin Kim
> > ---
> > Changes in V2:
> > * Added config option CONFIG_THERMAL_EMULATION instead of
> > CONFIG_EXYNOS_THERMAL_EMUL
> >
> > This patchset is based on thermal maintainer next tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
> >
> > Documentation/thermal/exynos_thermal_emulation |8 +-
> > drivers/thermal/Kconfig|9 --
> > drivers/thermal/exynos_thermal.c | 158
> > ++--
> > 3 files changed, 67 insertions(+), 108 deletions(-)
> >
> > diff --git a/Documentation/thermal/exynos_thermal_emulation
> > b/Documentation/thermal/exynos_thermal_emulation
> > index b73bbfb..36a3e79 100644
> > --- a/Documentation/thermal/exynos_thermal_emulation
> > +++ b/Documentation/thermal/exynos_thermal_emulation
> > @@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for
> > TMU's operation. User can set
> > manually with software code and TMU will read current temperature from
> > user value not from
> > sensor's value.
> >
> > -Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in
> > available.
> > -When it's enabled, sysfs node will be created under
> > -/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
> > +Enabling CONFIG_THERMAL_EMULATION option will make this support available.
> > +When it's enabled, sysfs node will be created as
> > +/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
> >
> > -The sysfs node, 'emulation', will contain value 0 for the initial state.
> > When you input any
> > +The sysfs node, 'emul_node', will contain value 0 for the initial state.
> > When you input any
> > temperature you want to update to sysfs node, it automatically enable
> > emulation mode and
> > current temperature will be changed into it.
> > (Exynos also supports user changable delay time which would be used to
> > delay of
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index e4cf7fb..2a79510 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -109,15 +109,6 @@ config EXYNOS_THERMAL
> > If you say yes here you get support for TMU (Thermal Management
> > Unit) on SAMSUNG EXYNOS series of SoC.
> >
> > -config EXYNOS_THERMAL_EMUL
> > - bool "EXYNOS TMU emulation mode support"
> > - depends on EXYNOS_THERMAL
> > - help
> > - Exynos 4412 and 4414 and 5 series has emulation mode on TMU.
> > - Enable this option will be make sysfs node in exynos thermal platform
> > - device directory to support emulation mode. With emulation mode sysfs
> > - node, you can manually input temperature to TMU for simulation
> > purpose.
> > -
> > config DB8500_THERMAL
> > bool "DB8500 thermal management"
> > depends on ARCH_U8500
> > diff --git a/drivers/thermal/exynos_thermal.c
> > b/drivers/thermal/exynos_thermal.c
> > index 327102a..afe9c2a 100644
> > --- a/drivers/thermal/exynos_thermal.c
> > +++ b/drivers/thermal/exynos_thermal.c
> > @@ -99,13 +99,13 @@
> > #define IDLE_INTERVAL 1
> > #define MCELSIUS 1000
> >
> > -#ifdef CONFIG_EXYNOS_THERMAL_EMUL
> > +#ifdef CONFIG_THERMAL_EMULATION
> > #define EXYNOS_EMUL_TIME 0x57F0
> > #define EXYNOS_EMUL_TIME_SHIFT 16
> > #define EXYNOS_EMUL_DATA_SHIFT 8
> > #define EXYNOS_EMUL_DATA_MASK 0xFF
> > #define EXYNOS_EMUL_ENABLE 0x1
> > -#endif /* CONFIG_EXYNOS_THERMAL_EMUL */
> > +#endif /* CONFIG_THERMAL_EMULATION */
> >
> > /* CPU Zone information */
> > #define PANIC_ZONE 4
> > @@ -143,6 +143,7 @@ struct thermal_cooling_conf {
> > struct thermal_sensor_conf {
> > char name[SENSOR_NAME_LEN];
> > int (*read_temperature)(void *data);
> > + int (*write_emul_temp)(void *data, unsigned long temp);
> > struct thermal_trip_point_conf trip_data;
> > struct thermal_cooling_conf cooling_data;
> > void *private_data;
> > @@ -366,6 +367,23 @@ static int exynos_get_temp(struct thermal_zone_device
> > *thermal,
> > return 0;
> > }
> >
> > +/* Get temperature callback functions for thermal zone */
> > +static int exynos_set_emul_temp(struct thermal_zone_device *thermal,
> > + unsigned long temp)
> > +{
> > + void *data;
> > + int ret = -EINVAL;
> > +
> > + if (!th_zone->sensor_conf) {
> > + pr_info("Temperature sensor not initialised\n");
> > + return -EINVAL;
> > + }
> > + data = th_zone->sensor_conf->private_data;
> > + if (th_zone->sensor_conf->write_emul_temp)
> > + ret =
Re: [PATCH 05/10] USB: EHCI: make ehci-atmel a separate driver
Hi Manjunath Goudar,
I test this patch based on linux master branch, the commit id is:
6bacaa9ddacb71c691d32c678d37bc59ffc71fac. (I am not sure this is the
right place for testing).
First, it has an compile error as following. After fix it, and
tested, the EHCI doesn't work.
---<8---
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of
function 'ehci_shutdown'
--->8---
And a little code style comments as following.
On 2/8/2013 1:34, manjunath.gou...@linaro.org wrote:
From: Manjunath Goudar
Separate the Atmel host controller driver from ehci-hcd host code
into its own driver module.
Signed-off-by: Manjunath Goudar
Cc: Alan Stern
Cc: Greg KH
Cc: Grant Likely
Cc: Rob Herring
Cc: Andrew Victor
Cc: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/usb/host/Kconfig |7
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-atmel.c | 78 ++---
drivers/usb/host/ehci-hcd.c |6 +---
4 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3689b7b..5a13f9d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -176,6 +176,13 @@ config USB_EHCI_HCD_ORION
---help---
Enables support for the on-chip EHCI controller on
Morvell Orion chips.
Need blank line here.
+config USB_EHCI_HCD_AT91
+tristate "Support for Atmel on-chip EHCI USB controller"
+depends on USB_EHCI_HCD && ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
config USB_EHCI_MSM
bool "Support for MSM on-chip EHCI USB controller"
[snip]
+static void __exit ehci_atmel_cleanup(void)
+{
+ platform_driver_unregister(_atmel_driver);
+}
+module_exit(ehci_atmel_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+
+MODULE_ALIAS("platform:ehci-atmel");
+MODULE_AUTHOR("Nicolas Ferre");
+MODULE_LICENSE("GPL");
+
Remove the blank line here. As to it is the EOF.
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add the values related to buddy system for filtering free pages.
Hello Lisa, On Thu, 07 Feb 2013 05:29:11 -0700 Lisa Mitchell wrote: > > > > Also, I have one question. Can we always think of 1st and 2nd kernels > > > > are same? > > > > > > Not at all. Distros frequently implement it with the same kernel in > > > both role but it should be possible to use an old crusty stable kernel > > > as the 2nd kernel. > > > > > > > If I understand correctly, kexec/kdump can use the 2nd kernel different > > > > from the 1st's. So, differnet kernels need to do the same thing as > > > > makedumpfile > > > > does. If assuming two are same, problem is mush simplified. > > > > > > As a developer it becomes attractive to use a known stable kernel to > > > capture the crash dump even as I experiment with a brand new kernel. > > > > To allow to use the 2nd kernel different from the 1st's, I think we have > > to take care of each kernel version with the logic included in makedumpfile > > for them. That's to say, makedumpfile goes on as before. > > > > > > Thanks > > Atsushi Kumagai > > > Atsushi and Vivek: > > I'm trying to get the status of whether the patch submitted in > https://lkml.org/lkml/2012/11/21/90 is going to be accepted upstream > and get in some version of the Linux 3.8 kernel. I'm replying to the > last email thread above on kexec_lists and lkml.org that I could find > about this patch. > > I was counting on this kernel patch to improve performance of > makedumpfilev1.5.1, so at least it wouldn't be a regression in > performance over makedumpfile v1.4. It was listed as recommended in > the makedumpfilev1.5.1 release posting: > http://lists.infradead.org/pipermail/kexec/2012-December/007460.html > > > All the conversations in the thread since this patch was committed seem > to voice some reservations now, and reference other fixes being tried to > improve performance. > > Does that mean you are abandoning getting this patch accepted upstream, > in favor of pursuing other alternatives? No, this patch has been merged into -next, we should just wait for it to be merged into linus tree. http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0c63e90dd1c7b35ae2ea9475ba67cf68d8801a26 What interests us now is improvement for interfaces of /proc/vmcore, it's not alternative but another idea which can be consistent with this patch. Thanks Atsushi Kumagai > > I had hoped this patch would be okay to get accepted upstream, and then > other improvements could be built on top of it. > > Is that not the case? > > Or has further review concluded now that this change is a bad idea due > to adding dependence of this new makedumpfile feature on some deep > kernel memory internals? > > Thanks, > > Lisa Mitchell > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On 8 February 2013 01:09, Artem Savkov wrote:
> Tested out linux-pm.git/linux-next with this patches pulled. It seems
> that my systemd-sleep issue is fixed, however there is a new 'sleeping
> in invalid context' bug during boot:
>
> [ 12.736484] BUG: sleeping function called from invalid context at
> mm/slub.c:925
> [ 12.739727] in_atomic(): 1, irqs_disabled(): 1, pid: 1799, name:
> systemd-modules
> [ 12.742961] 2 locks held by systemd-modules/1799:
> [ 12.746153] #0: (subsys mutex#3){..}, at: []
> subsys_interface_register+0x36/0xb0
> [ 12.749499] #1: (cpufreq_driver_lock){..}, at: []
> cpufreq_add_dev+0x22b/0x3d0
> [ 12.752865] Pid: 1799, comm: systemd-modules Not tainted 3.8.0-rc6+ #1
> [ 12.756175] Call Trace:
> [ 12.759538] [] __might_sleep+0xe0/0x100
> [ 12.762156] [] kmem_cache_alloc_trace+0xb1/0x150
> [ 12.765432] [] ? acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
> [ 12.768780] [] acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
> [ 12.772161] [] ? cpufreq_add_dev+0x22b/0x3d0
> [ 12.775549] [] ? _raw_spin_lock_irqsave+0x77/0x90
> [ 12.778932] [] ? cpufreq_add_dev+0x22b/0x3d0
> [ 12.782307] [] cpufreq_add_dev+0x238/0x3d0
Can you please try out this:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 819aa33..a77d0bc 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -919,17 +919,14 @@ static int cpufreq_add_dev(struct device *dev,
struct subsys_interface *sif)
init_completion(>kobj_unregister);
INIT_WORK(>update, handle_update);
- spin_lock_irqsave(_driver_lock, flags);
/* call driver. From then on the cpufreq must be able
* to accept all calls to ->verify and ->setpolicy for this CPU
*/
ret = driver->init(policy);
if (ret) {
pr_debug("initialization failed\n");
- spin_unlock_irqrestore(_driver_lock, flags);
goto err_set_policy_cpu;
}
- spin_unlock_irqrestore(_driver_lock, flags);
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On 8 February 2013 05:03, Rafael J. Wysocki wrote: > I should have done that before, sorry about it. > > Can you please rework this series on top of linux-pm.git/pm-cpufreq and > try to avoid introducing new issues this time? Even i want to do that, but when i fetch your repo i don't see all applied patches in this branch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On 8 February 2013 04:37, Rafael J. Wysocki wrote: > On Thursday, February 07, 2013 06:52:20 PM Viresh Kumar wrote: >> On 7 February 2013 18:35, Rafael J. Wysocki wrote: >> > I think they all make sense, so applied to linux-next. >> > >> > I would prefer not to make any more changes to cpufreq before v3.9 from >> > now on, >> > except for fixes and maybe the Drik's patchset that I kind of scheduled for >> >> Dirk :) > > Yes, sorry Dirk. > >> > merging into bleeding-edge later today. >> >> I probably have few more for you. Some sparse warnings to be fixed for >> Dirks work and an dangling exynos patch which is waiting for your reply :) > > Which Exynos patch? https://lkml.org/lkml/2013/1/30/592 > BTW, there still are locking problems in linux-next. Why do we need > to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(), > in particular? I thought cpufreq provides atomicity to all drivers callbacks and that's why i had those around it :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: next-20130206 cpufreq - WARN in sysfs_add_one
On 8 February 2013 00:48, wrote: > On Thu, 07 Feb 2013 13:11:52 +0530, Viresh Kumar said: > >> First of all i want to confirm something about your system. I am sure it is a >> multi-policy system (or multi cluster system). i.e. there are more than one >> clock line for different cpus ? And so multiple struct policy exist >> simultaneously. > > Hmm.. it's a bog-standard Dell Latitude E6500 laptop, with a single > Core2 Duo P8700 CPU (one die, 2 cores, no HT). It's apparently able > to clock both cores at different speeds (one core running busy at 2540mhz > and the other idling at 800mhz), if that's what you mean by multiple > clock lines. Perfect!! So, when the cpus can manage different freqs, we have multiple struct policies for them per cpu. > In any case, next-20130206 complained, and with this patch added I see > nothing in dmesg and cpufreq is acting properly on both cores, so: > > Tested-By: Valdis Kletnieks Thanks. > (btw - I had to hand-apply your patch, as it showed up white-space > damaged. Three lines wrapped, and tabs converted to spaces). I know that and feeling bad for you :( I gave you this because of my mails issue :) http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-valdis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc: kernel/kgdb.c: fix memory leakage
On Thu, 2013-01-31 at 20:04 -0600, Jason Wessel wrote:
> > diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> > index 8747447..5ca82cd 100644
> > --- a/arch/powerpc/kernel/kgdb.c
> > +++ b/arch/powerpc/kernel/kgdb.c
> > @@ -154,12 +154,12 @@ static int kgdb_handle_breakpoint(struct pt_regs
> > *regs)
> > static int kgdb_singlestep(struct pt_regs *regs)
> > {
> > struct thread_info *thread_info, *exception_thread_info;
> > - struct thread_info *backup_current_thread_info = \
> > - (struct thread_info *)kmalloc(sizeof(struct thread_info),
> > GFP_KERNEL);
> > + struct thread_info *backup_current_thread_info;
>
>
>
> Woh... This is definitely wrong. You have found a problem for sure,
> but this is not the right way to fix it.
>
> It is not a good idea to kmalloc while single stepping because you can
> hang the kernel if you single step any operation in kmalloc().
Ok. I applied the fix because it was obviously correct vs. the previous
version of the code (ie. the kmalloc was already there)
> I am in the process of going through all the kgdb mails from the last
> few months while I had been away from the project, so I didn't catch
> this one and I see it has upstream commit (fefd9e6f8). I'll submit
> another patch to fix this the right way and use a static variable.
> This is ok to use a static variable here because this is not something
> we can recursively call at a single CPU level.
But a static will be shared by all CPUs or do you mean a per-cpu one ?
> If Ben prefers we not burn the memory unless kgdb is active we can
> kmalloc / kfree the space we need at the time that kgdb is
> initialized. Else we can go with this patch you see below. We'll see
> what Ben desires.
What about the stack ? thread info isn't very big...
Cheers,
Ben.
> -
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index a7bc752..bb12c8b 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -151,15 +151,16 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
> return 1;
> }
>
> +static struct thread_info kgdb_backup_thread_info[NR_CPUS];
> +
> static int kgdb_singlestep(struct pt_regs *regs)
> {
> struct thread_info *thread_info, *exception_thread_info;
> - struct thread_info *backup_current_thread_info;
> + int cpu = raw_smp_processor_id();
>
> if (user_mode(regs))
> return 0;
>
> - backup_current_thread_info = (struct thread_info
> *)kmalloc(sizeof(struct thread_info), GFP_KERNEL);
> /*
>* On Book E and perhaps other processors, singlestep is handled on
>* the critical exception stack. This causes current_thread_info()
> @@ -175,7 +176,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
>
> if (thread_info != exception_thread_info) {
> /* Save the original current_thread_info. */
> - memcpy(backup_current_thread_info, exception_thread_info,
> sizeof *thread_info);
> + memcpy(_backup_thread_info[cpu], exception_thread_info,
> sizeof *thread_info);
> memcpy(exception_thread_info, thread_info, sizeof *thread_info);
> }
>
> @@ -183,9 +184,8 @@ static int kgdb_singlestep(struct pt_regs *regs)
>
> if (thread_info != exception_thread_info)
> /* Restore current_thread_info lastly. */
> - memcpy(exception_thread_info, backup_current_thread_info,
> sizeof *thread_info);
> + memcpy(exception_thread_info, _backup_thread_info[cpu],
> sizeof *thread_info);
>
> - kfree(backup_current_thread_info);
> return 1;
> }
>
>
> -
>
>
> Thanks,
> Jason.
>
>
> >
> > if (user_mode(regs))
> > return 0;
> >
> > + backup_current_thread_info = (struct thread_info
> > *)kmalloc(sizeof(struct thread_info), GFP_KERNEL);
> > /*
> > * On Book E and perhaps other processors, singlestep is handled on
> > * the critical exception stack. This causes current_thread_info()
> > @@ -185,6 +185,7 @@ static int kgdb_singlestep(struct pt_regs *regs)
> > /* Restore current_thread_info lastly. */
> > memcpy(exception_thread_info, backup_current_thread_info,
> > sizeof *thread_info);
> >
> > + kfree(backup_current_thread_info);
> > return 1;
> > }
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: splice() giving unexpected EOF in 3.7.3 and 3.8-rc4+
David Miller wrote: > From: Eric Dumazet > Date: Fri, 18 Jan 2013 22:13:16 -0800 > > > On Fri, 2013-01-18 at 21:54 -0800, Eric Dumazet wrote: > > > >> > >> Hmm, this might be already fixed in net-next tree, could you try it ? > >> > > > > Yes, running your program on net-next seems OK. > > > > David, we need the two following commits. > > Tossed into 'net' and queued up for -stable, thanks. Hi David, any update on getting these into -stable? 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/
