Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
On 02/06/2013 10:24 PM, Glauber Costa wrote: And one more question, a memory section is 128MB in Linux. If we reserve part of the them for page_cgroup, then anyone who wants to allocate a contiguous memory larger than 128MB, it will fail, right ? Is it OK ? No, it is not. Another take on this: Can't we free all the page_cgroup structure before we actually start removing the sections ? If we do this, we would be basically left with no problem at all, since when your code starts running we would no longer have any page_cgroup allocated. All you have to guarantee is that it happens after the memory block is already isolated and allocations no longer can reach it. What do you think ? Hi Glauber, I don't think so. We can offline some of the sections and leave the reset online. For example, we store page_cgroups of memory9~11 in memory8. So when we offline memory8, we free memory8's page_cgroup storing on other section, but we cannot free the page_cgroups being stored in memory8 if memory9~11 are left online. So we still need to offline memory9~11, and then offline memory8, right ? I think it makes no difference. 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 v2 3/3] ARM: davinci: da850: add mmc DT entries
Add DT entry for MMC. Also add entry for pinmux information.
Tested on da850-evm without card detect and EDMA support as
DT support for GPIO and EDMA are yet come.
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
---
Since v1:
Removed bitfields for specifying the device capabilty and accomodate
controller revision in compatible field.
arch/arm/boot/dts/da850-evm.dts |9 +
arch/arm/boot/dts/da850.dtsi| 15 +++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index fa04152..78a6fb7 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -30,6 +30,15 @@
rtc0: rtc@1c23000 {
status = "okay";
};
+ mmc0: mmc@1c4 {
+ max-frequency = <5000>;
+ mmc-cap-sd-highspeed;
+ mmc-cap-mmc-highspeed;
+ bus-width = <4>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ };
};
nand_cs3@6200 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 099c81e..3ef9c22 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,6 +56,15 @@
0x30 0x0110 0x0ff0
>;
};
+ mmc0_pins: pinmux_mmc_pins {
+ pinctrl-single,bits = <
+ /* MMCSD0_DAT[3] MMCSD0_DAT[2]
+* MMCSD0_DAT[1] MMCSD0_DAT[0]
+* MMCSD0_CMDMMCSD0_CLK
+*/
+ 0x28 0x0022 0x00ff
+ >;
+ };
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -88,6 +97,12 @@
19>;
status = "disabled";
};
+ mmc0: mmc@1c4 {
+ compatible = "ti,davinci-mmc-da830";
+ reg = <0x4 0x1000>;
+ interrupts = <16>;
+ status = "disabled";
+ };
};
nand_cs3@6200 {
compatible = "ti,davinci-nand";
--
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 v2 2/3] mmc: davinci_mmc: add DT support
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
+
+Example:
+ mmc0: mmc@1c4 {
+ compatible = "ti,davinci-mmc-da830",
+ reg = <0x4 0x1000>;
+ interrupts = <16>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ mmc-cap-sd-highspeed;
+ mmc-cap-mmc-highspeed;
+ };
+
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 27123f8..3f90316 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -1157,15 +1159,80 @@ static void __init init_mmcsd_host(struct
mmc_davinci_host *host)
mmc_davinci_reset_ctrl(host, 0);
}
-static int __init davinci_mmcsd_probe(struct platform_device *pdev)
+static const struct of_device_id davinci_mmc_dt_ids[] = {
+ {
+ .compatible = "ti,davinci-mmc-dm355",
+ .data = (void *)MMC_CTLR_VERSION_1,
+ },
+ {
+ .compatible = "ti,davinci-mmc-da830",
+ .data = (void *)MMC_CTLR_VERSION_2,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, davinci_mmc_dt_ids);
+
+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;
+
+ of_property_read_u32(np, "bus-width", );
+ switch (data) {
+ case 0:
+ case 4:
+ case 8:
+ pdata->wires = data;
+ break;
+ default:
+ pdata->wires = 1;
+ dev_info(>dev, "Unsupported buswidth, defaulting to 1
bit\n");
+ }
+nodata:
+ return pdata;
+}
+
+static int __init davinci_mmcsd_probe(struct platform_device *pdev)
+{
+ struct davinci_mmc_config *pdata = NULL;
struct mmc_davinci_host *host = NULL;
struct mmc_host *mmc = NULL;
struct resource *r, *mem = NULL;
int ret = 0, irq = 0;
size_t mem_size;
+ pdata = mmc_parse_pdata(pdev);
+ if (pdata == NULL) {
+ dev_err(>dev, "Can not get platform
[PATCH v2 1/3] ARM: davinci: da850: override mmc DT node device name
Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.
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
---
Since v1:
Compatible string modified to accomodate version information.
arch/arm/mach-davinci/da8xx-dt.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..3362ca4 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -39,9 +39,16 @@ static void __init da8xx_init_irq(void)
#ifdef CONFIG_ARCH_DAVINCI_DA850
+static const struct of_dev_auxdata da8xx_auxdata[] __initconst = {
+ OF_DEV_AUXDATA("ti,davinci-mmc-da830", 0x01c4, "davinci_mmc.0",
+ NULL),
+ {},
+};
+
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table, da8xx_auxdata,
+ NULL);
da8xx_uart_clk_enable();
}
--
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] mfd: ab8500: fix compile error
Hi Linus, On Wed, Feb 06, 2013 at 11:23:01PM +0100, Linus Walleij wrote: > From: Linus Walleij > > When compiling the AB8500 core driver in the latest > MFD tree the following happens: > > CC drivers/mfd/ab8500-debugfs.o > /home/elinwal/linux-next/drivers/mfd/ab8500-debugfs.c:157:3: error: > 'AB8500_SYS_CTRL1_BLOCK' undeclared here (not in a function) > /home/elinwal/linux-next/drivers/mfd/ab8500-debugfs.c:157:2: error: array > index in initializer not of integer type > /home/elinwal/linux-next/drivers/mfd/ab8500-debugfs.c:157:2: error: (near > initialization for 'debug_ranges') > (...) > > This is due to a missing include statement, so fix > it up. > > Cc: Lee Jones > Signed-off-by: Linus Walleij > --- > drivers/mfd/ab8500-debugfs.c | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen_max
On Thu, Feb 07, 2013 at 12:15:18PM +0800, Zhang Yanfei wrote:
> Since the type of netns_ipvs->sysctl_sync_qlen_max has been changed to
> unsigned long, type of its related proc var sync_qlen_max should be changed
> to unsigned long, too. Also the return type of function
> sysctl_sync_qlen_max().
>
> Besides, the type of ipvs_master_sync_state->sync_queue_len should also be
> changed to unsigned long.
>
> Changelog from V1:
> - change type of ipvs_master_sync_state->sync_queue_len to unsigned long
> as Simon addressed.
>
> Cc: Andrew Morton
> Cc: David Miller
> Cc: Julian Anastasov
> Cc: Simon Horman
> Signed-off-by: Zhang Yanfei
Acked-by: Simon Horman
> ---
> include/net/ip_vs.h|6 +++---
> net/netfilter/ipvs/ip_vs_ctl.c |4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> index 68c69d5..1d56f92 100644
> --- a/include/net/ip_vs.h
> +++ b/include/net/ip_vs.h
> @@ -874,7 +874,7 @@ struct ip_vs_app {
> struct ipvs_master_sync_state {
> struct list_headsync_queue;
> struct ip_vs_sync_buff *sync_buff;
> - int sync_queue_len;
> + unsigned long sync_queue_len;
> unsigned intsync_queue_delay;
> struct task_struct *master_thread;
> struct delayed_work master_wakeup_work;
> @@ -1052,7 +1052,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
> *ipvs)
> return ACCESS_ONCE(ipvs->sysctl_sync_ports);
> }
>
> -static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
> +static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
> {
> return ipvs->sysctl_sync_qlen_max;
> }
> @@ -1099,7 +1099,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
> *ipvs)
> return 1;
> }
>
> -static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
> +static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
> {
> return IPVS_SYNC_QLEN_MAX;
> }
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index ec664cb..d79a530 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -1747,9 +1747,9 @@ static struct ctl_table vs_vars[] = {
> },
> {
> .procname = "sync_qlen_max",
> - .maxlen = sizeof(int),
> + .maxlen = sizeof(unsigned long),
> .mode = 0644,
> - .proc_handler = proc_dointvec,
> + .proc_handler = proc_doulongvec_minmax,
> },
> {
> .procname = "sync_sock_size",
> --
> 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: next-20130206 cpufreq - WARN in sysfs_add_one
On Thu, Feb 7, 2013 at 2:54 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 06, 2013 12:44:35 PM Valdis Kletnieks wrote:
>> Seen in dmesg. next-20130128 was OK. Haven't done a bisect, but can
>> do so if the offender isn't obvious...
>
> I suppose this is 73bf0fc "cpufreq: Don't remove sysfs link for policy->cpu".
Not really. :)
Hi Valdis,
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.
Because this crash can only come on those.
Anyway, i have tested and pushed a fix here:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-valdis
Please test it.
For others, the patch is:
commit 007dda326f1b1415846671d7fcfbd520f4f16151
Author: Viresh Kumar
Date: Thu Feb 7 12:51:27 2013 +0530
cpufreq: governors: Fix WARN_ON() for multi-policy platforms
On multi-policy systems there is a single instance of governor for both the
policies (if same governor is chosen for both policies). With the
code update
from following patches:
8eeed09 cpufreq: governors: Get rid of dbs_data->enable field
b394058 cpufreq: governors: Reset tunables only for
cpufreq_unregister_governor()
We are creating/removing sysfs directory of governor for for every call to
GOV_START and STOP. This would fail for multi-policy system as there is a
per-policy call to START/STOP.
This patch reuses the governor->initialized variable to detect
total users of
governor.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 6 --
drivers/cpufreq/cpufreq_governor.c | 32 +++-
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index ccc598a..3b941a1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1567,8 +1567,10 @@ static int __cpufreq_governor(struct
cpufreq_policy *policy,
policy->cpu, event);
ret = policy->governor->governor(policy, event);
- if (!policy->governor->initialized && (event == CPUFREQ_GOV_START))
- policy->governor->initialized = 1;
+ if (event == CPUFREQ_GOV_START)
+ policy->governor->initialized++;
+ else if (event == CPUFREQ_GOV_STOP)
+ policy->governor->initialized--;
/* we keep one module reference alive for
each CPU governed by this CPU */
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index e4a306c..5a76086 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -247,11 +247,13 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
dbs_data->gov_dbs_timer);
}
- rc = sysfs_create_group(cpufreq_global_kobject,
- dbs_data->attr_group);
- if (rc) {
- mutex_unlock(_data->mutex);
- return rc;
+ if (!policy->governor->initialized) {
+ rc = sysfs_create_group(cpufreq_global_kobject,
+ dbs_data->attr_group);
+ if (rc) {
+ mutex_unlock(_data->mutex);
+ return rc;
+ }
}
/*
@@ -262,13 +264,15 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
cs_dbs_info->down_skip = 0;
cs_dbs_info->enable = 1;
cs_dbs_info->requested_freq = policy->cur;
- cpufreq_register_notifier(cs_ops->notifier_block,
- CPUFREQ_TRANSITION_NOTIFIER);
- if (!policy->governor->initialized)
+ if (!policy->governor->initialized) {
+
cpufreq_register_notifier(cs_ops->notifier_block,
+ CPUFREQ_TRANSITION_NOTIFIER);
+
dbs_data->min_sampling_rate =
MIN_SAMPLING_RATE_RATIO *
jiffies_to_usecs(10);
+ }
} else {
od_dbs_info->rate_mult = 1;
od_dbs_info->sample_type = OD_NORMAL_SAMPLE;
@@ -311,11 +315,13 @@ unlock:
mutex_lock(_data->mutex);
mutex_destroy(_cdbs->timer_mutex);
- sysfs_remove_group(cpufreq_global_kobject,
- dbs_data->attr_group);
- if (dbs_data->governor == GOV_CONSERVATIVE)
- cpufreq_unregister_notifier(cs_ops->notifier_block,
-
Re: [PATCH 03/15] drivers/mfd: add missing GENERIC_HARDIRQS dependecies
Hi Heiko, On Wed, Feb 06, 2013 at 05:23:51PM +0100, Heiko Carstens wrote: > A lot of mfd drivers select MFD_CORE which however depends on > GENERIC_HARDIRQS support. > So add the missing dependency to all drivers to get rid of > this link error: > > ERROR: "irq_create_mapping" [drivers/mfd/mfd-core.ko] undefined! > > Cc: Samuel Ortiz > Signed-off-by: Heiko Carstens > --- > drivers/mfd/Kconfig | 72 > +++ > 1 file changed, 38 insertions(+), 34 deletions(-) > Applied to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/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 8:23 AM, Michal Simek wrote:
>>> #define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
>>> #define iowrite16(v, addr) writew((v), (addr))
>>> #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
>>>
>>> static inline void __raw_writew(u16 b, volatile void __iomem *addr)
>>> {
>>> *(volatile u16 __force *) addr = b;
>>> }
>>>
>>> How is this suppose to work on Big Endian?
>>> be16_to_cpu(v) is (v)
>>> and
>>> __cpu_to_le16(b) is swab16(v)
>>
>> Yes.
>
> But on native BE system ( I expect that v is in big endian)
> iowrite16be(v, addr) should be just *(volatile u16 __force *) addr =
> v; not *(volatile u16 __force *) addr = swab16(v);
>>> What I would expect is
>>> #define iowrite16be(v, addr) __raw_writew(__cpu_to_be16(v), addr)
>>
>> Indeed, it should be "__cpu_to_be16(v)" instead of "be16_to_cpu(v)".
>
> What do you mean by that?
Bummer, I missed that current iowrite16be() uses (the little endian)
iowrite16(),
not _raw_writew(), and thought the only difference between the original
and your version was the endianness conversion macro.
Yes,
#define iowrite16be(v, addr) __raw_writew(__cpu_to_be16(v), addr)
should be correct.
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: [PATCH 0/2] perf stat: add per processor socket count aggregation
On Thu, Feb 7, 2013 at 3:31 AM, Namhyung Kim wrote: > Hi Stephane, > > On Wed, 6 Feb 2013 15:46:00 +0100, Stephane Eranian wrote: >> This patch adds per-processor socket count aggregation >> for system-wide mode measurements. This is a useful >> mode to detect imbalance between sockets for uniform >> workloads. >> >> To enable this mode, use --aggr-socket in addition >> to -a. (system-wide). This mode can be combined with >> interval printing. >> >> The output includes the socket number and the number >> of online processors on that socket. This is useful >> to gauge the amount of aggregation. >> >> # ./perf stat -I 1000 -a --aggr-socket -e cycles sleep 2 >> # time socket cpus counts events >> 1.97680 S04 5,788,785 cycles >> 2.000379943 S04 27,361,546 cycles >> 2.001167808 S04818,275 cycles > > Can it be genericized to support arbitrary cpu topology like per-core, > per-numa-node or something? > Yes, we could. I think that could be useful too. I will look into this. But please don't ask for stupid scripting to do this. We need to keep things simple. I think perf has gotten to be a very complex tool, hard to read code, more difficult to maintain. As for the particular feature, I know how to make it work on x86, but it is not clear to me how portable is the sysfs topology tree? For instance, on PPC, would that work? Worst case, we can make the topology routines arch specific and use weak functions to cover any architecture which does not have topology info. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1]linux-usb: fix the idProduct value to be compatible with current CPU in initializers.c
From: fangxiaozhi
1. The idProduct is little endian, so make sure its value to be compatible with
the current CPU. Make no break on big endian processors.
Signed-off-by: fangxiaozhi
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c
linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c 2013-02-06
14:48:51.564355283 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c2013-02-07
15:29:59.929482630 +0800
@@ -147,7 +147,7 @@ static int usb_stor_huawei_dongles_pid(s
int idProduct;
idesc = >pusb_intf->cur_altsetting->desc;
- idProduct = us->pusb_dev->descriptor.idProduct;
+ idProduct = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
/* The first port is CDROM,
* means the dongle in the single port mode,
* and a switch command is required to be sent. */
@@ -169,7 +169,7 @@ int usb_stor_huawei_init(struct us_data
int result = 0;
if (usb_stor_huawei_dongles_pid(us)) {
- if (us->pusb_dev->descriptor.idProduct >= 0x1446)
+ if (le16_to_cpu(us->pusb_dev->descriptor.idProduct) >= 0x1446)
result = usb_stor_huawei_scsi_init(us);
else
result = usb_stor_huawei_feature_init(us);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: syscon: Added support for using platform driver resources
Hi Alexander,
Thanks for the patch adding non-dt support. :-)
On Mon, Feb 04, 2013 at 07:00:40PM +0400, Alexander Shiyan wrote:
> This patch adds support usage platform driver resources, i.e.
> possibility works without oftree support. Additionally patch
> removes CONFIG_OF dependency and adds helper for accessing
> regmap by searching device by its name.
>
> Signed-off-by: Alexander Shiyan
> ---
> drivers/mfd/Kconfig| 1 -
> drivers/mfd/syscon.c | 62
> +++---
> include/linux/mfd/syscon.h | 1 +
> 3 files changed, 48 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 47ad4e2..389f5e2 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1065,7 +1065,6 @@ config MFD_STA2X11
>
> config MFD_SYSCON
> bool "System Controller Register R/W Based on Regmap"
> - depends on OF
> select REGMAP_MMIO
> help
> Select this option to enable accessing system control registers
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 3f10591..27d0a08 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -29,7 +29,27 @@ struct syscon {
> struct regmap *regmap;
> };
>
> -static int syscon_match(struct device *dev, void *data)
> +static int syscon_match_name(struct device *dev, void *data)
> +{
> + return !strcmp(dev_name(dev), (const char *)data);
> +}
> +
> +struct regmap *syscon_regmap_lookup_by_name(const char *name)
> +{
> + struct syscon *syscon;
> + struct device *dev;
> +
> + dev = driver_find_device(_driver.driver, NULL, (void *)name,
> + syscon_match_name);
> + if (!dev)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + syscon = dev_get_drvdata(dev);
> +
> + return syscon->regmap;
> +}
> +
How about syscon_dev_to_regmap(struct device *dev) as the exist dt version
syscon_node_to_regmap since it's not affected by the name change of devices?
> +static int syscon_match_of(struct device *dev, void *data)
> {
> struct syscon *syscon = dev_get_drvdata(dev);
> struct device_node *dn = data;
> @@ -43,7 +63,7 @@ struct regmap *syscon_node_to_regmap(struct device_node *np)
> struct device *dev;
>
> dev = driver_find_device(_driver.driver, NULL, np,
> - syscon_match);
> + syscon_match_of);
> if (!dev)
> return ERR_PTR(-EPROBE_DEFER);
>
> @@ -102,26 +122,38 @@ static int syscon_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct device_node *np = dev->of_node;
> struct syscon *syscon;
> - struct resource res;
> + struct resource *res, res_of;
> int ret;
>
> - if (!np)
> - return -ENOENT;
> -
> syscon = devm_kzalloc(dev, sizeof(struct syscon),
> GFP_KERNEL);
> if (!syscon)
> return -ENOMEM;
>
> - syscon->base = of_iomap(np, 0);
> - if (!syscon->base)
> - return -EADDRNOTAVAIL;
> -
> - ret = of_address_to_resource(np, 0, );
> - if (ret)
> - return ret;
> + if (IS_ENABLED(CONFIG_OF) && np) {
> + syscon->base = of_iomap(np, 0);
> + if (!syscon->base)
> + return -EADDRNOTAVAIL;
> +
> + res = _of;
> + ret = of_address_to_resource(np, 0, res);
> + if (ret)
> + return ret;
> + } else {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENXIO;
> +
> + if (!request_mem_region(res->start, resource_size(res),
> + dev_name(>dev)))
> + return -EBUSY;
> +
> + syscon->base = ioremap(res->start, resource_size(res));
> + if (!syscon->base)
> + return -EADDRNOTAVAIL;
devm_request_and_ioremap?
Regards
Dong Aisheng
> + }
>
> - syscon_regmap_config.max_register = res.end - res.start - 3;
> + syscon_regmap_config.max_register = res->end - res->start - 3;
> syscon->regmap = devm_regmap_init_mmio(dev, syscon->base,
> _regmap_config);
> if (IS_ERR(syscon->regmap)) {
> @@ -133,7 +165,7 @@ static int syscon_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, syscon);
>
> dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
> - res.start, res.end);
> + res->start, res->end);
>
> return 0;
> }
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 6aeb6b8..e14f7fd 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -15,6 +15,7 @@
> #ifndef __LINUX_MFD_SYSCON_H__
> #define __LINUX_MFD_SYSCON_H__
>
> +extern struct regmap *syscon_regmap_lookup_by_name(const
Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
2013/2/6 Geert Uytterhoeven :
> On Wed, Feb 6, 2013 at 6:40 PM, Michal Simek wrote:
>> One question regarding to asm-generic/io.h about iowrite16be implementation
>>
>> #define iowrite16be(v, addr) iowrite16(be16_to_cpu(v), (addr))
>> #define iowrite16(v, addr) writew((v), (addr))
>> #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
>>
>> static inline void __raw_writew(u16 b, volatile void __iomem *addr)
>> {
>> *(volatile u16 __force *) addr = b;
>> }
>>
>> How is this suppose to work on Big Endian?
>> be16_to_cpu(v) is (v)
>> and
>> __cpu_to_le16(b) is swab16(v)
>
> Yes.
But on native BE system ( I expect that v is in big endian)
iowrite16be(v, addr) should be just *(volatile u16 __force *) addr =
v; not *(volatile u16 __force *) addr = swab16(v);
>> On little
>> be16_to_cpu(v) is swab16(v)
>
> Yes.
>
>> and
>> __cpu_to_le16(swab(b)) is swab16(v)
>
> ???
>
> Don't you mean "__cpu_to_le16(b) is (b)"?
BTW: I took output value from the first line (be16_to_cpu(v) is swab16(v))
Grrr - on LE this code works. (I expect that v is in little endian)
iowrite16be(v, addr) is *(volatile u16 __force *) addr = swab16(v);
>> What I would expect is
>> #define iowrite16be(v, addr) __raw_writew(__cpu_to_be16(v), addr)
>
> Indeed, it should be "__cpu_to_be16(v)" instead of "be16_to_cpu(v)".
What do you mean by that?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] batman-adv: Remove unused variable
On Thu, Feb 07, 2013 at 12:32:37AM +0100, Emil Goode wrote: > The below commit removed one node parameter from iterators. > ed242d01bbe22ea0877472db49b2752d866c921c > (hlist: drop the node parameter from iterators) > > This patch removes a hlist_node struct that is no longer used. > > Sparse gives a warning: > > net/batman-adv/originator.c:411:21: warning: > unused variable ‘node_tmp’ [-Wunused-variable] > > Signed-off-by: Emil Goode Acked-by: Antonio Quartulli Thanks Emil Cheers, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara pgpK76rjWJcDW.pgp Description: PGP signature
Re: [PATCH 00/11] lockdep: LD_PRELOAD support
On Thu, Feb 7, 2013 at 12:11 AM, Sasha Levin wrote: > This patch series adds in LD_PRELOAD support for liblockdep. FWIW, Acked-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: MODSIGN without RTC?
Am 07.02.2013 07:42, schrieb Geert Uytterhoeven: > On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler wrote: >> Am 07.02.2013 00:42, schrieb Alexander Holler: >>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by: >>> >>> [1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is >>> not yet valid >>> >>> The reason is likely that the (ARM) device in question doesn't have a >>> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP. >>> >>> The used certificate was generated automatically. Having a look at it, >>> the following is shown: >>> >>> Validity >>> Not Before: Feb 6 02:56:46 2013 GMT >>> Not After : Jan 13 02:56:46 2113 GMT >>> >>> Without having thought about possible security problems, my first idea >>> would be to let the validity start at 1970. As I never did such I never >>> had thought about possible implications when doing such (e.g. I don't >>> know if someone checks the start date for plausabilitiy) >>> >>> Another solution would be to retry loading of the certificate if the >>> time gets set (and e.g. differs more than a year). >>> >>> Has someone already thought about how to solve that problem? Or did >>> everyone use sane systems which have a (working) RTC? >> >> >> Another option would be to make a configure option to just ignore the date. > > Or an option to auto-advance the clock to the "Not Before" date if needed... > >> I'm not sure if I would like to use MODSIGN when I have to fear that the >> machine wouldn't start when the RTC fails or got set to a wrong date. > > Hmm, nice failure mode... And the dream of every vendor, finally a working expiration date. And a nice TV-B-Gone, just feed a wrong date once. ;) Regards, Alexader -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/9] gpiolib: use descriptors internally
On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
>> Make sure gpiolib works internally with descriptors and (chip, offset)
>> pairs instead of using the global integer namespace. This prepares the
>
> Its a numberspace not a namespace right?
Yes, absolutely.
>> +/*
>> + * Internal gpiod_* API using descriptors instead of the integer namespace.
>> + * Most of this should eventually go public.
>> + */
>> +static int gpiod_request(struct gpio_desc *desc, const char *label);
>> +static void gpiod_free(struct gpio_desc *desc);
>> +static int gpiod_direction_input(struct gpio_desc *desc);
>> +static int gpiod_direction_output(struct gpio_desc *desc, int value);
>> +static int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
>> +static int gpiod_get_value_cansleep(struct gpio_desc *desc);
>> +static void gpiod_set_value_cansleep(struct gpio_desc *desc, int value);
>> +static int gpiod_get_value(struct gpio_desc *desc);
>> +static void gpiod_set_value(struct gpio_desc *desc, int value);
>> +static int gpiod_cansleep(struct gpio_desc *desc);
>> +static int gpiod_to_irq(struct gpio_desc *desc);
>> +static int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
>> +static int gpiod_export_link(struct device *dev, const char *name,
>> +struct gpio_desc *desc);
>> +static int gpiod_sysfs_set_active_low(struct gpio_desc *desc, int value);
>> +static void gpiod_unexport(struct gpio_desc *desc);
>
> Usually I don't like these upfrons forward-declarations, but in this
> case I *do* because they are here for a reason, to later become
> extern. So I like it!
Yeah, you know how the movie is going to end already. ;) Maybe it
would make sense to append the gpiod patches to this series and not
end up with these declarations?
>> +/*
>> + * Return the GPIO number of the passed descriptor relative to its chip
>> + */
>> +static int gpio_chip_hwgpio(const struct gpio_desc *desc)
>> +{
>> + return (desc - _desc[0]) - desc->chip->base;
>> +}
>
> That was a scary method. But it works as long as the
> descriptors are in a static array I guess...
Yes, and it's becomes less scary when the static array goes away.
>> +/**
>> + * Convert a GPIO number to its descriptor
>> + */
>> +static struct gpio_desc *gpio_to_desc(unsigned gpio)
>> +{
>> + if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
>> + return NULL;
>
> Don't we want to return ERR_PTR(-EINVAL); here?
>
> Then you can use IS_ERR() on the pointers later.
>
> This is the approach taken by the external API for clk
> and pins.
Yes, that completely makes sense.
>> /* caller holds gpio_lock *OR* gpio is marked as requested */
>
> That comment should be above the *next* function right?
>
> Strictly speaking it does not apply to gpiod_to_chip() if
> I read it right.
That's right. On a related topic there are actually a whole set of
comments that are not in the right place (because the function that
follows them has been switched to the gpiod prefix). I left them here
because once the gpiod interface becomes public they will be updated
to apply to them, and moving comments back and forth in such a short
time would only make the patches confusing.
>> static ssize_t gpio_direction_show(struct device *dev,
>> struct device_attribute *attr, char *buf)
>> {
>> - const struct gpio_desc *desc = dev_get_drvdata(dev);
>> - unsignedgpio = desc - gpio_desc;
>> + struct gpio_desc*desc = dev_get_drvdata(dev);
>
> Why not const anymore?
>
> (Applies to all these similar cases in the patch.)
>
> consting is nice. Especially in subsystem code.
> I know it is hard to get compilation right without warnings
> at times. But it pays off.
>
> In the pinctrl subsystem I spend endless hours reading this
> wiki page:
>
> http://en.wikipedia.org/wiki/Const-correctness
>
> I still don't quite get it. And it also wears off. But I like to use it.
Oh I do share your love for const-correctness (look at the parameters
for gpio_chip_hwgpio() and desc_to_gpio()). Only here I could not
preserve it AFAICT.
The previous version of the function was only using desc locally and
relied on GPIO numbers to do the dirty job. Here however, we pass desc
to gpiod_get_direction(). So you will tell me, that as it only returns
the direction its parameter could also be const and that's true -
excepted when it tries to clear some bits in desc->flags, there we
definitely cannot claim it is const anymore. Maybe we could cast the
pointer given to clear_bit/set_bit, but I'm not sure that's more
elegant. Ideally gpiod_get_direction() should not modify its parameter
at all.
>> @@ -594,29 +647,32 @@ static ssize_t export_store(struct class *class,
>> + desc = gpio_to_desc(gpio);
>
> I hope you have tested this hunk of the patch from userspace?
>
>> @@ -637,17 +694,18 @@ static ssize_t unexport_store(struct class
Re: [PATCH 11/11] liblockdep: preload helper
On Wed, 6 Feb 2013 17:11:34 -0500, Sasha Levin wrote: > diff --git a/tools/lib/lockdep/lockdep b/tools/lib/lockdep/lockdep > new file mode 100755 > index 000..616bf9a > --- /dev/null > +++ b/tools/lib/lockdep/lockdep > @@ -0,0 +1,3 @@ > +#! /bin/bash > + > +LD_PRELOAD=liblockdep.so "$@" Just try to be more conservative ;-) LD_PRELOAD="liblockdep.so $LD_PRELOAD" "$@" Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: manual merge of the akpm-current tree with the kvm tree
Hi Andrew, On Wed, 6 Feb 2013 22:23:57 -0800 Andrew Morton wrote: > > hm, not sure what you meant by "bad" but that patch went and took the > nice fits-in-80-cols kvm code and mucked it all up. Shall unmuck > tomorrow. "bad" in the sense that there was lots of white space changes to lines not otherwise touched by the patch and those white space changes introduced extra levels of tabs (so the indentation was incorrect) and merged some lines. I unmucked some of it, but got bored :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpTqr_EIrhnk.pgp Description: PGP signature
Re: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
On 02/07/2013 01:46 PM, Stephen Hemminger wrote:
On Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin wrote:
+static struct ethtool_ops ax88179_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_msglevel = usbnet_get_msglevel,
+ .set_msglevel = usbnet_set_msglevel,
+ .get_wol= ax88179_get_wol,
+ .set_wol= ax88179_set_wol,
+ .get_eeprom_len = ax88179_get_eeprom_len,
+ .get_eeprom = ax88179_get_eeprom,
+ .get_settings = ax88179_get_settings,
+ .set_settings = ax88179_set_settings,
+ .nway_reset = usbnet_nway_reset,
+};
+
ethtool_ops should always be const
Thank you, Stephen. I will fix these errors.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/07/2013 01:45 PM, Stephen Hemminger wrote:
On Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin wrote:
+struct {unsigned char ctrl, timer_l, timer_h, size, ifg; }
+AX88179_BULKIN_SIZE[] ={
+ {7, 0x4f, 0,0x12, 0xff},
+ {7, 0xf0, 1,0x15, 0xff},
+ {7, 0xae, 7,0x18, 0xff},
+ {7, 0xcc, 0x4c, 0x18, 8},
+};
Better to make it static, const, and add a couple
of line breaks.
static const struct {
unsigned char ctrl, timer_l, timer_h, size, ifg;
} AX88179_BULKIN_SIZE[] = {
{7, 0x4f, 0,0x12, 0xff},
{7, 0xf0, 1,0x15, 0xff},
{7, 0xae, 7,0x18, 0xff},
{7, 0xcc, 0x4c, 0x18, 8},
};
Thank you, Stephen. I will fix these errors.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: MODSIGN without RTC?
On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler wrote:
> Am 07.02.2013 00:42, schrieb Alexander Holler:
>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:
>>
>> [1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is
>> not yet valid
>>
>> The reason is likely that the (ARM) device in question doesn't have a
>> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.
>>
>> The used certificate was generated automatically. Having a look at it,
>> the following is shown:
>>
>> Validity
>> Not Before: Feb 6 02:56:46 2013 GMT
>> Not After : Jan 13 02:56:46 2113 GMT
>>
>> Without having thought about possible security problems, my first idea
>> would be to let the validity start at 1970. As I never did such I never
>> had thought about possible implications when doing such (e.g. I don't
>> know if someone checks the start date for plausabilitiy)
>>
>> Another solution would be to retry loading of the certificate if the
>> time gets set (and e.g. differs more than a year).
>>
>> Has someone already thought about how to solve that problem? Or did
>> everyone use sane systems which have a (working) RTC?
>
>
> Another option would be to make a configure option to just ignore the date.
Or an option to auto-advance the clock to the "Not Before" date if needed...
> I'm not sure if I would like to use MODSIGN when I have to fear that the
> machine wouldn't start when the RTC fails or got set to a wrong date.
Hmm, nice failure mode...
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/
[PATCH 1/1] eventfd: implementation of EFD_MASK flag
When implementing network protocols in user space, one has to implement
fake user-space file descriptors to represent the sockets for the protocol.
While all the BSD socket API functionality for such descriptors may be faked as
well (myproto_send(), myproto_recv() etc.) this approach doesn't work for
polling (select, poll, epoll). For polling, real system-level file descriptor
is needed.
In theory, eventfd may be used for this purpose, except that it is well suited
only for signaling POLLIN. With some hacking it can be also used to signal
POLLOUT and POLLERR, however:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitraty combination of POLL* flags. Most notably,
!POLLIN & !POLLOUT, which is a perfectly valid combination for a network
protocol (rx buffer is empty and tx buffer is full), cannot be signaled
using current implementation of eventfd.
This patch implements new EFD_MASK flag which attempts to solve this problem.
Additionally, when implementing network protocols in user space, there's a
need to associate user-space state with the each "socket". If eventfd object is
used as a reference to the socket, it should be possible to associate an opaque
pointer to user-space data with it.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a way
as to signal no events on the file descriptor when it is polled on. 'initval'
argument is ignored.
write(2):
User is allowed to write only buffers containing the following structure:
struct efd_mask {
short events;
void *ptr;
};
The value of 'events' should be any combination of event flags as defined by
poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified events will
be signaled when polling (select, poll, epoll) on the eventfd is done later on.
'ptr' is an opaque pointer that is not interpreted by eventfd object.
read(2):
User is allowed to read an efd_mask structure from the eventfd marked by
EFD_MASK. Returned value shall be the last one written to the eventfd.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events specified
in last written 'events' field shall be signaled.
Signed-off-by: Martin Sustrik
---
fs/eventfd.c| 105 ---
include/linux/eventfd.h |3 +-
2 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 35470d9..9fec49f 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi
+ * Copyright (C) 2013 Martin Sustrik
*
*/
@@ -22,18 +23,26 @@
#include
#include
+struct eventfd_mask {
+ short events;
+ void *ptr;
+};
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+ struct eventfd_mask mask;
+ };
unsigned int flags;
};
@@ -55,6 +64,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
{
unsigned long flags;
+ /* This function should never be used with eventfd in the mask mode. */
+ BUG_ON(ctx->flags & EFD_MASK);
+
spin_lock_irqsave(>wqh.lock, flags);
if (ULLONG_MAX - ctx->count < n)
n = ULLONG_MAX - ctx->count;
@@ -123,12 +135,16 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
poll_wait(file, >wqh, wait);
spin_lock_irqsave(>wqh.lock, flags);
- if (ctx->count > 0)
- events |= POLLIN;
- if (ctx->count == ULLONG_MAX)
- events |= POLLERR;
- if (ULLONG_MAX - 1 > ctx->count)
- events |= POLLOUT;
+ if (ctx->flags & EFD_MASK) {
+ events = ctx->mask.events;
+ } else {
+ if (ctx->count > 0)
+ events |= POLLIN;
+ if (ctx->count == ULLONG_MAX)
+ events |= POLLERR;
+ if (ULLONG_MAX - 1 > ctx->count)
+
Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
Hi Rob,
On Thu, Feb 7, 2013 at 5:39 AM, Rob Landley wrote:
> On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote:
>> Add the %pa format specifier for printing a phys_addr_t
>> type and its derivative types (such as resource_size_t),
>> since the physical address size on some platforms can vary
>> based on build options, regardless of the native integer
>> type.
>>
>> Signed-off-by: Stepan Moskovchenko
>
>
> Ok, I know I'm late to the party, but doesn't LP64 apply here? Are we really
> capable of building on a target where "long" and "pointer" are different
> sizes? Last I checked the kernel was full of that assumption because there
> was an actual standard and we demanded that the compiler building us comply
> with it, just like MacOS X and the BSDs do:
>
> Standard:
> http://www.unix.org/whitepapers/64bit.html
>
> Rationale:
> http://www.unix.org/version2/whatsnew/lp64_wp.html
>
> Insane legacy reasons Windows decided to be "special":
> http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
>
> Thus "unsigned long" should by definition be big enough. Using unsigned long
> long means you're doing 64 bit math on 32 bit targets for no apparent
> reason.
>
> What did I miss?
This is about phys_addr_t and resource_size_t, which are _physical_ addresses,
not virtual adresses. Virtual addresses are still 32-bit, so unsigned
long is fine for them.
But these days several CPUs have 36-bit physical addresses, which don't fit in
unsigned long.
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: [tip:x86/mm2] x86: Add Crash kernel low reservation
On Wed, Feb 6, 2013 at 9:14 PM, Rob Landley wrote: > Yeah yeah, I'm behind on email... > > > On 01/29/2013 07:51:25 PM, tip-bot for Yinghai Lu wrote: >> >> Commit-ID: 2cde8ae169982ad1d1023ac628bb54053d0e9d4d >> Gitweb: >> http://git.kernel.org/tip/2cde8ae169982ad1d1023ac628bb54053d0e9d4d >> Author: Yinghai Lu >> AuthorDate: Thu, 24 Jan 2013 12:20:11 -0800 >> Committer: H. Peter Anvin >> CommitDate: Tue, 29 Jan 2013 15:31:59 -0800 >> >> x86: Add Crash kernel low reservation >> >> During kdump kernel's booting stage, it need to find low ram for >> swiotlb buffer when system does not support intel iommu/dmar remapping. >> >> kexed-tools is appending memmap=exactmap and range from /proc/iomem >> with "Crash kernel", and that range is above 4G for 64bit after boot >> protocol 2.12. >> >> We need to add another range in /proc/iomem like "Crash kernel low", >> so kexec-tools could find that info and append to kdump kernel >> command line. >> >> User could specify the size with crashkernel_low=XX[KMG]. >> >> -v2: fix warning that is found by Fengguang's test robot. >> -v3: move out get_mem_size change to another patch, to solve compiling >> warning that is found by Borislav Petkov >> -v4: user must specify crashkernel_low if system does not support >> intel or amd iommu. > > > I missed: why can we not autodetect the lack of support and DTRT? We need to process crashkernel early, and at that time we can not find out if we can get iommu initialized properly. > > >> Signed-off-by: Yinghai Lu >> Link: >> http://lkml.kernel.org/r/1359058816-7615-31-git-send-email-ying...@kernel.org >> Cc: Eric Biederman >> Cc: Rob Landley >> Signed-off-by: H. Peter Anvin >> --- >> Documentation/kernel-parameters.txt | 3 +++ >> arch/x86/kernel/setup.c | 42 >> +++-- >> include/linux/kexec.h | 3 +++ >> kernel/kexec.c | 34 +- >> 4 files changed, 75 insertions(+), 7 deletions(-) >> >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 363e348..da0e077 100644 >> --- a/Documentation/kernel-parameters.txt >> +++ b/Documentation/kernel-parameters.txt >> @@ -594,6 +594,9 @@ bytes respectively. Such letter suffixes can also be >> entirely omitted. >> is selected automatically. Check >> Documentation/kdump/kdump.txt for further details. >> >> + crashkernel_low=size[KMG] >> + [KNL, x86] parts under 4G. >> + >> crashkernel=range1:size1[,range2:size2,...][@offset] >> [KNL] Same as above, but depends on the memory >> in the running system. The syntax of range is > > > I don't understand this documentation. Looks better if crashkernel_low is moved under crashkernel. > > The "parts under 4G." assumes you understand the context of this posting > which isn't going into the docs. Above you say: > > >> Try to reserve some under 4G if the normal "Crash kernel" is above 4G. > > > Which is much clearer. Adding this in the middle also makes the "Same as > above" slightly confusing (you have two different aboves...) > > The first version (crashkernel=onesize) strongly implies the reservation is > physically contiguous. The comma separated version implies that there are > discontiguous reservations, manually specified. > > So is crashkernel_low=size a separate reservation from crashkernel=size, or > a modifier on the existing contiguous allocation? Do you still need a > crashkernel= entry if you've got a crashkernel_low= entry? If you can (or > are required to) specify both, is one a constraint on part of the other or > it an addition (so it reserves crashkernel+crashkernel_low)? I seems > unlikely "parts under 4G" means it's trying to make one contiguous > reservation straddle the high/low boundary to put parts in each while still > being contiguous... > > I have no idea from what you've added to kernel-parameters.txt. > > Looking at the code, I _think_ this adds an additional independent > reservation. I.E. crashkernel=size says "allocate memory from anywhere", > crashkernel_low=size says "allocate memory from low memory", and doing both > allocates two chunks like the comma separated version. comma separated version only allocate one piece, right? The syntax is: crashkernel=:[,:,...][@offset] range=start-[end] 'start' is inclusive and 'end' is exclusive. For example: crashkernel=512M-2G:64M,2G-:128M This would mean: 1) if the RAM is smaller than 512M, then don't reserve anything (this is the "rescue" case) 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M 3) if the RAM size is larger than 2G, then reserve 128M > > Oh well. It's not hugely important that I understand a subsystem I don't > use, but having to look at the code to figure out what the documentation is > saying makes
Re: [PATCH 04/15] drivers/block/mtip32xx: add missing GENERIC_HARDIRQS dependency
On Wed, Feb 06 2013, Heiko Carstens wrote: > The MTIP32XX driver calls devm_request_irq() and therefore needs a > GENERIC_HARDIRQS dependency to prevent building it on s390. I'll queue this up for 3.9, thanks Heiko. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data
Hi,
On Thursday 07 February 2013 11:51 AM, Rajendra Nayak wrote:
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be "50". This signifies the controller can supply
upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
*/
ti,pulldowns = <0x03a1c4>;
};
+
+_otg_hs {
+interface_type = <0>;
+mode = <3>;
+power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts
b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
_gpio {
ti,use-leds;
};
+
+_otg_hs {
+interface_type = <0>;
+mode = <3>;
+power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
_gpio {
ti,use-leds;
};
+
+_otg_hs {
+interface_type = <0>;
+mode = <3>;
+power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+usb_otg_hs: usb_otg_hs@480ab000 {
+compatible = "ti,omap3-musb";
+reg = <0x480ab000 0x1000>;
+interrupts = <0 92 0x4>, <0 93 0x4>;
+interrupt-names = "mc", "dma";
+ti,hwmods = "usb_otg_hs";
+usb-phy = <_phy>;
+multipoint = <1>;
+num_eps = <16>;
+ram_bits = <12>;
Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'
It's documented in Documentation/devicetree/bindings/usb/omap-usb.txt
Actually the documentation and the drivers got merged with this binding
long back.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
On Thu, Feb 07, 2013 at 01:41:57AM +0100, Rafael J. Wysocki wrote: > On Wednesday, February 06, 2013 10:11:25 PM Rafael J. Wysocki wrote: > > On Thursday, February 07, 2013 12:25:13 AM Artem Savkov wrote: > > > I get the following BUG on suspend using systemd-sleep(this doesn't > > > happen with pm-suspend). This seems to be introduced by some of the > > > Viresh's patches. > > > > Which branch from which day? The log is from linux-next-20130205, still reproducible on -20130206 > OK, I've reproduced it and the appended patch fixes it for me. Can you please > try it and report back? I've tried the patch and the bug is still reproducible. I might be wrong but it seems that the bug happens on first __cpufreq_remove_dev call(CPU1) on __cpufreq_governor(data, CPUFREQ_GOV_STOP) call (line ~1050) but changes in your patch are all below that call. -- 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 3/3] acpi, memory-hotplug: Support getting hotplug info from SRAT.
On 02/07/2013 05:54 AM, Andrew Morton wrote:
On Wed, 06 Feb 2013 10:20:57 +0800
Tang Chen wrote:
+ if (!strncmp(p, "acpi", max(4, strlen(p
+ movablemem_map.acpi = true;
Generates a warning:
mm/page_alloc.c: In function 'cmdline_parse_movablemem_map':
mm/page_alloc.c:5312: warning: comparison of distinct pointer types lacks a cast
due to max(int, size_t).
This is easily fixed, but the code looks rather pointless. If the
incoming string is supposed to be exactly "acpi" then use strcmp(). If
the incoming string must start with "acpi" then use strncmp(p, "acpi", 4).
IOW, the max is unneeded?
Hi Andrew,
I think I made another mistake here. I meant to use min(4, strlen(p)) in
case p is
something like 'aaa' whose length is less then 4. But I mistook it with
max().
But after I dig into strcmp() in the kernel, I think it is OK to use
strcmp().
min() or max() is not needed.
OK, I did that.
But the code still looks a bit more complex than we need. Could we do
static int __init cmdline_parse_movablemem_map(char *p)
{
char *oldp;
u64 start_at, mem_size;
if (!p)
goto err;
/*
* If user decide to use info from BIOS, all the other user specified
* ranges will be ingored.
*/
if (!strcmp(p, "acpi")) {
movablemem_map.acpi = true;
if (movablemem_map.nr_map) {
memset(movablemem_map.map, 0,
sizeof(struct movablemem_entry)
* movablemem_map.nr_map);
movablemem_map.nr_map = 0;
}
return 0;
}
No, I don't think so.
If user specified like this:
1) movablemem_map=aaa@bbb -- will be added into array
2) movablemem_map=acpi-- will empty the array
3) movablemem_map=ccc@ddd -- will be added into array again (wrong!)
So, we need to code like this:
+ if (!strncmp(p, "acpi", max(4, strlen(p
+ movablemem_map.acpi = true;
In this way, 3) movablemem_map=ccc@ddd will not go into this if segment.
+
+ /*
+* If user decide to use info from BIOS, all the other user specified
+* ranges will be ingored.
+*/
+ if (movablemem_map.acpi) {
+ if (movablemem_map.nr_map) {
+ memset(movablemem_map.map, 0,
+ sizeof(struct movablemem_entry)
+ * movablemem_map.nr_map);
+ movablemem_map.nr_map = 0;
+ }
+ return 0;
+ }
But it will go into this if segment, and will not add the range into array.
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 3/8] ARM: dts: omap: Add usb_otg and glue data
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
*/
ti,pulldowns = <0x03a1c4>;
};
+
+_otg_hs {
+ interface_type = <0>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
_gpio {
ti,use-leds;
};
+
+_otg_hs {
+ interface_type = <0>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
_gpio {
ti,use-leds;
};
+
+_otg_hs {
+ interface_type = <0>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usb_otg_hs: usb_otg_hs@480ab000 {
+ compatible = "ti,omap3-musb";
+ reg = <0x480ab000 0x1000>;
+ interrupts = <0 92 0x4>, <0 93 0x4>;
+ interrupt-names = "mc", "dma";
+ ti,hwmods = "usb_otg_hs";
+ usb-phy = <_phy>;
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
_usb_comparator {
usb-supply = <>;
};
+
+_otg_hs {
+ interface_type = <1>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
_usb_comparator {
usb-supply = <>;
};
+
+_otg_hs {
+ interface_type = <1>;
+ mode = <3>;
+ power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = "control_dev_conf", "otghs_control";
ti,type = <1>;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = "ti,omap4-musb";
+ reg = <0x4a0ab000 0x7ff>;
+ interrupts = <0 92 0x4>, <0 93 0x4>;
+ interrupt-names = "mc", "dma";
+ ti,hwmods = "usb_otg_hs";
+ usb-phy = <_phy>;
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+ ti,has-mailbox;
+ };
};
};
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..398d2c3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -67,7 +67,7 @@
#interrupt-cells = <1>;
};
- twl4030-usb {
+ usb2_phy: twl4030-usb {
compatible = "ti,twl4030-usb";
interrupts = <10>, <4>;
usb1v5-supply = <>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the akpm-current tree with the kvm tree
On Thu, 7 Feb 2013 17:03:19 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/x86/kvm/mmu.c between commit 9bb4f6b15ec0 ("KVM: MMU: drop unneeded
> checks") from the kvm tree and commit "hlist: drop the node parameter
> from iterators" from the akpm-current tree.
>
> I fixed it up (the conflicts were caused by bad white space changes in
> the akpm tree patch) and can carry the fix as necessary (no action is
> required).
hm, not sure what you meant by "bad" but that patch went and took the
nice fits-in-80-cols kvm code and mucked it all up. Shall unmuck
tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] liblockdep: preload helper
Hi Sasha, On Wed, 6 Feb 2013 17:11:34 -0500, Sasha Levin wrote: > This is a simple wrapper to make using liblockdep on existing applications > much easier. > > After running 'make && make install', it becomes quite simple to test things > with liblockdep. For example, to try it on perf: > > liblockdep perf Shouldn't it be 'lockdep perf ...'? Thanks, Namhyung > > No other integration required. > > Signed-off-by: Sasha Levin > --- > tools/lib/lockdep/Makefile | 12 > tools/lib/lockdep/lockdep | 3 +++ > 2 files changed, 11 insertions(+), 4 deletions(-) > create mode 100755 tools/lib/lockdep/lockdep > > diff --git a/tools/lib/lockdep/Makefile b/tools/lib/lockdep/Makefile > index 245f8ba..b22122f 100644 > --- a/tools/lib/lockdep/Makefile > +++ b/tools/lib/lockdep/Makefile > @@ -34,7 +34,9 @@ DESTDIR ?= > DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))' > > prefix ?= /usr/local > -bindir_relative = lib > +libdir_relative = lib > +libdir = $(prefix)/$(libdir_relative) > +bindir_relative = bin > bindir = $(prefix)/$(bindir_relative) > > export DESTDIR DESTDIR_SQ INSTALL > @@ -90,13 +92,14 @@ objtree := $(CURDIR) > src := $(srctree) > obj := $(objtree) > > -export prefix bindir src obj > +export prefix libdir bindir src obj > > # Shell quotes > +libdir_SQ = $(subst ','\'',$(libdir)) > bindir_SQ = $(subst ','\'',$(bindir)) > -bindir_relative_SQ = $(subst ','\'',$(bindir_relative)) > > LIB_FILE = liblockdep.a liblockdep.so > +BIN_FILE = lockdep > > CONFIG_INCLUDES = > CONFIG_LIBS = > @@ -229,7 +232,8 @@ define do_install > endef > > install_lib: all_cmd > - $(Q)$(call do_install,$(LIB_FILE),$(bindir_SQ)) > + $(Q)$(call do_install,$(LIB_FILE),$(libdir_SQ)) > + $(Q)$(call do_install,$(BIN_FILE),$(bindir_SQ)) > > install: install_lib > > diff --git a/tools/lib/lockdep/lockdep b/tools/lib/lockdep/lockdep > new file mode 100755 > index 000..616bf9a > --- /dev/null > +++ b/tools/lib/lockdep/lockdep > @@ -0,0 +1,3 @@ > +#! /bin/bash > + > +LD_PRELOAD=liblockdep.so "$@" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
On 02/07/2013 09:44 AM, Rusty Russell wrote: > "Srivatsa S. Bhat" writes: >> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote: >> Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c >> latency] >> >> # online CPUsMainline (with stop-m/c) This patchset (no stop-m/c) >> >> 8 17.04 7.73 >> >> 16 18.05 6.44 >> >> 32 17.31 7.39 >> >> 64 32.40 9.28 >> >> 128 98.23 7.35 > > Nice! Thank you :-) > I wonder how the ARM guys feel with their quad-cpu systems... > That would be definitely interesting to know :-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] ia64/mm: fix a bad_page bug when crash kernel booting
> Sorry, this bug will be happen when use Sparse-Memory(section is valid, but
> last
> several pages are invalid). If use Flat-Memory, crash kernel will boot
> successfully.
> I think the following patch would be better.
>
> Hi Andrew, will you just ignore the earlier patch and consider the following
> one? :>
>
> Signed-off-by: Xishi Qiu
> ---
> arch/ia64/mm/init.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 082e383..23f2ee3 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -213,6 +213,8 @@ free_initrd_mem (unsigned long start, unsigned long end)
> for (; start < end; start += PAGE_SIZE) {
> if (!virt_addr_valid(start))
> continue;
> + if ((start >> PAGE_SHIFT) >= max_low_pfn)
I confused the vaddr and paddr, really sorry for it.
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
"crashkernel=1024M-:600M"
and use sparse memory model, when crash kernel booting it changes [128M-728M]
to [128M-720M].
But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the
invalid pages
when freeing initrd memory. There are some pages missed at the end of the
seciton.
ChangeLog V3:
fixed vaddr mistake
ChangeLog V2:
add invalid pages check when freeing initrd memory
Signed-off-by: Xishi Qiu
---
arch/ia64/mm/init.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 082e383..8a269f8 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -173,6 +173,7 @@ void __init
free_initrd_mem (unsigned long start, unsigned long end)
{
struct page *page;
+ unsigned long pfn;
/*
* EFI uses 4KB pages while the kernel can use 4KB or bigger.
* Thus EFI and the kernel may have different page sizes. It is
@@ -213,6 +214,9 @@ free_initrd_mem (unsigned long start, unsigned long end)
for (; start < end; start += PAGE_SIZE) {
if (!virt_addr_valid(start))
continue;
+ pfn = __pa(start) >> PAGE_SHIFT;
+ if (pfn >= max_low_pfn)
+ continue;
page = virt_to_page(start);
ClearPageReserved(page);
init_page_count(page);
--
1.7.6.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/
linux-next: manual merge of the akpm-current tree with the kvm tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/kvm/mmu.c between commit 9bb4f6b15ec0 ("KVM: MMU: drop unneeded
checks") from the kvm tree and commit "hlist: drop the node parameter
from iterators" from the akpm-current tree.
I fixed it up (the conflicts were caused by bad white space changes in
the akpm tree patch) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpAx1P0TP4Ke.pgp
Description: PGP signature
Re: [PATCH 0/1] (Was uprobes/perf: pre-filtering)
Hi Oleg,
On Wed, 6 Feb 2013 20:42:18 +0100, Oleg Nesterov wrote:
> OK, builtin-record.c:record sets .target->uses_mmap == T, this is correct,
> we are going to use perf_mmap().
>
> But why do we need it? It is for perf_evlist__create_maps() to ensure we
> do not use cpu_map__dummy_new().
>
> But. Even if we use perf_mmap(), "event->cpu == -1 && !event->attr.inherit"
> is fine. And indeed, "perf record -e whatever -p1" creates a single counter
> with "cpu = -1" and this works. Because, damn, perf_evlist__config_attrs()
> notices "evlist->cpus->map[0] < 0" and sets "opts->no_inherit = true".
>
> But at the same time, this does not allow to do, say,
> "perf record -e whatever -C0 -p1". -C0 is simply ignored because when
> perf_evlist__create_maps() is called perf_target__has_task() == T due to
> "-p1".
>
> Not to mention, there is no way to trace init and the children it will
> fork...
>
> And otoh. "perf record -e whatever -i true" creates a counter for each
> cpu due to ->uses_mmap. This is suboptimal, but of course the hack like
>
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1081,6 +1078,8 @@ int cmd_record(int argc, const char **argv, const
> char *prefix __maybe_unused)
> if (!argc && perf_target__none(>opts.target))
> usage_with_options(record_usage, record_options);
>
> + rec->opts.target.uses_mmap = !rec->opts.no_inherit;
> +
> if (rec->force && rec->append_file) {
> ui__error("Can't overwrite and append at the same time."
> " You need to choose between -f and -A");
>
> should not be even discussed.
>
> And why opts->target.system_wide is only set by OPT_BOOLEAN("all-cpus") ?
> I meant, why I can't do "perf record -e whatever -C0" to create a "global"
> counter on CPU_0? This doesn't work because __cmd_record() sees !.system_wide
> and assumes we need perf_event__synthesize_thread_map() which silently fail.
>
> So I am sending a single patch to fix the problem which complicated my
> testing. It is trivial but I am not sure it correct, please review.
Yes, it's not clear how it handles above (-C0) case. I think it should
be treated as a system_wide mode like --all-cpus (-a). So we could set
->system_wide to true if -C is given and/or test perf_target__has_cpu()
for perf_event__synthesize_thread_map() or both.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin wrote:
> +static struct ethtool_ops ax88179_ethtool_ops = {
> + .get_link = ethtool_op_get_link,
> + .get_msglevel = usbnet_get_msglevel,
> + .set_msglevel = usbnet_set_msglevel,
> + .get_wol= ax88179_get_wol,
> + .set_wol= ax88179_set_wol,
> + .get_eeprom_len = ax88179_get_eeprom_len,
> + .get_eeprom = ax88179_get_eeprom,
> + .get_settings = ax88179_get_settings,
> + .set_settings = ax88179_set_settings,
> + .nway_reset = usbnet_nway_reset,
> +};
> +
ethtool_ops should always be const
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Thu, 7 Feb 2013 12:36:34 +0800
Freddy Xin wrote:
> +struct {unsigned char ctrl, timer_l, timer_h, size, ifg; }
> +AX88179_BULKIN_SIZE[] = {
> + {7, 0x4f, 0,0x12, 0xff},
> + {7, 0xf0, 1,0x15, 0xff},
> + {7, 0xae, 7,0x18, 0xff},
> + {7, 0xcc, 0x4c, 0x18, 8},
> +};
Better to make it static, const, and add a couple
of line breaks.
static const struct {
unsigned char ctrl, timer_l, timer_h, size, ifg;
} AX88179_BULKIN_SIZE[] = {
{7, 0x4f, 0,0x12, 0xff},
{7, 0xf0, 1,0x15, 0xff},
{7, 0xae, 7,0x18, 0xff},
{7, 0xcc, 0x4c, 0x18, 8},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mm: accelerate munlock() treatment of THP pages
On 02/06/2013 09:50 PM, Li Zhong wrote: > On Wed, 2013-02-06 at 18:44 -0500, Sasha Levin wrote: >> On 02/04/2013 02:17 AM, Michel Lespinasse wrote: >>> munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE >>> at a time. When munlocking THP pages (or the huge zero page), this resulted >>> in taking the mm->page_table_lock 512 times in a row. >>> >>> We can do better by making use of the page_mask returned by follow_page_mask >>> (for the huge zero page case), or the size of the page munlock_vma_page() >>> operated on (for the true THP page case). >>> >>> Note - I am sending this as RFC only for now as I can't currently put >>> my finger on what if anything prevents split_huge_page() from operating >>> concurrently on the same page as munlock_vma_page(), which would mess >>> up our NR_MLOCK statistics. Is this a latent bug or is there a subtle >>> point I missed here ? >>> >>> Signed-off-by: Michel Lespinasse >> >> Hi Michel, >> >> Fuzzing with trinity inside a KVM tools guest produces a steady stream of: >> >> >> [ 51.823275] [ cut here ] >> [ 51.823302] kernel BUG at include/linux/page-flags.h:421! >> [ 51.823307] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC >> [ 51.823307] Dumping ftrace buffer: >> [ 51.823314](ftrace buffer empty) >> [ 51.823314] Modules linked in: >> [ 51.823314] CPU 2 >> [ 51.823314] Pid: 7116, comm: trinity Tainted: GW >> 3.8.0-rc6-next-20130206-sasha-00027-g3b5963c-dirty #273 >> [ 51.823316] RIP: 0010:[] [] >> munlock_vma_page+0x12/0xf0 >> [ 51.823317] RSP: 0018:880009641bb8 EFLAGS: 00010282 >> [ 51.823319] RAX: 011ffc008001 RBX: ea410040 RCX: >> >> [ 51.823320] RDX: RSI: RDI: >> ea410040 >> [ 51.823321] RBP: 880009641bc8 R08: R09: >> >> [ 51.823322] R10: R11: R12: >> 880009633958 >> [ 51.823324] R13: 01252000 R14: ea410040 R15: >> 00ff >> [ 51.823326] FS: 7fe7a9046700() GS:88000ba0() >> knlGS: >> [ 51.823327] CS: 0010 DS: ES: CR0: 80050033 >> [ 51.823328] CR2: 7fc583b90fcb CR3: 09bc8000 CR4: >> 000406e0 >> [ 51.823334] DR0: DR1: DR2: >> >> [ 51.823338] DR3: DR6: 0ff0 DR7: >> 0400 >> [ 51.823340] Process trinity (pid: 7116, threadinfo 88000964, task >> 880009638000) >> [ 51.823341] Stack: >> [ 51.823344] 00a01000 880009633958 880009641c08 >> 812429bd >> [ 51.823373] 880009638000 01ff09638000 880009ade000 >> 880009633958 >> [ 51.823373] 880009638810 880009ade098 880009641cb8 >> 81246d81 >> [ 51.823373] Call Trace: >> [ 51.823373] [] munlock_vma_pages_range+0x8d/0xf0 >> [ 51.823373] [] exit_mmap+0x51/0x170 >> [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 >> [ 51.823373] [] ? kmem_cache_free+0x22f/0x3b0 >> [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 >> [ 51.823373] [] mmput+0x77/0xe0 >> [ 51.823377] [] exit_mm+0x113/0x120 >> [ 51.823381] [] ? _raw_spin_unlock_irq+0x51/0x80 >> [ 51.823384] [] do_exit+0x24a/0x590 >> [ 51.823387] [] do_group_exit+0x8a/0xc0 >> [ 51.823390] [] get_signal_to_deliver+0x501/0x5b0 >> [ 51.823394] [] do_signal+0x42/0x110 >> [ 51.823399] [] ? rcu_eqs_exit_common+0x64/0x340 >> [ 51.823404] [] ? trace_hardirqs_on+0xd/0x10 >> [ 51.823407] [] ? trace_hardirqs_on_caller+0x128/0x160 >> [ 51.823409] [] ? trace_hardirqs_on+0xd/0x10 >> [ 51.823412] [] do_notify_resume+0x48/0xa0 >> [ 51.823415] [] retint_signal+0x4d/0x92 >> [ 51.823449] Code: 85 c0 75 0d 48 89 df e8 0d 30 fe ff 0f 1f 44 00 00 48 >> 83 c4 08 5b 5d c3 90 55 48 89 e5 41 54 53 48 89 fb 48 >> 8b 07 f6 c4 80 74 06 <0f> 0b 0f 1f 40 00 48 8b 07 48 c1 e8 0e 83 e0 01 83 f8 >> 01 48 8b >> [ 51.823449] RIP [] munlock_vma_page+0x12/0xf0 >> [ 51.823450] RSP >> [ 51.826846] ---[ end trace a7919e7f17c0a72a ]--- >> > > The similar warning prevents my system from booting. And it seems to me > that in munlock_vma_pages_range(), the page_mask needs be the page > number returned from munlock_vma_page() minus 1. And the following fix > solved my problem. Would you please have a try? Solved it here as well, awesome! 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: mmotm 2013-02-06-17-13 uploaded (iio)
On 02/06/13 17:14, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2013-02-06-17-13 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > on i386: (from linux-next.patch) CC drivers/iio/common/st_sensors/st_sensors_i2c.o In file included from include/linux/iio/common/st_sensors.h:17:0, from include/linux/iio/common/st_sensors_i2c.h:15, from drivers/iio/common/st_sensors/st_sensors_i2c.c:16: include/linux/iio/trigger.h:70:28: error: 'CONFIG_IIO_CONSUMERS_PER_TRIGGER' undeclared here (not in a function) make[5]: *** [drivers/iio/common/st_sensors/st_sensors_i2c.o] Error 1 Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.8.0-rc6-mm1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_FHANDLE=y # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y # CONFIG_TINY_PREEMPT_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set CONFIG_RCU_NOCB_CPU=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y # CONFIG_MEMCG_DEBUG_ASYNC_DESTROY is not set CONFIG_CGROUP_HUGETLB=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_UIDGID_CONVERTED=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_MM_OWNER=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_HAVE_UID16=y CONFIG_UID16=y #
[PATCH v3] media: ths7353: add support for ths7353 video amplifier
From: Lad, Prabhakar
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Hans Verkuil
Signed-off-by: Martin Bugge
Cc: Chaithrika U S
---
Changes for v3:
1: Fixed review comments pointed out by Hans.
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |6 +-
drivers/media/i2c/ths7303.c | 353 ---
include/media/ths7303.h | 42 +
include/media/v4l2-chip-ident.h |3 +
4 files changed, 343 insertions(+), 61 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ecdf7e3..bd08541 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -576,10 +576,10 @@ config VIDEO_UPD64083
comment "Miscelaneous helper chips"
config VIDEO_THS7303
- tristate "THS7303 Video Amplifier"
- depends on I2C
+ tristate "THS7303/53 Video Amplifier"
+ depends on VIDEO_V4L2 && I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..7300abc 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S
+ *
+ * Contributors:
+ * Lad, Prabhakar
+ * Hans Verkuil
+ * Martin Bugge
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include
-#include
-#include
-#include
#include
-#include
-#include
#include
-#include
-#include
+#include
-#include
-#include
+#include
#include
+#include
#define THS7303_CHANNEL_1 1
#define THS7303_CHANNEL_2 2
#define THS7303_CHANNEL_3 3
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_datapdata;
+ struct v4l2_bt_timings bt;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,84 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = >pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
if (!client)
return -EINVAL;
switch (mode) {
case THS7303_FILTER_MODE_1080P:
- val = (3 << 6);
- val |= (3 << 3);
+ sel = 0x3; /*1080p and SXGA/UXGA */
break;
case THS7303_FILTER_MODE_720P_1080I:
- val = (2 << 6);
- val |= (2 << 3);
+ sel = 0x2; /*720p, 1080i and SVGA/XGA */
break;
case THS7303_FILTER_MODE_480P_576P:
- val = (1 << 6);
- val |= (1 << 3);
+ sel = 0x1; /* EDTV 480p/576p and VGA */
break;
case
Re: [PATCH] Documentation: update top level 00-INDEX file with new additions
On 01/29/2013 09:34:00 AM, Paul Gortmaker wrote:
It seems there are about 80 new, but undocumented addtions at
the top level Documentation directory. This fixes up the top
level 00-INDEX by adding new entries and deleting a couple orphans.
Some subdirs could probably still use a check/cleanup too though.
Cc: Rob Landley
Signed-off-by: Paul Gortmaker
I've got a script that makes html navigation pages from the 00-INDEX
files and another one that parses that to find dead links in both
directions. (Files with no 00-INDEX entry and 00-INDEX entries that
don't refer ot a file.)
I haven't run it in forever because the kernel.org guys took
everybody's accounts away, and they won't give me a new .ssh key
without a blood test or some such, and even if I did jump through the
hoops they made ssh go to a git wrapper you can't rsync through, so I
can't update kernel.org/doc/Documentation anymore. (Files attached
anyway.)
The patch looks good, but it also highlights the fact that this
directory needs a wholesale cleanup. Translations into languages the
developers don't speak and can't audit really don't belong in this
directory (they belong on the web somewhere), but Greg KH says
otherwise. The architecture stuff needs to be collated under an "arch"
directory the same way the source is. Zorro is still a serial driver at
the top level...
Sigh. I have buckets of things I want to do to this directory but no
longer have a kernel account. *shrug*
Acked-by: Rob Landley
Can you send it through the trivial tree?
Rob#!/usr/bin/python
import os,sys
# Get a list of files under the Documentation directory,
# filtering out instances of index.html
dirlist = []
for i in os.walk("Documentation"):
for j in i[1]: dirlist.append("%s/%s/" % (i[0], j))
for j in i[2]:
if j!="index.html": dirlist.append("%s/%s" % (i[0], j))
dirlist.sort()
# Function to parse a relative link and append it to a list.
taglist = []
def handletag(path, tag, data):
tag = tag.split()
if tag[0]=="a":
for i in tag:
if i.startswith("href="):
i = i[5:]
if i[0]=='"' and i[-1]=='"': i=i[1:-1]
taglist.append("%s/%s" % (path, i))
# Find all the index.html files under Documentation, read each one,
# iterate through the html tags and call handletag() for each.
for dir in os.walk("Documentation"):
if "index.html" in dir[2]:
data = open("%s/index.html" % dir[0]).read()
data = data.split("<")[1:]
for i in data:
i = i.split(">")
handletag(dir[0], i[0], i[1])
# Display the links with no files, and the files nothing linked to.
print "404 errors:"
for i in filter(lambda a: a not in dirlist, taglist): print i
print "Unlinked documents:"
for i in filter(lambda a: a not in taglist, dirlist): print i
#!/usr/bin/python
# Convert kernel Documentation/.../00-INDEX to index.html
import os,sys
for dir in os.walk("Documentation"):
if not "00-INDEX" in dir[2]: continue
# Read input
lines = open("%s/00-INDEX" % dir[0]).read()
lines = lines.split("00-INDEX",1)
if len(lines)==1:
print "FAILED %s" % dir[0]
continue
# Open output, write header and section (if any)
out = open("%s/index.html" % dir[0], "w")
out.write("\n%s\n\n\n" % dir[0])
if lines[0]: out.write("%s\n" % lines[0])
lines = lines[1].split("\n")
lines[0] = "00-INDEX"
close = 0
for idx in range(len(lines)):
if not lines[idx]: continue
if not lines[idx][0].isspace():
if close: out.write('\n')
out.write('%s' % (lines[idx].strip(), lines[idx].strip()))
close = 1
else: out.write(" %s" % lines[idx].strip())
out.write("\n\n\n\n")
linux-next: manual merge of the signal tree with the s390 tree
Hi Al,
Today's linux-next merge of the signal tree got a conflict in
arch/s390/Kconfig between commit ad2c429560fc ("s390/Kconfig: sort list
of arch selected config options") from the s390 tree and commits
e181ee4cd7e5 ("s390: switch to generic old sigsuspend") and 7eddd99c289a
("s390: switch to generic old sigaction()") from the signal tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/s390/Kconfig
index b220e15,ec12a35..000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -91,55 -129,19 +91,57 @@@ config S39
select ARCH_INLINE_WRITE_UNLOCK_BH
select ARCH_INLINE_WRITE_UNLOCK_IRQ
select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
- select HAVE_UID16 if 32BIT
+ select ARCH_SAVE_PAGE_KEYS if HIBERNATION
select ARCH_WANT_IPC_PARSE_VERSION
- select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
+ select BUILDTIME_EXTABLE_SORT
+ select CLONE_BACKWARDS2
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_CPU_DEVICES if !SMP
+ select GENERIC_KERNEL_THREAD
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL_OLD
- select GENERIC_CLOCKEVENTS
- select KTIME_SCALAR if 32BIT
+ select HAVE_ALIGNED_STRUCT_PAGE if SLUB
+ select HAVE_ARCH_JUMP_LABEL if !MARCH_G5
+ select HAVE_ARCH_MUTEX_CPU_RELAX
select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
+ select HAVE_BPF_JIT if 64BIT && PACK_STACK
+ select HAVE_CMPXCHG_DOUBLE
+ select HAVE_CMPXCHG_LOCAL
+ select HAVE_C_RECORDMCOUNT
+ select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DYNAMIC_FTRACE
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_FUNCTION_GRAPH_TRACER
+ select HAVE_FUNCTION_TRACER
+ select HAVE_FUNCTION_TRACE_MCOUNT_TEST
+ select HAVE_KERNEL_BZIP2
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZMA
+ select HAVE_KERNEL_LZO
+ select HAVE_KERNEL_XZ
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
+ select HAVE_KVM if 64BIT
+ select HAVE_MEMBLOCK
+ select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_OPROFILE
+ select HAVE_PERF_EVENTS
+ select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_SYSCALL_TRACEPOINTS
+ select HAVE_SYSCALL_WRAPPERS
+ select HAVE_UID16 if 32BIT
+ select HAVE_VIRT_CPU_ACCOUNTING
+ select INIT_ALL_POSSIBLE
+ select KTIME_SCALAR if 32BIT
select MODULES_USE_ELF_RELA
- select CLONE_BACKWARDS2
- select OLD_SIGSUSPEND3
+ select OLD_SIGACTION
++ select OLD_SIGSUSPEND3
+ select SYSCTL_EXCEPTION_TRACE
+ select USE_GENERIC_SMP_HELPERS if SMP
+ select VIRT_CPU_ACCOUNTING
config SCHED_OMIT_FRAME_POINTER
def_bool y
pgpDajbsXdp2p.pgp
Description: PGP signature
Re: [PATCH] cpufreq: exynos: simplify .init() for setting policy->cpus
On 4 February 2013 17:52, Viresh Kumar wrote: > On 31 January 2013 07:56, Viresh Kumar wrote: >> With the recent changes in cpufreq core, we just need to set mask of all >> possible cpus into policy->cpus. Rest would be done by core. >> >> Signed-off-by: Viresh Kumar >> --- >> drivers/cpufreq/exynos-cpufreq.c | 14 +- >> 1 file changed, 1 insertion(+), 13 deletions(-) > > Hi Rafael, > > Are you picking up this patch ? Ping!! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tip:x86/mm2] x86: Add Crash kernel low reservation
Yeah yeah, I'm behind on email... On 01/29/2013 07:51:25 PM, tip-bot for Yinghai Lu wrote: Commit-ID: 2cde8ae169982ad1d1023ac628bb54053d0e9d4d Gitweb: http://git.kernel.org/tip/2cde8ae169982ad1d1023ac628bb54053d0e9d4d Author: Yinghai Lu AuthorDate: Thu, 24 Jan 2013 12:20:11 -0800 Committer: H. Peter Anvin CommitDate: Tue, 29 Jan 2013 15:31:59 -0800 x86: Add Crash kernel low reservation During kdump kernel's booting stage, it need to find low ram for swiotlb buffer when system does not support intel iommu/dmar remapping. kexed-tools is appending memmap=exactmap and range from /proc/iomem with "Crash kernel", and that range is above 4G for 64bit after boot protocol 2.12. We need to add another range in /proc/iomem like "Crash kernel low", so kexec-tools could find that info and append to kdump kernel command line. User could specify the size with crashkernel_low=XX[KMG]. -v2: fix warning that is found by Fengguang's test robot. -v3: move out get_mem_size change to another patch, to solve compiling warning that is found by Borislav Petkov -v4: user must specify crashkernel_low if system does not support intel or amd iommu. I missed: why can we not autodetect the lack of support and DTRT? Signed-off-by: Yinghai Lu Link: http://lkml.kernel.org/r/1359058816-7615-31-git-send-email-ying...@kernel.org Cc: Eric Biederman Cc: Rob Landley Signed-off-by: H. Peter Anvin --- Documentation/kernel-parameters.txt | 3 +++ arch/x86/kernel/setup.c | 42 +++-- include/linux/kexec.h | 3 +++ kernel/kexec.c | 34 +- 4 files changed, 75 insertions(+), 7 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 363e348..da0e077 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -594,6 +594,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. is selected automatically. Check Documentation/kdump/kdump.txt for further details. + crashkernel_low=size[KMG] + [KNL, x86] parts under 4G. + crashkernel=range1:size1[,range2:size2,...][@offset] [KNL] Same as above, but depends on the memory in the running system. The syntax of range is I don't understand this documentation. The "parts under 4G." assumes you understand the context of this posting which isn't going into the docs. Above you say: Try to reserve some under 4G if the normal "Crash kernel" is above 4G. Which is much clearer. Adding this in the middle also makes the "Same as above" slightly confusing (you have two different aboves...) The first version (crashkernel=onesize) strongly implies the reservation is physically contiguous. The comma separated version implies that there are discontiguous reservations, manually specified. So is crashkernel_low=size a separate reservation from crashkernel=size, or a modifier on the existing contiguous allocation? Do you still need a crashkernel= entry if you've got a crashkernel_low= entry? If you can (or are required to) specify both, is one a constraint on part of the other or it an addition (so it reserves crashkernel+crashkernel_low)? I seems unlikely "parts under 4G" means it's trying to make one contiguous reservation straddle the high/low boundary to put parts in each while still being contiguous... I have no idea from what you've added to kernel-parameters.txt. Looking at the code, I _think_ this adds an additional independent reservation. I.E. crashkernel=size says "allocate memory from anywhere", crashkernel_low=size says "allocate memory from low memory", and doing both allocates two chunks like the comma separated version. Oh well. It's not hugely important that I understand a subsystem I don't use, but having to look at the code to figure out what the documentation is saying makes me uncomfortable. Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv1] crypto: caam - set RDB bit in security configuration register
This change is required for post SEC-5.0 devices which have RNG4.
Setting RDB in security configuration register allows CAAM to use the
"Random Data Buffer" to be filled by a single request. The Random Data
Buffer is large enough for ten packets to get their IVs from a single
request. If the Random Data Buffer is not enabled, then each IV causes a
separate request, and RNG4 hardware cannot keep up resulting in lower
IPSEC throughput if random IVs are used.
Signed-off-by: Vakul Garg
---
drivers/crypto/caam/ctrl.c |3 +++
drivers/crypto/caam/regs.h |4 +++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index bf20dd8..79278d5 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -304,6 +304,9 @@ static int caam_probe(struct platform_device *pdev)
caam_remove(pdev);
return ret;
}
+
+ /* Enable RDB bit so that RNG works faster */
+ setbits32(>ctrl.scfgr, SCFGR_RDBENABLE);
}
/* NOTE: RTIC detection ought to go here, around Si time */
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 3223fc6..cd6feda 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -252,7 +252,8 @@ struct caam_ctrl {
/* Read/Writable*/
u32 rsvd1;
u32 mcr;/* MCFG Master Config Register */
- u32 rsvd2[2];
+ u32 rsvd2;
+ u32 scfgr; /* SCFGR, Security Config Register */
/* Bus Access Configuration Section 010-11f */
/* Read/Writable*/
@@ -299,6 +300,7 @@ struct caam_ctrl {
#define MCFGR_WDFAIL 0x2000 /* DECO watchdog force-fail */
#define MCFGR_DMA_RESET0x1000
#define MCFGR_LONG_PTR 0x0001 /* Use >32-bit desc addressing */
+#define SCFGR_RDBENABLE0x0400
/* AXI read cache control */
#define MCFGR_ARCACHE_SHIFT12
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the iommu tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-shmobile/setup-sh73a0.c between commit 9a27dee73f55 ("ARM:
mach-shmobile: sh73a0: Add IPMMU device") from the iommu tree and commit
486095331af0 ("ARM: mach-shmobile: sh73a0: Minimal setup using DT") from
the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-shmobile/setup-sh73a0.c
index 36c2b2e,2ecd668..000
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@@ -755,36 -780,7 +781,36 @@@ static struct platform_device pmu_devic
.resource = pmu_resources,
};
+/* an IPMMU module for ICB */
+static struct resource ipmmu_resources[] = {
+ [0] = {
+ .name = "IPMMU",
+ .start = 0xfe951000,
+ .end= 0xfe9510ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const char * const ipmmu_dev_names[] = {
+ "sh_mobile_lcdc_fb.0",
+};
+
+static struct shmobile_ipmmu_platform_data ipmmu_platform_data = {
+ .dev_names = ipmmu_dev_names,
+ .num_dev_names = ARRAY_SIZE(ipmmu_dev_names),
+};
+
+static struct platform_device ipmmu_device = {
+ .name = "ipmmu",
+ .id = -1,
+ .dev = {
+ .platform_data = _platform_data,
+ },
+ .resource = ipmmu_resources,
+ .num_resources = ARRAY_SIZE(ipmmu_resources),
+};
+
- static struct platform_device *sh73a0_early_devices[] __initdata = {
+ static struct platform_device *sh73a0_early_devices_dt[] __initdata = {
_device,
_device,
_device,
@@@ -795,9 -791,11 +821,12 @@@
_device,
_device,
_device,
+ };
+
+ static struct platform_device *sh73a0_early_devices[] __initdata = {
_device,
_device,
+ _device,
};
static struct platform_device *sh73a0_late_devices[] __initdata = {
pgpPgOeWQl5N9.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the iommu tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-shmobile/setup-r8a7740.c between commit f671e0224a7f ("ARM:
mach-shmobile: r8a7740: Add IPMMU device") from the iommu tree and
commits f977ec94f7f2 ("ARM: shmobile: Remove duplicate inclusion of
dma-mapping.h in setup-r8a7740.c") and e67d7afc5674 ("ARM: shmobile:
r8a7740: add TMU timer support") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-shmobile/setup-r8a7740.c
index b85bea5,30ac79c..000
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@@ -27,8 -27,6 +27,7 @@@
#include
#include
#include
- #include
+#include
#include
#include
#include
@@@ -263,37 -287,97 +288,128 @@@ static struct platform_device cmt10_dev
.num_resources = ARRAY_SIZE(cmt10_resources),
};
+/* IPMMUI (an IPMMU module for ICB/LMB) */
+static struct resource ipmmu_resources[] = {
+ [0] = {
+ .name = "IPMMUI",
+ .start = 0xfe951000,
+ .end= 0xfe9510ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static const char * const ipmmu_dev_names[] = {
+ "sh_mobile_lcdc_fb.0",
+ "sh_mobile_lcdc_fb.1",
+ "sh_mobile_ceu.0",
+};
+
+static struct shmobile_ipmmu_platform_data ipmmu_platform_data = {
+ .dev_names = ipmmu_dev_names,
+ .num_dev_names = ARRAY_SIZE(ipmmu_dev_names),
+};
+
+static struct platform_device ipmmu_device = {
+ .name = "ipmmu",
+ .id = -1,
+ .dev = {
+ .platform_data = _platform_data,
+ },
+ .resource = ipmmu_resources,
+ .num_resources = ARRAY_SIZE(ipmmu_resources),
+};
+
+ /* TMU */
+ static struct sh_timer_config tmu00_platform_data = {
+ .name = "TMU00",
+ .channel_offset = 0x4,
+ .timer_bit = 0,
+ .clockevent_rating = 200,
+ };
+
+ static struct resource tmu00_resources[] = {
+ [0] = {
+ .name = "TMU00",
+ .start = 0xfff80008,
+ .end= 0xfff80014 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xe80),
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ static struct platform_device tmu00_device = {
+ .name = "sh_tmu",
+ .id = 0,
+ .dev = {
+ .platform_data = _platform_data,
+ },
+ .resource = tmu00_resources,
+ .num_resources = ARRAY_SIZE(tmu00_resources),
+ };
+
+ static struct sh_timer_config tmu01_platform_data = {
+ .name = "TMU01",
+ .channel_offset = 0x10,
+ .timer_bit = 1,
+ .clocksource_rating = 200,
+ };
+
+ static struct resource tmu01_resources[] = {
+ [0] = {
+ .name = "TMU01",
+ .start = 0xfff80014,
+ .end= 0xfff80020 - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xea0),
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ static struct platform_device tmu01_device = {
+ .name = "sh_tmu",
+ .id = 1,
+ .dev = {
+ .platform_data = _platform_data,
+ },
+ .resource = tmu01_resources,
+ .num_resources = ARRAY_SIZE(tmu01_resources),
+ };
+
+ static struct sh_timer_config tmu02_platform_data = {
+ .name = "TMU02",
+ .channel_offset = 0x1C,
+ .timer_bit = 2,
+ .clocksource_rating = 200,
+ };
+
+ static struct resource tmu02_resources[] = {
+ [0] = {
+ .name = "TMU02",
+ .start = 0xfff80020,
+ .end= 0xfff8002C - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0xec0),
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ static struct platform_device tmu02_device = {
+ .name = "sh_tmu",
+ .id = 2,
+ .dev = {
+ .platform_data = _platform_data,
+ },
+ .resource = tmu02_resources,
+ .num_resources = ARRAY_SIZE(tmu02_resources),
+ };
+
static struct platform_device *r8a7740_early_devices[] __initdata = {
_device,
_device,
@@@ -305,7 -389,9 +421,10 @@@
_device,
_device,
_device,
+ _device,
+ _device,
+ _device,
+ _device,
};
/* DMA */
pgp0d7WAjw4Uu.pgp
Description: PGP signature
Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote: Add the %pa format specifier for printing a phys_addr_t type and its derivative types (such as resource_size_t), since the physical address size on some platforms can vary based on build options, regardless of the native integer type. Signed-off-by: Stepan Moskovchenko Ok, I know I'm late to the party, but doesn't LP64 apply here? Are we really capable of building on a target where "long" and "pointer" are different sizes? Last I checked the kernel was full of that assumption because there was an actual standard and we demanded that the compiler building us comply with it, just like MacOS X and the BSDs do: Standard: http://www.unix.org/whitepapers/64bit.html Rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html Insane legacy reasons Windows decided to be "special": http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Thus "unsigned long" should by definition be big enough. Using unsigned long long means you're doing 64 bit math on 32 bit targets for no apparent reason. What did I miss? Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] crypto: caam - set RDB bit in security configuration register
> -Original Message- > From: Phillips Kim-R1AAHA > Sent: Thursday, February 07, 2013 7:03 AM > To: Garg Vakul-B16394 > Cc: linux-cry...@vger.kernel.org; Herbert Xu; David S. Miller; Liu > Shengzhou-B36685; Porosanu Alexandru-B06830; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] crypto: caam - set RDB bit in security configuration > register > > On Wed, 6 Feb 2013 17:17:46 +0530 > Vakul Garg wrote: > > > This change is required for post SEC-5.0 devices which have RNG4. > > Setting RDB > > wrap your commit message text to 75 chars Ok > > > in security configuration register allows CAAM to use the "Random Data > Buffer" > > to be filled by a single request. The Random Data Buffer is large > > enough for ten packets to get their IVs from a single request. If the > > Random Data Buffer is not enabled, then each IV causes a separate > > request, and RNG4 hardware cannot keep up resulting in lower IPSEC > throughput. > > Linux kernel IPSec or another IPSEC stack? how much lower? We measured USDPAA IPSEC throughput to be 1.9 times better on T4240 with this change. > > > + if (of_device_is_compatible(nprop, "fsl,sec-v5.0")) > > + setbits32(>ctrl.scfgr, SCFGR_RDBENABLE); > > + > > this belongs further down - at the end of the RNG4 initialization > section. Ok > > Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
From: Freddy Xin This is a resubmission. 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 --- drivers/net/usb/Kconfig| 18 + drivers/net/usb/Makefile |1 + drivers/net/usb/ax88179_178a.c | 1398 3 files changed, 1417 insertions(+) create mode 100644 drivers/net/usb/ax88179_178a.c diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index ef97621..75af401 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -158,6 +158,24 @@ config USB_NET_AX8817X This driver creates an interface named "ethX", where X depends on what other networking devices you have in use. +config USB_NET_AX88179_178A + tristate "ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet" + depends on USB_USBNET + select CRC32 + select PHYLIB + default y + help + This option adds support for ASIX AX88179 based USB 3.0/2.0 + to Gigabit Ethernet adapters. + + This driver should work with at least the following devices: + * ASIX AX88179 + * ASIX AX88178A + * Sitcomm LN-032 + + This driver creates an interface named "ethX", where X depends on + what other networking devices you have in use. + config USB_NET_CDCETHER tristate "CDC Ethernet support (smart devices such as cable modems)" depends on USB_USBNET diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile index 4786913..119b06c 100644 --- a/drivers/net/usb/Makefile +++ b/drivers/net/usb/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_USB_RTL8150) += rtl8150.o obj-$(CONFIG_USB_HSO) += hso.o obj-$(CONFIG_USB_NET_AX8817X) += asix.o asix-y := asix_devices.o asix_common.o ax88172a.o +obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o obj-$(CONFIG_USB_NET_DM9601) += dm9601.o diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c new file mode 100644 index 000..6862e47 --- /dev/null +++ b/drivers/net/usb/ax88179_178a.c @@ -0,0 +1,1398 @@ +/* + * ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet Devices + * + * Copyright (C) 2011-2013 ASIX + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include +#include +#include +#include +#include +#include + +#define AX88179_PHY_ID 0x03 +#define AX_EEPROM_LEN 0x100 +#define AX88179_EEPROM_MAGIC 0x17900b95 +#define AX_MCAST_FLTSIZE 8 +#define AX_MAX_MCAST 64 +#define AX_INT_PPLS_LINK BIT(0) +#define AX_RXHDR_L4_TYPE_UDP 1 +#define AX_RXHDR_L4_TYPE_TCP 4 +#define AX_ACCESS_MAC 0x01 +#define AX_ACCESS_PHY 0x02 +#define AX_ACCESS_EEPROM 0x04 +#define AX_ACCESS_EFUS 0x05 +#define AX_PAUSE_WATERLVL_HIGH 0x54 +#define AX_PAUSE_WATERLVL_LOW 0x55 + +#define PHYSICAL_LINK_STATUS 0x02 + #define AX_USB_SS 0x04 + #define AX_USB_HS 0x02 + +#define GENERAL_STATUS 0x03 +/* Check AX88179 version. UA1:Bit2 = 0, UA2:Bit2 = 1 */ + #define AX_SECLD0x04 + +#define AX_SROM_ADDR 0x07 +#define AX_SROM_CMD0x0a + #define
Re: [PATCH] rtc: max8997: Add driver for max8997 rtc.
On 2013년 02월 07일 13:14, devendra.aaru wrote:
> Hello,
>
> On Wed, Feb 6, 2013 at 4:53 PM, Jonghwa Lee wrote:
>> This patch adds rtc driver for Maxim 8997 multifunction chip.
>> Max8997 has rtc module in it. and it can be used for timekeeping
>> clock and system alarm. It provide various operational mode those are
>> BCD/binary, 24/12hour, am/pm. Driver sets binary/24/ for default.
>> Maxim 8997 also supports SMPL(Sudden Momentary Power Loss), WTSR
>> (Watchdog Timeout and Software Reset).
>>
>> Signed-off-by: Jonghwa Lee
>> ---
>> drivers/rtc/Kconfig | 30 +++
>> drivers/rtc/Makefile |1 +
>> drivers/rtc/rtc-max8997.c | 542
>> +
>> 3 files changed, 573 insertions(+)
>> create mode 100644 drivers/rtc/rtc-max8997.c
>>
>> +
>> +static int max8997_rtc_probe(struct platform_device *pdev)
>> +{
>> + struct max8997_dev *max8997 = dev_get_drvdata(pdev->dev.parent);
>> + struct max8997_rtc_info *info;
>> + int ret, virq;
>> +
>> + info = devm_kzalloc(>dev, sizeof(struct max8997_rtc_info),
>> + GFP_KERNEL);
>> + if (!info)
>> + return -ENOMEM;
>> +
>> + mutex_init(>lock);
>> + info->dev = >dev;
>> + info->max8997 = max8997;
>> + info->rtc = max8997->rtc;
>> +
>> + platform_set_drvdata(pdev, info);
>> +
>> + ret = max8997_rtc_init_reg(info);
>> +
>> + if (ret < 0) {
>> + dev_err(>dev, "Failed to initialize RTC reg:%d\n",
>> ret);
>> + return ret;
>> + }
>> +
>> + max8997_rtc_enable_wtsr(info, true);
>> + max8997_rtc_enable_smpl(info, true);
>> +
>> + device_init_wakeup(>dev, 1);
>> +
>> + info->rtc_dev = rtc_device_register("max8997-rtc", >dev,
>> + _rtc_ops, THIS_MODULE);
>> +
>> + if (IS_ERR(info->rtc_dev)) {
>> + ret = PTR_ERR(info->rtc_dev);
>> + dev_err(>dev, "Failed to register RTC device: %d\n",
>> ret);
>> + return ret;
>> + }
>> +
>> + virq = irq_create_mapping(max8997->irq_domain,
>> MAX8997_PMICIRQ_RTCA1);
>> + if (!virq) {
>> + dev_err(>dev, "Failed to create mapping alarm IRQ\n");
>+ rtc_device_unregister(>dev, _rtc_ops) ?
Yes, It should be,,
>> + return ret;
>> + }
>> + info->virq = virq;
>> +
>> + ret = request_threaded_irq(virq, NULL, max8997_rtc_alarm_irq, 0,
>> + "rtc-alarm0", info);
>> + if (ret < 0) {
>> + dev_err(>dev, "Failed to request alarm IRQ: %d: %d\n",
>> + info->virq, ret);
>+ here unregistering the rtc dev too?
also
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>
Thanks for reviewing, I'll fix it.
Thanks,
Jonghwa
>
> 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 00/40] CPU hotplug rework - episode I
Thomas Gleixner writes: > On Fri, 1 Feb 2013, Linus Torvalds wrote: >> So for me it's the "expose these states" that I get worried about.. A >> random driver should not necessarily even be able to *see* this, and >> decide to be clever and take advantage of the ordering. >> >> So I'd hope there would be some visibility restrictions. We currently >> have drivers already being confused by DOWN_PREPARE vs DOWN_FAILED etc >> etc random state transitions, and giving them even more flexibility to >> pick random states sounds like a really bad idea. I'd like to make >> sure that drivers and filesystems etc do not even *see* the states >> that are meant for the scheduler or workqueues, for example). Yeah, I assume Episode II is where we collapse each into sane states as Thomas clarified. That can be reviewed: I'd hate to try to do it in one go. 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 8/8] drivers:net:misc: Remove unnecessary alloc/OOM messages
Joe Perches writes: > alloc failures already get standardized OOM > messages and a dump_stack. > > Signed-off-by: Joe Perches Why not, less code is always good. Acked-by: Rusty Russell (virtio_net) 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 v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
"Srivatsa S. Bhat" writes: > On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote: > Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c > latency] > > # online CPUsMainline (with stop-m/c) This patchset (no stop-m/c) > > 8 17.04 7.73 > > 16 18.05 6.44 > > 32 17.31 7.39 > > 64 32.40 9.28 > > 128 98.23 7.35 Nice! I wonder how the ARM guys feel with their quad-cpu systems... Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen_max
Since the type of netns_ipvs->sysctl_sync_qlen_max has been changed to
unsigned long, type of its related proc var sync_qlen_max should be changed
to unsigned long, too. Also the return type of function sysctl_sync_qlen_max().
Besides, the type of ipvs_master_sync_state->sync_queue_len should also be
changed to unsigned long.
Changelog from V1:
- change type of ipvs_master_sync_state->sync_queue_len to unsigned long
as Simon addressed.
Cc: Andrew Morton
Cc: David Miller
Cc: Julian Anastasov
Cc: Simon Horman
Signed-off-by: Zhang Yanfei
---
include/net/ip_vs.h|6 +++---
net/netfilter/ipvs/ip_vs_ctl.c |4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 68c69d5..1d56f92 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -874,7 +874,7 @@ struct ip_vs_app {
struct ipvs_master_sync_state {
struct list_headsync_queue;
struct ip_vs_sync_buff *sync_buff;
- int sync_queue_len;
+ unsigned long sync_queue_len;
unsigned intsync_queue_delay;
struct task_struct *master_thread;
struct delayed_work master_wakeup_work;
@@ -1052,7 +1052,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
*ipvs)
return ACCESS_ONCE(ipvs->sysctl_sync_ports);
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return ipvs->sysctl_sync_qlen_max;
}
@@ -1099,7 +1099,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
*ipvs)
return 1;
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return IPVS_SYNC_QLEN_MAX;
}
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index ec664cb..d79a530 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1747,9 +1747,9 @@ static struct ctl_table vs_vars[] = {
},
{
.procname = "sync_qlen_max",
- .maxlen = sizeof(int),
+ .maxlen = sizeof(unsigned long),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_doulongvec_minmax,
},
{
.procname = "sync_sock_size",
--
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] rtc: max8997: Add driver for max8997 rtc.
Hello,
On Wed, Feb 6, 2013 at 4:53 PM, Jonghwa Lee wrote:
> This patch adds rtc driver for Maxim 8997 multifunction chip.
> Max8997 has rtc module in it. and it can be used for timekeeping
> clock and system alarm. It provide various operational mode those are
> BCD/binary, 24/12hour, am/pm. Driver sets binary/24/ for default.
> Maxim 8997 also supports SMPL(Sudden Momentary Power Loss), WTSR
> (Watchdog Timeout and Software Reset).
>
> Signed-off-by: Jonghwa Lee
> ---
> drivers/rtc/Kconfig | 30 +++
> drivers/rtc/Makefile |1 +
> drivers/rtc/rtc-max8997.c | 542
> +
> 3 files changed, 573 insertions(+)
> create mode 100644 drivers/rtc/rtc-max8997.c
>
> +
> +static int max8997_rtc_probe(struct platform_device *pdev)
> +{
> + struct max8997_dev *max8997 = dev_get_drvdata(pdev->dev.parent);
> + struct max8997_rtc_info *info;
> + int ret, virq;
> +
> + info = devm_kzalloc(>dev, sizeof(struct max8997_rtc_info),
> + GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + mutex_init(>lock);
> + info->dev = >dev;
> + info->max8997 = max8997;
> + info->rtc = max8997->rtc;
> +
> + platform_set_drvdata(pdev, info);
> +
> + ret = max8997_rtc_init_reg(info);
> +
> + if (ret < 0) {
> + dev_err(>dev, "Failed to initialize RTC reg:%d\n", ret);
> + return ret;
> + }
> +
> + max8997_rtc_enable_wtsr(info, true);
> + max8997_rtc_enable_smpl(info, true);
> +
> + device_init_wakeup(>dev, 1);
> +
> + info->rtc_dev = rtc_device_register("max8997-rtc", >dev,
> + _rtc_ops, THIS_MODULE);
> +
> + if (IS_ERR(info->rtc_dev)) {
> + ret = PTR_ERR(info->rtc_dev);
> + dev_err(>dev, "Failed to register RTC device: %d\n",
> ret);
> + return ret;
> + }
> +
> + virq = irq_create_mapping(max8997->irq_domain, MAX8997_PMICIRQ_RTCA1);
> + if (!virq) {
> + dev_err(>dev, "Failed to create mapping alarm IRQ\n");
+ rtc_device_unregister(>dev, _rtc_ops) ?
> + return ret;
> + }
> + info->virq = virq;
> +
> + ret = request_threaded_irq(virq, NULL, max8997_rtc_alarm_irq, 0,
> + "rtc-alarm0", info);
> + if (ret < 0) {
> + dev_err(>dev, "Failed to request alarm IRQ: %d: %d\n",
> + info->virq, ret);
+ here unregistering the rtc dev too?
> + return ret;
> + }
> +
> + return ret;
> +}
> +
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 1/4] audit: Syscall rules are not applied to existing processes on non-x86
Hi,
Just following up on this. I've had a few people complaining about
audit being broken on ppc64 and it would be nice to fix.
Anton
--
On Wed, 9 Jan 2013 10:46:17 +1100
Anton Blanchard wrote:
>
> Commit b05d8447e782 (audit: inline audit_syscall_entry to reduce
> burden on archs) changed audit_syscall_entry to check for a dummy
> context before calling __audit_syscall_entry. Unfortunately the dummy
> context state is maintained in __audit_syscall_entry so once set it
> never gets cleared, even if the audit rules change.
>
> As a result, if there are no auditing rules when a process starts
> then it will never be subject to any rules added later. x86 doesn't
> see this because it has an assembly fast path that calls directly into
> __audit_syscall_entry.
>
> I noticed this issue when working on audit performance optimisations.
> I wrote a set of simple test cases available at:
>
> http://ozlabs.org/~anton/junkcode/audit_tests.tar.gz
>
> 02_new_rule.py fails without the patch and passes with it. The
> test case clears all rules, starts a process, adds a rule then
> verifies the process produces a syscall audit record.
>
> Signed-off-by: Anton Blanchard
> Cc: # 3.3+
> ---
>
> Index: b/include/linux/audit.h
> ===
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -119,7 +119,7 @@ static inline void audit_syscall_entry(i
> unsigned long a1, unsigned
> long a2, unsigned long a3)
> {
> - if (unlikely(!audit_dummy_context()))
> + if (unlikely(current->audit_context))
> __audit_syscall_entry(arch, major, a0, a1, a2, a3);
> }
> static inline void audit_syscall_exit(void *pt_regs)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/3] introduce static_vm for ARM-specific static mapped area
On Wed, 6 Feb 2013, Joonsoo Kim wrote: > Changelog > v5->v6: > Add Ack-by, Reviewed-by, Tested-by tags > [3/3]: Change from Nicolas' suggestion >- remove redundant parenthesis This looks all fine now. Please submit your patches here for RMK to merge: http://www.arm.linux.org.uk/developer/patches/ Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtc: max8997: Add driver for max8997 rtc.
On 2013년 02월 07일 11:28, Andrew Morton wrote: > On Thu, 07 Feb 2013 10:43:23 +0900 jonghwa3@samsung.com wrote: > >>> The best way of handling this sort of thing is for the driver to probe >>> the hardware, work out its capabilities and "do the right thing". >>> >>> The second best way is to require that the user add certain module >>> parameters to enable the functionality. >>> >> >> How do we create sysfs node for enabling these options? > > I suggest using module_param[_named](), so users can execute "modprobe > max8997 wtsr=1". Or, if the driver is built into vmlinux, add > "max8997.wtsr=1" to the kernel boot command line. > > Documentation/kernel-parameters.txt mentions this. > Sorry, my question was incorrect, I meant to suggest to create sysfs node not to ask you to let me know how to implement sysfs node. Anyway I'll apply your comment and re-patch it soon. Thanks, Jonghwa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] 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.
:100644 100644 e8e8724... 6ad76a3... M drivers/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;
}
- 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/2] fix kernel crash with macvtap on top of LRO
On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote: At the moment, macvtap crashes are observed if macvtap is attached to an interface with LRO enabled. The crash in question is BUG() in macvtap_skb_to_vnet_hdr. This happens because several drivers set gso_size but not gso_type in incoming skbs. The following patches fix this for Additionally, cbf1de72324a8105ddcc3d9ce9acbc613faea17e is required to fix this for broadcom - would it make sense to cherry-pick this patch into 3.8? Doesn't macvtap need to call skb_warn_if_lro() too like bridge and openvswitch? Something like... diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index b181dfb..b2c6227 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -253,6 +253,9 @@ static int macvtap_forward(struct net_device *dev, struct sk_buff *skb) if (!q) goto drop; + if (unlikely(skb_warn_if_lro(skb))) + goto drop; + if (skb_queue_len(>sk.sk_receive_queue) >= dev->tx_queue_len) goto drop; I am not saying these drivers don't need to fix, I am just saying if we need to fix LRO case. 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 1/2] ixgbe: fix gso type
On Thu, 2013-02-07 at 01:02 +0200, Michael S. Tsirkin wrote: > ixgbe set gso_size but not gso_type. This leads to > crashes in macvtap. > > Signed-off-by: Michael S. Tsirkin > --- > > I tested that this fixes the crash for me. I am told on ixgbe LRO only > triggers with TCP so checking protocol should be enough? > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > index 396e280..9d01673 100644 > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > @@ -1399,6 +1399,10 @@ static void ixgbe_set_rsc_gso_size(struct ixgbe_ring > *ring, > /* set gso_size to avoid messing up TCP MSS */ > skb_shinfo(skb)->gso_size = DIV_ROUND_UP((skb->len - hdr_len), >IXGBE_CB(skb)->append_cnt); > + if (skb->protocol == ETH_P_IPV6) Same problem here (skb->protocol == htons(ETH_P_IPV6)) > + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6; > + else > + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] qlcnic: set gso_type
On Thu, 2013-02-07 at 01:02 +0200, Michael S. Tsirkin wrote:
> qlcnic set gso_size but not gso type. This leads to crashes
> in macvtap.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> This one I only compiled - don't have qlogic hardware.
>
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> index bb4311e..370049c 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> @@ -1043,8 +1043,13 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
> th->seq = htonl(seq_number);
> length = skb->len;
>
> - if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
> + if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP) {
> skb_shinfo(skb)->gso_size = qlcnic_get_lro_sts_mss(sts_data1);
> + if (skb->protocol == ETH_P_IPV6)
Are you sure its not skb->protocol == htons(ETH_P_IPV6) ?
> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
> + else
> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
> + }
>
> if (vid != 0x)
> __vlan_hwaccel_put_tag(skb, vid);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in
arch/x86/include/asm/vmx.h between commit af170c5061dd ("UAPI: (Scripted)
Disintegrate arch/x86/include/asm") from Linus' tree (v3.8-rc1) and commit
b0da5bec30ec ("KVM: VMX: add missing exit names to VMX_EXIT_REASONS
array") from the kvm tree.
The section modified by the latter has been moved to
arch/x86/include/uapi/asm/vmx.h, so my fix up patch for that file now is
below and can carry the fix as necessary (no action is required).
From: Stephen Rothwell
Date: Thu, 7 Feb 2013 14:15:07 +1100
Subject: [PATCH] x86, apicv: merge fixup for uapi include file split
Signed-off-by: Stephen Rothwell
---
arch/x86/include/uapi/asm/vmx.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index 979d03b..2871fcc 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -62,10 +62,12 @@
#define EXIT_REASON_MCE_DURING_VMENTRY 41
#define EXIT_REASON_TPR_BELOW_THRESHOLD 43
#define EXIT_REASON_APIC_ACCESS 44
+#define EXIT_REASON_EOI_INDUCED 45
#define EXIT_REASON_EPT_VIOLATION 48
#define EXIT_REASON_EPT_MISCONFIG 49
#define EXIT_REASON_WBINVD 54
#define EXIT_REASON_XSETBV 55
+#define EXIT_REASON_APIC_WRITE 56
#define EXIT_REASON_INVPCID 58
#define VMX_EXIT_REASONS \
@@ -103,7 +105,12 @@
{ EXIT_REASON_APIC_ACCESS, "APIC_ACCESS" }, \
{ EXIT_REASON_EPT_VIOLATION, "EPT_VIOLATION" }, \
{ EXIT_REASON_EPT_MISCONFIG, "EPT_MISCONFIG" }, \
- { EXIT_REASON_WBINVD,"WBINVD" }
+ { EXIT_REASON_WBINVD,"WBINVD" }, \
+ { EXIT_REASON_APIC_WRITE,"APIC_WRITE" }, \
+ { EXIT_REASON_EOI_INDUCED, "EOI_INDUCED" }, \
+ { EXIT_REASON_INVALID_STATE, "INVALID_STATE" }, \
+ { EXIT_REASON_INVD, "INVD" }, \
+ { EXIT_REASON_INVPCID, "INVPCID" }
#endif /* _UAPIVMX_H */
--
1.8.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpj68Y10o0Ui.pgp
Description: PGP signature
Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
On Wed, 2013-02-06 at 23:34 +, Ben Hutchings wrote: > If we want to allow forwarding from LRO then net/ipv4/inet_lro.c also > needs to set gso_type. Then, what is dev_disable_lro() purpose ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen_max
Since the type of netns_ipvs->sysctl_sync_qlen_max has been changed to
unsigned long, type of its related proc var sync_qlen_max should be changed
to unsigned long, too. Also the return type of function sysctl_sync_qlen_max().
Cc: David Miller
Cc: Julian Anastasov
Cc: Simon Horman
Signed-off-by: Zhang Yanfei
---
include/net/ip_vs.h|4 ++--
net/netfilter/ipvs/ip_vs_ctl.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 68c69d5..ba3bd85 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1052,7 +1052,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
*ipvs)
return ACCESS_ONCE(ipvs->sysctl_sync_ports);
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return ipvs->sysctl_sync_qlen_max;
}
@@ -1099,7 +1099,7 @@ static inline int sysctl_sync_ports(struct netns_ipvs
*ipvs)
return 1;
}
-static inline int sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
+static inline unsigned long sysctl_sync_qlen_max(struct netns_ipvs *ipvs)
{
return IPVS_SYNC_QLEN_MAX;
}
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index ec664cb..d79a530 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1747,9 +1747,9 @@ static struct ctl_table vs_vars[] = {
},
{
.procname = "sync_qlen_max",
- .maxlen = sizeof(int),
+ .maxlen = sizeof(unsigned long),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_doulongvec_minmax,
},
{
.procname = "sync_sock_size",
--
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] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
On Wed, Feb 6, 2013 at 7:08 PM, Andy Lutomirski wrote: > We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping > is enabled. Users of that capability expect it to mean that remapping > is secure (i.e. compatibility format interrupts are blocked). Explicitly > check whether CFIs are blocked and, if not, don't report the capability. FWIW, I've wanted a feature IOMMU_CAP_SECURE that means that all DMA and MSI from the domain is secure (i.e. only does what is explicitly requested via the iommu api). The current situation is hard to understand, as evidenced by the iommu type 1 stuff in vfio. But I don't even understand what an iommu group is, and I've read a decent chunk of the code. But that's not really relevant to this patch. --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/
[PATCH] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping
is enabled. Users of that capability expect it to mean that remapping
is secure (i.e. compatibility format interrupts are blocked). Explicitly
check whether CFIs are blocked and, if not, don't report the capability.
Cc: Alex Williamson
Cc: Don Zickus
Cc: Prarit Bhargava
Cc: David Woodhouse
Signed-off-by: Andy Lutomirski
---
This applies on top of my previous patch:
http://git.kernel.org/tip/af8d102f999a41c0189bd2cce488bac2ee88c29b
This is poorly tested. My x2apic-opted-out server boots and appears
to work. My x2apic-supporting server is busy doing production
things, so I can't reboot it to test. I don't have anything that
uses vfio or kvm device assignment.
drivers/iommu/intel-iommu.c | 9 +++--
drivers/iommu/intel_irq_remapping.c | 25 ++---
include/linux/intel-iommu.h | 7 +++
3 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c2c07a4..b764117 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4129,8 +4129,13 @@ static int intel_iommu_domain_has_cap(struct
iommu_domain *domain,
if (cap == IOMMU_CAP_CACHE_COHERENCY)
return dmar_domain->iommu_snooping;
- if (cap == IOMMU_CAP_INTR_REMAP)
- return irq_remapping_enabled;
+ if (cap == IOMMU_CAP_INTR_REMAP) {
+ /*
+* This could be per-domain, but unless something's wrong,
+* we should have CFIs blocked on all domains.
+*/
+ return irq_remapping_enabled && irq_remapping_is_secure;
+ }
return 0;
}
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index eca8832..c7eda74 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -37,6 +37,7 @@ struct hpet_scope {
static struct ioapic_scope ir_ioapic[MAX_IO_APICS];
static struct hpet_scope ir_hpet[MAX_HPET_TBS];
static int ir_ioapic_num, ir_hpet_num;
+bool irq_remapping_is_secure;
static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
@@ -436,10 +437,15 @@ static void iommu_set_irq_remapping(struct intel_iommu
*iommu, int mode)
* protected from dangerous (i.e. compatibility) interrupts
* regardless of x2apic status. Check just to be sure.
*/
- if (sts & DMA_GSTS_CFIS)
+ if (sts & DMA_GSTS_CFIS) {
+ /* This should not happen unless the hardware is broken. */
WARN(1, KERN_WARNING
- "Compatibility-format IRQs enabled despite intr
remapping;\n"
- "you are vulnerable to IRQ injection.\n");
+ "Failed to block compatibility format interrupts.\n");
+ iommu->cfi_blocked = false;
+ } else {
+ /* We are now secure against irq injection attack. */
+ iommu->cfi_blocked = true;
+ }
raw_spin_unlock_irqrestore(>register_lock, flags);
}
@@ -537,18 +543,15 @@ static int __init intel_irq_remapping_supported(void)
static int __init intel_enable_irq_remapping(void)
{
struct dmar_drhd_unit *drhd;
- bool x2apic_present;
int setup = 0;
int eim = 0;
- x2apic_present = x2apic_supported();
-
if (parse_ioapics_under_ir() != 1) {
printk(KERN_INFO "Not enable interrupt remapping\n");
goto error;
}
- if (x2apic_present) {
+ if (x2apic_supported()) {
eim = !dmar_x2apic_optout();
if (!eim)
printk(KERN_WARNING
@@ -616,6 +619,7 @@ static int __init intel_enable_irq_remapping(void)
/*
* Setup Interrupt-remapping for all the DRHD's now.
*/
+ irq_remapping_is_secure = 1;
for_each_drhd_unit(drhd) {
struct intel_iommu *iommu = drhd->iommu;
@@ -624,6 +628,8 @@ static int __init intel_enable_irq_remapping(void)
if (intel_setup_irq_remapping(iommu, eim))
goto error;
+ if (!iommu->cfi_blocked)
+ irq_remapping_is_secure = 0;
setup = 1;
}
@@ -641,10 +647,7 @@ error:
* handle error condition gracefully here!
*/
- if (x2apic_present)
- WARN(1, KERN_WARNING
- "Failed to enable irq remapping. You are vulnerable to
irq-injection attacks.\n");
-
+ irq_remapping_is_secure = 0;
return -1;
}
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 78e2ada..85cb711 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -333,6 +333,7 @@ struct intel_iommu {
#ifdef CONFIG_IRQ_REMAP
struct ir_table *ir_table; /* Interrupt remapping info */
+ bool cfi_blocked;
#endif
Re: [PATCHv3 5/6] zswap: add to mm/
On 02/06/2013 05:47 PM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] >> Subject: Re: [PATCHv3 5/6] zswap: add to mm/ >> >> On 01/29/2013 12:27 AM, Minchan Kim wrote: >>> First feeling is it's simple and nice approach. >>> Although we have some problems to decide policy, it could solve by later >>> patch >>> so I hope we make basic infrasture more solid by lots of comment. >> >> Thanks very much for the review! >>> >>> Another question. >>> >>> What's the benefit of using mempool for zsmalloc? >>> As you know, zsmalloc doesn't use mempool as default. >>> I guess you see some benefit. if so, zram could be changed. >>> If we can change zsmalloc's default scheme to use mempool, >>> all of customer of zsmalloc could be enhanced, too. >> >> In the case of zswap, through experimentation, I found that adding a >> mempool behind the zsmalloc pool added some elasticity to the pool. >> Fewer stores failed if we kept a small reserve of pages around instead >> of having to go back to the buddy allocator who, under memory >> pressure, is more likely to reject our request. >> >> I don't see this situation being applicable to all zsmalloc users >> however. I don't think we want incorporate it directly into zsmalloc >> for now. The ability to register custom page alloc/free functions at >> pool creation time allows users to do something special, like back >> with a mempool, if they want to do that. > > (sorry, still catching up on backlog after being gone last week) > > IIUC, by using mempool, you are essentially setting aside a > special cache of pageframes that only zswap can use (or other > users of mempool, I don't know what other subsystems use it). > So one would expect that fewer stores would fail if more > pageframes are available to zswap, the same as if you had > increased zswap_max_pool_percent by some small fraction. Yes this is correct. > > But by setting those pageframes aside, you are keeping them from > general use, which may be a use with a higher priority as determined > by the mm system. > > This seems wrong to me. Should every subsystem hide a bunch of > pageframes away in case it might need them? Well, like you said, any user of mempool does this. There were two reasons for using it in this way in zswap: (1) pages allocations and frees happen very frequently and going to the buddy allocator every time for these operations is more expensive. Especially the free-then-alloc pattern. Its faster to free to a mempool (if it is below its minimum) then get that page right back, than free to the buddy allocator and (try to) get that page back. (2) the bursty nature of swap writeback leads to a large number of failures if there isn't some pool of pages ready to accept them, especially for workloads with bursty memory demands. The workload suddenly requests a lot of memory, the system starts swapping, zswap asks for pages but the buddy allocator is already swamped by requests from the workload which isn't yet being throttled by direct reclaim. The zswap allocations all fail and pages race by into the swap device. Having a mempool allows for a little buffer. By the time the buffer is used up, hopefully the workload is being throttled and the system is more balanced. Thanks, Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: davinci: update to devm_* API
Hi Sergei,
On Wed, Feb 06, 2013 at 17:21:36, Sergei Shtylyov wrote:
> Hello.
>
> On 06-02-2013 15:22, Vishwanathrao Badarkhe, Manish wrote:
>
> > Update the code to use devm_* API so that driver core will manage
> > resources.
>
> > Signed-off-by: Vishwanathrao Badarkhe, Manish
> > ---
> > Changes since V1:
> >- Rebase on top of v3.8-rc6 of linus tree.
> >- Apply devm operation on clk_get.
>
> > :100644 100644 6a0a553... da4e218... M drivers/i2c/busses/i2c-davinci.c
> > drivers/i2c/busses/i2c-davinci.c | 45
> > +++---
> > 1 files changed, 13 insertions(+), 32 deletions(-)
>
> > diff --git a/drivers/i2c/busses/i2c-davinci.c
> > b/drivers/i2c/busses/i2c-davinci.c
> > index 6a0a553..da4e218 100644
> > --- a/drivers/i2c/busses/i2c-davinci.c
> > +++ b/drivers/i2c/busses/i2c-davinci.c
> [...]
> > @@ -699,22 +693,24 @@ static int davinci_i2c_probe(struct platform_device
> > *pdev)
> > dev->pdata = _i2c_platform_data_default;
> > }
> >
> > - dev->clk = clk_get(>dev, NULL);
> > + dev->clk = devm_clk_get(>dev, NULL);
> > if (IS_ERR(dev->clk)) {
> > r = -ENODEV;
> > goto err_free_mem;
> > }
> > clk_prepare_enable(dev->clk);
> >
> > - dev->base = ioremap(mem->start, resource_size(mem));
> > + dev->base = devm_request_and_ioremap(>dev, mem);
> > if (!dev->base) {
> > r = -EBUSY;
>
> Comment to devm_request_and_ioremap() suggests returning -EADDRNOTAVAIL
> on failure. -EBUSY wasn't the right code even before this change, should have
> been -ENOMEM.
Oh, you are right. I will change this to -EADDRNOTAVAIL. Thanks for
pointing this out.
Thanks,
Manish Badarkhe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb host: Faraday FUSBH200 HCD driver.
On Thu, Feb 7, 2013 at 12:38 AM, Felipe Balbi wrote: > On Wed, Feb 06, 2013 at 07:24:01PM +0800, Yuan-Hsin Chen wrote: >> From: Yuan-Hsin Chen >> >> USB2.0 HCD driver for Faraday FUSBH200 >> >> Signed-off-by: Yuan-Hsin Chen > > just use ehci-platform.c and avoid the duplication > > -- > balbi Thanks for your advice. I will modify and re-submit it later. Yuan-Hsin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the s390 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/s390/Kconfig between commit ad2c429560fc ("s390/Kconfig: sort list
of arch selected config options") from the s390 tree and commit
6147a9d8070e ("irq_work: Remove CONFIG_HAVE_IRQ_WORK") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/s390/Kconfig
index 17775cf,c15ba7d..000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -91,56 -128,17 +91,55 @@@ config S39
select ARCH_INLINE_WRITE_UNLOCK_BH
select ARCH_INLINE_WRITE_UNLOCK_IRQ
select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
- select HAVE_UID16 if 32BIT
+ select ARCH_SAVE_PAGE_KEYS if HIBERNATION
select ARCH_WANT_IPC_PARSE_VERSION
- select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
+ select BUILDTIME_EXTABLE_SORT
+ select CLONE_BACKWARDS2
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_CPU_DEVICES if !SMP
+ select GENERIC_KERNEL_THREAD
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL_OLD
- select GENERIC_CLOCKEVENTS
- select KTIME_SCALAR if 32BIT
+ select HAVE_ALIGNED_STRUCT_PAGE if SLUB
+ select HAVE_ARCH_JUMP_LABEL if !MARCH_G5
+ select HAVE_ARCH_MUTEX_CPU_RELAX
select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
+ select HAVE_BPF_JIT if 64BIT && PACK_STACK
+ select HAVE_CMPXCHG_DOUBLE
+ select HAVE_CMPXCHG_LOCAL
+ select HAVE_C_RECORDMCOUNT
+ select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DYNAMIC_FTRACE
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_FUNCTION_GRAPH_TRACER
+ select HAVE_FUNCTION_TRACER
+ select HAVE_FUNCTION_TRACE_MCOUNT_TEST
- select HAVE_IRQ_WORK
+ select HAVE_KERNEL_BZIP2
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZMA
+ select HAVE_KERNEL_LZO
+ select HAVE_KERNEL_XZ
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
+ select HAVE_KVM if 64BIT
+ select HAVE_MEMBLOCK
+ select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_OPROFILE
+ select HAVE_PERF_EVENTS
+ select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_SYSCALL_TRACEPOINTS
+ select HAVE_SYSCALL_WRAPPERS
+ select HAVE_UID16 if 32BIT
+ select HAVE_VIRT_CPU_ACCOUNTING
+ select INIT_ALL_POSSIBLE
+ select KTIME_SCALAR if 32BIT
select MODULES_USE_ELF_RELA
- select CLONE_BACKWARDS2
+ select SYSCTL_EXCEPTION_TRACE
+ select USE_GENERIC_SMP_HELPERS if SMP
+ select VIRT_CPU_ACCOUNTING
config SCHED_OMIT_FRAME_POINTER
def_bool y
pgpnid9fEYePe.pgp
Description: PGP signature
Re: [PATCH v2 3/3] mm: accelerate munlock() treatment of THP pages
On Wed, 2013-02-06 at 18:44 -0500, Sasha Levin wrote: > On 02/04/2013 02:17 AM, Michel Lespinasse wrote: > > munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE > > at a time. When munlocking THP pages (or the huge zero page), this resulted > > in taking the mm->page_table_lock 512 times in a row. > > > > We can do better by making use of the page_mask returned by follow_page_mask > > (for the huge zero page case), or the size of the page munlock_vma_page() > > operated on (for the true THP page case). > > > > Note - I am sending this as RFC only for now as I can't currently put > > my finger on what if anything prevents split_huge_page() from operating > > concurrently on the same page as munlock_vma_page(), which would mess > > up our NR_MLOCK statistics. Is this a latent bug or is there a subtle > > point I missed here ? > > > > Signed-off-by: Michel Lespinasse > > Hi Michel, > > Fuzzing with trinity inside a KVM tools guest produces a steady stream of: > > > [ 51.823275] [ cut here ] > [ 51.823302] kernel BUG at include/linux/page-flags.h:421! > [ 51.823307] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 51.823307] Dumping ftrace buffer: > [ 51.823314](ftrace buffer empty) > [ 51.823314] Modules linked in: > [ 51.823314] CPU 2 > [ 51.823314] Pid: 7116, comm: trinity Tainted: GW > 3.8.0-rc6-next-20130206-sasha-00027-g3b5963c-dirty #273 > [ 51.823316] RIP: 0010:[] [] > munlock_vma_page+0x12/0xf0 > [ 51.823317] RSP: 0018:880009641bb8 EFLAGS: 00010282 > [ 51.823319] RAX: 011ffc008001 RBX: ea410040 RCX: > > [ 51.823320] RDX: RSI: RDI: > ea410040 > [ 51.823321] RBP: 880009641bc8 R08: R09: > > [ 51.823322] R10: R11: R12: > 880009633958 > [ 51.823324] R13: 01252000 R14: ea410040 R15: > 00ff > [ 51.823326] FS: 7fe7a9046700() GS:88000ba0() > knlGS: > [ 51.823327] CS: 0010 DS: ES: CR0: 80050033 > [ 51.823328] CR2: 7fc583b90fcb CR3: 09bc8000 CR4: > 000406e0 > [ 51.823334] DR0: DR1: DR2: > > [ 51.823338] DR3: DR6: 0ff0 DR7: > 0400 > [ 51.823340] Process trinity (pid: 7116, threadinfo 88000964, task > 880009638000) > [ 51.823341] Stack: > [ 51.823344] 00a01000 880009633958 880009641c08 > 812429bd > [ 51.823373] 880009638000 01ff09638000 880009ade000 > 880009633958 > [ 51.823373] 880009638810 880009ade098 880009641cb8 > 81246d81 > [ 51.823373] Call Trace: > [ 51.823373] [] munlock_vma_pages_range+0x8d/0xf0 > [ 51.823373] [] exit_mmap+0x51/0x170 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] ? kmem_cache_free+0x22f/0x3b0 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] mmput+0x77/0xe0 > [ 51.823377] [] exit_mm+0x113/0x120 > [ 51.823381] [] ? _raw_spin_unlock_irq+0x51/0x80 > [ 51.823384] [] do_exit+0x24a/0x590 > [ 51.823387] [] do_group_exit+0x8a/0xc0 > [ 51.823390] [] get_signal_to_deliver+0x501/0x5b0 > [ 51.823394] [] do_signal+0x42/0x110 > [ 51.823399] [] ? rcu_eqs_exit_common+0x64/0x340 > [ 51.823404] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823407] [] ? trace_hardirqs_on_caller+0x128/0x160 > [ 51.823409] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823412] [] do_notify_resume+0x48/0xa0 > [ 51.823415] [] retint_signal+0x4d/0x92 > [ 51.823449] Code: 85 c0 75 0d 48 89 df e8 0d 30 fe ff 0f 1f 44 00 00 48 83 > c4 08 5b 5d c3 90 55 48 89 e5 41 54 53 48 89 fb 48 > 8b 07 f6 c4 80 74 06 <0f> 0b 0f 1f 40 00 48 8b 07 48 c1 e8 0e 83 e0 01 83 f8 > 01 48 8b > [ 51.823449] RIP [] munlock_vma_page+0x12/0xf0 > [ 51.823450] RSP > [ 51.826846] ---[ end trace a7919e7f17c0a72a ]--- > The similar warning prevents my system from booting. And it seems to me that in munlock_vma_pages_range(), the page_mask needs be the page number returned from munlock_vma_page() minus 1. And the following fix solved my problem. Would you please have a try? Thanks, Zhong diff --git a/mm/mlock.c b/mm/mlock.c index af1d115..1e3d794 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -255,7 +255,7 @@ void munlock_vma_pages_range(struct vm_area_struct *vma, unlock_page(page); put_page(page); } - page
Re: [ANNOUNCE] 3.8-rc6-nohz4
I'll reply to this as I come up with comments. First thing is, don't call it NO_HZ_FULL. A better name would be NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we totally remove jiffies :-) And the kconfig help should probably call it "Adaptive tickless" or "Tickless for single tasks". The full tickless system really sounds like we totally removed jiffies. It should explain it better. Something like: "Adaptive tickless system" With this option, you may designate CPUs that will turn off the periodic interrupt "tick" when only a single task is scheduled on the CPU. This is similar to NO_HZ where the tick is suspended when the CPU goes into idle. With this option, it takes it one step further. When only a single task is scheduled on the CPU, there scheduler does not need to keep track of time slices, as the running task does not need to be preempted for other tasks. Stopping the tick allows the task to avoid being interrupted by service routines by the kernel. CPUs must be designated at time of boot via the kernel command line parameter (cpu_nohz) and must be a subset of the rcu_nocb parameter, which prevents RCU service routines from being called on the CPUs as well. --- Something like that. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6 RFC] Mapping range lock
On Wed, Feb 06, 2013 at 08:25:34PM +0100, Jan Kara wrote: > On Wed 06-02-13 10:25:12, Dave Chinner wrote: > > On Mon, Feb 04, 2013 at 01:38:31PM +0100, Jan Kara wrote: > > > On Thu 31-01-13 16:07:57, Andrew Morton wrote: > > > > > c) i_mutex doesn't allow any paralellism of operations using it and > > > > > some > > > > >filesystems workaround this for specific cases (e.g. DIO reads). > > > > > Using > > > > >range locking allows for concurrent operations (e.g. writes, DIO) > > > > > on > > > > >different parts of the file. Of course, range locking itself isn't > > > > >enough to make the parallelism possible. Filesystems still have to > > > > >somehow deal with the concurrency when manipulating inode > > > > > allocation > > > > >data. But the range locking at least provides a common VFS > > > > > mechanism for > > > > >serialization VFS itself needs and it's upto each filesystem to > > > > >serialize more if it needs to. > > > > > > > > That would be useful to end-users, but I'm having trouble predicting > > > > *how* useful. > > > As Zheng said, there are people interested in this for DIO. Currently > > > filesystems each invent their own tweaks to avoid the serialization at > > > least for the easiest cases. > > > > The thing is, this won't replace the locking those filesystems use > > to parallelise DIO - it just adds another layer of locking they'll > > need to use. The locks filesystems like XFS use to serialise IO > > against hole punch also serialise against many more internal > > functions and so if these range locks don't have the same capability > > we're going to have to retain those locks even after the range locks > > are introduced. It basically means we're going to have two layers > > of range locks - one for IO sanity and atomicity, and then this > > layer just for hole punch vs mmap. > > > > As i've said before, what we really need in XFS is IO range locks > > because we need to be able to serialise operations against IO in > > progress, not page cache operations in progress. > Hum, I'm not sure I follow you here. So mapping tree lock + PageLocked + > PageWriteback serialize all IO for part of the file underlying the page. > I.e. at most one of truncate (punch hole), DIO, writeback, buffered write, > buffered read, page fault can run on that part of file. Right, it serialises page cache operations sufficient to avoid page cache coherence problems, but it does not serialise operations sufficiently to provide atomicity between operations that should be atomic w.r.t. each other. > So how come it > doesn't provide enough serialization for XFS? > > Ah, is it the problem that if two threads do overlapping buffered writes > to a file then we can end up with data mixed from the two writes (if we > didn't have something like i_mutex)? That's one case of specific concern - the POSIX write() atomicity guarantee - but it indicates the cause of many of my other concerns, too. e.g. write vs prealloc, write vs punch, read vs truncate, write vs truncate, buffered vs direct write, etc. Basically, page-cache granularity locking for buffered IO means that it cannot be wholly serialised against any other operation in progress. That means we can't use the range lock to provide a barrier to guarantee that no IO is currently in progress at all, and hence it doesn't provide the IO barrier semantics we need for various operations within XFS. An example of this is that the online defrag ioctl requires copyin + mtime updates in the write path are atomic w.r.t the swap extents ioctl so that it can detect concurrent modification of the file being defragged and abort. The page cache based range locks simply don't provide this coverage, and so we'd need to maintain the IO operation locking we currently have to provide this exclusion.. Truncate is something I also see as particularly troublesome, because the i_mutex current provides mutual exclusion against the operational range of a buffered write (i.e. at the .aio_write level) and not page granularity like this patch set would result in. Hence the behaviour of write vs truncate races could change quite significantly. e.g. instead of "write completes then truncate" or "truncate completes then write", we could have "partial write, truncate, write continues and completes" resulting in a bunch of zeros inside the range the write call wrote to. The application won't even realise that the data it wrote was corrupted by the racing truncate. IOWs, I think that the fundamental unit of atomicity we need here is the operational range of the syscall i.e. that each of the protected operations needs to execute atomically as a whole with respect to each other, not in a piecemeal fashion where some use whole range locking and others use fine-grained page-range locking... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote: > On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote: > > Thanks much. I will hang on to this test system for testing your fix. > > Okay, here is the simple fix for v3.8-rc6. I guess it is not > straighforward to port it to v3.4, but it should be doable. > > From 2ecf57c85e67e0243b36b787d0490c0b47202ba8 Mon Sep 17 00:00:00 2001 > From: Joerg Roedel > Date: Wed, 6 Feb 2013 12:55:23 +0100 > Subject: [PATCH] iommu/amd: Initialize device table after dma_ops > > When dma_ops are initialized the unity mappings are > created. The init_device_table_dma() function makes sure DMA > from all devices is blocked by default. This opens a short > window in time where DMA to unity mapped regions is blocked > by the IOMMU. Make sure this does not happen by initializing > the device table after dma_ops. > > Signed-off-by: Joerg Roedel Joerg, I tested your patch on 3.8. I was able to reproduce the problem and then apply your patch to verify that the problem is fixed. This patch applies cleanly to 3.7.6, however I could not reproduce the problem on 3.7.6 without the patch. But the window exists on 3.7 as well. Your patch can be applied to 3.7.6 as is. I back-ported the patch to 3.4 and 3.0 and tested. I am sending those patches after this email. On 3.4.29 and 3.0.62 I was able to reproduce the problem and then applied the back-ported patch to verify that the problem is fixed. Thanks again for the fix. -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ia64/mm: fix a bad_page bug when crash kernel booting
On 2013/2/5 0:32, Matt Fleming wrote:
> On Tue, 2013-01-29 at 11:52 +0800, Xishi Qiu wrote:
>> On ia64 platform, I set "crashkernel=1024M-:600M", and dmesg shows 128M-728M
>> memory is reserved for crash kernel. Then "echo c > /proc/sysrq-trigger" to
>> test kdump.
>>
>> When crash kernel booting, efi_init() will aligns the memory address in
>> IA64_GRANULE_SIZE(16M), so 720M-728M memory will be dropped, It means
>> crash kernel only manage 128M-720M memory.
>>
>> But initrd start and end are fixed in boot loader, it is before efi_init(),
>> so initrd size maybe overflow when free_initrd_mem().
>
> [...]
>
>> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
>> index b755ea9..cfdb1eb 100644
>> --- a/arch/ia64/mm/init.c
>> +++ b/arch/ia64/mm/init.c
>> @@ -207,6 +207,17 @@ free_initrd_mem (unsigned long start, unsigned long end)
>> start = PAGE_ALIGN(start);
>> end = end & PAGE_MASK;
>>
>> +/*
>> + * Initrd size is fixed in boot loader, but kernel parameter max_addr
>> + * which aligns in granules is fixed after boot loader, so initrd size
>> + * maybe overflow.
>> + */
>> +if (max_addr != ~0UL) {
>> +end = GRANULEROUNDDOWN(end);
>> +if (start > end)
>> +start = end;
>> +}
>> +
>> if (start < end)
>> printk(KERN_INFO "Freeing initrd memory: %ldkB freed\n", (end -
>> start) >> 10);
>
> I don't think this is the correct fix.
>
> Now, my ia64-fu is weak, but could it be that there's actually a bug in
> efi_init() and that the following patch would be the best way to fix
> this?
>
> ---
>
> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
> index f034563..8d579f1 100644
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -482,7 +482,7 @@ efi_init (void)
> if (memcmp(cp, "mem=", 4) == 0) {
> mem_limit = memparse(cp + 4, );
> } else if (memcmp(cp, "max_addr=", 9) == 0) {
> - max_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
> + max_addr = GRANULEROUNDUP(memparse(cp + 9, ));
> } else if (memcmp(cp, "min_addr=", 9) == 0) {
> min_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
> } else {
>
>
Sorry, this bug will be happen when use Sparse-Memory(section is valid, but last
several pages are invalid). If use Flat-Memory, crash kernel will boot
successfully.
I think the following patch would be better.
Hi Andrew, will you just ignore the earlier patch and consider the following
one? :>
Signed-off-by: Xishi Qiu
---
arch/ia64/mm/init.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 082e383..23f2ee3 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -213,6 +213,8 @@ free_initrd_mem (unsigned long start, unsigned long end)
for (; start < end; start += PAGE_SIZE) {
if (!virt_addr_valid(start))
continue;
+ if ((start >> PAGE_SHIFT) >= max_low_pfn)
+ continue;
page = virt_to_page(start);
ClearPageReserved(page);
init_page_count(page);
--
1.7.6.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/2] perf stat: add per processor socket count aggregation
Hi Stephane, On Wed, 6 Feb 2013 15:46:00 +0100, Stephane Eranian wrote: > This patch adds per-processor socket count aggregation > for system-wide mode measurements. This is a useful > mode to detect imbalance between sockets for uniform > workloads. > > To enable this mode, use --aggr-socket in addition > to -a. (system-wide). This mode can be combined with > interval printing. > > The output includes the socket number and the number > of online processors on that socket. This is useful > to gauge the amount of aggregation. > > # ./perf stat -I 1000 -a --aggr-socket -e cycles sleep 2 > # time socket cpus counts events > 1.97680 S04 5,788,785 cycles > 2.000379943 S04 27,361,546 cycles > 2.001167808 S04818,275 cycles Can it be genericized to support arbitrary cpu topology like per-core, per-numa-node or something? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] stop_machine: dequeue work before signal completion
Hello, On Wed, Feb 6, 2013 at 6:21 PM, Namhyung Kim wrote: >> Why does this matter? It's inside spinlock. What's being made better >> by this change? > > IIUC the work should be deleted from the list, otherwise it'd trigger > BUG_ON when the cpu gets online again. Ah, okay, the original code was missing list_del_init(), so we end up with trashy work list if CPU goes down while there are pending work items which will trigger BUG_ON() later when the CPU comes back on. Hillf, can you please redo the patch description? I can't tell what the patch is about from the description at all. If it's a bug fix, describe the bug and maybe accompany with oops trace if possible, and then describe how it's fixed. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vmalloc: Remove alloc_map from vmap_block.
There is no reason to maintain alloc_map in the vmap_block.
The use of alloc_map may require heavy bitmap operation sometimes.
In the worst-case, We need 1024 for-loops to find 1 free bit and
thus cause overhead. vmap_block is fragmented unnecessarily by
2 order alignment as well.
Instead we can map by using vb->free in order. When It is freed,
Its corresponding bit will be set in the dirty_map and all
free/purge operations are carried out in the dirty_map.
vmap_block is not fragmented sporadically anymore and thus
purge_fragmented_blocks_thiscpu in the vb_alloc can be removed.
Signed-off-by: Chanho Min
Signed-off-by: Joonsoo Kim
---
mm/vmalloc.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5123a16..4fd3555 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -744,7 +744,6 @@ struct vmap_block {
struct vmap_area *va;
struct vmap_block_queue *vbq;
unsigned long free, dirty;
- DECLARE_BITMAP(alloc_map, VMAP_BBMAP_BITS);
DECLARE_BITMAP(dirty_map, VMAP_BBMAP_BITS);
struct list_head free_list;
struct rcu_head rcu_head;
@@ -810,7 +809,6 @@ static struct vmap_block *new_vmap_block(gfp_t gfp_mask)
vb->va = va;
vb->free = VMAP_BBMAP_BITS;
vb->dirty = 0;
- bitmap_zero(vb->alloc_map, VMAP_BBMAP_BITS);
bitmap_zero(vb->dirty_map, VMAP_BBMAP_BITS);
INIT_LIST_HEAD(>free_list);
@@ -863,7 +861,6 @@ static void purge_fragmented_blocks(int cpu)
if (vb->free + vb->dirty == VMAP_BBMAP_BITS && vb->dirty !=
VMAP_BBMAP_BITS) {
vb->free = 0; /* prevent further allocs after releasing
lock */
vb->dirty = VMAP_BBMAP_BITS; /* prevent purging it
again */
- bitmap_fill(vb->alloc_map, VMAP_BBMAP_BITS);
bitmap_fill(vb->dirty_map, VMAP_BBMAP_BITS);
spin_lock(>lock);
list_del_rcu(>free_list);
@@ -881,11 +878,6 @@ static void purge_fragmented_blocks(int cpu)
}
}
-static void purge_fragmented_blocks_thiscpu(void)
-{
- purge_fragmented_blocks(smp_processor_id());
-}
-
static void purge_fragmented_blocks_allcpus(void)
{
int cpu;
@@ -900,7 +892,6 @@ static void *vb_alloc(unsigned long size, gfp_t gfp_mask)
struct vmap_block *vb;
unsigned long addr = 0;
unsigned int order;
- int purge = 0;
BUG_ON(size & ~PAGE_MASK);
BUG_ON(size > PAGE_SIZE*VMAP_MAX_ALLOC);
@@ -924,17 +915,8 @@ again:
if (vb->free < 1UL << order)
goto next;
- i = bitmap_find_free_region(vb->alloc_map,
- VMAP_BBMAP_BITS, order);
+ i = VMAP_BBMAP_BITS - vb->free;
- if (i < 0) {
- if (vb->free + vb->dirty == VMAP_BBMAP_BITS) {
- /* fragmented and no outstanding allocations */
- BUG_ON(vb->dirty != VMAP_BBMAP_BITS);
- purge = 1;
- }
- goto next;
- }
addr = vb->va->va_start + (i << PAGE_SHIFT);
BUG_ON(addr_to_vb_idx(addr) !=
addr_to_vb_idx(vb->va->va_start));
@@ -950,9 +932,6 @@ next:
spin_unlock(>lock);
}
- if (purge)
- purge_fragmented_blocks_thiscpu();
-
put_cpu_var(vmap_block_queue);
rcu_read_unlock();
--
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] rtc: max8997: Add driver for max8997 rtc.
On Thu, 07 Feb 2013 10:43:23 +0900 jonghwa3@samsung.com wrote: > > The best way of handling this sort of thing is for the driver to probe > > the hardware, work out its capabilities and "do the right thing". > > > > The second best way is to require that the user add certain module > > parameters to enable the functionality. > > > > How do we create sysfs node for enabling these options? I suggest using module_param[_named](), so users can execute "modprobe max8997 wtsr=1". Or, if the driver is built into vmlinux, add "max8997.wtsr=1" to the kernel boot command line. Documentation/kernel-parameters.txt mentions this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] stop_machine: dequeue work before signal completion
Hi Tejun and Hillf,
On Wed, 6 Feb 2013 10:47:49 -0800, Tejun Heo wrote:
> On Wed, Feb 06, 2013 at 08:38:43PM +0800, Hillf Danton wrote:
>> As handled by the kernel thread, work is dequeued first for further actions.
>
> Ditto as the previous patch.
>
>> Signed-off-by: Hillf Danton
>> ---
>>
>> --- a/kernel/stop_machine.c Wed Feb 6 19:57:12 2013
>> +++ b/kernel/stop_machine.c Wed Feb 6 20:02:12 2013
>> @@ -334,23 +334,24 @@ static int __cpuinit cpu_stop_cpu_callba
>> #ifdef CONFIG_HOTPLUG_CPU
>> case CPU_UP_CANCELED:
>> case CPU_POST_DEAD:
>> -{
>> -struct cpu_stop_work *work;
>> -
>> sched_set_stop_task(cpu, NULL);
>> /* kill the stopper */
>> kthread_stop(stopper->thread);
>> /* drain remaining works */
>> spin_lock_irq(>lock);
>> -list_for_each_entry(work, >works, list)
>> +while (!list_empty(>works)) {
>> +struct cpu_stop_work *work;
>> +work = list_first_entry(>works,
>> +struct cpu_stop_work, list);
>> +list_del_init(>list);
>> cpu_stop_signal_done(work->done, false, 0);
>> +}
>> stopper->enabled = false;
>> spin_unlock_irq(>lock);
>
> Why does this matter? It's inside spinlock. What's being made better
> by this change?
IIUC the work should be deleted from the list, otherwise it'd trigger
BUG_ON when the cpu gets online again.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/5] r8169: Modify the method for setting firmware
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
>
> Did you check that none of rtl_nic/rtl8168d-{1, 2}.fw uses
> PHY_READ_EFUSE ?
>
I have made sure that none of the current firmwares use PHY_READ_EFUSE.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
problem with ocfs2 in 3.7.6 and 3.6.11
Hi All, Today i found a problem in linux 3.7.6 with ocfs2 when using ocfs2 from inside a chroot or linux-vserver guest. This problem also exists at least in 3.6.11. how to reproduce: node:~# cat /etc/debian_version 6.0.6 node:~# rbd showmapped id pool image snap device 1 rbd ocfs2 -/dev/rbd1 mounted ocfs2 fs on rdb device on /ocfs2: /dev/rbd1 on /ocfs2 type ocfs2 (rw,_netdev,noatime,data=writeback,heartbeat=local) mount --bind /ocfs2 /var/lib/vservers/www/ocfs2 chroot /var/lib/vservers/www www:/# cat /etc/debian_version 5.0.10 DocumentRoots for apache are on ocfs2 /etc/init.d/apache2 start Then apache hangs and i have to reboot, see trace (annotated with addr2line where available): [ 225.548824] general protection fault: [#1] PREEMPT SMP [ 225.549067] Modules linked in: ipt_REJECT xt_multiport arpt_mangle arptable_filter arp_tables ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative ocfs2_stack_o2cb bridge stp llc bonding fuse ocfs2_dlm ocfs2_dlmfs dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd acpi_cpufreq mperf coretemp kvm_intel kvm psmouse serio_raw lpc_ich mfd_core i2c_i801 evdev i2c_core btrfs lzo_compress [ 225.551698] CPU 1 [ 225.551755] Pid: 5888, comm: apache2 Not tainted 3.7.6 #1 Supermicro X9SCI/X9SCA/X9SCI/X9SCA [ 225.551913] RIP: 0010:[] [] strnlen+0x10/0x19/lib/string.c:405 [ 225.552059] RSP: 0018:8808160a3b80 EFLAGS: 00010216 [ 225.552135] RAX: e889440200a5 RBX: e889440200a5 RCX: 0063ea4c [ 225.552215] RDX: 0063ea4c RSI: 0f3f RDI: e889440200a5 [ 225.552294] RBP: ea00170650b8 R08: 810b8c7e R09: [ 225.552374] R10: 880816b50100 R11: 880816b50100 R12: 8806974afbf8 [ 225.552450] R13: 000200da R14: 000201da R15: [ 225.552530] FS: 7eff6d9e2750() GS:88083fc4() knlGS: [ 225.552625] CS: 0010 DS: ES: CR0: 80050033 [ 225.552701] CR2: 7fa71e7fbd40 CR3: 0007f7849000 CR4: 000407e0 [ 225.552778] DR0: DR1: DR2: [ 225.552858] DR3: DR6: 0ff0 DR7: 0400 [ 225.552938] Process apache2 (pid: 5888, threadinfo 8808160a2000, task 880816b50100) [ 225.553032] Stack: [ 225.553103] a06d7d27 ea00170650b8 8806974afd38 ea00170650b8 [ 225.553408] 810b8c7e 8806974afd38 ea00170650b8 [ 225.553711] 810b8ddd 8808160a3ca8 a06d7c20 8806974d2440 [ 225.554016] Call Trace: [ 225.554098] [] ? ocfs2_fast_symlink_readpage+0x107/0x1a0[ocfs2] ??:0 [ 225.554194] [] ? add_to_page_cache_lru+0x2c/0x36 /include/linux/swap.h:253 [ 225.554272] [] ? do_read_cache_page+0x8f/0x132 /mm/filemap.c:1802 [ 225.554359] [] ? ocfs2_osb_debug_open+0x670/0x670[ocfs2] ??:0 [ 225.554442] [] ? read_cache_page+0x9/0x12 /mm/filemap.c:1921 [ 225.554521] [] ? page_getlink+0x25/0x86 /fs/namei.c:3956 [ 225.554598] [] ? page_follow_link_light+0x1b/0x2c /include/linux/namei.h:88 [ 225.554675] [] ? link_path_walk+0x400/0x7c5 /fs/namei.c:851 [ 225.554751] [] ? path_lookupat+0x52/0x6cf /fs/namei.c:1983 [ 225.554835] [] ? filename_lookup+0x20/0x92 /fs/namei.c:2024 [ 225.554922] [] ? getname_flags+0x70/0x146 /fs/namei.c:159 [ 225.554997] [] ? user_path_at_empty+0x49/0x7d /fs/namei.c:2172 [ 225.555077] [] ? autoremove_wake_function+0x2a/0x2a /kernel/wait.c:174 [ 225.555155] [] ? cp_new_stat+0x10d/0x11f /fs/stat.c:241 [ 225.555231] [] ? vfs_fstatat+0x39/0x66 /fs/stat.c:89 [ 225.555314] [] ? sys_newstat+0x11/0x2d /fs/stat.c:248 [ 225.555402] [] ? system_call_fastpath+0x16/0x1b /arch/x86/kernel/entry_64.S:645 [ 225.555480] Code: f6 82 30 a9 58 81 20 75 f1 c3 48 89 f8 eb 03 48 ff c0 80 38 00 75 f8 48 29 f8 c3 48 89 f8 eb 03 48 ff c0 48 85 f6 74 08 48 ff ce <80> 38 00 75 f0 48 29 f8 c3 31 c0 eb 14 44 38 c1 74 0c 48 ff c2 [ 225.559020] RIP [] strnlen+0x10/0x19 /lib/string.c:405 [ 225.559143] RSP [ 225.559254] ---[ end trace 10bd8a6b280d52b1 ]--- -- Mit freundlichen Grüßen, Florian Wiessner Smart Weblications GmbH Martinsberger Str. 1 D-95119 Naila fon.: +49 9282 9638 200 fax.: +49 9282 9638 205 24/7: +49 900 144 000 00 - 0,99 EUR/Min* http://www.smart-weblications.de -- Sitz der Gesellschaft: Naila Geschäftsführer: Florian Wiessner HRB-Nr.: HRB 3840 Amtsgericht Hof *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz [ 225.548824] general protection fault: [#1] PREEMPT SMP [ 225.549067] Modules linked in: ipt_REJECT xt_multiport arpt_mangle arptable_filter arp_tables ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables
[PATCH wq/for-3.9] workqueue: cosmetic update in try_to_grab_pending()
With the recent is-work-queued-here test simplification, the nested
if() in try_to_grab_pending() can be collapsed. Collapse it.
This patch is purely cosmetic.
Signed-off-by: Tejun Heo
Cc: Lai Jiangshan
---
A follow-up cleanup patch.
Thanks.
kernel/workqueue.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1107,31 +1107,27 @@ static int try_to_grab_pending(struct wo
* item is currently queued on that pool.
*/
cwq = get_work_cwq(work);
- if (cwq) {
- if (cwq->pool == pool) {
- debug_work_deactivate(work);
+ if (cwq && cwq->pool == pool) {
+ debug_work_deactivate(work);
- /*
-* A delayed work item cannot be grabbed directly
-* because it might have linked NO_COLOR work items
-* which, if left on the delayed_list, will confuse
-* cwq->nr_active management later on and cause
-* stall. Make sure the work item is activated
-* before grabbing.
-*/
- if (*work_data_bits(work) & WORK_STRUCT_DELAYED)
- cwq_activate_delayed_work(work);
+ /*
+* A delayed work item cannot be grabbed directly because
+* it might have linked NO_COLOR work items which, if left
+* on the delayed_list, will confuse cwq->nr_active
+* management later on and cause stall. Make sure the work
+* item is activated before grabbing.
+*/
+ if (*work_data_bits(work) & WORK_STRUCT_DELAYED)
+ cwq_activate_delayed_work(work);
- list_del_init(>entry);
- cwq_dec_nr_in_flight(get_work_cwq(work),
- get_work_color(work));
+ list_del_init(>entry);
+ cwq_dec_nr_in_flight(get_work_cwq(work), get_work_color(work));
- /* work->data points to cwq iff queued, point to pool */
- set_work_pool_and_keep_pending(work, pool->id);
+ /* work->data points to cwq iff queued, point to pool */
+ set_work_pool_and_keep_pending(work, pool->id);
- spin_unlock(>lock);
- return 1;
- }
+ spin_unlock(>lock);
+ return 1;
}
spin_unlock(>lock);
fail:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] mm: accurately document nr_free_*_pages functions with code comments
Functions nr_free_zone_pages, nr_free_buffer_pages and nr_free_pagecache_pages
are horribly badly named, so accurately document them with code comments
in case of the misuse of them.
Reviewed-by: Randy Dunlap
Signed-off-by: Zhang Yanfei
---
mm/page_alloc.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index df2022f..0790716 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2785,6 +2785,15 @@ void free_pages_exact(void *virt, size_t size)
}
EXPORT_SYMBOL(free_pages_exact);
+/**
+ * nr_free_zone_pages - get pages that is beyond high watermark
+ * @offset: The zone index of the highest zone
+ *
+ * The function counts pages which are beyond high watermark within
+ * all zones at or below a given zone index. For each zone, the
+ * amount of pages is calculated as:
+ * present_pages - high_pages
+ */
static unsigned int nr_free_zone_pages(int offset)
{
struct zoneref *z;
@@ -2805,8 +2814,11 @@ static unsigned int nr_free_zone_pages(int offset)
return sum;
}
-/*
- * Amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL
+/**
+ * nr_free_buffer_pages - get pages that is beyond high watermark
+ *
+ * The function counts pages which are beyond high watermark within
+ * ZONE_DMA and ZONE_NORMAL.
*/
unsigned int nr_free_buffer_pages(void)
{
@@ -2814,8 +2826,11 @@ unsigned int nr_free_buffer_pages(void)
}
EXPORT_SYMBOL_GPL(nr_free_buffer_pages);
-/*
- * Amount of free RAM allocatable within all zones
+/**
+ * nr_free_pagecache_pages - get pages that is beyond high watermark
+ *
+ * The function counts pages which are beyond high watermark within
+ * all zones.
*/
unsigned int nr_free_pagecache_pages(void)
{
--
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: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD caching software for Linux kernel
> -Original Message- > From: Kent Overstreet [mailto:koverstr...@google.com] > Sent: Wednesday, February 06, 2013 4:01 PM > To: Amit Kale > Cc: Michel Lespinasse; Darrick J. Wong; linux-bcache; device-mapper > development; Kent Overstreet; Mike Snitzer; LKML; Jason Warr; > thorn...@redhat.com > Subject: Re: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO SSD > caching software for Linux kernel > > On Thu, Feb 07, 2013 at 06:57:40AM +0800, Amit Kale wrote: > > > -Original Message- > > > From: Michel Lespinasse [mailto:wal...@google.com] > > > Sent: Friday, February 01, 2013 4:58 PM > > > To: Darrick J. Wong > > > Cc: Amit Kale; linux-bcache; device-mapper development; Kent > > > Overstreet; Mike Snitzer; LKML; Jason Warr; thorn...@redhat.com > > > Subject: Re: [RFC] [DONOTAPPLY] [PATCH] enhanceio: STEC EnhanceIO > > > SSD caching software for Linux kernel > > > > > > On Fri, Feb 1, 2013 at 4:44 PM, Darrick J. Wong > > > wrote: > > > > This is a patch to migrate STEC's enhanceio driver out of their > > > github > > > > repository and into the staging tree. From their README: > > > > > > > > "EnhanceIO driver is based on EnhanceIO SSD caching software > > > > product developed by STEC Inc. EnhanceIO was derived from > > > > Facebook's open source Flashcache project. EnhanceIO uses SSDs as > > > > cache devices for traditional rotating hard disk drives (referred > > > > to as source volumes > > > throughout this document). > > > > EnhanceIO can work with any block device, be it an entire > physical > > > > disk, an individual disk partition, a RAIDed DAS device, a SAN > > > > volume, a device mapper volume or a software RAID (md) device." > > > > > > What's your take on the benefits of this vs bcache ? > > > > EnhanceIO was designed for and has been validated in enterprise > > environments. The important benefits are - 1. There is no downtime > for cache creation, deletion, editing properties, > writeback/readonly/writethrough mode change. > > True of bcache. > > > 2. Wb mode comes with an option to control whether dirty data should > be clean-up across reboots, which prevents SSD/HDD going out of sync. > > No idea why you'd want this. You have to be able to handle a rebooting > with a dirty cache, if you hope to handle unclean shutdown - bcache > does this. And if you're running in writeback mode there's probably > going to be many gigabytes of dirty data in your cache, at least > sometimes, and you aren't going to want to wait for that to flush > before you reboot. > > If you want to flush dirty data with bcache, you can switch back to > writethrough mode whenever you want. We have two modes of operation with writeback 1. Warm restart mode (default) - Reboots are quick. Dirty data is kept as it is across reboots. So is clean data. Abrupt reboots are handled correctly by throwing away clean data and retaining dirty data. The throwing away clean data is a fallout of an optimization done to skip metadata updates for clean data. 2. Cold restart mode - A reboot or a shutdown involves clean-up of dirty data. This is for paranoid sysads who are afraid that iSCSI HDD setup may cause them to be reattached. Switching to writethrough mode will achieve the same thing, however with a persistent cache configuration in place, the cache will be write-through after a reboot. I am happy to see bcache being compliant with the rest of the items I had noted. -Amit > > > 3. Our in-house testing was done for large setups with 500GB+SSDs and > proportionately large HDDs, on 24CPU machines with plenty of RAM. It's > survived heavy IO loads without any locking or corruption problems. > > True of bcache. > > > 4. Error handling is exactly what enterprises look for - > writethrough/readonly modes work seamlessly regardless of SSD failures. > In all the three caching modes, the guarantees of completion in > presence of IO errors or shutdowns, in terms of granularity and > persistence of data written, is identical to underlying HDDs. > > True of bcache. > > > 5. It works for all known block devices - Software RAIDs, full block > devices with or without partitions, individual partitions, various > intelligent block devices. > > True of bcache. > > > -Amit > > > > PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED > > > > This electronic transmission, and any documents attached hereto, may > contain confidential, proprietary and/or legally privileged > information. The information is intended only for use by the recipient > named above. If you received this electronic message in error, please > notify the sender and delete the electronic message. Any disclosure, > copying, distribution, or use of the contents of information received > in error is strictly prohibited, and violators will be pursued legally. > > Which of the above information was proprietary, and should I not be > resending this to lkml or - who? > > ... PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED This electronic
Re: next-20130206 cpufreq - WARN in sysfs_add_one
On Thursday, February 07, 2013 02:12:17 AM Rafael J. Wysocki wrote: > On Wednesday, February 06, 2013 07:55:58 PM valdis.kletni...@vt.edu wrote: > > On Wed, 06 Feb 2013 22:24:39 +0100, "Rafael J. Wysocki" said: > > > On Wednesday, February 06, 2013 12:44:35 PM Valdis Kletnieks wrote: > > > > Seen in dmesg. next-20130128 was OK. Haven't done a bisect, but can > > > > do so if the offender isn't obvious... > > > > > > I suppose this is 73bf0fc "cpufreq: Don't remove sysfs link for > > > policy->cpu". > > > > > > Can you test the linux-pm.git/pm-cpufreq branch alone, please, and see > > > if that's this one (top-most commit)? > > > > Color me mystified. I can't find that commit by either number or > > the description: > > > > [/usr/src/linux-next] git log | egrep -i 'cpufreq.*remove.*link' > > [/usr/src/linux-next] git log | grep -i 73bf0fc > > [/usr/src/linux-next] > > > > Was that a very recent commit that may have gotten pushed too late > > for the next-20130206 merge? > > Well, sorry, next-20130206 didn't include that commit. > > Can you please test the linux-pm.git/pm-cpufreq branch, then? To be precise, I mean the pm-cpufreq branch of the tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git which is based on v3.8-rc6. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: accurately document nr_free_*_pages functions with code comments
于 2013年02月07日 08:55, Randy Dunlap 写道:
> On 02/06/13 00:25, Zhang Yanfei wrote:
>> Functions nr_free_zone_pages, nr_free_buffer_pages and
>> nr_free_pagecache_pages
>> are horribly badly named, so accurately document them with code comments
>> in case of the misuse of them.
>>
>> Signed-off-by: Zhang Yanfei
>> ---
>> mm/page_alloc.c | 23 +++
>> 1 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index df2022f..0790716 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -2785,6 +2785,15 @@ void free_pages_exact(void *virt, size_t size)
>> }
>> EXPORT_SYMBOL(free_pages_exact);
>>
>> +/**
>> + * nr_free_zone_pages - get pages that is beyond high watermark
>> + * @offset - The zone index of the highest zone
>
> Function parameter format uses a ':', not a '-'. E.g.,
>
> * @offset: the zone index of the highest zone
Sorry for my mistake. Thanks for your review.
>
>
>> + *
>> + * The function counts pages which are beyond high watermark within
>> + * all zones at or below a given zone index. For each zone, the
>> + * amount of pages is calculated as:
>> + * present_pages - high_pages
>> + */
>> static unsigned int nr_free_zone_pages(int offset)
>> {
>> struct zoneref *z;
>> @@ -2805,8 +2814,11 @@ static unsigned int nr_free_zone_pages(int offset)
>> return sum;
>> }
>>
>> -/*
>> - * Amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL
>> +/**
>> + * nr_free_buffer_pages - get pages that is beyond high watermark
>> + *
>> + * The function counts pages which are beyond high watermark within
>> + * ZONE_DMA and ZONE_NORMAL.
>> */
>> unsigned int nr_free_buffer_pages(void)
>> {
>> @@ -2814,8 +2826,11 @@ unsigned int nr_free_buffer_pages(void)
>> }
>> EXPORT_SYMBOL_GPL(nr_free_buffer_pages);
>>
>> -/*
>> - * Amount of free RAM allocatable within all zones
>> +/**
>> + * nr_free_pagecache_pages - get pages that is beyond high watermark
>> + *
>> + * The function counts pages which are beyond high watermark within
>> + * all zones.
>> */
>> unsigned int nr_free_pagecache_pages(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] kernel: arg2 is unsigned long which is never < 0
于 2013年02月06日 23:24, Serge Hallyn 写道: > This really seems like splitting hairs to me. > > Acked-by: Serge E. Hallyn > > on the original patch. > > thanks, > -serge thank you. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with late 3.8-rc5 and 3.8-rc6 on i686
On Fri, Feb 01, 2013 at 14:13:32 -0600, Bruno Wolff III wrote: I have been testing 3.8 kernels on Fedora. The last good kernel was 3.8.0-0.rc5.git1.1.fc19.i686.PAE. I tested 3.8.0-0.rc5.git2.1.fc19.i686.PAE, 3.8.0-0.rc5.git3.1.fc19.i686 and 3.8.0-0.rc6.git0.1.fc19.i686.PAE and found these all had two odd effects. This turned out to be due Fedora changing some config options to turn off namespaces for i686 when it was thought by some people that they had been off previously. (And so this wasn't thought to be a change.) This broke the private network feature of systemd, used by rtkit-daemon. There is a new kernel build which fixes this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 wq/for-3.9] workqueue: simplify is-work-item-queued-here test
From: Lai Jiangshan
Currently, determining whether a work item is queued on a locked pool
involves somewhat convoluted memory barrier dancing. It goes like the
following.
* When a work item is queued on a pool, work->data is updated before
work->entry is linked to the pending list with a wmb() inbetween.
* When trying to determine whether a work item is currently queued on
a pool pointed to by work->data, it locks the pool and looks at
work->entry. If work->entry is linked, we then do rmb() and then
check whether work->data points to the current pool.
This works because, work->data can only point to a pool if it
currently is or were on the pool and,
* If it currently is on the pool, the tests would obviously succeed.
* It it left the pool, its work->entry was cleared under pool->lock,
so if we're seeing non-empty work->entry, it has to be from the work
item being linked on another pool. Because work->data is updated
before work->entry is linked with wmb() inbetween, work->data update
from another pool is guaranteed to be visible if we do rmb() after
seeing non-empty work->entry. So, we either see empty work->entry
or we see updated work->data pointin to another pool.
While this works, it's convoluted, to put it mildly. With recent
updates, it's now guaranteed that work->data points to cwq only while
the work item is queued and that updating work->data to point to cwq
or back to pool is done under pool->lock, so we can simply test
whether work->data points to cwq which is associated with the
currently locked pool instead of the convoluted memory barrier
dancing.
This patch replaces the memory barrier based "are you still here,
really?" test with much simpler "does work->data points to me?" test -
if work->data points to a cwq which is associated with the currently
locked pool, the work item is guaranteed to be queued on the pool as
work->data can start and stop pointing to such cwq only under
pool->lock and the start and stop coincide with queue and dequeue.
tj: Rewrote the comments and description.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 40
1 file changed, 16 insertions(+), 24 deletions(-)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1068,6 +1068,7 @@ static int try_to_grab_pending(struct wo
unsigned long *flags)
{
struct worker_pool *pool;
+ struct cpu_workqueue_struct *cwq;
local_irq_save(*flags);
@@ -1097,14 +1098,17 @@ static int try_to_grab_pending(struct wo
goto fail;
spin_lock(>lock);
- if (!list_empty(>entry)) {
- /*
-* This work is queued, but perhaps we locked the wrong
-* pool. In that case we must see the new value after
-* rmb(), see insert_work()->wmb().
-*/
- smp_rmb();
- if (pool == get_work_pool(work)) {
+ /*
+* work->data is guaranteed to point to cwq only while the work
+* item is queued on cwq->wq, and both updating work->data to point
+* to cwq on queueing and to pool on dequeueing are done under
+* cwq->pool->lock. This in turn guarantees that, if work->data
+* points to cwq which is associated with a locked pool, the work
+* item is currently queued on that pool.
+*/
+ cwq = get_work_cwq(work);
+ if (cwq) {
+ if (cwq->pool == pool) {
debug_work_deactivate(work);
/*
@@ -1159,13 +1163,6 @@ static void insert_work(struct cpu_workq
/* we own @work, set data and link */
set_work_cwq(work, cwq, extra_flags);
-
- /*
-* Ensure that we get the right work->data if we see the
-* result of list_add() below, see try_to_grab_pending().
-*/
- smp_wmb();
-
list_add_tail(>entry, head);
/*
@@ -2799,15 +2796,10 @@ static bool start_flush_work(struct work
return false;
spin_lock_irq(>lock);
- if (!list_empty(>entry)) {
- /*
-* See the comment near try_to_grab_pending()->smp_rmb().
-* If it was re-queued to a different pool under us, we
-* are not going to wait.
-*/
- smp_rmb();
- cwq = get_work_cwq(work);
- if (unlikely(!cwq || pool != cwq->pool))
+ /* see the comment in try_to_grab_pending() with the same code */
+ cwq = get_work_cwq(work);
+ if (cwq) {
+ if (unlikely(cwq->pool != pool))
goto already_gone;
} else {
worker = find_worker_executing_work(pool, work);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 6/7] net: change type of netns_ipvs->sysctl_sync_qlen_max
于 2013年02月07日 09:09, Simon Horman 写道: > On Wed, Feb 06, 2013 at 05:36:12PM +0800, Zhang Yanfei wrote: >> 于 2013年02月06日 17:29, Julian Anastasov 写道: >>> >>> Hello, >>> >>> Sorry that I'm writing a private email but I >>> deleted your original message by mistake. Your change >>> of the sysctl_sync_qlen_max from int to long is may be >>> not enough. >>> >>> net/netfilter/ipvs/ip_vs_ctl.c contains >>> proc var "sync_qlen_max" that should be changed to >>> sizeof(unsigned long) and updated with proc_doulongvec_minmax. >>> >> >> Thanks for pointing this. I will update this in patch v2. > > Hi Zhang, > > Thanks for helping to keep IPVS up to date. > > It seems to me that include/net/ip_vs.h:sysctl_sync_qlen_max() > and its call site, net/netfilter/ipvs/ip_vs_sync.c:sb_queue_tail() > may also need to be updated. > > Could you look at including that in v2 too? OK. I will update it. Thanks Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] hlist: drop the node parameter from iterators
On 2013/2/7 9:00, Tejun Heo wrote:
> (cc'ing Li)
>
> On Wed, Feb 6, 2013 at 4:55 PM, Andrew Morton
> wrote:
>> Problems in cgroup_load_subsys().
>>
>> In linux-next, that function is now using the `node' storage which your
>> patch removes:
>>
>> @@ -4503,23 +4525,17 @@ int __init_or_module cgroup_load_subsys(struct
>> cgroup_subsys *ss)
>> * this is all done under the css_set_lock.
>> */
>> write_lock(_set_lock);
>> - for (i = 0; i < CSS_SET_TABLE_SIZE; i++) {
>> - struct css_set *cg;
>> - struct hlist_node *node, *tmp;
>> - struct hlist_head *bucket = _set_table[i], *new_bucket;
>> -
>> - hlist_for_each_entry_safe(cg, node, tmp, bucket, hlist) {
>> - /* skip entries that we already rehashed */
>> - if (cg->subsys[ss->subsys_id])
>> - continue;
>> - /* remove existing entry */
>> - hlist_del(>hlist);
>> - /* set new value */
>> - cg->subsys[ss->subsys_id] = css;
>> - /* recompute hash and restore entry */
>> - new_bucket = css_set_hash(cg->subsys);
>> - hlist_add_head(>hlist, new_bucket);
>> - }
>> + hash_for_each_safe(css_set_table, i, node, tmp, cg, hlist) {
>> + /* skip entries that we already rehashed */
>> + if (cg->subsys[ss->subsys_id])
>> + continue;
>> + /* remove existing entry */
>> + hash_del(>hlist);
>> + /* set new value */
>> + cg->subsys[ss->subsys_id] = css;
>> + /* recompute hash and restore entry */
>> + key = css_set_hash(cg->subsys);
>> + hash_add(css_set_table, node, key); here
>> }
>> write_unlock(_set_lock);
>>
>>
>>
>> This didn't show up (apart from a "used unintialized" warning) because
>> your patch forgot to remove the definition of `node'.
>>
>> I did this. Tejun, could you please opine?
>>
>>
>> @@ -4456,7 +4455,7 @@ int __init_or_module cgroup_load_subsys(
>> {
>> struct cgroup_subsys_state *css;
>> int i, ret;
>> - struct hlist_node *node, *tmp;
>> + struct hlist_node *tmp;
>> struct css_set *cg;
>> unsigned long key;
>>
>> @@ -4534,7 +4533,7 @@ int __init_or_module cgroup_load_subsys(
>> cg->subsys[ss->subsys_id] = css;
>> /* recompute hash and restore entry */
>> key = css_set_hash(cg->subsys);
>> - hash_add(css_set_table, node, key);
>> + hash_add(css_set_table, >hlist, key);
>> }
>> write_unlock(_set_lock);
>
> Yeah, looks correct & better to me. Li?
>
obviously correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: max8997: Add driver for max8997 rtc.
On 2013년 02월 07일 06:06, Andrew Morton wrote: > On Wed, 06 Feb 2013 20:23:05 +0900 > Jonghwa Lee wrote: > >> This patch adds rtc driver for Maxim 8997 multifunction chip. >> Max8997 has rtc module in it. and it can be used for timekeeping >> clock and system alarm. It provide various operational mode those are >> BCD/binary, 24/12hour, am/pm. Driver sets binary/24/ for default. >> Maxim 8997 also supports SMPL(Sudden Momentary Power Loss), WTSR >> (Watchdog Timeout and Software Reset). >> >> ... >> >> --- a/drivers/rtc/Kconfig >> +++ b/drivers/rtc/Kconfig >> @@ -233,6 +233,36 @@ config RTC_DRV_MAX8998 >>This driver can also be built as a module. If so, the module >>will be called rtc-max8998. >> >> +config RTC_DRV_MAX8997 >> +tristate "Maxim MAX8997" >> +depends on MFD_MAX8997 >> +help >> + If you say yes here you will get support for the >> + RTC of Maxim MAX8997 PMIC. >> + >> + This driver can also be built as a module. If so, the module >> + will be called rtc-max8997. >> + >> +config MAX8997_RTC_WTSR >> +bool "MAX8997_RTC_WTSR" >> +depends on RTC_DRV_MAX8997 >> +help >> + MAX8997 rtc can supports WTSR(Watchdog Timeout and Software Reset). >> + WTSR event would keep the PMIC on regardless of PWRHOLD signal. >> + When PWRHOLD signal is falling, it turns on WTSR timer rather executes >> + reset imidiately. After timer expiring, it determine to reset the PMIC >> + depends on PWRHOLD state. >> + >> +config MAX8997_RTC_SMPL >> +bool "MAX8997_RTC_SMPL" >> +depends on RTC_DRV_MAX8997 >> +help >> + MAX8997 rtc can supports SMPL(Sudden Momentary Power Loss). >> + SMPL function can be used to intiate a power up sequence after >> momentarily >> + loosing contact to the battery pack. If battery goes under UVLO(Under >> + Lock Out) it starts SMPL timer. After timer exipiring, it checks >> battery >> + whether its state recovers from UVLO or not to make power supplies >> keep on. > > Can we avoid creating CONFIG_MAX8997_RTC_WTSR and > CONFIG_MAX8997_RTC_SMPL? It would be much better for the users if > these features were always available in all kernel builds. > Okay, I'll apply it. > The best way of handling this sort of thing is for the driver to probe > the hardware, work out its capabilities and "do the right thing". > > The second best way is to require that the user add certain module > parameters to enable the functionality. > How do we create sysfs node for enabling these options? Thanks, Jonghwa > The worst way is to require the user to make the decision at kernel > build time! > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: arg2 is unsigned long which is never < 0
于 2013年02月07日 03:41, Kees Cook 写道: > Well, it seems we'd need to add an include to gain access to binfmts.h > in once place, but that doesn't seem bad. I'll send to patch to clean > this up. thank you. and after your patch is integrated into main branch (at least in next-* branch), I should send patch v2 for it, too. and excuse me I will 'disappear' during next 7-10 days for Chinese Year (Spring Festival). during these days, welcome any members to send patch v2 instead of me (better to mark Reported-by Cyrill Gorcunov , too) thanks. :-) -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: caam - set RDB bit in security configuration register
On Wed, 6 Feb 2013 17:17:46 +0530 Vakul Garg wrote: > This change is required for post SEC-5.0 devices which have RNG4. Setting RDB wrap your commit message text to 75 chars > in security configuration register allows CAAM to use the "Random Data Buffer" > to be filled by a single request. The Random Data Buffer is large enough for > ten packets to get their IVs from a single request. If the Random Data Buffer > is not enabled, then each IV causes a separate request, and RNG4 hardware > cannot keep up resulting in lower IPSEC throughput. Linux kernel IPSec or another IPSEC stack? how much lower? > + if (of_device_is_compatible(nprop, "fsl,sec-v5.0")) > + setbits32(>ctrl.scfgr, SCFGR_RDBENABLE); > + this belongs further down - at the end of the RNG4 initialization section. Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/77] cgroup: don't use idr_remove_all()
On 2013/2/7 3:39, Tejun Heo wrote: > idr_destroy() can destroy idr by itself and idr_remove_all() is being > deprecated. Drop its usage. > > Signed-off-by: Tejun Heo Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Perf Script: Add a python script to statistic direct io behavior
From: chenggang@taobao.com The last version of this patch need to introduce 2 new tracepoint events in VFS, but introduce new tracepoint events into VFS is not a clever idea. So, I modified this patch, and only use a existing tracepoint event (ext4:ext4_direct_IO_exit). If the engineers want to analyze the direct io behavior of some applications without source code, perf tools with some appropriate tracepoints events in the VFS subsystem are excellent choice. Many database systems use their own page cache subsystems and use the direct IO to access the disks. Sometimes, the system engineers need to know the misses rate of the database system's page cache. This requirements can be satisfied by recording the database's file access behavior through the way of direct IO. So, we use tracepoint event, ext4:ext4_direct_IO_exit, to record the system wide's direct IO behavior. The script direct-io.py are introduced by this patch can record the tracepoint events, ext4:ext4_direct_IO_exit, analyse the sample data, and give a concise report. usage: "perf script record direct-io\n" "perf script report direct-io [comm|pid]\n" Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Arjan van de Ven Cc: Namhyung Kim Cc: Yanmin Zhang Cc: Wu Fengguang Cc: Mike Galbraith Cc: Andrew Morton Signed-off-by: Chenggang Qin --- tools/perf/scripts/python/bin/direct-io-record |2 + tools/perf/scripts/python/bin/direct-io-report | 21 +++ tools/perf/scripts/python/direct-io.py | 197 3 files changed, 220 insertions(+) create mode 100755 tools/perf/scripts/python/bin/direct-io-record create mode 100644 tools/perf/scripts/python/bin/direct-io-report create mode 100644 tools/perf/scripts/python/direct-io.py diff --git a/tools/perf/scripts/python/bin/direct-io-record b/tools/perf/scripts/python/bin/direct-io-record new file mode 100755 index 000..f38d5fc --- /dev/null +++ b/tools/perf/scripts/python/bin/direct-io-record @@ -0,0 +1,2 @@ +#!/bin/bash +perf record -e ext4:ext4_direct_IO_exit $@ diff --git a/tools/perf/scripts/python/bin/direct-io-report b/tools/perf/scripts/python/bin/direct-io-report new file mode 100644 index 000..828d9c6 --- /dev/null +++ b/tools/perf/scripts/python/bin/direct-io-report @@ -0,0 +1,21 @@ +#!/bin/bash +# description: direct_io statistic +# args: [comm|pid] +n_args=0 +for i in "$@" +do +if expr match "$i" "-" > /dev/null ; then + break +fi +n_args=$(( $n_args + 1 )) +done +if [ "$n_args" -gt 1 ] ; then +echo "usage: perf script report direct-io [comm|pid]" +exit +fi + +if [ "$n_args" -gt 0 ] ; then +comm=$1 +shift +fi +perf script $@ -s "$PERF_EXEC_PATH"/scripts/python/direct-io.py $comm diff --git a/tools/perf/scripts/python/direct-io.py b/tools/perf/scripts/python/direct-io.py new file mode 100644 index 000..b609e95 --- /dev/null +++ b/tools/perf/scripts/python/direct-io.py @@ -0,0 +1,197 @@ +# direct IO counts +# (c) 2013, Chenggang Qin +# Licensed under the terms of the GNU GPL License version 2 + +# Displays system-wide file direct IO behavior. +# It helps us to investigate which processes trigger a direct IO, +# and what files are accessed by these processes. +# +# options +# comm, pid: show details of the file r/w behavior of a special process. + +import os, sys + +sys.path.append(os.environ['PERF_EXEC_PATH'] + \ + '/scripts/python/Perf-Trace-Util/lib/Perf/Trace') + +from perf_trace_context import * +from Core import * +from Util import * + +MINORBITS = 20 +MINORMASK = ((1 << MINORBITS) - 1) + +usage = "perf script record direct-io\n" \ + "perf script report direct-io [comm|pid]\n" + +for_comm = None +for_pid = None +pid_2_comm = None + +if len(sys.argv) > 2: + sys.exit(usage) + +if len(sys.argv) > 1: + try: + for_pid = int(sys.argv[1]) + except: + for_comm = sys.argv[1] + +direct_write = autodict() +direct_read = autodict() + +direct_write_bytes = autodict() +direct_read_bytes = autodict() + +comm_read_info = autodict() +comm_write_info = autodict() + +wevent_count = 0 +revent_count = 0 + +comm_revent_count = 0; +comm_wevent_count = 0; + +def MAJOR(dev): + return (dev) >> MINORBITS + +def MINOR(dev): + return (dev) & MINORMASK + +def trace_begin(): + print "Press control+C to stop and show the summary" + +def trace_end(): + if (for_comm is not None) or (for_pid is not None): + print_direct_io_event_for_comm() + else: + print_direct_io_event_totals() + +def ext4__ext4_direct_IO_exit(event_name, context, common_cpu, + common_secs, common_nsecs, common_pid, common_comm, + ino, dev, pos, len, rw, ret): + global wevent_count + global comm_wevent_count + global pid_2_comm + + if rw is 1: #write + if (for_comm is not None) or (for_pid is not None): +
