Re: [PATCH] coccinelle: add pycocci wrapper for multithreaded support
> I checked the profile results, the reason the jobs finish is some threads > had no work or little work. Could you find out during the data processing which parts or files result in a special application behaviour you would like to point out here? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Chanwoo, On 11 April 2014 11:24, Chanwoo Choi wrote: > Hi Sachin, > > On 04/11/2014 12:56 PM, Sachin Kamat wrote: >> Hi Chanwoo, >> >> On 10 April 2014 15:07, Chanwoo Choi wrote: >>> This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that >>> is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses >>> Cortex-A7 >>> dual cores and has a target speed of 1.0GHz. >>> >>> Signed-off-by: Chanwoo Choi >>> Signed-off-by: Kyungmin Park >>> --- >>> arch/arm/mach-exynos/Kconfig | 22 ++ >>> arch/arm/mach-exynos/exynos.c| 1 + >>> arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ >>> 3 files changed, 33 insertions(+) >>> >>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig >>> index fc8bf18..6da8a68 100644 >>> --- a/arch/arm/mach-exynos/Kconfig >>> +++ b/arch/arm/mach-exynos/Kconfig >>> @@ -11,6 +11,17 @@ if ARCH_EXYNOS >>> >>> menu "SAMSUNG EXYNOS SoCs Support" >>> >>> +config ARCH_EXYNOS3 >>> + bool "SAMSUNG EXYNOS3" >>> + select ARM_AMBA >>> + select CLKSRC_OF >>> + select HAVE_ARM_SCU if SMP >>> + select HAVE_SMP >>> + select PINCTRL >>> + select PM_GENERIC_DOMAINS if PM_RUNTIME >>> + help >>> + Samsung EXYNOS3 SoCs based systems >>> + >>> config ARCH_EXYNOS4 >>> bool "SAMSUNG EXYNOS4" >>> default y >>> @@ -41,6 +52,17 @@ config ARCH_EXYNOS5 >>> >>> comment "EXYNOS SoCs" >>> >>> +config SOC_EXYNOS3250 >>> + bool "SAMSUNG EXYNOS3250" >>> + default y >>> + depends on ARCH_EXYNOS3 >>> + select ARCH_HAS_BANDGAP >>> + select ARM_CPU_SUSPEND if PM >>> + select PINCTRL_EXYNOS >>> + select SAMSUNG_DMADEV >>> + help >>> + Enable EXYNOS3250 CPU support >> >> There is a Kconfig consolidation patch submitted by me [1]. Please base your >> code on that one to avoid merge conflicts. >> >> [1] http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642 >> > > Your patch is applied? I can't find merged patch on linux-samsung.git and > arm-soc.git. > If this patch is applied, I will rebase this patchset. Thanks. This patch hasn't been merged yet but has been agreed upon by Kukjin, Tomasz and others. You may follow the mailing list for details. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Sachin, On 04/11/2014 12:56 PM, Sachin Kamat wrote: > Hi Chanwoo, > > On 10 April 2014 15:07, Chanwoo Choi wrote: >> This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that >> is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses >> Cortex-A7 >> dual cores and has a target speed of 1.0GHz. >> >> Signed-off-by: Chanwoo Choi >> Signed-off-by: Kyungmin Park >> --- >> arch/arm/mach-exynos/Kconfig | 22 ++ >> arch/arm/mach-exynos/exynos.c| 1 + >> arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ >> 3 files changed, 33 insertions(+) >> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig >> index fc8bf18..6da8a68 100644 >> --- a/arch/arm/mach-exynos/Kconfig >> +++ b/arch/arm/mach-exynos/Kconfig >> @@ -11,6 +11,17 @@ if ARCH_EXYNOS >> >> menu "SAMSUNG EXYNOS SoCs Support" >> >> +config ARCH_EXYNOS3 >> + bool "SAMSUNG EXYNOS3" >> + select ARM_AMBA >> + select CLKSRC_OF >> + select HAVE_ARM_SCU if SMP >> + select HAVE_SMP >> + select PINCTRL >> + select PM_GENERIC_DOMAINS if PM_RUNTIME >> + help >> + Samsung EXYNOS3 SoCs based systems >> + >> config ARCH_EXYNOS4 >> bool "SAMSUNG EXYNOS4" >> default y >> @@ -41,6 +52,17 @@ config ARCH_EXYNOS5 >> >> comment "EXYNOS SoCs" >> >> +config SOC_EXYNOS3250 >> + bool "SAMSUNG EXYNOS3250" >> + default y >> + depends on ARCH_EXYNOS3 >> + select ARCH_HAS_BANDGAP >> + select ARM_CPU_SUSPEND if PM >> + select PINCTRL_EXYNOS >> + select SAMSUNG_DMADEV >> + help >> + Enable EXYNOS3250 CPU support > > There is a Kconfig consolidation patch submitted by me [1]. Please base your > code on that one to avoid merge conflicts. > > [1] http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642 > Your patch is applied? I can't find merged patch on linux-samsung.git and arm-soc.git. If this patch is applied, I will rebase this patchset. Thanks. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/10] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file
On 04/02/2014 08:27 PM, Sylwester Nawrocki wrote: Hi, On 02/04/14 09:50, Pankaj Dubey wrote: From: Young-Gun Jang While making PMU (Power Mengement Unit) implementation device tree based, there are few offsets related with SYSREG present in regs-pmu.h, so let's make a new header file "regs-sys.h" to keep all such SYSREG related register definition and remove them from "regs-pmu.h" Signed-off-by: Young-Gun Jang Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/exynos.c |1 + arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/regs-pmu.h |3 --- arch/arm/mach-exynos/regs-sys.h | 22 ++ 4 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-exynos/regs-sys.h [...] diff --git a/arch/arm/mach-exynos/regs-sys.h b/arch/arm/mach-exynos/regs-sys.h new file mode 100644 index 000..84332b0 --- /dev/null +++ b/arch/arm/mach-exynos/regs-sys.h @@ -0,0 +1,22 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * EXYNOS - system register definition + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#ifndef __ASM_ARCH_REGS_SYS_H +#define __ASM_ARCH_REGS_SYS_H __FILE__ + +#include + +#define S5P_SYSREG(x) (S3C_VA_SYS + (x)) + +/* For EXYNOS5 */ +#define EXYNOS5_SYS_I2C_CFGS5P_SYSREG(0x0234) Can this be defined as a regular register offset in a header file placed at include/linux/mfd/syscon/ ? I.e. can the mfd syscon driver be used instead of these hacks ? No. As currently SysRegs are being accessed via iodesc table and not via DT, it has dependency on "mach/map.h". We separated these definitions from "regs-pmu.h" as it does not belong to EXYNOS PMU IP. But this can be done once we make some way of accessing SysReg register sets via DT. -- Best Regards, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] pci: added or removed a space to resolve checkpatch message
changes made to resolve following messages:
WARNING: please, no spaces at the start of a line
ERROR: space prohibited after that '!' (ctx:BxW)
ERROR: space required before the open parenthesis '('
Signed-off-by: Ryan Desfosses
---
drivers/pci/pci.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fdbc294..20bcb1a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -114,7 +114,7 @@ unsigned char pci_bus_max_busnr(struct pci_bus* bus)
max = bus->busn_res.end;
list_for_each(tmp, >children) {
n = pci_bus_max_busnr(pci_bus_b(tmp));
- if(n > max)
+ if (n > max)
max = n;
}
return max;
@@ -489,7 +489,7 @@ static inline bool platform_pci_power_manageable(struct
pci_dev *dev)
}
static inline int platform_pci_set_power_state(struct pci_dev *dev,
-pci_power_t t)
+ pci_power_t t)
{
return pci_platform_pm ? pci_platform_pm->set_state(dev, t) : -ENOSYS;
}
@@ -1431,7 +1431,7 @@ void pcim_pin_device(struct pci_dev *pdev)
* devices are added. This is the default implementation. Architecture
* implementations can override this.
*/
-int __weak pcibios_add_device (struct pci_dev *dev)
+int __weak pcibios_add_device(struct pci_dev *dev)
{
return 0;
}
@@ -1454,7 +1454,7 @@ void __weak pcibios_release_device(struct pci_dev *dev) {}
* is the default implementation. Architecture implementations can
* override this.
*/
-void __weak pcibios_disable_device (struct pci_dev *dev) {}
+void __weak pcibios_disable_device(struct pci_dev *dev) {}
static void do_pci_disable_device(struct pci_dev *dev)
{
@@ -2565,7 +2565,7 @@ static int __pci_request_selected_regions(struct pci_dev
*pdev, int bars,
return 0;
err_out:
- while(--i >= 0)
+ while (--i >= 0)
if (bars & (1 << i))
pci_release_region(pdev, i);
@@ -2798,7 +2798,7 @@ pci_set_mwi(struct pci_dev *dev)
return rc;
pci_read_config_word(dev, PCI_COMMAND, );
- if (! (cmd & PCI_COMMAND_INVALIDATE)) {
+ if (!(cmd & PCI_COMMAND_INVALIDATE)) {
dev_dbg(>dev, "enabling Mem-Wr-Inval\n");
cmd |= PCI_COMMAND_INVALIDATE;
pci_write_config_word(dev, PCI_COMMAND, cmd);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] drivers: mfd: Add support of exynos-pmu driver
Hi Bartlomiej,
Thanks for review.
On 04/03/2014 08:56 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday, April 02, 2014 05:24:44 PM Pankaj Dubey wrote:
From: Younggun Jang
This driver is mainly used for setting misc bits of register from PMU IP
of Exynos SoC which will be required to configure before Suspend/Resume.
Currently all these settings are done in "arch/arm/mach-exynos/pmu.c" but
moving ahead for ARM64 based SoC support, there is a need of DT based
implementation of PMU driver.
PMU support for ARM32 EXYNOS SoCs is heavily SoC dependent and there
is very little code shared between diffirent SoCs. Unless PMU setup
for Samsung ARM64 SoCs is similar to some existing ARM32 EXYNOS SoCs
it may be better to just add a separate PMU driver for Samsung ARM64
SoCs. IOW it would be best to show that this patch series is really
useful before merging it.
We think it will be useful, but I will consider your point of making driver
which should have common piece of code to address various EXYNOS SoCs.
We are working on it, once it takes some proper shape I will post details here.
When it comes to the current patches it would be better to do changes
converting PMU support to be a platform driver first for the existing
arch/arm/mach-exynos/pmu.c file and then move+rename this file in
the separate patch. Currently the code changes are done at the same
time as the code movement which makes them difficult to review/verify.
OK, will do as you suggested in next version.
There are also some minor issues with the new code:
[...]
diff --git a/drivers/mfd/exynos-pmu.c b/drivers/mfd/exynos-pmu.c
new file mode 100644
index 000..24abd9b
--- /dev/null
+++ b/drivers/mfd/exynos-pmu.c
@@ -0,0 +1,534 @@
+/*
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
2015?
Will fix this.
[...]
+static int __init exynos4210_pmu_init(void)
+{
+ exynos_pmu_config = exynos4210_pmu_config;
+ pmu_data->pmu_id = PMU_EXYNOS4210;
+ pr_info("EXYNOS4210 PMU Initialize\n");
+
+ return 0;
+}
+
+static int __init exynos4212_pmu_init(void)
+{
+ exynos_pmu_config = exynos4x12_pmu_config;
+ pmu_data->pmu_id = PMU_EXYNOS4212;
+ pr_info("EXYNOS4x12 PMU Initialize\n");
+
+ return 0;
+}
+
+static int __init exynos4412_pmu_init(void)
+{
+ exynos_pmu_config = exynos4x12_pmu_config;
+ pmu_data->pmu_id = PMU_EXYNOS4412;
+ pr_info("EXYNOS4412 PMU Initialize\n");
+
+ return 0;
+}
+
+static int __init exynos5250_pmu_init(void)
+{
+ unsigned int value;
+
+ /*
+* When SYS_WDTRESET is set, watchdog timer reset request
+* is ignored by power management unit.
+*/
+ value = __raw_readl(pmu_data->regs + EXYNOS5_AUTO_WDTRESET_DISABLE);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ __raw_writel(value, pmu_data->regs + EXYNOS5_AUTO_WDTRESET_DISABLE);
+
+ value = __raw_readl(pmu_data->regs + EXYNOS5_MASK_WDTRESET_REQUEST);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ __raw_writel(value, pmu_data->regs + EXYNOS5_MASK_WDTRESET_REQUEST);
+
+ exynos_pmu_config = exynos5250_pmu_config;
+ pmu_data->pmu_id = PMU_EXYNOS5250;
+ pr_info("EXYNOS5250 PMU Initialize\n");
+
+ return 0;
+}
+
+/*
+ * PMU platform driver and devicetree bindings.
+ */
+static struct of_device_id exynos_pmu_of_device_ids[] = {
+ {
+ .compatible = "samsung,exynos4210-pmu",
+ .data = (void *)exynos4210_pmu_init
+ },
+ {
+ .compatible = "samsung,exynos4212-pmu",
+ .data = (void *)exynos4212_pmu_init
+ },
+ {
+ .compatible = "samsung,exynos4412-pmu",
+ .data = (void *)exynos4412_pmu_init
+ },
+ {
+ .compatible = "samsung,exynos5250-pmu",
+ .data = (void *)exynos5250_pmu_init
+ },
+ {},
+};
+
+static int exynos_pmu_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ exynos_pmu_init_t exynos_pmu_init;
+ struct resource *res;
+
+ pmu_data = devm_kzalloc(>dev,
+ sizeof(struct exynos_pmu_data), GFP_KERNEL);
+ if (!pmu_data) {
+ dev_err(>dev, "exynos_pmu driver probe failed\n");
+ return -ENOMEM;
+ }
+
+ pmu_data->dev = >dev;
+
+ match = of_match_node(exynos_pmu_of_device_ids, pdev->dev.of_node);
+ exynos_pmu_init = match->data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pmu_data->regs = devm_ioremap_resource(>dev, res);
devm_ioremap_resouce() return value should be checked for errors with
if (IS_ERR(pmu_data->regs))
return PTR_ERR(pmu_data->regs);
Will take care.
+
+ exynos_pmu_init();
exynos*_pmu_init() methods should be void as they always return 0 and
the return value is ignored anyway.
Also they cannot be marked with __init as the driver probe function
Re: [PATCH 04/27] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
Hi,
On 04/11/2014 10:44 AM, Olof Johansson wrote:
> On Thu, Apr 10, 2014 at 06:37:15PM +0900, Chanwoo Choi wrote:
>> From: Kyungmin Park
>>
>> This patch fix the offset of CPU boot address and change parameter of smc
>> call
>> of SMC_CMD_CPU1BOOT command for Exynos4212.
>>
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/firmware.c | 14 --
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/firmware.c
>> b/arch/arm/mach-exynos/firmware.c
>> index 932129e..91a911d 100644
>> --- a/arch/arm/mach-exynos/firmware.c
>> +++ b/arch/arm/mach-exynos/firmware.c
>> @@ -18,6 +18,8 @@
>>
>> #include
>>
>> +#include
>> +
>> #include "smc.h"
>>
>> static int exynos_do_idle(void)
>> @@ -28,14 +30,22 @@ static int exynos_do_idle(void)
>>
>> static int exynos_cpu_boot(int cpu)
>> {
>> -exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>> +if (soc_is_exynos4212())
>> +exynos_smc(SMC_CMD_CPU1BOOT, 0, 0, 0);
>> +else
>> +exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
>
> /* */
It's better to ask system lsi person. We don't know it well.
I got the guide about secondary boot from system lsi.
But, this patch was completely tested.
> if (soc_is_exynos4212())
> cpu = 0;
>
> ...and then do the call as before.
OK, I'll modify it as following:
static int exynos_cpu_boot(int cpu)
{
+ if (soc_is_exynos4212())
+ cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
>
>
>> return 0;
>> }
>>
>> static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
>> {
>> -void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
>> +void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>>
>> +if (soc_is_exynos4212())
>> +goto out;
>> +else
>> +boot_reg += 4*cpu;
>
> if (!soc_is_exynos4212())
> boot_reg += 4 * cpu;
>
> That way you avoid a goto, especially since the "goto out" isn't actually
> an "out", it's still doing stuff at the end of the funciton.
>
OK, I'll remove goto statement and then modify it as your comment.
- void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
aic94xx: maybe uninitialized variable in asd_process_ctrl_a_user
Hi James, While building a recent kernel with -Werror I found this warning: drivers/scsi/aic94xx/aic94xx_sds.c: In function 'asd_read_flash': drivers/scsi/aic94xx/aic94xx_sds.c:597:21: error: 'offs' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/aic94xx/aic94xx_sds.c:985:6: note: 'offs' was declared here This looks like a valid complaint from the compiler, since in asd_process_ctrl_a_user if the call to asd_find_flash_de fails (and returns -ENOENT) then offs will not be set, but that will not prevent the variable to be later passed to the call to asd_read_flash_seg later in that same function. Would you please have a look at it? Let me know if there's a more appropriate way to report these issues (e.g. bug tracker.) Thanks, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [writeback] 6903673566d: +2.5% fileio.requests_per_sec
On Thu, Apr 10, 2014 at 09:27:51PM +0200, Jan Kara wrote: > On Thu 10-04-14 21:05:52, Wu Fengguang wrote: > > On Thu, Apr 10, 2014 at 08:41:37PM +0800, Fengguang Wu wrote: > > Here are the changed stats before/after the patchset: > Thanks for gathering the numbers! > > > v3.14-rc8 ea87e2e7e0905325c58cf5643 > > --- - > > 58.98 ~102% -73.2% 15.78 > > snb-drag/sysbench/fileio/600s-100%-1HDD-ext4-64G-1024-rndwr-sync > >2215.64 ~61% -69.2% 682.57 > > snb-drag/sysbench/fileio/600s-100%-1HDD-ext4-64G-1024-seqrewr-sync > > 185.22 ~132% -93.6% 11.80 > > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-rndwr-sync > >2459.84 ~67% -71.1% 710.15 TOTAL > > fileio.request_latency_max_ms > > > > v3.14-rc8 ea87e2e7e0905325c58cf5643 > > --- - > > 6251 ~ 0% +4.0% 6503 > > snb-drag/sysbench/fileio/600s-100%-1HDD-ext4-64G-1024-seqrewr-sync > > 6532 ~ 0% +3.2% 6737 ~ 0% > > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync > > 6444 ~ 0% +1.7% 6554 ~ 0% > > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqwr-sync > > 19227 ~ 0% +3.0% 19795 TOTAL fileio.requests_per_sec > > > So fileio got better latency and higher requests per second. That's good. > ... > > > v3.14-rc8 ea87e2e7e0905325c58cf5643 > > --- - > > 397285 ~ 0% -6.9% 369872 ~ 0% > > lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd > > 359312 ~ 0% -5.5% 339685 > > lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-xfs-100dd > > 404981 ~ 0% -4.5% 386775 > > lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd > >1161579 ~ 0% -5.6%1096334 TOTAL iostat.md0.wkB/s > So dd writing tests got lower throughput reported by iostat. I'll try to > have a look whether I can reproduce that. BTW: Does that also correspond to > longer time-to-completion of the dd test? Nope, there are no noticeable changes for time.elapsed_time: v3.14-rc8 ea87e2e7e0905325c58cf5643 --- - 601.99 ~ 0% +0.0% 602.07 ~ 0% lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd 630.92 ~ 0% -0.9% 625.24 lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-100dd 615.98 ~ 0% -0.2% 614.74 lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd 610.58 ~ 0% -0.1% 609.92 ~ 0% lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd 608.90 ~ 0% +0.0% 609.09 lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-xfs-100dd 604.46 ~ 0% +0.0% 604.66 lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-xfs-10dd 603.67 ~ 0% +0.0% 603.70 lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-xfs-1dd 606.65 ~ 0% +0.0% 606.93 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-ext4-100dd 606.31 ~ 0% +0.0% 606.49 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-ext4-10dd 602.97 ~ 0% -0.2% 601.89 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-ext4-1dd 603.92 ~ 0% -0.2% 603.01 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-xfs-100dd 602.66 ~ 0% -0.0% 602.63 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd 602.19 ~ 0% +0.2% 603.52 lkp-ws02/micro/dd-write/11HDD-RAID5-cfq-xfs-1dd > > > v3.14-rc8 ea87e2e7e0905325c58cf5643 > > --- - > >1.2e+08 ~ 0% +4.0% 1.249e+08 > > snb-drag/sysbench/fileio/600s-100%-1HDD-ext4-64G-1024-seqrewr-sync > > 1.254e+08 ~ 0% +3.1% 1.294e+08 ~ 0% > > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync > > 1.237e+08 ~ 0% +1.7% 1.259e+08 ~ 0% > > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqwr-sync > > 3.692e+08 ~ 0% +3.0% 3.801e+08 TOTAL time.file_system_outputs > What's this measuring? It corresponds to the "File system outputs" line in the below output. It should be the number of dirtied pages. % /usr/bin/time -v sleep 1 Command being timed: "sleep 1" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2608 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 213 Voluntary context switches: 2 Involuntary context switches: 1 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals
Re: [PATCH v7 4/6] pci: Introduce a domain number for pci_host_bridge.
On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote: > Half of it ;-) > > I think it would be better to not have an architecture specific data > structure, just like it would be better not to have architecture specific > pcibios_* functions that get called by the PCI core. Note that the > architecture specific functions are the ones that rely on the architecture > specific data structures as well. If they only use the common fields, > it should also be possible to share the code. I don't understand... we'll never get rid of architecture specific hooks in one form or another. We'll always need to some things in an architecture or host-bridge specific way. Now if you don't want to call them arch hooks, then call them host bridge ops, but they are needed and thus they will need some kind of architecture specific extension to the base host bridge structure. EEH is one big nasty example on powerpc. Another random one that happens to be hot in my brain right now because we just finished debugging it: On powernv, we are just fixing a series of bugs caused by the generic code trying to do hot resets on PCIe "by hand" by directly toggling the secondary reset register in bridges. Well, on our root complexes, this triggers a link loss which triggers a fatal EEH "ER_all" interrupt which we escalate into a fence and all hell breaks loose. We need to mask some error traps in the hardware before doing something that can cause an intentional link loss... and unmask them when done. (Among other things, there are other issues on P7 with hot reset). So hot reset must be an architecture hook. PERST (fundamental reset) can *only* be a hook. The way to generate a PERST is not specified. In fact, on our machines, we have special GPIOs we can use to generate PERST on individual slots below a PLX bridge and a different methods for slots directly on a PHB. Eventually most of those hooks land into firmware, and as such it's akin to ACPI which also keeps a separate state structure and a pile of hooks. > I also don't realistically think we can get there on a lot of architectures > any time soon. Note that most architectures only have one PCI host > implementation, so the architecture structure is the same as the host > driver structure anyway. > > For architectures like powerpc and arm that have people actively working > on them, we have a chance to clean up that code in the way we want it > (if we can agree on the direction), but it's still not trivial to do. > > Speaking of arm32 in particular, I think we will end up with a split > approach: modern platforms (multiplatform, possibly all DT based) using > PCI core infrastructure directly and no architecture specific PCI > code on the one side, and a variation of today's code for the legacy > platforms on the other. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] pci: changed "foo* bar" to "foo *bar"
change made to resolve following checkpatch message:
drivers/pci/pci.c:109: ERROR: "foo* bar" should be "foo *bar"
branch: Linux 3.14-rc8
Signed-off-by: Ryan Desfosses
---
drivers/pci/pci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fdbc294..4070a60 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -106,7 +106,7 @@ static bool pcie_ari_disabled;
* Given a PCI bus, returns the highest PCI bus number present in the set
* including the given PCI bus and its list of child PCI buses.
*/
-unsigned char pci_bus_max_busnr(struct pci_bus* bus)
+unsigned char pci_bus_max_busnr(struct pci_bus *bus)
{
struct list_head *tmp;
unsigned char max, n;
@@ -1359,7 +1359,7 @@ static void pcim_release(struct device *gendev, void *res)
pci_disable_device(dev);
}
-static struct pci_devres * get_pci_dr(struct pci_dev *pdev)
+static struct pci_devres *get_pci_dr(struct pci_dev *pdev)
{
struct pci_devres *dr, *new_dr;
@@ -1373,7 +1373,7 @@ static struct pci_devres * get_pci_dr(struct pci_dev
*pdev)
return devres_get(>dev, new_dr, NULL, NULL);
}
-static struct pci_devres * find_pci_dr(struct pci_dev *pdev)
+static struct pci_devres *find_pci_dr(struct pci_dev *pdev)
{
if (pci_is_managed(pdev))
return devres_find(>dev, pcim_release, NULL, NULL);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] introduce devm_mdiobus_alloc/devm_mdiobus_free
Hi Grygorii, 2014-04-04 6:40 GMT-07:00 Grygorii Strashko : > Introduce a resource managed devm_mdiobus_alloc()/devm_mdiobus_free() > to automatically clean up MDIO bus alocations made by MDIO drivers, > thus leading to simplified MDIO drivers code. > > Update Davinci MDIO driver ss example of new devm APIs usage. This does look good at first glance. net-next is currently closed at the moment, so this will have to be merged later. At some point, we might also want to handle the mdio_bus irq array, as that one is also usually dynamically allocated. Maybe we could just do a static irq[PHY_MAX_ADDR] allocation, 32 times the size of an integer might not be worth a potential leak. > > Grygorii Strashko (2): > mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free > net: davinci_mdio: use devm_* api > > Documentation/driver-model/devres.txt |4 ++ > drivers/net/ethernet/ti/davinci_mdio.c | 21 ++ > drivers/net/phy/mdio_bus.c | 68 > > include/linux/phy.h|2 + > 4 files changed, 78 insertions(+), 17 deletions(-) > > -- > 1.7.9.5 > -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] FS: Add generic data flush to fsync
Currently, there's no generic HW flush management support in kernel.
Only 7 filesystems have their own way to manage the barrier flag.
This patch adds MS_BARRIER in sb_flags and conditionnaly issues the flush
in generic_file_fsync.
That option would be enabled from userspace mount tool.
(-As discussed with Jan, we could add barrier/no barrier in older filesystems
but this would mix both filesystem and vfs barrier terminology plus
generic_file_fsync does not have access to FS sbi.
-Some modern FS will be involved as well ; eg no journal ext4 partitions.
)
Cc: Jan Kara
Cc: linux-fsde...@vger.kernel.org
Suggested-by: Jan Kara
Reviewed-by: Jan Kara
Signed-off-by: Fabian Frederick
---
fs/libfs.c | 7 +++
include/uapi/linux/fs.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c
index a184424..21983d9 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -3,6 +3,7 @@
* Library for filesystems writers.
*/
+#include
#include
#include
#include
@@ -952,6 +953,12 @@ int generic_file_fsync(struct file *file, loff_t start,
loff_t end,
err = sync_inode_metadata(inode, 1);
if (ret == 0)
ret = err;
+ if (inode->i_sb->s_flags & MS_BARRIER) {
+ err = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+ if (ret == 0)
+ ret = err;
+ }
+
out:
mutex_unlock(>i_mutex);
return ret;
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index ca1a11b..7c14ebd 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -89,6 +89,7 @@ struct inodes_stat_t {
#define MS_KERNMOUNT (1<<22) /* this is a kern_mount call */
#define MS_I_VERSION (1<<23) /* Update inode I_version field */
#define MS_STRICTATIME (1<<24) /* Always perform atime updates */
+#define MS_BARRIER (1<<25) /* Flush data during sync operations */
/* These sb flags are internal to the kernel */
#define MS_NOSEC (1<<28)
--
1.8.4.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 15/27] ARM: dts: exynos3250: Add uart dt node to support seiral ports
Hi, On 04/11/2014 01:03 PM, Sachin Kamat wrote: > On 10 April 2014 15:36, Chanwoo Choi wrote: >> This patch add UART dt node for Exynos3250. Exynos3250 uses same UART IP >> of Exynos4 SoC and has only two independent channels. >> >> Signed-off-by: Chanwoo Choi >> [Fix incorrect clock id by Tomasz Figa] >> Signed-off-by: Tomasz Figa >> Signed-off-by: Kyungmin Park >> --- > > typo in patch subject: s/seiral/serial > I'll fix it. Thanks. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected with GIC
Hi, On 04/11/2014 01:00 PM, Olof Johansson wrote: > On Thu, Apr 10, 2014 at 07:06:02PM +0900, Chanwoo Choi wrote: >> This patch add interrupt-parent node to connected with GIC. >> All interrupt-related dt nodes need default interrupt-parent node. >> >> Signed-off-by: Chanwoo Choi >> Signed-off-by: Kyungmin Park > > There's no point in splitting these off in separate patches; fold them > into one patch that introduces the SoC dtsi, please. OK, I will consolidate following two patches into one patch. [PATCH 11/27] ARM: dts: exynos3250: Add GIC dt node for Exynos3250 [PATCH 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected with GIC > > Also, you missed your sign-off on one or two of the previous ones, but that > won't be a problem once they're folded in. :) I'll add my sign-off to all the patches on next posting(v2). > > Finally, if the code is yours, and you're posting it, then Kyungmin should > probably have a Reviewed-by or Acked-by tag, not a Signed-off-by. See > Documentation/SubmittingPatches, section 12 and 13. > OK, I'll change from 'Signed-off-by' to 'Acked-by'. Thanks, Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/27] ARM: dts: exynos3250: Add new exynos3250.dtsi file
Hi,
On 04/11/2014 01:01 PM, Sachin Kamat wrote:
> Hi Chanwoo,
>
> On 10 April 2014 15:36, Chanwoo Choi wrote:
>> From: Tomasz Figa
>>
>> This patch add new exynos3250.dtsi to support Exynos3250 SoC and includes
>> chipid/sys_reg dt node.
>>
>> Signed-off-by: Tomasz Figa
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>> 1 file changed, 34 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> new file mode 100644
>> index 000..3c8cee6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -0,0 +1,34 @@
>> +/*
>> + * Samsung's Exynos3250 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Samsung's Exynos3250 SoC device nodes are listed in this file. Exynos3250
>> + * based board files can include this file and provide values for board
>> specfic
>> + * bindings.
>> + *
>> + * Note: This file does not include device nodes for all the controllers in
>> + * Exynos3250 SoC. As device tree coverage for Exynos3250 increases,
>> additional
>> + * nodes can be added to this file.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include "skeleton.dtsi"
>> +
>> +/ {
>> + compatible = "samsung,exynos3250";
>> +
>> + chipid@1000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x1000 0x100>;
>> + };
>> +
>> + sys_reg: syscon@1001 {
>> + compatible = "samsung,exynos3-sysreg", "syscon";
>> + reg = <0x1001 0x400>;
>> + };
>> +};
>
> Shouldn't these be grouped under the soc node?
I don't understand accurate meaning.
Do you have to explain more detailed comment?
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
On Fri, 2014-04-11 at 05:52 +0200, Mike Galbraith wrote: > On Thu, 2014-04-10 at 23:25 -0400, Steven Rostedt wrote: > > On Fri, 11 Apr 2014 04:50:26 +0200 > > Mike Galbraith wrote: > > > > > Oh, there was another useful bit. > > > > > > 3.12.17-rt25 403991 384216 377786 > > >405466 394011 392850 > > > > > > 3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE > > >350385 318786 367336 !TTWU_QUEUE > > >326009 356939 378215 !TTWU_QUEUE > > > > > > IPI == low-pass filter. > > > > I'm sorry, but I don't have the foggiest clue to what the above means. > > It means.. > > # Overhead > > Symbol > # > ... > # > 17.33% [k] native_write_msr_safe > | > |--88.45%-- __x2apic_send_IPI_mask > | | > | |--97.89%-- try_to_wake_up > | | | > | | |--99.91%-- wake_futex > | | | | > | | | |--99.77%-- futex_wake_op > | | | | do_futex > | | | | sys_futex > | | | | system_call_fastpath > > ..wakeup frequency is restricted by the IPI. Turn TTWU_QUEUE off, bottleneck goes away. # Overhead Symbol # ... # 6.12% [.] _ZN13ObjectMonitor20TrySpin_VaryDurationEP6Thread | |--61.27%-- _ZN13ObjectMonitor5enterEP6Thread | | | |--99.96%-- _ZN13SharedRuntime26complete_monitor_locking_CEP7oopDescP9BasicLockP10JavaThread | | 0x7f93149b2748 | | | | | |--99.76%-- 0xf1a02b30 | | | 0xbabafc24 | | --0.24%-- [...] | --0.04%-- [...] | |--38.40%-- _ZN13ObjectMonitor6EnterIEP6Thread | _ZN13ObjectMonitor5enterEP6Thread | | | |--99.98%-- _ZN13SharedRuntime26complete_monitor_locking_CEP7oopDescP9BasicLockP10JavaThread | | 0x7f93149b2748 | | | | | |--99.89%-- 0xf1a02b30 | | | 0xbabafc24 | | --0.11%-- [...] | --0.02%-- [...] --0.32%-- [...] 3.59% [k] intel_idle | --- cpuidle_enter_state cpuidle_idle_call arch_cpu_idle cpu_startup_entry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] cpufreq: Introduce macros for cpufreq_frequency_table iteration
On 11 April 2014 03:31, Stratos Karafotis wrote:
> This patch intoduces 2 macros which can be used for iteration
> over cpufreq_frequency_table:
>
> - cpufreq_for_each_entry: iterate over each entry of the table
> - cpufreq_for_each_valid_entry: iterate over each entry of the
> table that contains a valid frequency.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
>
> I found about 20 occurrences in various drivers that these macros
> can be used. I will proceed with the necessary changes if you
> approve something like this.
>
> Thanks in advance for your time,
Thanks for your time and I find it useful enough. So its a yes from
me :)
But, have you tested this yet?
> Stratos Karafotis.
> ---
>
> drivers/cpufreq/freq_table.c | 54
>
> include/linux/cpufreq.h | 29
> 2 files changed, 53 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index 08e7bbc..19bf0c4 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -21,22 +21,18 @@
> int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
> struct cpufreq_frequency_table *table)
> {
> + struct cpufreq_frequency_table *pos;
> unsigned int min_freq = ~0;
> unsigned int max_freq = 0;
> - unsigned int i;
>
> - for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> - unsigned int freq = table[i].frequency;
> - if (freq == CPUFREQ_ENTRY_INVALID) {
> - pr_debug("table entry %u is invalid, skipping\n", i);
> + cpufreq_for_each_valid_entry(pos, table) {
> + unsigned int freq = pos->frequency;
move the definition part to the top of this routine, we don't need
to create freq for every iteration here. It was bad earlier as well :)
>
> - continue;
> - }
> if (!cpufreq_boost_enabled()
> - && (table[i].flags & CPUFREQ_BOOST_FREQ))
> + && (pos->flags & CPUFREQ_BOOST_FREQ))
> continue;
>
> - pr_debug("table entry %u: %u kHz\n", i, freq);
> + pr_debug("table entry %lu: %u kHz\n", pos - table, freq);
> if (freq < min_freq)
> min_freq = freq;
> if (freq > max_freq)
> @@ -57,7 +53,8 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_cpuinfo);
> int cpufreq_frequency_table_verify(struct cpufreq_policy *policy,
>struct cpufreq_frequency_table *table)
> {
> - unsigned int next_larger = ~0, freq, i = 0;
> + struct cpufreq_frequency_table *pos;
> + unsigned int next_larger = ~0, freq;
> bool found = false;
>
> pr_debug("request for verification of policy (%u - %u kHz) for cpu
> %u\n",
> @@ -65,9 +62,9 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy
> *policy,
>
> cpufreq_verify_within_cpu_limits(policy);
>
> - for (; freq = table[i].frequency, freq != CPUFREQ_TABLE_END; i++) {
> - if (freq == CPUFREQ_ENTRY_INVALID)
> - continue;
> + cpufreq_for_each_valid_entry(pos, table) {
> + freq = pos->frequency;
> +
> if ((freq >= policy->min) && (freq <= policy->max)) {
> found = true;
> break;
> @@ -118,7 +115,8 @@ int cpufreq_frequency_table_target(struct cpufreq_policy
> *policy,
> .driver_data = ~0,
> .frequency = 0,
> };
> - unsigned int i;
> + struct cpufreq_frequency_table *pos;
> + unsigned int i = 0;
>
> pr_debug("request for target %u kHz (relation: %u) for cpu %u\n",
> target_freq, relation, policy->cpu);
> @@ -132,10 +130,10 @@ int cpufreq_frequency_table_target(struct
> cpufreq_policy *policy,
> break;
> }
>
> - for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> - unsigned int freq = table[i].frequency;
> - if (freq == CPUFREQ_ENTRY_INVALID)
> - continue;
> + cpufreq_for_each_valid_entry(pos, table) {
> + unsigned int freq = pos->frequency;
same here.
> +
> + i = pos - table;
> if ((freq < policy->min) || (freq > policy->max))
> continue;
> switch (relation) {
> @@ -184,8 +182,7 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_target);
> int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
> unsigned int freq)
> {
> - struct cpufreq_frequency_table *table;
> - int i;
> + struct cpufreq_frequency_table *pos, *table;
>
> table = cpufreq_frequency_get_table(policy->cpu);
>
[PATCH 2/2] i2c/ACPI: Don't ignore IRQ flags
Currently irq flags from IRQ resources are ignored. They have important
IRQ configuration for level, trigger and sharable.
Signed-off-by: Srinivas Pandruvada
---
drivers/i2c/i2c-core.c | 6 +-
include/linux/i2c.h| 4
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a69a7b4..cb72629 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1093,6 +1093,7 @@ struct i2c_resource_info {
unsigned short flags[MAX_CRS_ELEMENTS];
int count;
int common_irq;
+ int common_irq_flags;
};
static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
@@ -1116,8 +1117,10 @@ static int acpi_i2c_add_resource(struct acpi_resource
*ares, void *data)
} else if (rcs_info->common_irq < 0) {
struct resource r;
- if (acpi_dev_resource_interrupt(ares, 0, ))
+ if (acpi_dev_resource_interrupt(ares, 0, )) {
rcs_info->common_irq = r.start;
+ rcs_info->common_irq_flags = r.flags;
+ }
}
/* Tell the ACPI core to skip this resource */
@@ -1157,6 +1160,7 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
adev->power.flags.ignore_parent = true;
info.irq = rcs_info.common_irq;
+ info.irq_flags = rcs_info.common_irq_flags;
for (i = 0; i < rcs_info.count; ++i) {
if (!rcs_info.addr[i])
continue;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index ce75c73..cea41ab 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -207,6 +207,7 @@ struct i2c_driver {
* @adapter: manages the bus segment hosting this I2C device
* @dev: Driver model device node for the slave.
* @irq: indicates the IRQ generated by this device (if any)
+ * @irq_flags: indicates the IRQ flags (format: IORESOURCE_IRQ_)
* @detected: member of an i2c_driver.clients list or i2c-core's
* userspace_devices list
*
@@ -223,6 +224,7 @@ struct i2c_client {
struct i2c_adapter *adapter;/* the adapter we sit on*/
struct device dev; /* the device structure */
int irq;/* irq issued by device */
+ unsigned long irq_flags;/* irq flags by device */
struct list_head detected;
};
#define to_i2c_client(d) container_of(d, struct i2c_client, dev)
@@ -256,6 +258,7 @@ static inline void i2c_set_clientdata(struct i2c_client
*dev, void *data)
* @of_node: pointer to OpenFirmware device node
* @acpi_node: ACPI device node
* @irq: stored in i2c_client.irq
+ * @irq_flags: indicates the IRQ flags (format: IORESOURCE_IRQ_)
*
* I2C doesn't actually support hardware probing, although controllers and
* devices may be able to use I2C_SMBUS_QUICK to tell whether or not there's
@@ -277,6 +280,7 @@ struct i2c_board_info {
struct device_node *of_node;
struct acpi_dev_node acpi_node;
int irq;
+ unsigned long irq_flags;
};
/**
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] i2c/ACPI: Support for multiple serial bus addresses
ACPI specification allows multiple i2c addresses defined under one
ACPI device object. These addresses are defined using _CRS method.
The current implementation will pickup the last entry in _CRS, and
create an i2C device, ignoring all other previous entries for addresses.
The ACPI specification does not define, whether these addresses for one
i2c device or for multiple i2c devices, which are defined under the same
ACPI device object. We need some appoach where i2c clients can enumerate
on each of the i2C address and/or have access to those extra addresses.
This change addresses both cases:
- Create a new i2c device for each i2c address
- Allow each i2 client to get addresses of all other devices under
the same ACPI device object (companions or siblings)
Example 1:
Here in the following example, there are two i2C address in _CRS.
They belong to two different physical chipsets, with two different i2c
address but part of a module.
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0068, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C5",
0x00, ResourceConsumer, ,
)
I2cSerialBus (0x000C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C5",
0x00, ResourceConsumer, ,
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x0044,
}
})
Return (RBUF)
}
This change adds i2c_new_device for each i2c address. Here contents of
/sys/bus/i2c/devices will
i2c-some_acpi_dev_name:00:068
i2c-some_acpi_dev_name::00:00c
Example 2
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0018
}
I2cSerialBus (0x0010, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C4",
0x00, ResourceConsumer, ,
)
I2cSerialBus (0x000C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C4",
0x00, ResourceConsumer, ,
)
I2cSerialBus (0x0054, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C4",
0x00, ResourceConsumer, ,
)
})
Return (SBUF) /* \_SB_.I2C4.CAM1._CRS.SBUF */
}
}
Here there are three i2c addresses for this device.
When there is only I2cSerialBus address is present then there is no
change. The device name will not include address. In this way if
some device is using hardcoded path, this change will not impact them.
Here any i2c client driver simply need to add ACPI bindings. They will
be probed multiple times, the client will bind to correct i2c device,
based on checking its identity and returning error for other.
At the same time, any i2c client can call i2c_for_each_acpi_comp_client
to get the i2c client instances of companion addresses defined
under the same ACPI device.
Signed-off-by: Srinivas Pandruvada
---
drivers/i2c/i2c-core.c | 111 ++---
include/linux/i2c.h| 13 ++
2 files changed, 109 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5fb80b8..a69a7b4 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -627,7 +627,7 @@ static void i2c_dev_set_name(struct i2c_adapter *adap,
struct acpi_device *adev = ACPI_COMPANION(>dev);
if (adev) {
- dev_set_name(>dev, "i2c-%s", acpi_dev_name(adev));
+ dev_set_name(>dev, "i2c-%s", client->name);
return;
}
@@ -1080,24 +1080,44 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap) { }
/* ACPI support code */
#if IS_ENABLED(CONFIG_ACPI)
+/*
+ * acpi_i2c_add_resource is a callback, which is called while walking
+ * name spaces, adding a limit allows for faster processing, without
+ * using reallocation,
+ * Adding some limit for max adresses in resource. Currently we see
+ * max only 3 addresses, so 20 is more than enough
+ */
+#define MAX_CRS_ELEMENTS 20
+struct i2c_resource_info {
+ unsigned short addr[MAX_CRS_ELEMENTS];
+ unsigned short flags[MAX_CRS_ELEMENTS];
+ int
[RFC PATCH v2] Use kernfs_break_active_protection() for device online store callbacks
I noticed following lockdep warning when trying acpi hot-remove cpus:
[84154.204080] ==
[84154.204080] [ INFO: possible circular locking dependency detected ]
[84154.204080] 3.14.0-next-20140408+ #24 Tainted: GW
[84154.204080] ---
[84154.204080] bash/777 is trying to acquire lock:
[84154.204080] (cpu_add_remove_lock){+.+.+.}, at: []
cpu_maps_update_begin+0x17/0x20
[84154.213203]
[84154.213203] but task is already holding lock:
[84154.213203] (s_active#79){.+}, at: []
kernfs_fop_write+0xe4/0x190
[84154.213203]
[84154.213203] which lock already depends on the new lock.
[84154.213203]
[84154.213203]
[84154.213203] the existing dependency chain (in reverse order) is:
[84154.213203]
-> #3 (s_active#79){.+}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] __kernfs_remove+0x250/0x310
[84154.213203][] kernfs_remove_by_name_ns
+0x50/0xc0
[84154.213203][] sysfs_remove_file_ns
+0x15/0x20
[84154.213203][] device_remove_file+0x19/0x20
[84154.213203][] device_remove_attrs+0x33/0x80
[84154.213203][] device_del+0x127/0x1c0
[84154.213203][] device_unregister+0x22/0x60
[84154.213203][] unregister_cpu+0x1e/0x40
[84154.213203][] arch_unregister_cpu+0x23/0x30
[84154.213203][] acpi_processor_remove
+0x8d/0xb2
[84154.213203][] acpi_bus_trim+0x5a/0x8d
[84154.213203][] acpi_device_hotplug
+0x1a8/0x3ec
[84154.213203][] acpi_hotplug_work_fn
+0x1f/0x2b
[84154.213203][] process_one_work+0x1eb/0x6b0
[84154.213203][] worker_thread+0x11b/0x370
[84154.213203][] kthread+0xe4/0x100
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203]
-> #2 (cpu_hotplug.lock#2){+.+.+.}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] mutex_lock_nested+0x50/0x3c0
[84154.213203][] cpu_hotplug_begin+0x4f/0x80
[84154.213203][] _cpu_up+0x3f/0x160
[84154.213203][] cpu_up+0x69/0x80
[84154.213203][] smp_init+0x60/0x8c
[84154.213203][] kernel_init_freeable
+0x126/0x23b
[84154.213203][] kernel_init+0xe/0xf0
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203]
-> #1 (cpu_hotplug.lock){++}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] cpu_hotplug_begin+0x41/0x80
[84154.213203][] _cpu_up+0x3f/0x160
[84154.213203][] cpu_up+0x69/0x80
[84154.213203][] smp_init+0x60/0x8c
[84154.213203][] kernel_init_freeable
+0x126/0x23b
[84154.213203][] kernel_init+0xe/0xf0
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203]
-> #0 (cpu_add_remove_lock){+.+.+.}:
[84154.213203][] __lock_acquire+0x1f2a/0x1f60
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] mutex_lock_nested+0x50/0x3c0
[84154.213203][] cpu_maps_update_begin
+0x17/0x20
[84154.213203][] cpu_down+0x1d/0x50
[84154.213203][] cpu_subsys_offline+0x14/0x20
[84154.213203][] device_offline+0xad/0xd0
[84154.213203][] online_store+0x42/0x80
[84154.213203][] dev_attr_store+0x18/0x30
[84154.213203][] sysfs_kf_write+0x49/0x60
[84154.213203][] kernfs_fop_write+0x109/0x190
[84154.213203][] vfs_write+0xbe/0x1c0
[84154.213203][] SyS_write+0x52/0xb0
[84154.213203][] tracesys+0xd0/0xd5
[84154.213203]
[84154.213203] other info that might help us debug this:
[84154.213203]
[84154.213203] Chain exists of:
cpu_add_remove_lock --> cpu_hotplug.lock#2 --> s_active#79
[84154.213203] Possible unsafe locking scenario:
[84154.213203]
[84154.213203]CPU0CPU1
[84154.213203]
[84154.213203] lock(s_active#79);
[84154.213203]lock(cpu_hotplug.lock#2);
[84154.213203]lock(s_active#79);
[84154.213203] lock(cpu_add_remove_lock);
[84154.213203]
[84154.213203] *** DEADLOCK ***
.
The deadlock itself seems already fixed in commit 5e33bc41.
As Tejun suggested, to avoid this lockdep warning,
kernfs_break_active_protection() is used before online/offline callbacks
to take the s_active lock out of the dependency chain during
online/offline operations.
Signed-off-by: Li Zhong
---
drivers/base/core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528..2b9f68e 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -439,6 +439,7 @@ static ssize_t online_store(struct device *dev, struct
device_attribute *attr,
{
bool val;
int ret;
+ struct kernfs_node *kn;
ret = strtobool(buf, );
if (ret < 0)
@@ -448,7 +449,15 @@ static ssize_t online_store(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+
Re: [PATCH 15/27] ARM: dts: exynos3250: Add uart dt node to support seiral ports
On 10 April 2014 15:36, Chanwoo Choi wrote: > This patch add UART dt node for Exynos3250. Exynos3250 uses same UART IP > of Exynos4 SoC and has only two independent channels. > > Signed-off-by: Chanwoo Choi > [Fix incorrect clock id by Tomasz Figa] > Signed-off-by: Tomasz Figa > Signed-off-by: Kyungmin Park > --- typo in patch subject: s/seiral/serial -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/27] ARM: dts: exynos3250: Add new exynos3250.dtsi file
Hi Chanwoo,
On 10 April 2014 15:36, Chanwoo Choi wrote:
> From: Tomasz Figa
>
> This patch add new exynos3250.dtsi to support Exynos3250 SoC and includes
> chipid/sys_reg dt node.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
> 1 file changed, 34 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> new file mode 100644
> index 000..3c8cee6
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -0,0 +1,34 @@
> +/*
> + * Samsung's Exynos3250 SoC device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung's Exynos3250 SoC device nodes are listed in this file. Exynos3250
> + * based board files can include this file and provide values for board
> specfic
> + * bindings.
> + *
> + * Note: This file does not include device nodes for all the controllers in
> + * Exynos3250 SoC. As device tree coverage for Exynos3250 increases,
> additional
> + * nodes can be added to this file.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "samsung,exynos3250";
> +
> + chipid@1000 {
> + compatible = "samsung,exynos4210-chipid";
> + reg = <0x1000 0x100>;
> + };
> +
> + sys_reg: syscon@1001 {
> + compatible = "samsung,exynos3-sysreg", "syscon";
> + reg = <0x1001 0x400>;
> + };
> +};
Shouldn't these be grouped under the soc node?
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected with GIC
On Thu, Apr 10, 2014 at 07:06:02PM +0900, Chanwoo Choi wrote: > This patch add interrupt-parent node to connected with GIC. > All interrupt-related dt nodes need default interrupt-parent node. > > Signed-off-by: Chanwoo Choi > Signed-off-by: Kyungmin Park There's no point in splitting these off in separate patches; fold them into one patch that introduces the SoC dtsi, please. Also, you missed your sign-off on one or two of the previous ones, but that won't be a problem once they're folded in. :) Finally, if the code is yours, and you're posting it, then Kyungmin should probably have a Reviewed-by or Acked-by tag, not a Signed-off-by. See Documentation/SubmittingPatches, section 12 and 13. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Chanwoo, On 10 April 2014 15:07, Chanwoo Choi wrote: > This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that > is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses > Cortex-A7 > dual cores and has a target speed of 1.0GHz. > > Signed-off-by: Chanwoo Choi > Signed-off-by: Kyungmin Park > --- > arch/arm/mach-exynos/Kconfig | 22 ++ > arch/arm/mach-exynos/exynos.c| 1 + > arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ > 3 files changed, 33 insertions(+) > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index fc8bf18..6da8a68 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -11,6 +11,17 @@ if ARCH_EXYNOS > > menu "SAMSUNG EXYNOS SoCs Support" > > +config ARCH_EXYNOS3 > + bool "SAMSUNG EXYNOS3" > + select ARM_AMBA > + select CLKSRC_OF > + select HAVE_ARM_SCU if SMP > + select HAVE_SMP > + select PINCTRL > + select PM_GENERIC_DOMAINS if PM_RUNTIME > + help > + Samsung EXYNOS3 SoCs based systems > + > config ARCH_EXYNOS4 > bool "SAMSUNG EXYNOS4" > default y > @@ -41,6 +52,17 @@ config ARCH_EXYNOS5 > > comment "EXYNOS SoCs" > > +config SOC_EXYNOS3250 > + bool "SAMSUNG EXYNOS3250" > + default y > + depends on ARCH_EXYNOS3 > + select ARCH_HAS_BANDGAP > + select ARM_CPU_SUSPEND if PM > + select PINCTRL_EXYNOS > + select SAMSUNG_DMADEV > + help > + Enable EXYNOS3250 CPU support There is a Kconfig consolidation patch submitted by me [1]. Please base your code on that one to avoid merge conflicts. [1] http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642 -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
On Thu, 2014-04-10 at 23:25 -0400, Steven Rostedt wrote: > On Fri, 11 Apr 2014 04:50:26 +0200 > Mike Galbraith wrote: > > > Oh, there was another useful bit. > > > > 3.12.17-rt25 403991 384216 377786 > >405466 394011 392850 > > > > 3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE > >350385 318786 367336 !TTWU_QUEUE > >326009 356939 378215 !TTWU_QUEUE > > > > IPI == low-pass filter. > > I'm sorry, but I don't have the foggiest clue to what the above means. It means.. # Overhead Symbol # ... # 17.33% [k] native_write_msr_safe | |--88.45%-- __x2apic_send_IPI_mask | | | |--97.89%-- try_to_wake_up | | | | | |--99.91%-- wake_futex | | | | | | | |--99.77%-- futex_wake_op | | | | do_futex | | | | sys_futex | | | | system_call_fastpath ..wakeup frequency is restricted by the IPI. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14.0+/x86: lockdep and mutexes not getting along
On Thu, Apr 10, 2014 at 07:26:52PM -0400, Dave Jones wrote: > On Thu, Apr 10, 2014 at 10:14:44AM -0700, Jason Low wrote: > > On Thu, 2014-04-10 at 11:18 +0200, Peter Zijlstra wrote: > > > On Wed, Apr 09, 2014 at 10:42:59PM -0700, Jason Low wrote: > > > > As a starting point, would either of you like to test the following > > > > patch to see if it fixes the issue? This patch essentially generates > the > > > > same code as in older kernels in the debug case. This applies on top of > > > > kernels with both commits 6f008e72cd11 and 1d8fe7dc8078. > > > > > > > > > So I managed to reproduce, and the below makes it go away. I just don't > > > understand why though. will stare more. > > > > So one thing I noticed that is different in the current code is that in > > debug_mutex_unlock(), there is is a possibility that it does not unlock > > the mutex (when !debug_locks). May be interesting to try out this > > patch too: > > I've been seeing lockups this last week or two too, that manifested by > RCU spewing stall messages, and the box being totally unresponsive. > This patch seems to cure that for me, which I'm sure will make Paul > happy to hear. Whew!!! ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] SPI: Add driver for Cadence SPI controller
Hi Mark,
On Fri, Apr 11, 2014 at 4:18 AM, Mark Brown wrote:
> On Thu, Apr 10, 2014 at 05:43:49PM +0530, Harini Katakam wrote:
>> Add driver for Cadence SPI controller. This is used in Xilinx Zynq.
>
> This looks mostly good, the issues below are very small.
>
>> +static int __maybe_unused cdns_spi_suspend(struct device *dev)
>> +{
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, dev);
>> + struct spi_master *master = platform_get_drvdata(pdev);
>> + struct cdns_spi *xspi = spi_master_get_devdata(master);
>> +
>> + spi_master_suspend(master);
>> +
>> + clk_disable(xspi->ref_clk);
>> +
>> + clk_disable(xspi->pclk);
>
> You're only doing clk_disable() here, I would expect the clocks to also
> be unprepared over suspend - there is no value in leaving them prepared
> that I can see. Just use clk_unprepare_disable().
>
> It would also be good (though not essential) to implement runtime PM and
> disable the clocks while there are no transfers in progress for a small
> power saving. The auto_runtime_pm feature in the core will do the
> runtime PM calls for you.
>
> Otherwise this looks good.
Thanks. I'll make these changes and send a v4 next week.
Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwrng: bcm2835: fix oops when rng h/w is accessed during registration
On Thu, Apr 10, 2014 at 03:22:10PM -0400, Matt Porter wrote: > Commit "d9e7972 hwrng: add randomness to system from rng sources" > exposed a bug in the bcm2835-rng driver resulting in boot failure > on Raspberry Pi due to the following oops: > > [ 28.261523] BUG: soft lockup - CPU#0 stuck for 23s! [swapper:1] > [ 28.271058] > [ 28.275958] CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.0+ #11 > [ 28.285374] task: db48 ti: db484000 task.ti: db484000 > [ 28.294279] PC is at bcm2835_rng_read+0x28/0x48 > [ 28.302276] LR is at hwrng_register+0x1a8/0x238 > . > . > . > > The RNG h/w is not completely initialized and enabled before > hwrng_register() is called and so the bcm2835_rng_read() fails. > Fix this by making the warmup/enable writes before registering > the RNG source with the hwrng core. > > Signed-off-by: Matt Porter Patch applied. Thanks a lot! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ipv4: current group_info should be put after using.
There is a memory leak in ping. Current group_info had been got in
ping_init_sock and group_info->usage increased.
But the usage hasn't decreased anywhere in ping.
This will make this group_info never freed and cause memory leak.
unreferenced object 0xcd0e8840 (size 192):
comm "dumpstate", pid 7583, jiffies 78360 (age 91.810s)
hex dump (first 32 bytes):
02 00 00 00 06 00 00 00 01 00 00 00 ef 03 00 00
f1 03 00 00 f7 03 00 00 04 04 00 00 bb 0b 00 00
backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] __kmalloc+0xe7/0x1d0
[] groups_alloc+0x34/0xb0
[] SyS_setgroups+0x3c/0xf0
[] syscall_call+0x7/0xb
[] 0x
Signed-off-by: Chuansheng Liu
Signed-off-by: Zhang Dongxing
Signed-off-by: xiaoming wang
---
net/ipv4/ping.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index f4b19e5..2af7b1f 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -255,23 +255,28 @@ int ping_init_sock(struct sock *sk)
struct group_info *group_info = get_current_groups();
int i, j, count = group_info->ngroups;
kgid_t low, high;
+ int ret = 0;
inet_get_ping_group_range_net(net, , );
if (gid_lte(low, group) && gid_lte(group, high))
- return 0;
+ goto out_release_group;
for (i = 0; i < group_info->nblocks; i++) {
int cp_count = min_t(int, NGROUPS_PER_BLOCK, count);
for (j = 0; j < cp_count; j++) {
kgid_t gid = group_info->blocks[i][j];
if (gid_lte(low, gid) && gid_lte(gid, high))
- return 0;
+ goto out_release_group;
}
count -= cp_count;
}
- return -EACCES;
+ ret = -EACCES;
+
+out_release_group:
+ put_group_info(group_info);
+ return ret;
}
EXPORT_SYMBOL_GPL(ping_init_sock);
--
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: linux-next: Tree for Apr 11
On Fri, 11 Apr 2014 13:03:13 +1000 Stephen Rothwell wrote: > > Non-merge commits (relative to Linus' tree): 568 > 1077 files changed, 16245 insertions(+), 11823 deletions(-) Actually ... Non-merge commits (relative to Linus' tree): 533 996 files changed, 12720 insertions(+), 12603 deletions(-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp5gO1APMm2w.pgp Description: PGP signature
Re: [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
On Fri, 11 Apr 2014 04:50:26 +0200 Mike Galbraith wrote: > Oh, there was another useful bit. > > 3.12.17-rt25 403991 384216 377786 >405466 394011 392850 > > 3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE >350385 318786 367336 !TTWU_QUEUE >326009 356939 378215 !TTWU_QUEUE > > IPI == low-pass filter. I'm sorry, but I don't have the foggiest clue to what the above means. -- 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: hpsa driver bug crack kernel down!
On 04/10/14 at 04:34pm, Jiang Liu wrote:
> Hi Baoquan,
> Could you please help to give output of "lspci -"?
> Is device "hpsa :03:00.0" a legacy PCI device(non-PCIe)?
> It may have relationship with IOMMU driver.
> Thanks!
> Gerry
Well, the machine bug was reported on is a AMD machine, and it doesn't
have the IOMMU problem. David saw there are some DMAR errors, it should
be a intel machine which use the VT-d.
>
> On 2014/4/10 12:03, Bjorn Helgaas wrote:
> > [+cc Joerg, iommu list]
> >
> > On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso wrote:
> >> On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
> >>> On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote:
> On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote:
> > On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote:
> >> [+linux-scsi]
> >> On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote:
> >>> On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote:
> Hi,
>
> The kernel is 3.14.0+ which is pulled just now.
> >>>
> >>> Cc'ing more people.
> >>>
> >>> While the hpsa driver appears to be involved in some way, I'm sure if
> >>> this is a related issue, but as of today's pull I'm getting another
> >>> problem that causes my DL980 not to come up.
> >>>
> >>> *Massive* amounts of:
> >>>
> >>> DMAR:[fault reason 02] Present bit in context entry is clear
> >>> dmar: DRHD: handling fault status reg 602
> >>> dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
> >>>
> >>> Then:
> >>>
> >>> hpsa :03:00.0: Controller lockup detected: 0x
> >>> ...
> >>> Workqueue: events hpsa_monitor_ctlr_worker [hpsa]
> >>> ...
> >>>
> >>> Screenshot of the actual LOCKUP:
> >>> http://stgolabs.net/hpsa-hard-lockup-3.14+.png
> >>>
> >>> While I haven't bisected, things worked fine until at least until
> >>> commit
> >>> 39de65aa2c3e (April 2nd).
> >>>
> >>> Any ideas?
> >>
> >> Well, it's either a DMA remapping issue or a hpsa one. Your assertion
> >> that everything worked fine until 39de65aa2c3e would tend to vindicate
> >> hpsa,
>
> Hmm here you mean DMA, right?
> >>>
> >>> No, it vindicates the hpsa changes ... they don't seem to be causing
> >>> problems until something goes wrong with dma remapping.
> >>>
> > because all the hpsa changes went in before that under
> > Missing crucial info:
> >
> > commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1
> >
> >> Merge: 3e75c6d b2bff6c
> >> Author: Linus Torvalds
> >> Date: Tue Apr 1 18:49:04 2014 -0700
> >>
> >> Merge tag 'scsi-misc' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> >>
> >> can you revalidate that this commit works OK just to make sure?
>
> Ok so I don't see those DMA messages and system starts just fine. I'm
> thinking perhaps something broke after the IO mmu stuff in commit
> 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly
> causing the CPU stalls and just blame hpsa in the path as a side effect?
>
> /me goes out to try the commit.
> >>>
> >>> That's my guess. The DMAR messages are DMA remapping issues caused in
> >>> the IOMMU. If I had to guess, I'd say the DMAR fault message is
> >>> indicating the IOMMU is calling for a mapping address before it can
> >>> satisfy the driver read request, which is causing the hang apparently in
> >>> the hpsa driver.
> >>>
> >>> I've added linux-pci to the cc; I think they deal with iommu issues on
> >>> x86.
> >>
> >> So that merge commit appears to be the culprit, I see both the DMA
> >> messages and the lockup blaming hpsa...
> >
> > My understanding so far (please correct me if I'm wrong):
> >
> > 39de65aa2c3e OK ("Merge branch 'i2c/for-next'")
> > 1a0b6abaea78 OK ("Merge tag 'scsi-misc'")
> > 3f583bc21977 BAD ("Merge tag 'iommu-updates-v3.15'")
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hpsa: fix uninitialized trans_support in hpsa_put_ctlr_into_performant_mode()
This patch works for me.
Tested-by: Baoquan He
Thanks
Baoquan
On 04/10/14 at 05:17pm, scame...@beardog.cce.hp.com wrote:
>
> Without this, you'll see a null pointer dereference in
> hpsa_enter_performant_mode().
>
> Signed-off-by: Stephen M. Cameron
> ---
> drivers/scsi/hpsa.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 8cf4a0c..ef4dfdd 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
> ctlr_info *h)
> if (hpsa_simple_mode)
> return;
>
> + trans_support = readl(&(h->cfgtable->TransportSupport));
> + if (!(trans_support & PERFORMANT_MODE))
> + return;
> +
> /* Check for I/O accelerator mode support */
> if (trans_support & CFGTBL_Trans_io_accel1) {
> transMethod |= CFGTBL_Trans_io_accel1 |
> --
> 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] net: ipv4: current group_info should be put after using.
From: "Wang, Xiaoming" Date: Fri, 11 Apr 2014 12:10:38 -0400 > +EXIT: Do not use all CAPS names for local labels. Make the label, in lower case, say something about what state needs to be released at that point. Something like "out_release_group:" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] NTB bug fixes and features for v3.15
Hi Linus, Below are a number of NTB bug fixes for v3.15. Please consider pulling them. Thanks, Jon The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://github.com/jonmason/ntb.git tags/ntb-3.15 for you to fetch changes up to f220baad08963a75c78c80cdc1c9e9492ca0eb2a: ntb: Use pci_enable_msix_range() instead of pci_enable_msix() (2014-04-07 10:59:20 -0700) NTB driver bug fixes to address issues in list traversal, skb leak in ntb_netdev, a typo, and a leak of msix entries in the error path. Clean ups of the event handling logic, as well as a overall style cleanup. Finally, the driver was converted to use the new pci_enable_msix_range logic (and the refactoring to go along with it). Alexander Gordeev (4): ntb: Fix leakage of ntb_device::msix_entries[] array ntb: Use pci_msix_vec_count() to obtain number of MSI-Xs ntb: Split ntb_setup_msix() into separate BWD/SNB routines ntb: Use pci_enable_msix_range() instead of pci_enable_msix() Jon Mason (4): ntb_netdev: Fix list_for_each_entry exit issue ntb_netdev: Fix skb free issue in open NTB: client event cleanup NTB: Code Style Clean-up Roland Dreier (1): NTB: Fix typo in setting one translation register drivers/net/ntb_netdev.c| 27 ++--- drivers/ntb/ntb_hw.c| 192 +-- drivers/ntb/ntb_hw.h|8 ++-- drivers/ntb/ntb_transport.c | 20 +-- include/linux/ntb.h | 19 +++--- 5 files changed, 150 insertions(+), 116 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: core: Increase timeout value
Hi Mark, On Thu, Apr 10, 2014 at 11:06 PM, Mark Brown wrote: > On Thu, Apr 10, 2014 at 06:20:29PM +0530, Harini Katakam wrote: > >> Considering acceptable latencies, this timeout can be set to a large >> value >= 1*HZ typically. > >> This patch adds a tolerance of 2000 msec in the core accordingly. > > That's too much, it's 2 seconds which gets to be incredibly painful when > trying to debug problems - if you're sitting there waiting for a driver > to time out some operations (and it may be more than one of them) so you > can look at the diagnostics it can be quite aggrivating. That's why the > delays are related to the expected runtime for the operation. Something > like double the expected runtime plus something in the 100ms or so range > perhaps? > OK. > Ideally we'd use the actual speed the device set rather than the > requested one too, that'd help. How would you propose to do that - driver should write back actual speed set to xfer->speed_hz? Regards, Harini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC V2 4/4] tools: virtio: add a top-like utility for displaying vhost satistics
On Thu, 2014-04-10 at 17:27 +0800, Fam Zheng wrote: > On Fri, 03/21 17:41, Jason Wang wrote: > > This patch adds simple python to display vhost satistics of vhost, the codes > > were based on kvm_stat script from qemu. As work function has been recored, > > filters could be used to distinguish which kinds of work are being executed > > or > > queued: > > > > vhost statistics > > > > vhost_virtio_update_used_idx 1215215 0 > > vhost_virtio_get_vq_desc 1215215 0 > > vhost_work_queue_wakeup 986808 0 > > vhost_virtio_signal 811601 0 > > vhost_net_tx611457 0 > > vhost_net_rx603758 0 > > vhost_net_tx(datacopy) 601903 0 > > vhost_work_queue_wakeup(rx_net) 565081 0 > > vhost_virtio_signal(rx) 461603 0 > > vhost_work_queue_wakeup(tx_kick)421718 0 > > vhost_virtio_update_avail_event 417346 0 > > vhost_virtio_signal(tx) 349998 0 > > vhost_work_queue_coalesce39384 0 > > vhost_work_queue_coalesce(rx_net)38677 0 > > vhost_net_tx(zerocopy)9554 0 > > vhost_work_queue_coalesce(tx_kick) 707 0 > > vhost_work_queue_wakeup(rx_kick) 9 0 > > > > Signed-off-by: Jason Wang > > --- > > tools/virtio/vhost_stat | 375 > > > > 1 file changed, 375 insertions(+) > > create mode 100755 tools/virtio/vhost_stat > > > > diff --git a/tools/virtio/vhost_stat b/tools/virtio/vhost_stat > > new file mode 100755 > > index 000..398fd4a > > --- /dev/null > > +++ b/tools/virtio/vhost_stat > > @@ -0,0 +1,375 @@ > > +#!/usr/bin/python > > +# > > +# top-like utility for displaying vhost statistics > > +# > > +# Copyright 2012 Red Hat, Inc. > > Should it be 2014? > > Fam > > Yes it should, thanks for pointing this out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tuntap: add flow control to support back pressure
On Thu, 2014-04-10 at 21:42 -0400, Steven Galgano wrote:
> On 04/10/2014 06:29 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 09, 2014 at 10:19:40PM -0400, Steven Galgano wrote:
> >> Add tuntap flow control support for use by back pressure routing
> >> protocols. Setting the new TUNSETIFF flag IFF_FLOW_CONTROL, will signal
> >> resources as unavailable when the tx queue limit is reached by issuing a
> >> netif_tx_stop_all_queues() rather than discarding frames. A
> >> netif_tx_wake_all_queues() is issued after reading a frame from the queue
> >> to signal resource availability.
> >>
> >> Back pressure capability was previously supported by the legacy tun
> >> default mode. This change restores that functionality, which was last
> >> present in v3.7.
> >>
> >> Reported-by: Brian Adamson
> >> Tested-by: Joseph Giovatto
> >> Signed-off-by: Steven Galgano
> >
> > I don't think it's a good idea.
> >
> > This trivial flow control really created more problems than it was worth.
> >
> > In particular this blocks all flows so it's trivially easy for one flow
> > to block and starve all others: just send a bunch of packets to loopback
> > destinations that get queued all over the place.
> >
> > Luckily it was never documented so we changed the default and nothing
> > seems to break, but we won't be so lucky if we add an explicit API.
> >
> >
> > One way to implement this would be with ubuf_info callback this is
> > already invoked in most places where a packet might get stuck for a long
> > time. It's still incomplete though: this will prevent head of queue
> > blocking literally forever, but a single bad flow can still degrade
> > performance significantly.
> >
> > Another alternative is to try and isolate the flows that we
> > can handle and throttle them.
> >
> > It's all fixable but we really need to fix the issues *before*
> > exposing the interface to userspace.
> >
> >
> >
>
> It was only after recent upgrades that we picked up a newer kernel and
> discovered the change to the default tun mode.
>
> The new default behavior has broken applications that depend on the
> legacy behavior. Although not documented, the legacy behavior was well
> known at least to those working in the back pressure research community.
> The default legacy mode was/is a valid use case although I am not sure
> it fits with recent multiqueue support.
>
> When back pressure protocols are running over a tun interface they
> require legacy flow control in order to communicate congestion detected
> on the physical media they are using. Multiqueues do not apply here.
> These protocols only use one queue, so netif_tx_stop_all_queues() is the
> necessary behavior.
>
> I'm not tied to the idea of IFF_FLOW_CONTROL. I was aiming for middle
> ground where an application controlling the tun interface can state it
> wants the legacy flow control behavior understanding its limitations
> concerning multiple queues.
>
> What if we resurrect IFF_ONE_QUEUE and use that as a mechanism to
> indicate legacy flow control. A tun instance initially configured with
> IFF_ONE_QUEUE would not be allowed to attach or detach queues with
> TUNSETQUEUE and any additional opens with the same device name would
> fail. This mode would use the
> netif_tx_stop_all_queues()/netif_tx_wake_all_queues() flow control
> mechanism.
>
Even if you choose this method, using
netif_tx_stop_queue()/netif_tx_wake_queue() should still be ok and more
readable.
> If a tun application wants the current default behavior with only a
> single queue, it would not set the IFF_ONE_QUEUE flag. Not setting
> IFF_MULTI_QUEUE would not imply IFF_ONE_QUEUE.
>
> I'd be happy to implement this change if it is an acceptable solution.
> This would allow multiqueue tun development to advance while still
> supporting use cases dependent on legacy flow control.
>
> -steve
>
> >> ---
> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> index ee328ba..268130c 100644
> >> --- a/drivers/net/tun.c
> >> +++ b/drivers/net/tun.c
> >> @@ -783,8 +783,19 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
> >> struct net_device *dev)
> >> * number of queues.
> >> */
> >>if (skb_queue_len(>socket.sk->sk_receive_queue) * numqueues
> >> ->= dev->tx_queue_len)
> >> - goto drop;
> >> + >= dev->tx_queue_len) {
> >> + if (tun->flags & TUN_FLOW_CONTROL) {
> >> + /* Resources unavailable stop transmissions */
> >> + netif_tx_stop_all_queues(dev);
> >> +
> >> + /* We won't see all dropped packets individually, so
> >> + * over run error is more appropriate.
> >> + */
> >> + dev->stats.tx_fifo_errors++;
> >> + } else {
> >> + goto drop;
> >> + }
> >> + }
> >>
> >>if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
> >>goto drop;
> >> @@ -1362,6 +1373,9 @@ static
Re: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
(2014/04/10 23:20), Denys Vlasenko wrote: > On 04/10/2014 03:57 PM, Masami Hiramatsu wrote: >> (2014/04/10 22:41), Denys Vlasenko wrote: >>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote: On 04/08, Jim Keniston wrote: > > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote: >> 0xe8. Anything else? > > No, I think e8 is the only call instruction uprobes will see. Good. >>> >>> There is this monstrosity, "16-bit override for branches" in 64-mode: >>> >>> 66 e8 nn nn callw >>> >>> Nobody sane uses it because it truncates instruction pointer. >> >> No problem, insn.c can handle that too. :) > > That's good that we decode it correctly, > but there is more to it. > > Call insn pushes return address to stack. > > This "mutant 16-bit call", what should it push? > Full RIP? > Truncated 16-bit IP? If yes, by how much does it > advance RSP? +2? +8? > Hmm. Does it affect RSP or only its 16-bit lower part? At least, if we can trust Intel SDM, it says that depends on the operand-size (insn->opnd_bytes) and stack segment descriptor. Please check the SDM vol.1 6.2.2 Stack Alignment and vol.2a, 3.2 Instructions (A-M), CALL—Call Procedure. But we'd better check it on x86-32. Thank you! > > It's a can of worms! :) -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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/
linux-next: Tree for Apr 11
Hi all, Please do not add material intended for v3.16 to your linux-next included branches until after v3.15-rc1 is released. This tree still fails (more than usual) the powerpc allyesconfig build. Changes since 20140410: Dropped trees: akpm-current, akpm (too complex conflicts) The arm tree lost its build failure. The powerpc tree still had its build failure. Non-merge commits (relative to Linus' tree): 568 1077 files changed, 16245 insertions(+), 11823 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 213 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4ba85265790b Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (61fb4bfc010b ARC: [nsimosci] Unbork console) Merging arm-current/fixes (c9d347e02776 ARM: 8009/1: dcscb.c: remove call to outer_flush_all()) Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for v3.14-rc1) Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5) Merging powerpc-merge/merge (cc4f265ad9a3 powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self) Merging sparc/master (455c6fdbd219 Linux 3.14) Merging net/master (f34c4a35d879 l2tp: take PMTU from tunnel UDP socket) Merging ipsec/master (5596732fa8c1 xfrm: Fix crash with ipv6 IPsec tunnel and NAT.) Merging sound-current/for-linus (a5065eb6da55 ALSA: usb-audio: Suppress repetitive debug messages from retire_playback_urb()) Merging pci-current/for-linus (707d4eefbdb3 Revert "[PATCH] Insert GART region into resource map") Merging wireless/master (5869e795e07d ath9k: fix a scheduling while atomic bug in CSA handling) Merging driver-core.current/driver-core-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging tty.current/tty-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging usb.current/usb-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging staging.current/staging-linus (4ba85265790b Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86) Merging char-misc.current/char-misc-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging input-current/for-linus (692d96552c9a Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (8ceee72808d1 crypto: ghash-clmulni-intel - use C implementation for setkey()) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for of_match_node()) Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter kernel symbols for arm) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling delayed works) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git:/
Re: [PATCH] tuntap: add flow control to support back pressure
On Thu, 2014-04-10 at 13:29 +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 09, 2014 at 10:19:40PM -0400, Steven Galgano wrote:
> > Add tuntap flow control support for use by back pressure routing protocols.
> > Setting the new TUNSETIFF flag IFF_FLOW_CONTROL, will signal resources as
> > unavailable when the tx queue limit is reached by issuing a
> > netif_tx_stop_all_queues() rather than discarding frames. A
> > netif_tx_wake_all_queues() is issued after reading a frame from the queue
> > to signal resource availability.
> >
> > Back pressure capability was previously supported by the legacy tun default
> > mode. This change restores that functionality, which was last present in
> > v3.7.
> >
> > Reported-by: Brian Adamson
> > Tested-by: Joseph Giovatto
> > Signed-off-by: Steven Galgano
>
> I don't think it's a good idea.
>
> This trivial flow control really created more problems than it was worth.
>
> In particular this blocks all flows so it's trivially easy for one flow
> to block and starve all others: just send a bunch of packets to loopback
> destinations that get queued all over the place.
>
> Luckily it was never documented so we changed the default and nothing
> seems to break, but we won't be so lucky if we add an explicit API.
>
>
> One way to implement this would be with ubuf_info callback this is
> already invoked in most places where a packet might get stuck for a long
> time. It's still incomplete though: this will prevent head of queue
> blocking literally forever, but a single bad flow can still degrade
> performance significantly.
This is send queue for tuntap. Like all other real nics, we can solve
this through fairness qdiscs?
>
> Another alternative is to try and isolate the flows that we
> can handle and throttle them.
>
> It's all fixable but we really need to fix the issues *before*
> exposing the interface to userspace.
>
>
>
> > ---
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index ee328ba..268130c 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -783,8 +783,19 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
> > struct net_device *dev)
> > * number of queues.
> > */
> > if (skb_queue_len(>socket.sk->sk_receive_queue) * numqueues
> > - >= dev->tx_queue_len)
> > - goto drop;
> > + >= dev->tx_queue_len) {
> > + if (tun->flags & TUN_FLOW_CONTROL) {
> > + /* Resources unavailable stop transmissions */
> > + netif_tx_stop_all_queues(dev);
> > +
> > + /* We won't see all dropped packets individually, so
> > +* over run error is more appropriate.
> > +*/
> > + dev->stats.tx_fifo_errors++;
> > + } else {
> > + goto drop;
> > + }
> > + }
> >
> > if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
> > goto drop;
> > @@ -1362,6 +1373,9 @@ static ssize_t tun_do_read(struct tun_struct *tun,
> > struct tun_file *tfile,
> > continue;
> > }
> >
> > + /* Wake in case resources previously signaled unavailable */
> > + netif_tx_wake_all_queues(tun->dev);
> > +
> > ret = tun_put_user(tun, tfile, skb, iv, len);
> > kfree_skb(skb);
> > break;
> > @@ -1550,6 +1564,9 @@ static int tun_flags(struct tun_struct *tun)
> > if (tun->flags & TUN_PERSIST)
> > flags |= IFF_PERSIST;
> >
> > + if (tun->flags & TUN_FLOW_CONTROL)
> > + flags |= IFF_FLOW_CONTROL;
> > +
> > return flags;
> > }
> >
> > @@ -1732,6 +1749,11 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr)
> > else
> > tun->flags &= ~TUN_TAP_MQ;
> >
> > + if (ifr->ifr_flags & IFF_FLOW_CONTROL)
> > + tun->flags |= TUN_FLOW_CONTROL;
> > + else
> > + tun->flags &= ~TUN_FLOW_CONTROL;
> > +
> > /* Make sure persistent devices do not get stuck in
> > * xoff state.
> > */
> > @@ -1900,7 +1922,8 @@ static long __tun_chr_ioctl(struct file *file,
> > unsigned int cmd,
> > * This is needed because we never checked for invalid flags on
> > * TUNSETIFF. */
> > return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
> > - IFF_VNET_HDR | IFF_MULTI_QUEUE,
> > + IFF_VNET_HDR | IFF_MULTI_QUEUE |
> > + IFF_FLOW_CONTROL,
> > (unsigned int __user*)argp);
> > } else if (cmd == TUNSETQUEUE)
> > return tun_set_queue(file, );
> > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> > index e9502dd..bcf2790 100644
> > --- a/include/uapi/linux/if_tun.h
> > +++ b/include/uapi/linux/if_tun.h
> > @@ -36,6 +36,7 @@
> > #define TUN_PERSIST0x0100
> > #define TUN_VNET_HDR
[tip:x86/platform] x86, calgary: Use 8M TCE table size by default
Commit-ID: 0534af01cca338193abbfdb53650af91e65dbf10
Gitweb: http://git.kernel.org/tip/0534af01cca338193abbfdb53650af91e65dbf10
Author: WANG Chao
AuthorDate: Mon, 10 Mar 2014 22:52:00 +0800
Committer: H. Peter Anvin
CommitDate: Thu, 10 Apr 2014 19:51:32 -0700
x86, calgary: Use 8M TCE table size by default
New kexec-tools wants to pass kdump kernel needed memmap via E820
directly, instead of memmap=exactmap. This makes saved_max_pfn not
be passed down to 2nd kernel. To keep 1st kernel and 2nd kernel using
the same TCE table size, Muli suggest to hard code the size to max (8M).
We can't get rid of saved_max_pfn this time, for backward compatibility
with old first kernel and new second kernel. However new first kernel
and old second kernel can not work unfortunately.
v2->v1:
- retain saved_max_pfn so new 2nd kernel can work with old 1st kernel
from Vivek
Signed-off-by: WANG Chao
Acked-by: Vivek Goyal
Acked-by: Muli Ben-Yehuda
Acked-by: Jon Mason
Link:
http://lkml.kernel.org/r/1394463120-26999-1-git-send-email-chaow...@redhat.com
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/pci-calgary_64.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 299d493..0497f71 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -1207,23 +1207,31 @@ error:
return ret;
}
-static inline int __init determine_tce_table_size(u64 ram)
+static inline int __init determine_tce_table_size(void)
{
int ret;
if (specified_table_size != TCE_TABLE_SIZE_UNSPECIFIED)
return specified_table_size;
- /*
-* Table sizes are from 0 to 7 (TCE_TABLE_SIZE_64K to
-* TCE_TABLE_SIZE_8M). Table size 0 has 8K entries and each
-* larger table size has twice as many entries, so shift the
-* max ram address by 13 to divide by 8K and then look at the
-* order of the result to choose between 0-7.
-*/
- ret = get_order(ram >> 13);
- if (ret > TCE_TABLE_SIZE_8M)
+ if (is_kdump_kernel() && saved_max_pfn) {
+ /*
+* Table sizes are from 0 to 7 (TCE_TABLE_SIZE_64K to
+* TCE_TABLE_SIZE_8M). Table size 0 has 8K entries and each
+* larger table size has twice as many entries, so shift the
+* max ram address by 13 to divide by 8K and then look at the
+* order of the result to choose between 0-7.
+*/
+ ret = get_order((saved_max_pfn * PAGE_SIZE) >> 13);
+ if (ret > TCE_TABLE_SIZE_8M)
+ ret = TCE_TABLE_SIZE_8M;
+ } else {
+ /*
+* Use 8M by default (suggested by Muli) if it's not
+* kdump kernel and saved_max_pfn isn't set.
+*/
ret = TCE_TABLE_SIZE_8M;
+ }
return ret;
}
@@ -1418,8 +1426,7 @@ int __init detect_calgary(void)
return -ENOMEM;
}
- specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
- saved_max_pfn : max_pfn) * PAGE_SIZE);
+ specified_table_size = determine_tce_table_size();
for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) {
struct calgary_bus_info *info = _info[bus];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / devfreq: Use freq_table for available_frequencies
Some devices use freq_table instead of OPP. For those devices, the
available_frequencies file shows up empty. Fix that by using freq_table to
generate the available_frequencies data when OPP is not present.
Signed-off-by: Saravana Kannan
---
drivers/devfreq/devfreq.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 2042ec3..a715d15 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -912,19 +912,26 @@ static ssize_t available_frequencies_show(struct device
*d,
struct devfreq *df = to_devfreq(d);
struct device *dev = df->dev.parent;
struct dev_pm_opp *opp;
+ unsigned int i = 0, max_state = df->profile->max_state;
+ bool use_opp;
ssize_t count = 0;
unsigned long freq = 0;
rcu_read_lock();
+ use_opp = dev_pm_opp_get_opp_count(dev) > 0;
do {
- opp = dev_pm_opp_find_freq_ceil(dev, );
- if (IS_ERR(opp))
- break;
+ if (use_opp) {
+ opp = dev_pm_opp_find_freq_ceil(dev, );
+ if (IS_ERR(opp))
+ break;
+ } else {
+ freq = df->profile->freq_table[i++];
+ }
count += scnprintf([count], (PAGE_SIZE - count - 2),
"%lu ", freq);
freq++;
- } while (1);
+ } while (use_opp || (!use_opp && i < max_state));
rcu_read_unlock();
/* Truncate the trailing space */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
Oh, there was another useful bit. 3.12.17-rt25 403991 384216 377786 405466 394011 392850 3.12.17-nopreempt 109049 186133 118766 !?!.. ew, TTWU_QUEUE 350385 318786 367336 !TTWU_QUEUE 326009 356939 378215 !TTWU_QUEUE IPI == low-pass filter. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A
On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote: > On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding > wrote: >> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote: >>> GK20A's timer is directly attached to the system timer and cannot be >>> calibrated. Skip the calibration phase on that chip since the >>> corresponding registers do not exist. >>> >>> Signed-off-by: Alexandre Courbot >>> --- >>> drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +-- >>> 1 file changed, 13 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c >>> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c >>> index c0bdd10358d7..822fe0d8a871 100644 >>> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c >>> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c >>> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object) >>> if (ret) >>> return ret; >>> >>> + /* gk20a does not have the calibration registers */ >>> + if (device->chipset == 0xea) >>> + goto skip_clk_init; >> >> I'm concerned that this won't scale in the future. Perhaps a better >> solution would be to add a "flags" or "features" field to struct >> nouveau_device along with feature bits such as HAS_CALIBRATION or >> similar. >> >> That way we don't have to touch this code for every new future Tegra >> chip. Unless perhaps if there's a reason to expect things to change in >> newer generations. > I've already handled this in a slightly different way in the tree I'd > previously pointed Alex at (I think!), as I needed to do the same for > GM107. > > Should just be able to use that implementation (so, just change the > probe patch) here too. I will skip this patch and use your implementation then. Btw, shouldn't the source file for the GK20A implementation be named nvea.c instead of gk20a.c? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 4/5] mfd: palmas: support IRQ inversion at the board level
On Fri, Apr 11, 2014 at 12:42 AM, Stephen Warren wrote: > On 04/10/2014 01:04 AM, Alexandre Courbot wrote: >> Stephen, any news about this patch? I'm waiting for it to be merged in >> order to resend some Tegra DTs, but still cannot see it in -next. > > To be honest, this became too painful to work on just to fix a warning > at boot which has no practical side-effect in our case. The best thing > to do is just merge your DTs for 3.16, and keep ignoring the warning > just like we always have on Dalmore. Hopefully at some point I (or > someone) will run out of higher priority work items and get back to this. Ok, fine by me. I will wait for -rc1, see if I can enable more devices with 3.16 and send you the updated DTs soon after. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] blk-mq: move request structures into struct blk_mq_tags
On 2014-04-10 04:01, Christoph Hellwig wrote: On Wed, Apr 09, 2014 at 10:23:32AM -0600, Jens Axboe wrote: This should go into block/blk-mq-tag.h. Ok. We might as well leave this, the mtip32xx conversion ends up using it. So if we pull it now, it'll just be reintroduced shortly. It's back in the latest revision of the patch, just taking a struct blk_mq_tag pointer now so that it can be used by SCSI as well. I've also changed an opencode variant of it to use the helper. Great. Will you send out an updated patchset? -- 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: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
(2014/04/11 2:00), Oleg Nesterov wrote:
> On 04/10, Oleg Nesterov wrote:
>>
>> On 04/10, Masami Hiramatsu wrote:
>>>
>>> (2014/04/10 22:41), Denys Vlasenko wrote:
There is this monstrosity, "16-bit override for branches" in 64-mode:
66 e8 nn nn callw
Nobody sane uses it because it truncates instruction pointer.
>>>
>>> No problem, insn.c can handle that too. :)
>>
>> Does it?
>>
>> "callw 1f; 1:\n"
>> "rep; nop\n"
>>
>> objdump:
>>
>> 66 e8 00 00 callw 485 <_init-0x3ffed3>
>> f3 90 pause
>>
>>
>> if we probe this "callw", we copy MAX_INSN_BYTES into auprobe->insn,
>> and after insn_get_length() (insn_complete() == T)
>>
>> // this is correct
>> OPCODE1() == e8
>>
>> // this all looks wrong
>> insn->length == 6
>> insn->immediate.value == -1863122944
>> insn->immediate.nbytes == 4
>>
>> so it seems that lib/insn.c treats the next "pause" insn as the high
>> 16 bits of address.
>
> Or perhaps lib/insn.c is fine but objdump is wrong? And everything
> should work correctly? Although in this case I do not understand what
> this "callw" actually does.
Yeah, I think objdump is wrong. see below.
>
> int main(void)
> {
> asm (
> "nop\n"
>
> "callw 1f; 1:\n"
> ".byte 0\n"
> ".byte 0\n"
> );
>
> return 0;
> }
>
> this runs just fine. With or without gdb. And gdb shows that ->ip is
> incremented by 6 after "callw".
>
> int main(void)
> {
> asm (
> "nop\n"
>
> "callw 1f; 1:\n"
> ".byte 10\n"
> ".byte 20\n"
> );
>
> return 0;
> }
>
> objdump:
>
> 0040047c :
> 40047c: 55 push %rbp
> 40047d: 48 89 e5mov%rsp,%rbp
> 400480: 90 nop
> 400481: 66 e8 00 00 callw 485 <_init-0x3ffed3>
> 400485: 0a 14 b8or (%rax,%rdi,4),%dl
> 400488: 00 00 add%al,(%rax)
> 40048a: 00 00 add%al,(%rax)
> 40048c: c9 leaveq
> 40048d: c3 retq
>
> run:
>
> $ ./t
> Segmentation fault (core dumped)
>
> $ gdb ./t core.*
> ...
> #0 0x144a0487 in ?? ()
>
> 0x144a0487 - 0x400481 == 0x140a0006, this matches the additional 2 .bytes
> treated
> as offset.
Ah, OK. Ive also forgotten the operand size prefix on x86/x86-64.
The callw is actually "call with operand-size override prefix".
The operand-size prefix(0x66) changes the number of bytes (size) of
its operand (including immediate). But that depends on the opcode.
As I said, opcode 0xe8 (call) has Jz operand (jump offset immediate
with 16bit or 32bit size, depends on the operand size).
And on x86-32, the default operand-size is 4bytes, and it
changes to 2bytes with the 0x66 prefix. This means that the "66 e8"
becomes "callw" on x86-32.
However, please see Intel SDM 2b, appendix A,
A.2.5 Superscripts Utilized in Opcode Tables
f64
The operand size is forced to a 64-bit operand size when in 64-bit mode
(prefixes that change operand size are ignored for this instruction in 64-bit
mode
And Table A-2. One-byte Opcode Map: (08H — FFH)
-
CALL(f64) Jz
-
Ah, I got this. This means that "call" on x86-64 never be "callw",
because the operand-size always 64bit, and in that case, immediate
is 4 bytes(*).
(*) again, at A.2.2 Codes for Operand Type
---
z Word for 16-bit operand-size or doubleword for 32 or 64-bit operand-size.
---
So, at least for this case, objdump is wrong. lib/insn.c is correct. :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
[RFC PATCH RT V3] rwsem: The return of multi-reader PI rwsems
Changes since v2 - move the setting of the rt_rw_limit to
late_initcall, and use 2 x nr_cpu_ids. Thanks to Paul McKenney for
suggesting using nr_cpu_ids instead of num_possible_cpus(). The 2x is
because out testing shows that 2x gives twice the performance as 1x
using Clark's whack_mmap_sem benchmark.
Also fixed the rwsem_reader_limit == 0. Now it gives much better
performance. The wrapper function to test rt_rw_limit tested zero
against the counter and not the rt_rw_limit. It didn't lock up because
it allowed a reader to take the lock if it was the only one. Basically
it simulated rt_rw_limit == 1.
I added Carsten to the Cc, so I'll post the entire change log of v1
here again.
-
A while back ago I wrote a patch that would allow for reader/writer
locks like rwlock and rwsems to have multiple readers in PREEMPT_RT. It
was slick and fast but unfortunately it was way too complex and ridden
with nasty little critters which earned me my large collection of
frozen sharks in the fridge (which are quite tasty).
The main problem with my previous solution was that I tried to be too
clever. I worked hard on making the rw mutex still have the "fast
path". That is, the cmpxchg that could allow a non contended grabbing
of the lock be one instruction and be off with it. But to get that
working required lots of tricks and black magic that was certainly
going to fail. Thus, with the raining of sharks on my parade, the
priority inheritance mutex with multiple owners died a slow painful
death.
So we thought.
But over the years, a new darkness was on the horizon. Complaints about
running highly threaded processes (did I hear Java?) were suffering
huge performance hits on the PREEMPT_RT kernel. Whether or not the
processes were real-time tasks, they still were horrible compared to
running the same tasks on the mainline kernel. Note, this was being
done on machines with many CPUs.
The culprit mostly was a single rwsem, the notorious mmap_sem that
can be taking several times for read, and as on RT, this is just a
single mutex, and it would serialize these accesses that would not
happen on mainline.
I looked back at my poor dead rw multi pi reader patch and thought to
myself. "How complex would this be if I removed the 'fast path' from
the code". I decided to build a new tower in Mordor.
I feel that I am correct. By removing the fast path and requiring all
accesses to the rwsem to go through the slow path (must take the
wait_lock to do anything). The code really wasn't that bad. I also only
focused on the rwsem and did not worry about the rwlocks as that hasn't
been pointed out as a bottle neck yet. If it does happen to be, this
code could easily work on rwlocks too.
I'm much more confident in this code than I was with my previous
version of the rwlock multi-reader patch. I added a bunch of comments
to this code to explain how things interact. The writer unlock was
still able to use the fast path as the writers are pretty much like a
normal mutex. Too bad that the writer unlock is not a high point of
contention.
This patch is built on top of the two other patches that I posted
earlier, which should not be as controversial.
If you have any benchmark on large machines I would be very happy if
you could test this patch against the unpatched version of -rt.
Cheers,
-- Steve
Signed-off-by: Steven Rostedt
Index: linux-rt.git/kernel/rtmutex.c
===
--- linux-rt.git.orig/kernel/rtmutex.c
+++ linux-rt.git/kernel/rtmutex.c
@@ -26,6 +26,21 @@
#include "rtmutex_common.h"
/*
+ * rt_rw_limit is the number of simultaneous readers of a rwsem lock.
+ *
+ * rt_rw_limit gets updated on boot up to the number of
+ * possible CPUs, but we need to initialize it to something other
+ * than zero.
+ */
+unsigned rt_rw_limit = NR_CPUS;
+
+/* cnt == 0 means unlimited */
+static inline int under_rt_rw_limit(int cnt)
+{
+ return !rt_rw_limit || cnt < rt_rw_limit;
+}
+
+/*
* lock->owner state tracking:
*
* lock->owner holds the task_struct pointer of the owner. Bit 0
@@ -110,19 +125,44 @@ static inline void init_lists(struct rt_
plist_head_init(>wait_list);
}
+static inline void init_rw_lists(struct rt_rw_mutex *rwlock)
+{
+ struct rt_mutex *lock = >mutex;
+
+ /*
+* A rwsem priority is initialized to -1 and never will
+* be that again.
+*/
+ if (unlikely(rwlock->prio < 0)) {
+ rwlock->prio = MAX_PRIO;
+ init_lists(lock);
+ }
+}
+
+static int rt_mutex_get_readers_prio(struct task_struct *task, int prio);
+static inline int task_has_reader_locks(struct task_struct *task);
+
/*
* Calculate task priority from the waiter list priority
*
* Return task->normal_prio when the waiter list is empty or when
* the waiter is not allowed to do priority boosting
+ *
+ * On PREEMPT_RT, we also check the priorities of the list
+ * of read locks that the task holds.
*/
int
Re: [GIT PULL] Audit subsystem for v3.15
My tree is fine, your tree is fine, but the merge (even if you solve the conflicts) has a build failure on MIPS just discovered when I published by 'merge-test' branch because of the syscall_get_arch(void) changes. (thanks to the kbuild test robot) attached is my solution which I just sent to the MIPS people. I hope that you can apply it as part of the merge itself... On Thu, 2014-04-10 at 19:53 -0400, Eric Paris wrote: > Linus, > > Please pull the audit tree for v3.15. You will have merge conflicts. > I'll publish my branch "merge-test" where I attempted to resolve them > the way you will. > > The main issue is an across tree change to syscall_get_arch(). I change > it from taking a task_struct and pt_regs to take a void. Not a single > arch used or needed either of these arguments. (For 3.16 we plan to > implement the function on more arches) > > There are a couple of conflicts where I made changes to #includes and > your tree also has some additions. Should be obvious. > > Two conflict issues with Kconfig changes. The first is just that your > tree has some additional 'select' lines mine didn't. Obvious to > resolve. > > The second is a conflict in init/Kconfig. I don't completely understand > it. I believe it was the addition of ALPHA to the gigantic depends > line. I cherry-picked the patch from your tree that introduced ALPHA > before I made the switch to HAVE_ARCH_AUDITSYSCALL. I believed that > would avoid the conflict, but I guess I was wrong. In any case, I have > the 'select HAVE_ARCH_AUDITSYSCALL' in alpha. > > There is also a conflict given the last second EPERM->ECONNREFUSED > switcheroo. My 3.15 is less restrictive. We return ECONNREFUSED only > for non-init username. Should be another easy one... > > Please let me know if anything isn't easy/obvious for you! > > Thank you! > > -Eric > > The following changes since commit b7d3622a39fde7658170b7f3cf6c6889bb8db30d: > > Merge tag 'v3.13' into for-3.15 (2014-03-07 11:41:32 -0500) > > are available in the git repository at: > > > git://git.infradead.org/users/eparis/audit.git master > > for you to fetch changes up to 312103d64d0fcadb332899a2c84b357ddb18f4e3: > > AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC > (2014-04-10 17:51:29 -0400) > > > AKASHI Takahiro (2): > audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL > audit: Add generic compat syscall support > > Chris Metcalf (1): > AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC > > Eric Paris (7): > audit: include subject in login records > syscall_get_arch: remove useless function arguments > audit: use uapi/linux/audit.h for AUDIT_ARCH declarations > audit: define audit_is_compat in kernel internal header > AUDIT: Allow login in non-init namespaces > audit: do not cast audit_rule_data pointers pointlesly > audit: renumber AUDIT_FEATURE_CHANGE into the 1300 range > > Eric W. Biederman (2): > audit: Use struct net not pid_t to remember the network namespce to > reply in > audit: Send replies in the proper network namespace. > > Joe Perches (1): > audit: remove stray newline from audit_log_execve_info() audit_panic() > call > > Josh Boyer (1): > audit: remove stray newlines from audit_log_lost messages > > Monam Agarwal (1): > kernel: Use RCU_INIT_POINTER(x, NULL) in audit.c > > Richard Guy Briggs (9): > audit: Use more current logging style again > capabilities: add descriptions for AUDIT_CONTROL and AUDIT_WRITE > audit: rename the misleading audit_get_context() to audit_take_context() > pid: get pid_t ppid of task in init_pid_ns > audit: convert PPIDs to the inital PID namespace. > audit: anchor all pid references in the initial pid namespace > audit: allow user processes to log from another PID namespace > audit: remove superfluous new- prefix in AUDIT_LOGIN messages > sched: declare pid_alive as inline > > William Roberts (3): > mm: Create utility function for accessing a tasks commandline value > proc: Update get proc_pid_cmdline() to use mm.h helpers > audit: Audit proc//cmdline aka proctitle > > 蔡正龙 (1): > alpha: Enable system-call auditing support. > > arch/alpha/Kconfig | 4 > arch/alpha/include/asm/ptrace.h | 5 + > arch/alpha/include/asm/thread_info.h | 2 ++ > arch/alpha/kernel/Makefile | 1 + > arch/alpha/kernel/audit.c| 60 > +++ > arch/alpha/kernel/entry.S| 6 +- > arch/alpha/kernel/ptrace.c | 4 > arch/arm/Kconfig | 1 + > arch/arm/include/asm/syscall.h | 5 ++--- > arch/ia64/Kconfig| 1 + > arch/mips/include/asm/syscall.h | 4 ++-- >
Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP
On 04/10/2014 06:19 AM, Romer, Benjamin M wrote: > > I'm confused by the intended behavior of KVM.. Is the intention of the > -cpu switch to fully emulate a particular CPU? If that's the case, the > Intel documentation says bit 31 should always be 0, so the value > returned by the cpuid instruction isn't correct. If the intention is to > present a VM with a specific CPU architecture, the CPU ought to behave > as described in Intel's virtualization documentation and just vmexit > instead of faulting with invalid op, IMHO. > > I've already said the check in the code was insufficient, and I'm trying > to fix that part now. :) > I'm still confused where KVM comes into the picture. Are you actually using KVM (and thus talking about nested virtualization) or are you using Qemu in JIT mode and running another hypervisor underneath? The hypervisor bit is a complete red herring. If the guest CPU is running in VT-x mode, then VMCALL should VMEXIT inside the guest (invoking the guest root VT-x), but the fact still remains that you should never, ever, invoke VMCALL unless you know what hypervisor you have underneath. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: ipv4: current group_info should be put after using.
There is a memory leak in ping when call ping in dumpstate.
Current group_info had been got in ping_init_sock and group_info->usage
increased. But the usage hasn't decreased.
This will make group_info never freed and cause memory leak.
unreferenced object 0xcd0e8840 (size 192):
comm "dumpstate", pid 7583, jiffies 78360 (age 91.810s)
hex dump (first 32 bytes):
02 00 00 00 06 00 00 00 01 00 00 00 ef 03 00 00
f1 03 00 00 f7 03 00 00 04 04 00 00 bb 0b 00 00
backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] __kmalloc+0xe7/0x1d0
[] groups_alloc+0x34/0xb0
[] SyS_setgroups+0x3c/0xf0
[] syscall_call+0x7/0xb
[] 0x
Signed-off-by: Chuansheng Liu
Signed-off-by: Zhang Dongxing
Signed-off-by: xiaoming wang
---
net/ipv4/ping.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index f4b19e5..2af7b1f 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -255,23 +255,28 @@ int ping_init_sock(struct sock *sk)
struct group_info *group_info = get_current_groups();
int i, j, count = group_info->ngroups;
kgid_t low, high;
+ int ret = 0;
inet_get_ping_group_range_net(net, , );
if (gid_lte(low, group) && gid_lte(group, high))
- return 0;
+ goto EXIT;
for (i = 0; i < group_info->nblocks; i++) {
int cp_count = min_t(int, NGROUPS_PER_BLOCK, count);
for (j = 0; j < cp_count; j++) {
kgid_t gid = group_info->blocks[i][j];
if (gid_lte(low, gid) && gid_lte(gid, high))
- return 0;
+ goto EXIT;
}
count -= cp_count;
}
- return -EACCES;
+ ret = -EACCES;
+
+EXIT:
+ put_group_info(group_info);
+ return ret;
}
EXPORT_SYMBOL_GPL(ping_init_sock);
--
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 03/27] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
On 04/11/2014 10:48 AM, Olof Johansson wrote: > On Thu, Apr 10, 2014 at 06:37:14PM +0900, Chanwoo Choi wrote: >> This patch add memory mapping for PMU (Power Management Unit) which is used >> for power control of Exynos3250. >> >> Signed-off-by: Chanwoo Choi >> Signed-off-by: Kyungmin Park > > Signed-off-by is in the wrong order, if Kyungmin wrote the patch and you're > just posting it... No, I implemented this patch and posted it. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron
Cc: Kukjin Kim
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
drivers/iio/adc/exynos_adc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..4cd1975 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -88,6 +88,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -308,6 +309,13 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
+ info->sclk = devm_clk_get(>dev, "sclk_tsadc");
+ if (IS_ERR(info->sclk)) {
+ dev_warn(>dev, "failed getting sclk clock, err = %ld\n",
+ PTR_ERR(info->sclk));
+ info->sclk = NULL;
+ }
+
info->vdd = devm_regulator_get(>dev, "vdd");
if (IS_ERR(info->vdd)) {
dev_err(>dev, "failed getting regulator, err = %ld\n",
@@ -341,6 +349,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_iio_dev;
clk_prepare_enable(info->clk);
+ clk_prepare_enable(info->sclk);
exynos_adc_hw_init(info);
@@ -357,6 +366,7 @@ err_of_populate:
exynos_adc_remove_devices);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->sclk);
err_iio_dev:
iio_device_unregister(indio_dev);
err_irq:
@@ -373,6 +383,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
exynos_adc_remove_devices);
regulator_disable(info->vdd);
clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->sclk);
writel(0, info->enable_reg);
iio_device_unregister(indio_dev);
free_irq(info->irq, info);
@@ -398,6 +409,7 @@ static int exynos_adc_suspend(struct device *dev)
}
clk_disable_unprepare(info->clk);
+ clk_disable_unprepare(info->sclk);
writel(0, info->enable_reg);
regulator_disable(info->vdd);
@@ -416,6 +428,7 @@ static int exynos_adc_resume(struct device *dev)
writel(1, info->enable_reg);
clk_prepare_enable(info->clk);
+ clk_prepare_enable(info->sclk);
exynos_adc_hw_init(info);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/27] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
On Thu, Apr 10, 2014 at 06:37:14PM +0900, Chanwoo Choi wrote: > This patch add memory mapping for PMU (Power Management Unit) which is used > for power control of Exynos3250. > > Signed-off-by: Chanwoo Choi > Signed-off-by: Kyungmin Park Signed-off-by is in the wrong order, if Kyungmin wrote the patch and you're just posting it... -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo Choi wrote:
> This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
> is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses
> Cortex-A7
> dual cores and has a target speed of 1.0GHz.
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/Kconfig | 22 ++
> arch/arm/mach-exynos/exynos.c| 1 +
> arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
> 3 files changed, 33 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index fc8bf18..6da8a68 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -11,6 +11,17 @@ if ARCH_EXYNOS
>
> menu "SAMSUNG EXYNOS SoCs Support"
>
> +config ARCH_EXYNOS3
> + bool "SAMSUNG EXYNOS3"
> + select ARM_AMBA
> + select CLKSRC_OF
> + select HAVE_ARM_SCU if SMP
> + select HAVE_SMP
> + select PINCTRL
> + select PM_GENERIC_DOMAINS if PM_RUNTIME
> + help
> + Samsung EXYNOS3 SoCs based systems
> +
> config ARCH_EXYNOS4
> bool "SAMSUNG EXYNOS4"
> default y
> @@ -41,6 +52,17 @@ config ARCH_EXYNOS5
>
> comment "EXYNOS SoCs"
>
> +config SOC_EXYNOS3250
> + bool "SAMSUNG EXYNOS3250"
> + default y
> + depends on ARCH_EXYNOS3
> + select ARCH_HAS_BANDGAP
> + select ARM_CPU_SUSPEND if PM
> + select PINCTRL_EXYNOS
> + select SAMSUNG_DMADEV
> + help
> + Enable EXYNOS3250 CPU support
> +
> config CPU_EXYNOS4210
> bool "SAMSUNG EXYNOS4210"
> default y
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index b32a907..b134868 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -370,6 +370,7 @@ static void __init exynos_dt_machine_init(void)
> }
>
> static char const *exynos_dt_compat[] __initconst = {
> + "samsung,exynos3250",
Please consider samsung,exynos3 instead, so you don't have to update this table
for every SoC. We've talked about this before..
> "samsung,exynos4",
> "samsung,exynos4210",
> "samsung,exynos4212",
> diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
> b/arch/arm/plat-samsung/include/plat/cpu.h
> index 5992b8d..3d808f6b 100644
> --- a/arch/arm/plat-samsung/include/plat/cpu.h
> +++ b/arch/arm/plat-samsung/include/plat/cpu.h
> @@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
> #define S5PV210_CPU_ID 0x4311
> #define S5PV210_CPU_MASK 0xF000
>
> +#define EXYNOS3250_SOC_ID 0xE3472000
> +#define EXYNOS3_SOC_MASK0xF000
> +
> #define EXYNOS4210_CPU_ID0x4321
> #define EXYNOS4212_CPU_ID0x4322
> #define EXYNOS4412_CPU_ID0xE4412200
> @@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
> IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
> IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
> IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
> +IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
> IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
> IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
> IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
> @@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
> EXYNOS5_SOC_MASK)
> # define soc_is_s5pv210()0
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +# define soc_is_exynos3250()is_samsung_exynos3250()
> +#else
> +# define soc_is_exynos3250()0
> +#endif
In general, I think we have too much code littered with soc_is_() going
on, so please try to avoid adding more for this SoC. Especially in cases where
you just want to bail out of certain features where we might already have
function pointers to control if a function is called or not, such as the
firmware interfaces.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/27] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
On Thu, Apr 10, 2014 at 06:37:15PM +0900, Chanwoo Choi wrote:
> From: Kyungmin Park
>
> This patch fix the offset of CPU boot address and change parameter of smc call
> of SMC_CMD_CPU1BOOT command for Exynos4212.
>
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/firmware.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index 932129e..91a911d 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -18,6 +18,8 @@
>
> #include
>
> +#include
> +
> #include "smc.h"
>
> static int exynos_do_idle(void)
> @@ -28,14 +30,22 @@ static int exynos_do_idle(void)
>
> static int exynos_cpu_boot(int cpu)
> {
> - exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> + if (soc_is_exynos4212())
> + exynos_smc(SMC_CMD_CPU1BOOT, 0, 0, 0);
> + else
> + exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
/* */
if (soc_is_exynos4212())
cpu = 0;
...and then do the call as before.
> return 0;
> }
>
> static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
> {
> - void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
> + void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>
> + if (soc_is_exynos4212())
> + goto out;
> + else
> + boot_reg += 4*cpu;
if (!soc_is_exynos4212())
boot_reg += 4 * cpu;
That way you avoid a goto, especially since the "goto out" isn't actually
an "out", it's still doing stuff at the end of the funciton.
> +out:
> __raw_writel(boot_addr, boot_reg);
> return 0;
> }
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tuntap: add flow control to support back pressure
On 04/10/2014 06:29 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 09, 2014 at 10:19:40PM -0400, Steven Galgano wrote:
>> Add tuntap flow control support for use by back pressure routing protocols.
>> Setting the new TUNSETIFF flag IFF_FLOW_CONTROL, will signal resources as
>> unavailable when the tx queue limit is reached by issuing a
>> netif_tx_stop_all_queues() rather than discarding frames. A
>> netif_tx_wake_all_queues() is issued after reading a frame from the queue to
>> signal resource availability.
>>
>> Back pressure capability was previously supported by the legacy tun default
>> mode. This change restores that functionality, which was last present in
>> v3.7.
>>
>> Reported-by: Brian Adamson
>> Tested-by: Joseph Giovatto
>> Signed-off-by: Steven Galgano
>
> I don't think it's a good idea.
>
> This trivial flow control really created more problems than it was worth.
>
> In particular this blocks all flows so it's trivially easy for one flow
> to block and starve all others: just send a bunch of packets to loopback
> destinations that get queued all over the place.
>
> Luckily it was never documented so we changed the default and nothing
> seems to break, but we won't be so lucky if we add an explicit API.
>
>
> One way to implement this would be with ubuf_info callback this is
> already invoked in most places where a packet might get stuck for a long
> time. It's still incomplete though: this will prevent head of queue
> blocking literally forever, but a single bad flow can still degrade
> performance significantly.
>
> Another alternative is to try and isolate the flows that we
> can handle and throttle them.
>
> It's all fixable but we really need to fix the issues *before*
> exposing the interface to userspace.
>
>
>
It was only after recent upgrades that we picked up a newer kernel and
discovered the change to the default tun mode.
The new default behavior has broken applications that depend on the
legacy behavior. Although not documented, the legacy behavior was well
known at least to those working in the back pressure research community.
The default legacy mode was/is a valid use case although I am not sure
it fits with recent multiqueue support.
When back pressure protocols are running over a tun interface they
require legacy flow control in order to communicate congestion detected
on the physical media they are using. Multiqueues do not apply here.
These protocols only use one queue, so netif_tx_stop_all_queues() is the
necessary behavior.
I'm not tied to the idea of IFF_FLOW_CONTROL. I was aiming for middle
ground where an application controlling the tun interface can state it
wants the legacy flow control behavior understanding its limitations
concerning multiple queues.
What if we resurrect IFF_ONE_QUEUE and use that as a mechanism to
indicate legacy flow control. A tun instance initially configured with
IFF_ONE_QUEUE would not be allowed to attach or detach queues with
TUNSETQUEUE and any additional opens with the same device name would
fail. This mode would use the
netif_tx_stop_all_queues()/netif_tx_wake_all_queues() flow control
mechanism.
If a tun application wants the current default behavior with only a
single queue, it would not set the IFF_ONE_QUEUE flag. Not setting
IFF_MULTI_QUEUE would not imply IFF_ONE_QUEUE.
I'd be happy to implement this change if it is an acceptable solution.
This would allow multiqueue tun development to advance while still
supporting use cases dependent on legacy flow control.
-steve
>> ---
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ee328ba..268130c 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -783,8 +783,19 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb,
>> struct net_device *dev)
>> * number of queues.
>> */
>> if (skb_queue_len(>socket.sk->sk_receive_queue) * numqueues
>> - >= dev->tx_queue_len)
>> -goto drop;
>> +>= dev->tx_queue_len) {
>> +if (tun->flags & TUN_FLOW_CONTROL) {
>> +/* Resources unavailable stop transmissions */
>> +netif_tx_stop_all_queues(dev);
>> +
>> +/* We won't see all dropped packets individually, so
>> + * over run error is more appropriate.
>> + */
>> +dev->stats.tx_fifo_errors++;
>> +} else {
>> +goto drop;
>> +}
>> +}
>>
>> if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
>> goto drop;
>> @@ -1362,6 +1373,9 @@ static ssize_t tun_do_read(struct tun_struct *tun,
>> struct tun_file *tfile,
>> continue;
>> }
>>
>> +/* Wake in case resources previously signaled unavailable */
>> +netif_tx_wake_all_queues(tun->dev);
>> +
>> ret = tun_put_user(tun, tfile, skb, iv, len);
>> kfree_skb(skb);
>>
Re: hpsa driver bug crack kernel down!
On 04/10/14 at 04:34pm, Jiang Liu wrote:
> Hi Baoquan,
> Could you please help to give output of "lspci -"?
> Is device "hpsa :03:00.0" a legacy PCI device(non-PCIe)?
> It may have relationship with IOMMU driver.
> Thanks!
> Gerry
Hi,
I just saw your mail now. Do you still need the output of "lspci -"
on my test machine?
In fact, I didn't see the DMAR error related to intel vt-d issues.
If the output is helpful, I can make a latest build to do this.
Thanks
Baoquan
>
> On 2014/4/10 12:03, Bjorn Helgaas wrote:
> > [+cc Joerg, iommu list]
> >
> > On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso wrote:
> >> On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
> >>> On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote:
> On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote:
> > On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote:
> >> [+linux-scsi]
> >> On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote:
> >>> On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote:
> Hi,
>
> The kernel is 3.14.0+ which is pulled just now.
> >>>
> >>> Cc'ing more people.
> >>>
> >>> While the hpsa driver appears to be involved in some way, I'm sure if
> >>> this is a related issue, but as of today's pull I'm getting another
> >>> problem that causes my DL980 not to come up.
> >>>
> >>> *Massive* amounts of:
> >>>
> >>> DMAR:[fault reason 02] Present bit in context entry is clear
> >>> dmar: DRHD: handling fault status reg 602
> >>> dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
> >>>
> >>> Then:
> >>>
> >>> hpsa :03:00.0: Controller lockup detected: 0x
> >>> ...
> >>> Workqueue: events hpsa_monitor_ctlr_worker [hpsa]
> >>> ...
> >>>
> >>> Screenshot of the actual LOCKUP:
> >>> http://stgolabs.net/hpsa-hard-lockup-3.14+.png
> >>>
> >>> While I haven't bisected, things worked fine until at least until
> >>> commit
> >>> 39de65aa2c3e (April 2nd).
> >>>
> >>> Any ideas?
> >>
> >> Well, it's either a DMA remapping issue or a hpsa one. Your assertion
> >> that everything worked fine until 39de65aa2c3e would tend to vindicate
> >> hpsa,
>
> Hmm here you mean DMA, right?
> >>>
> >>> No, it vindicates the hpsa changes ... they don't seem to be causing
> >>> problems until something goes wrong with dma remapping.
> >>>
> > because all the hpsa changes went in before that under
> > Missing crucial info:
> >
> > commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1
> >
> >> Merge: 3e75c6d b2bff6c
> >> Author: Linus Torvalds
> >> Date: Tue Apr 1 18:49:04 2014 -0700
> >>
> >> Merge tag 'scsi-misc' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> >>
> >> can you revalidate that this commit works OK just to make sure?
>
> Ok so I don't see those DMA messages and system starts just fine. I'm
> thinking perhaps something broke after the IO mmu stuff in commit
> 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly
> causing the CPU stalls and just blame hpsa in the path as a side effect?
>
> /me goes out to try the commit.
> >>>
> >>> That's my guess. The DMAR messages are DMA remapping issues caused in
> >>> the IOMMU. If I had to guess, I'd say the DMAR fault message is
> >>> indicating the IOMMU is calling for a mapping address before it can
> >>> satisfy the driver read request, which is causing the hang apparently in
> >>> the hpsa driver.
> >>>
> >>> I've added linux-pci to the cc; I think they deal with iommu issues on
> >>> x86.
> >>
> >> So that merge commit appears to be the culprit, I see both the DMA
> >> messages and the lockup blaming hpsa...
> >
> > My understanding so far (please correct me if I'm wrong):
> >
> > 39de65aa2c3e OK ("Merge branch 'i2c/for-next'")
> > 1a0b6abaea78 OK ("Merge tag 'scsi-misc'")
> > 3f583bc21977 BAD ("Merge tag 'iommu-updates-v3.15'")
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi, On 04/10/2014 06:43 PM, Arnd Bergmann wrote: > On Thursday 10 April 2014 18:28:18 Chanwoo Choi wrote: >> This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that >> is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses >> Cortex-A7 >> dual cores and has a target speed of 1.0GHz. >> >> Signed-off-by: Chanwoo Choi >> Signed-off-by: Kyungmin Park >> --- >> arch/arm/mach-exynos/Kconfig | 22 ++ >> arch/arm/mach-exynos/exynos.c| 1 + >> arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ >> 3 files changed, 33 insertions(+) >> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig >> index fc8bf18..6da8a68 100644 >> --- a/arch/arm/mach-exynos/Kconfig >> +++ b/arch/arm/mach-exynos/Kconfig >> @@ -11,6 +11,17 @@ if ARCH_EXYNOS >> >> menu "SAMSUNG EXYNOS SoCs Support" >> >> +config ARCH_EXYNOS3 >> +bool "SAMSUNG EXYNOS3" >> +select ARM_AMBA >> +select CLKSRC_OF >> +select HAVE_ARM_SCU if SMP >> +select HAVE_SMP >> +select PINCTRL >> +select PM_GENERIC_DOMAINS if PM_RUNTIME >> +help >> + Samsung EXYNOS3 SoCs based systems >> + > > Isn't S5PV210 also called an Exynos3 these days? Are we going to get > any conflicts here when merging that code into Exynos as Tomasz has > suggested in the past? I knew. But, S5PV210/S5PC110 has not yet included in Exynos3 category on mainline. Need opinion of Exynos SoC Maintainer to clear this ambiguous stuff. Dear Kukjin and Tomasz, I need your opinion about this patch. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Re: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
(2014/04/10 23:28), Oleg Nesterov wrote: > On 04/10, Masami Hiramatsu wrote: >> >> (2014/04/10 22:41), Denys Vlasenko wrote: >>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote: On 04/08, Jim Keniston wrote: > > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote: >> 0xe8. Anything else? > > No, I think e8 is the only call instruction uprobes will see. Good. >>> >>> There is this monstrosity, "16-bit override for branches" in 64-mode: >>> >>> 66 e8 nn nn callw >>> >>> Nobody sane uses it because it truncates instruction pointer. >> >> No problem, insn.c can handle that too. :) > > Does it? > > "callw 1f; 1:\n" > "rep; nop\n" > > objdump: > > 66 e8 00 00 callw 485 <_init-0x3ffed3> > f3 90 pause > > > if we probe this "callw", we copy MAX_INSN_BYTES into auprobe->insn, > and after insn_get_length() (insn_complete() == T) > > // this is correct > OPCODE1() == e8 > > // this all looks wrong > insn->length == 6 > insn->immediate.value == -1863122944 > insn->immediate.nbytes == 4 Oops, that should be a bug in insn.c! I'll fix that asap! Thank you, > > so it seems that lib/insn.c treats the next "pause" insn as the high > 16 bits of address. > > Oleg. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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 2/6] shm: add sealing API
On 04/10/2014 05:22 PM, David Herrmann wrote: > Hi > > On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby > wrote: >> For O_DIRECT the kernel pins the submitted pages in memory for DMA by >> incrementing the page reference counts when the I/O is submitted, >> allowing the pages to be modified by DMA even if they are no longer >> mapped in the address space of the process. This is different from a >> regular read(), which uses the CPU to copy the data and will fail if the >> pages are not mapped. > > Can you please provide an example code-path? For instance, > file_read_actor() does not pin any pages but only keeps the user-space > address and resolves it once it has data to write. This may be an issue for anything in the kernel that calls get_user_pages and holds onto the result at any time that mmap_sem isn't held. I don't know exactly what does that, but RDMA comes to mind. So does (ugh!) vmsplice, although I suspect that vmsplice doesn't write. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf list: Fix --raw-dump argument
Jiri Olsa wrote: > but looks like the usage is for bash completion only, so we probably > need only the first example functionality above. > > If this is the case I think it should not be an option but another > command like 'raw-dump'. I decided that there's no point making it an option, so I've sent you a patch making it a subcommand instead. 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 08/27] pinctrl: exynos: Add driver data for Exynos3250
Hi, On 04/11/2014 04:17 AM, Tomasz Figa wrote: > Hi, > > On 10.04.2014 20:42, Linus Walleij wrote: >> On Thu, Apr 10, 2014 at 11:28 AM, Chanwoo Choi wrote: >> >>> From: Tomasz Figa >>> >>> This patch adds driver data (bank list and EINT layout) for Exynos3250 >>> to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional >>> input/output >>> ports. There are 23 general port groups. >>> >>> Signed-off-by: Tomasz Figa >>> Signed-off-by: Kyungmin Park >> >> Ugh can Tomasz send out his patches himself, I get confused... >> It was also sent two times, the second time with CC:s added. >> Tomasz, shall I merge this? > > I'm fine with this patch being sent by Chanwoo, although he should have > probably added his sign-off to the list, as the person sending it. > > Chanwoo, can you make sure that there is your sign-off on all the patches > from this series? > OK, I'll add my sign-off to all the patches on next posting(v2). Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 list: Fix --raw-dump argument
While adding usage information, 44d742e (perf list: Add usage,
2013-10-30) broke
$ perf list --raw-dump
Fix this by making raw-dump a subcommand.
Cc: David Ahern
Cc: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Ramkumar Ramachandra
---
tools/perf/builtin-list.c | 2 +-
tools/perf/perf-completion.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..c74aef5 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -53,7 +53,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, false);
- else if (strcmp(argv[i], "--raw-dump") == 0)
+ else if (strcmp(argv[i], "raw-dump") == 0)
print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index ae3a576..8f518f0 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -119,7 +119,7 @@ __perf_main ()
fi
# List possible events for -e option
elif [[ $prev == "-e" && "${words[1]}" == @(record|stat|top) ]]; then
- evts=$($cmd list --raw-dump)
+ evts=$($cmd list raw-dump)
__perfcomp_colon "$evts" "$cur"
# List subcommands for 'perf kvm'
elif [[ $prev == "kvm" ]]; then
--
1.9.2.667.ge5b74e1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/27] ARM: EXYNOS:: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
On 04/10/2014 09:07 PM, Marc Zyngier wrote:
> On Thu, Apr 10 2014 at 11:56:33 am BST, Chanwoo Choi
> wrote:
>> On 04/10/2014 06:51 PM, Marc Zyngier wrote:
>>> On Thu, Apr 10 2014 at 10:28:23 am BST, Chanwoo Choi
>>> wrote:
This patch decide proper lowpower mode of either a15 or a9 according to
own ID
from Main ID register.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/hotplug.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c
b/arch/arm/mach-exynos/hotplug.c
index 5eead53..36d3db6 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,13 +135,20 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
- * we're ready for shutdown now, so do it.
- * Exynos4 is A9 based while Exynos5 is A15; check the CPU part
+ * we're ready for shutdown now, so do it. Exynos4 is A9 based
+ * while Exynos5 is A15/Exynos7 is A7; check the CPU part
* number by reading the Main ID register and then perform the
* appropriate sequence for entering low power.
*/
asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
>>>
>>> While you're touching that code, how about using:
>>>
>>> primary_part = read_cpuid(CPUID_ID);
>>
>> Or,
>> I suggest read_cpuid_part_number() instead of assembler directly.
>>
>> primary_part = read_cpuid_part_number();
>
> Yup, even better.
>
>>>
- if ((primary_part & 0xfff0) == 0xc0f0)
+
+ /*
+ * Main ID register of Cortex series
+ * - Cortex-a7 : 0x410F_C07x
+ * - Cortex-a15 : 0x410F_C0Fx
+ */
+ primary_part = primary_part & 0xfff0;
+ if (primary_part == 0xc0f0 || primary_part == 0xc070)
>>>
>>> ARM_CPU_PART_CORTEX_A15, ARM_CPU_PART_CORTEX_A7
>>
>> OK I'll use this defined constant as following:
>>
>> switch (primary_part)
>> case ARM_CPU_PART_CORTEX_A7:
>> case ARM_CPU_PART_CORTEX_A15:
>> cpu_enter_lowpower_a15();
>> break;
>> default:
>> cpu_enter_lowpower_a9();
>> break;
>> }
>
> Looks good.
>
Thanks for your review.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/14] thunderbolt: Initialize root switch and ports
This patch adds the structures tb_switch and tb_port as well as code to
initialize the root switch.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/switch.c | 186 +++
drivers/thunderbolt/tb.c | 8 ++
drivers/thunderbolt/tb.h | 138
4 files changed, 333 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/switch.c
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 1f996bb..4ac18d9 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o tb.o
+thunderbolt-objs := nhi.o ctl.o tb.o switch.o
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
new file mode 100644
index 000..e89121f
--- /dev/null
+++ b/drivers/thunderbolt/switch.c
@@ -0,0 +1,186 @@
+/*
+ * Thunderbolt Cactus Ridge driver - switch/port utility functions
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+
+#include "tb.h"
+
+/* port utility functions */
+
+static const char *tb_port_type(struct tb_regs_port_header *port)
+{
+ switch (port->type >> 16) {
+ case 0:
+ switch ((u8) port->type) {
+ case 0:
+ return "Inactive";
+ case 1:
+ return "Port";
+ case 2:
+ return "NHI";
+ default:
+ return "unknown";
+ }
+ case 0x2:
+ return "Ethernet";
+ case 0x8:
+ return "SATA";
+ case 0xe:
+ return "DP/HDMI";
+ case 0x10:
+ return "PCIe";
+ case 0x20:
+ return "USB";
+ default:
+ return "unknown";
+ }
+}
+
+static void tb_dump_port(struct tb *tb, struct tb_regs_port_header *port)
+{
+ tb_info(tb,
+ " Port %d: %x:%x (Revision: %d, TB Version: %d, Type: %s
(%#x))\n",
+ port->port_number, port->vendor_id, port->device_id,
+ port->revision, port->thunderbolt_version, tb_port_type(port),
+ port->type);
+ tb_info(tb, " Max hop id (in/out): %d/%d\n",
+ port->max_in_hop_id, port->max_out_hop_id);
+ tb_info(tb, " Max counters: %d\n", port->max_counters);
+ tb_info(tb, " NFC Credits: %#x\n", port->nfc_credits);
+}
+
+/**
+ * tb_init_port() - initialize a port
+ *
+ * This is a helper method for tb_switch_alloc. Does not check or initialize
+ * any downstream switches.
+ *
+ * Return: Returns 0 on success or an error code on failure.
+ */
+static int tb_init_port(struct tb_switch *sw, u8 port_nr)
+{
+ int res;
+ struct tb_port *port = >ports[port_nr];
+ port->sw = sw;
+ port->port = port_nr;
+ port->remote = NULL;
+ res = tb_port_read(port, >config, TB_CFG_PORT, 0, 8);
+ if (res)
+ return res;
+
+ tb_dump_port(sw->tb, >config);
+
+ /* TODO: Read dual link port, DP port and more from EEPROM. */
+ return 0;
+
+}
+
+/* switch utility functions */
+
+static void tb_dump_switch(struct tb *tb, struct tb_regs_switch_header *sw)
+{
+ tb_info(tb,
+ " Switch: %x:%x (Revision: %d, TB Version: %d)\n",
+ sw->vendor_id, sw->device_id, sw->revision,
+ sw->thunderbolt_version);
+ tb_info(tb, " Max Port Number: %d\n", sw->max_port_number);
+ tb_info(tb, " Config:\n");
+ tb_info(tb,
+ " Upstream Port Number: %d Depth: %d Route String: %#llx
Enabled: %d, PlugEventsDelay: %dms\n",
+ sw->upstream_port_number, sw->depth,
+ (((u64) sw->route_hi) << 32) | sw->route_lo,
+ sw->enabled, sw->plug_events_delay);
+ tb_info(tb,
+ " unknown1: %#x unknown4: %#x\n",
+ sw->__unknown1, sw->__unknown4);
+}
+
+/**
+ * tb_switch_free() - free a tb_switch and all downstream switches
+ */
+void tb_switch_free(struct tb_switch *sw)
+{
+ int i;
+ /* port 0 is the switch itself and never has a remote */
+ for (i = 1; i <= sw->config.max_port_number; i++) {
+ if (tb_is_upstream_port(>ports[i]))
+ continue;
+ if (sw->ports[i].remote)
+ tb_switch_free(sw->ports[i].remote->sw);
+ sw->ports[i].remote = NULL;
+ }
+
+ kfree(sw->ports);
+ kfree(sw);
+}
+
+/**
+ * tb_switch_alloc() - allocate and initialize a switch
+ *
+ * Return: Returns a NULL on failure.
+ */
+struct tb_switch *tb_switch_alloc(struct tb *tb, u64 route)
+{
+ int i;
+ struct tb_switch *sw;
+ int upstream_port = tb_cfg_get_upstream_port(tb->ctl, route);
+ if (upstream_port < 0)
+ return NULL;
+
+ sw = kzalloc(sizeof(*sw),
Re: [PATCH 1/3] perf bench: Set more defaults in the 'numa' suite
Jiri Olsa wrote: > ### > # 1 task will execute (on 1 nodes, 4 CPUs): > # -1x 1MB global shared mem operations > # -1x 0MB process shared mem operations > # -1x 0MB thread local mem operations > ### > ... > > > '-1x' does not seem right/intentional for default case As you can see from print_summary(), -1 is the value of nr_loops. In init_params(), Ingo set nr_loops is set to -1 in his original patch -- I haven't touched that. So, unless I'm missing something, it's quite an apt default case. Ram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/14] thunderbolt: Add thunderbolt capability handling
Thunderbolt config areas contain capability lists similar to those found
on pci devices. This patch introduces a tb_find_cap utility method to
search for capabilities.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/cap.c| 116 +++
drivers/thunderbolt/tb.h | 2 +
3 files changed, 119 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/cap.c
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 4ac18d9..617b314 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o tb.o switch.o
+thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o
diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
new file mode 100644
index 000..a7b47e7
--- /dev/null
+++ b/drivers/thunderbolt/cap.c
@@ -0,0 +1,116 @@
+/*
+ * Thunderbolt Cactus Ridge driver - capabilities lookup
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+#include
+
+#include "tb.h"
+
+
+struct tb_cap_any {
+ union {
+ struct tb_cap_basic basic;
+ struct tb_cap_extended_short extended_short;
+ struct tb_cap_extended_long extended_long;
+ };
+} __packed;
+
+static bool tb_cap_is_basic(struct tb_cap_any *cap)
+{
+ /* basic.cap is u8. This checks only the lower 8 bit of cap. */
+ return cap->basic.cap != 5;
+}
+
+static bool tb_cap_is_long(struct tb_cap_any *cap)
+{
+ return !tb_cap_is_basic(cap)
+ && cap->extended_short.next == 0
+ && cap->extended_short.length == 0;
+}
+
+static enum tb_cap tb_cap(struct tb_cap_any *cap)
+{
+ if (tb_cap_is_basic(cap))
+ return cap->basic.cap;
+ else
+ /* extended_short/long have cap at the same offset. */
+ return cap->extended_short.cap;
+}
+
+static u32 tb_cap_next(struct tb_cap_any *cap, u32 offset)
+{
+ int next;
+ if (offset == 1) {
+ /*
+* The first pointer is part of the switch header and always
+* a simple pointer.
+*/
+ next = cap->basic.next;
+ } else {
+ /*
+* Somehow Intel decided to use 3 different types of capability
+* headers. It is not like anyone could have predicted that
+* single byte offsets are not enough...
+*/
+ if (tb_cap_is_basic(cap))
+ next = cap->basic.next;
+ else if (!tb_cap_is_long(cap))
+ next = cap->extended_short.next;
+ else
+ next = cap->extended_long.next;
+ }
+ /*
+* "Hey, we could terminate some capability lists with a null offset
+* and others with a pointer to the last element." - "Great idea!"
+*/
+ if (next == offset)
+ return 0;
+ return next;
+}
+
+/**
+ * tb_find_cap() - find a capability
+ *
+ * Return: Returns a positive offset if the capability was found and 0 if not.
+ * Returns an error code on failure.
+ */
+int tb_find_cap(struct tb_port *port, enum tb_cfg_space space, enum tb_cap cap)
+{
+ u32 offset = 1;
+ struct tb_cap_any header;
+ int res;
+ int retries = 10;
+ while (retries--) {
+ res = tb_port_read(port, , space, offset, 1);
+ if (res) {
+ /* Intel needs some help with linked lists. */
+ if (space == TB_CFG_PORT && offset == 0xa
+ && port->config.type == TB_TYPE_DP_HDMI_OUT) {
+ offset = 0x39;
+ continue;
+ }
+ return res;
+ }
+ if (offset != 1) {
+ if (tb_cap() == cap)
+ return offset;
+ if (tb_cap_is_long()) {
+ /* tb_cap_extended_long is 2 dwords */
+ res = tb_port_read(port, , space,
+ offset, 2);
+ if (res)
+ return res;
+ }
+ }
+ offset = tb_cap_next(, offset);
+ if (!offset)
+ return 0;
+ }
+ tb_port_WARN(port,
+"run out of retries while looking for cap %#x in config
space %d, last offset: %#x\n",
+cap, space, offset);
+ return -EIO;
+}
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 9f01800..e620f1b 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -159,6 +159,8 @@ void thunderbolt_shutdown_and_free(struct tb
[PATCH v2 04/14] thunderbolt: Add tb_regs.h
Every thunderbolt device consists (logically) of a switch with multiple
ports. Every port contains up to four config regions (HOPS, PORT,
SWITCH, COUNTERS) which are used to configure the device.
The tb_regs.h file contains all known registers and capabilities from
these config regions.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/tb.c | 5 +
drivers/thunderbolt/tb_regs.h | 213 ++
2 files changed, 218 insertions(+)
create mode 100644 drivers/thunderbolt/tb_regs.h
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 6920979..164dea0 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -9,6 +9,7 @@
#include
#include "tb.h"
+#include "tb_regs.h"
/* hotplug handling */
@@ -100,6 +101,10 @@ struct tb *thunderbolt_alloc_and_start(struct tb_nhi *nhi)
{
struct tb *tb;
+ BUILD_BUG_ON(sizeof(struct tb_regs_switch_header) != 5 * 4);
+ BUILD_BUG_ON(sizeof(struct tb_regs_port_header) != 8 * 4);
+ BUILD_BUG_ON(sizeof(struct tb_regs_hop) != 2 * 4);
+
tb = kzalloc(sizeof(*tb), GFP_KERNEL);
if (!tb)
return NULL;
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
new file mode 100644
index 000..6577af7
--- /dev/null
+++ b/drivers/thunderbolt/tb_regs.h
@@ -0,0 +1,213 @@
+/*
+ * Thunderbolt Cactus Ridge driver - Port/Switch config area registers
+ *
+ * Every thunderbolt device consists (logically) of a switch with multiple
+ * ports. Every port contains up to four config regions (HOPS, PORT, SWITCH,
+ * COUNTERS) which are used to configure the device.
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#ifndef _TB_REGS
+#define _TB_REGS
+
+#include
+
+
+#define TB_ROUTE_SHIFT 8 /* number of bits in a port entry of a route */
+
+
+/*
+ * TODO: should be 63? But we do not know how to receive frames larger than 256
+ * bytes at the frame level. (header + checksum = 16, 60*4 = 240)
+ */
+#define TB_MAX_CONFIG_RW_LENGTH 60
+
+enum tb_cap {
+ TB_CAP_PHY = 0x0001,
+ TB_CAP_TIME1= 0x0003,
+ TB_CAP_PCIE = 0x0004,
+ TB_CAP_I2C = 0x0005,
+ TB_CAP_PLUG_EVENTS = 0x0105, /* also EEPROM */
+ TB_CAP_TIME2= 0x0305,
+ TB_CAL_IECS = 0x0405,
+ TB_CAP_LINK_CONTROLLER = 0x0605, /* also IECS */
+};
+
+enum tb_port_state {
+ TB_PORT_DISABLED= 0, /* tb_cap_phy.disable == 1 */
+ TB_PORT_CONNECTING = 1, /* retry */
+ TB_PORT_UP = 2,
+ TB_PORT_UNPLUGGED = 7,
+};
+
+/* capability headers */
+
+struct tb_cap_basic {
+ u8 next;
+ /* enum tb_cap cap:8; prevent "narrower than values of its type" */
+ u8 cap; /* if cap == 0x05 then we have a extended capability */
+} __packed;
+
+struct tb_cap_extended_short {
+ u8 next; /* if next and length are zero then we have a long cap */
+ enum tb_cap cap:16;
+ u8 length;
+} __packed;
+
+struct tb_cap_extended_long {
+ u8 zero1;
+ enum tb_cap cap:16;
+ u8 zero2;
+ u16 next;
+ u16 length;
+} __packed;
+
+/* capabilities */
+
+struct tb_cap_link_controller {
+ struct tb_cap_extended_long cap_header;
+ u32 count:4; /* number of link controllers */
+ u32 unknown1:4;
+ u32 base_offset:8; /*
+ * offset (into this capability) of the configuration
+ * area of the first link controller
+ */
+ u32 length:12; /* link controller configuration area length */
+ u32 unknown2:4; /* TODO check that length is correct */
+} __packed;
+
+struct tb_cap_phy {
+ struct tb_cap_basic cap_header;
+ u32 unknown1:16;
+ u32 unknown2:14;
+ bool disable:1;
+ u32 unknown3:11;
+ enum tb_port_state state:4;
+ u32 unknown4:2;
+} __packed;
+
+struct tb_eeprom_ctl {
+ bool clock:1; /* send pulse to transfer one bit */
+ bool access_low:1; /* set to 0 before access */
+ bool data_out:1; /* to eeprom */
+ bool data_in:1; /* from eeprom */
+ bool access_high:1; /* set to 1 before access */
+ bool not_present:1; /* should be 0 */
+ bool unknown1:1;
+ bool present:1; /* should be 1 */
+ u32 unknown2:24;
+} __packed;
+
+struct tb_cap_plug_events {
+ struct tb_cap_extended_short cap_header;
+ u32 __unknown1:2;
+ u32 plug_events:5;
+ u32 __unknown2:25;
+ u32 __unknown3;
+ u32 __unknown4;
+ struct tb_eeprom_ctl eeprom_ctl;
+ u32 __unknown5[7];
+ u32 drom_offset; /* 32 bit register, but eeprom addresses are 16 bit */
+} __packed;
+
+/* device headers */
+
+/* Present on port 0 in TB_CFG_SWITCH at address zero. */
+struct tb_regs_switch_header {
+ /* DWORD 0 */
+ u16 vendor_id;
+ u16 device_id;
+ /* DWORD 1 */
+ u32
[PATCH v2 07/14] thunderbolt: Enable plug events
Thunderbolt switches have a plug events capability. This patch adds the
tb_plug_events_active method and uses it to activate plug events during
switch allocation.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/switch.c | 46
drivers/thunderbolt/tb.h | 1 +
2 files changed, 47 insertions(+)
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index e89121f..21457cc 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -99,6 +99,39 @@ static void tb_dump_switch(struct tb *tb, struct
tb_regs_switch_header *sw)
}
/**
+ * tb_plug_events_active() - enable/disable plug events on a switch
+ *
+ * Also configures a sane plug_events_delay of 255ms.
+ *
+ * Return: Returns 0 on success or an error code on failure.
+ */
+static int tb_plug_events_active(struct tb_switch *sw, bool active)
+{
+ u32 data;
+ int res;
+
+ sw->config.plug_events_delay = 0xff;
+ res = tb_sw_write(sw, ((u32 *) >config) + 4, TB_CFG_SWITCH, 4, 1);
+ if (res)
+ return res;
+
+ res = tb_sw_read(sw, , TB_CFG_SWITCH, sw->cap_plug_events + 1, 1);
+ if (res)
+ return res;
+
+ if (active) {
+ data = data & 0xFF83;
+ if (sw->config.device_id == 0x1547)
+ data |= 4;
+ } else {
+ data = data | 0x7c;
+ }
+ return tb_sw_write(sw, , TB_CFG_SWITCH,
+ sw->cap_plug_events + 1, 1);
+}
+
+
+/**
* tb_switch_free() - free a tb_switch and all downstream switches
*/
void tb_switch_free(struct tb_switch *sw)
@@ -113,6 +146,8 @@ void tb_switch_free(struct tb_switch *sw)
sw->ports[i].remote = NULL;
}
+ tb_plug_events_active(sw, false);
+
kfree(sw->ports);
kfree(sw);
}
@@ -125,6 +160,7 @@ void tb_switch_free(struct tb_switch *sw)
struct tb_switch *tb_switch_alloc(struct tb *tb, u64 route)
{
int i;
+ int cap;
struct tb_switch *sw;
int upstream_port = tb_cfg_get_upstream_port(tb->ctl, route);
if (upstream_port < 0)
@@ -177,6 +213,16 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, u64 route)
/* TODO: I2C, IECS, EEPROM, link controller */
+ cap = tb_find_cap(>ports[0], TB_CFG_SWITCH, TB_CAP_PLUG_EVENTS);
+ if (cap < 0) {
+ tb_sw_warn(sw, "cannot find TB_CAP_PLUG_EVENTS aborting\n");
+ goto err;
+ }
+ sw->cap_plug_events = cap;
+
+ if (tb_plug_events_active(sw, true))
+ goto err;
+
return sw;
err:
kfree(sw->ports);
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index e620f1b..feb6c7a 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -19,6 +19,7 @@ struct tb_switch {
struct tb_regs_switch_header config;
struct tb_port *ports;
struct tb *tb;
+ int cap_plug_events; /* offset, zero if not found */
};
/**
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
On Thu, Apr 10, 2014 at 4:38 PM, Tony Lindgren wrote: > Currently we get the following kind of errors if we try to use interrupt > phandles to irqchips that have not yet initialized: > > irq: no irq domain found for /ocp/pinmux@48002030 ! > [ cut here ] > WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 > of_device_alloc+0x144/0x184() > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012 > (show_stack+0x14/0x1c) > (dump_stack+0x6c/0xa0) > (warn_slowpath_common+0x64/0x84) > (warn_slowpath_null+0x1c/0x24) > (of_device_alloc+0x144/0x184) > (of_platform_device_create_pdata+0x44/0x9c) > (of_platform_bus_create+0xd0/0x170) > (of_platform_bus_create+0x12c/0x170) > (of_platform_populate+0x60/0x98) > > This is because we're wrongly trying to populate resources that are not yet > available. It's perfectly valid to create irqchips dynamically, so let's > fix up the issue by populating the interrupt resources at the driver probe > time instead. > > Note that at least currently we cannot dynamically allocate the resources as > bus > specific code may add legacy resources with platform_device_add_resources() > before the driver probe. At least omap_device_alloc() currently relies on > num_resources to determine if legacy resources should be added. Some of these > will clear automatically when mach-omap2 boots with DT only, but there are > probably other places too where platform_device_add_resources() modifies > things before driver probe. > > This patch was discussed quite a bit earlier, but so far it seems we don't > have any better options to fix the problem. For the earlier discussion, > please see: > > https://lkml.org/lkml/2013/11/22/520 There is a newer solution here which Grant seemed happier with: http://lkml.iu.edu/hypermail/linux/kernel/1403.2/03666.html Does it work for you? > The addition of of_platform_probe() is based on patches posted earlier by > Thierry Reding . I fail to see how this patch does EPROBE_DEFER and solves the problem. Don't you need Thierry's other patches for that? I'm probably missing something. 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/
[PATCH v2 08/14] thunderbolt: Scan for downstream switches
Add utility methods tb_port_state and tb_wait_for_port. Add
tb_scan_switch which recursively checks for downstream switches.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/switch.c | 97
drivers/thunderbolt/tb.c | 44
drivers/thunderbolt/tb.h | 16
3 files changed, 157 insertions(+)
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 21457cc..279b9c5 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -53,6 +53,92 @@ static void tb_dump_port(struct tb *tb, struct
tb_regs_port_header *port)
}
/**
+ * tb_port_state() - get connectedness state of a port
+ *
+ * The port must have a TB_CAP_PHY (i.e. it should be a real port).
+ *
+ * Return: Returns an enum tb_port_state on success or an error code on
failure.
+ */
+static int tb_port_state(struct tb_port *port)
+{
+ struct tb_cap_phy phy;
+ int res;
+ if (port->cap_phy == 0) {
+ tb_port_WARN(port, "does not have a PHY\n");
+ return -EINVAL;
+ }
+ res = tb_port_read(port, , TB_CFG_PORT, port->cap_phy, 2);
+ if (res)
+ return res;
+ return phy.state;
+}
+
+/**
+ * tb_wait_for_port() - wait for a port to become ready
+ *
+ * Wait up to 1 second for a port to reach state TB_PORT_UP. If
+ * wait_if_unplugged is set then we also wait if the port is in state
+ * TB_PORT_UNPLUGGED (it takes a while for the device to be registered after
+ * switch resume). Otherwise we only wait if a device is registered but the
link
+ * has not yet been established.
+ *
+ * Return: Returns an error code on failure. Returns 0 if the port is not
+ * connected or failed to reach state TB_PORT_UP within one second. Returns 1
+ * if the port is connected and in state TB_PORT_UP.
+ */
+int tb_wait_for_port(struct tb_port *port, bool wait_if_unplugged)
+{
+ int retries = 10;
+ int state;
+ if (!port->cap_phy) {
+ tb_port_WARN(port, "does not have PHY\n");
+ return -EINVAL;
+ }
+ if (tb_is_upstream_port(port)) {
+ tb_port_WARN(port, "is the upstream port\n");
+ return -EINVAL;
+ }
+
+ while (retries--) {
+ state = tb_port_state(port);
+ if (state < 0)
+ return state;
+ if (state == TB_PORT_DISABLED) {
+ tb_port_info(port, "is disabled (state: 0)\n");
+ return 0;
+ }
+ if (state == TB_PORT_UNPLUGGED) {
+ if (wait_if_unplugged) {
+ /* used during resume */
+ tb_port_info(port,
+"is unplugged (state: 7),
retrying...\n");
+ msleep(100);
+ continue;
+ }
+ tb_port_info(port, "is unplugged (state: 7)\n");
+ return 0;
+ }
+ if (state == TB_PORT_UP) {
+ tb_port_info(port,
+"is connected, link is up (state: 2)\n");
+ return 1;
+ }
+
+ /*
+* After plug-in the state is TB_PORT_CONNECTING. Give it some
+* time.
+*/
+ tb_port_info(port,
+"is connected, link is not up (state: %d),
retrying...\n",
+state);
+ msleep(100);
+ }
+ tb_port_warn(port,
+"failed to reach state TB_PORT_UP. Ignoring port...\n");
+ return 0;
+}
+
+/**
* tb_init_port() - initialize a port
*
* This is a helper method for tb_switch_alloc. Does not check or initialize
@@ -63,6 +149,7 @@ static void tb_dump_port(struct tb *tb, struct
tb_regs_port_header *port)
static int tb_init_port(struct tb_switch *sw, u8 port_nr)
{
int res;
+ int cap;
struct tb_port *port = >ports[port_nr];
port->sw = sw;
port->port = port_nr;
@@ -71,6 +158,16 @@ static int tb_init_port(struct tb_switch *sw, u8 port_nr)
if (res)
return res;
+ /* Port 0 is the switch itself and has no PHY. */
+ if (port->config.type == TB_TYPE_PORT && port_nr != 0) {
+ cap = tb_find_cap(port, TB_CFG_PORT, TB_CAP_PHY);
+
+ if (cap > 0)
+ port->cap_phy = cap;
+ else
+ tb_port_WARN(port, "non switch port without a PHY\n");
+ }
+
tb_dump_port(sw->tb, >config);
/* TODO: Read dual link port, DP port and more from EEPROM. */
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index f1b6100..3b716fd 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -11,6
[PATCH v2 02/14] thunderbolt: Add control channel interface
Thunderbolt devices are configured by reading/writing into their
configuration space (similar to pci). This is done by sending packets
through the NHI (native host interface) onto the control channel.
This patch handles the low level packet based protocol and exposes
higher level operations like tb_cfg_read/tb_cfg_write.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/ctl.c| 731 +++
drivers/thunderbolt/ctl.h| 75 +
3 files changed, 807 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/ctl.c
create mode 100644 drivers/thunderbolt/ctl.h
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index d473ab9..4b21c99 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o
+thunderbolt-objs := nhi.o ctl.o
diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
new file mode 100644
index 000..8f9a2e2
--- /dev/null
+++ b/drivers/thunderbolt/ctl.c
@@ -0,0 +1,731 @@
+/*
+ * Thunderbolt Cactus Ridge driver - control channel and configuration commands
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ctl.h"
+
+
+struct ctl_pkg {
+ struct tb_ctl *ctl;
+ void *buffer;
+ struct ring_frame frame;
+};
+
+#define TB_CTL_RX_PKG_COUNT 10
+
+/**
+ * struct tb_cfg - thunderbolt control channel
+ */
+struct tb_ctl {
+ struct tb_nhi *nhi;
+ struct tb_ring *tx;
+ struct tb_ring *rx;
+
+ struct dma_pool *frame_pool;
+ struct ctl_pkg *rx_packets[TB_CTL_RX_PKG_COUNT];
+ DECLARE_KFIFO(response_fifo, struct ctl_pkg*, 16);
+ struct completion response_ready;
+
+ hotplug_cb callback;
+ void *callback_data;
+};
+
+
+#define tb_ctl_WARN(ctl, format, arg...) \
+ dev_WARN(&(ctl)->nhi->pdev->dev, format, ## arg)
+
+#define tb_ctl_err(ctl, format, arg...) \
+ dev_err(&(ctl)->nhi->pdev->dev, format, ## arg)
+
+#define tb_ctl_warn(ctl, format, arg...) \
+ dev_warn(&(ctl)->nhi->pdev->dev, format, ## arg)
+
+#define tb_ctl_info(ctl, format, arg...) \
+ dev_info(&(ctl)->nhi->pdev->dev, format, ## arg)
+
+
+/* configuration packets definitions */
+
+enum tb_cfg_pkg_type {
+ TB_CFG_PKG_READ = 1,
+ TB_CFG_PKG_WRITE = 2,
+ TB_CFG_PKG_ERROR = 3,
+ TB_CFG_PKG_NOTIFY_ACK = 4,
+ TB_CFG_PKG_EVENT = 5,
+ TB_CFG_PKG_XDOMAIN_REQ = 6,
+ TB_CFG_PKG_XDOMAIN_RESP = 7,
+ TB_CFG_PKG_OVERRIDE = 8,
+ TB_CFG_PKG_RESET = 9,
+ TB_CFG_PKG_PREPARE_TO_SLEEP = 0xd,
+};
+
+/* common header */
+struct tb_cfg_header {
+ u32 route_hi:22;
+ u32 unknown:10; /* highest order bit is set on replies */
+ u32 route_lo;
+} __packed;
+
+/* additional header for read/write packets */
+struct tb_cfg_address {
+ u32 offset:13; /* in dwords */
+ u32 length:6; /* in dwords */
+ u32 port:6;
+ enum tb_cfg_space space:2;
+ u32 seq:2; /* sequence number */
+ u32 zero:3;
+} __packed;
+
+/* TB_CFG_PKG_READ, response for TB_CFG_PKG_WRITE */
+struct cfg_read_pkg {
+ struct tb_cfg_header header;
+ struct tb_cfg_address addr;
+} __packed;
+
+/* TB_CFG_PKG_WRITE, response for TB_CFG_PKG_READ */
+struct cfg_write_pkg {
+ struct tb_cfg_header header;
+ struct tb_cfg_address addr;
+ u32 data[64]; /* maximum size, tb_cfg_address.length has 6 bits */
+} __packed;
+
+/* TB_CFG_PKG_ERROR */
+struct cfg_error_pkg {
+ struct tb_cfg_header header;
+ enum tb_cfg_error error:4;
+ u32 zero1:4;
+ u32 port:6;
+ u32 zero2:2; /* Both should be zero, still they are different fields. */
+ u32 zero3:16;
+} __packed;
+
+/* TB_CFG_PKG_EVENT */
+struct cfg_event_pkg {
+ struct tb_cfg_header header;
+ u32 port:6;
+ u32 zero:25;
+ bool unplug:1;
+} __packed;
+
+/* TB_CFG_PKG_RESET */
+struct cfg_reset_pkg {
+ struct tb_cfg_header header;
+} __packed;
+
+/* TB_CFG_PKG_PREPARE_TO_SLEEP */
+struct cfg_pts_pkg {
+ struct tb_cfg_header header;
+ u32 data;
+} __packed;
+
+
+/* utility functions */
+
+static u64 get_route(struct tb_cfg_header header)
+{
+ return (u64) header.route_hi << 32 | header.route_lo;
+}
+
+static struct tb_cfg_header make_header(u64 route)
+{
+ struct tb_cfg_header header = {
+ .route_hi = route >> 32,
+ .route_lo = route,
+ };
+ /* check for overflow, route_hi is not 32 bits! */
+ WARN_ON(get_route(header) != route);
+ return header;
+}
+
+static int check_header(struct ctl_pkg *pkg, u32 len, enum tb_cfg_pkg_type
type,
+ u64 route)
+{
+ struct tb_cfg_header *header = pkg->buffer;
+
+ /* check frame, TODO: frame flags */
+ if (WARN(len != pkg->frame.size,
[PATCH v2 09/14] thunderbolt: Handle hotplug events
We reveive a plug event callback whenever a thunderbolt device is added
or removed. This patch fills in the tb_handle_hotplug method and starts
reacting to these events by adding/removing switches from the hierarchy.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/switch.c | 42 +++-
drivers/thunderbolt/tb.c | 46 +++-
drivers/thunderbolt/tb.h | 3 +++
3 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 279b9c5..c092f7c 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -195,6 +195,24 @@ static void tb_dump_switch(struct tb *tb, struct
tb_regs_switch_header *sw)
sw->__unknown1, sw->__unknown4);
}
+struct tb_switch *get_switch_at_route(struct tb_switch *sw, u64 route)
+{
+ u8 next_port = route; /*
+ * Routes use a stride of 8 bits,
+ * eventhough a port index has 6 bits at most.
+ * */
+ if (route == 0)
+ return sw;
+ if (next_port > sw->config.max_port_number)
+ return 0;
+ if (tb_is_upstream_port(>ports[next_port]))
+ return 0;
+ if (!sw->ports[next_port].remote)
+ return 0;
+ return get_switch_at_route(sw->ports[next_port].remote->sw,
+ route >> TB_ROUTE_SHIFT);
+}
+
/**
* tb_plug_events_active() - enable/disable plug events on a switch
*
@@ -243,7 +261,8 @@ void tb_switch_free(struct tb_switch *sw)
sw->ports[i].remote = NULL;
}
- tb_plug_events_active(sw, false);
+ if (!sw->is_unplugged)
+ tb_plug_events_active(sw, false);
kfree(sw->ports);
kfree(sw);
@@ -327,3 +346,24 @@ err:
return NULL;
}
+/**
+ * tb_sw_set_unpplugged() - set is_unplugged on switch and downstream switches
+ */
+void tb_sw_set_unpplugged(struct tb_switch *sw)
+{
+ int i;
+ if (sw == sw->tb->root_switch) {
+ tb_sw_WARN(sw, "cannot unplug root switch\n");
+ return;
+ }
+ if (sw->is_unplugged) {
+ tb_sw_WARN(sw, "is_unplugged already set\n");
+ return;
+ }
+ sw->is_unplugged = true;
+ for (i = 0; i <= sw->config.max_port_number; i++) {
+ if (!tb_is_upstream_port(>ports[i]) && sw->ports[i].remote)
+ tb_sw_set_unpplugged(sw->ports[i].remote->sw);
+ }
+}
+
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 3b716fd..1efcacc 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -71,11 +71,55 @@ static void tb_handle_hotplug(struct work_struct *work)
{
struct tb_hotplug_event *ev = container_of(work, typeof(*ev), work);
struct tb *tb = ev->tb;
+ struct tb_switch *sw;
+ struct tb_port *port;
mutex_lock(>lock);
if (!tb->hotplug_active)
goto out; /* during init, suspend or shutdown */
- /* do nothing for now */
+ sw = get_switch_at_route(tb->root_switch, ev->route);
+ if (!sw) {
+ tb_warn(tb,
+ "hotplug event from non existent switch %llx:%x
(unplug: %d)\n",
+ ev->route, ev->port, ev->unplug);
+ goto out;
+ }
+ if (ev->port > sw->config.max_port_number) {
+ tb_warn(tb,
+ "hotplug event from non existent port %llx:%x (unplug:
%d)\n",
+ ev->route, ev->port, ev->unplug);
+ goto out;
+ }
+ port = >ports[ev->port];
+ if (tb_is_upstream_port(port)) {
+ tb_warn(tb,
+ "hotplug event for upstream port %llx:%x (unplug:
%d)\n",
+ ev->route, ev->port, ev->unplug);
+ goto out;
+ }
+ if (ev->unplug) {
+ if (port->remote) {
+ tb_port_info(port, "unplugged\n");
+ tb_sw_set_unpplugged(port->remote->sw);
+ tb_switch_free(port->remote->sw);
+ port->remote = NULL;
+ } else {
+ tb_port_info(port,
+"got unplug event for disconnected port,
ignoring\n");
+ }
+ } else if (port->remote) {
+ tb_port_info(port,
+"got plug event for connected port, ignoring\n");
+ } else {
+ tb_port_info(port, "hotplug: scanning\n");
+ tb_scan_port(port);
+ if (!port->remote) {
+ tb_port_info(port, "hotplug: no switch found\n");
+ } else if (port->remote->sw->config.depth > 1) {
+ tb_sw_warn(port->remote->sw,
+
[PATCH v2 12/14] pci: Suspend/resume support for appel thunderbolt
This patch makes changes to the pcieport driver to support thunderbolt
suspend/resume on apple systems. We need to perform two different
actions during suspend and resume:
The whole controller has to be powered down before suspend. If this is
not done then the NHI device will be gone after resume if a thunderbolt
device was plugged in while suspending. The controller represents itself
as multiple PCI devices/bridges. To power it down we hook into the
upstream bridge of the controller and call the magic ACPI methods. Power
will be restored automatically during resume (by the firmware
presumably).
During resume we have to wait for the NHI do reestablish all pci
tunnels. Since there is no parent-child relationship between the NHI
and the bridges we have to explicitly wait for them using
device_pm_wait_for_dev. We do this in the resume_noirq phase of the
downstream bridges of the controller (which lead into the thunderbolt
tunnels).
Signed-off-by: Andreas Noever
---
drivers/pci/pcie/portdrv_pci.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 0d8fdc4..6d33666 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
#include "portdrv.h"
#include "aer/aerdrv.h"
@@ -79,6 +82,114 @@ static int pcie_portdrv_restore_config(struct pci_dev *dev)
}
#ifdef CONFIG_PM
+
+#if defined(CONFIG_THUNDERBOLT) || defined(CONFIG_THUNDERBOLT_MODULE)
+
+bool is_thunderbolt(struct pci_dev *pdev)
+{
+ if (!dmi_match(DMI_PRODUCT_NAME, "MacBookPro10,1"))
+ return false;
+ return pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x1547;
+}
+
+static void shutdown_thunderbolt_controller(struct pci_dev *pdev)
+{
+ /*
+* The thunderbolt controller consists of a pcie switch with downstream
+* bridges leading to the NHI (native host interface) and to the tunnel
+* pci bridges.
+*
+* Without the following quirk the NHI will not resume if a tb device
was
+* plugged in before suspend.
+*
+* This quirk cuts power to the whole chip. Therefore we have to apply
it
+* during suspend_noirq of the upstream bridge.
+*
+* Power is automagically restored before resume. No action is needed.
+*/
+ acpi_handle bridge, SXIO, SXFP, SXLV;
+ if (!is_thunderbolt(pdev))
+ return;
+ if (pci_pcie_type(pdev) != PCI_EXP_TYPE_UPSTREAM)
+ return;
+ bridge = ACPI_HANDLE(>dev);
+ if (!bridge)
+ return;
+ /*
+* TB bridges in external devices might have the same device id as those
+* on the host, but they will not have the associated ACPI methods. This
+* implicitly checks that we are at the right bridge.
+*/
+ if (ACPI_FAILURE(acpi_get_handle(bridge, "DSB0.NHI0.SXIO", ))
+ || ACPI_FAILURE(acpi_get_handle(bridge, "DSB0.NHI0.SXFP",
))
+ || ACPI_FAILURE(acpi_get_handle(bridge, "DSB0.NHI0.SXLV",
)))
+ return;
+ dev_info(>dev, "cutting power to thunderbolt controller...\n");
+
+ /* save registers manually, the pci core won't be able to do later */
+ pci_save_state(pdev);
+ pci_prepare_to_sleep(pdev);
+
+ /* magic sequence */
+ acpi_execute_simple_method(SXIO, NULL, 1);
+ acpi_execute_simple_method(SXFP, NULL, 0);
+ msleep(300);
+ acpi_execute_simple_method(SXLV, NULL, 0);
+ acpi_execute_simple_method(SXIO, NULL, 0);
+ acpi_execute_simple_method(SXLV, NULL, 0);
+}
+
+static void wait_for_thunderbolt_controller(struct pci_dev *pdev)
+{
+ struct pci_dev *sibling = NULL;
+ struct pci_dev *nhi = NULL;
+ /*
+* During suspend the thunderbolt controller is reset and all pci
+* tunnels are lost. The NHI driver will try to reestablish all tunnels
+* during resume. We have to manually wait for the NHI since there is
+* no parent child relationship between the NHI and the tunneled
+* bridges.
+*/
+ if (!is_thunderbolt(pdev))
+ return;
+ if (pci_pcie_type(pdev) != PCI_EXP_TYPE_DOWNSTREAM)
+ return;
+ /*
+* Find the NHI and confirm that we are a bridge on the tb host
+* controller and not on a tb endpoint.
+*/
+ sibling = pci_get_slot(pdev->bus, 0x0);
+ if (sibling == pdev)
+ goto out; /* we are the downstream bridge to the NHI */
+ if (!sibling || !sibling->subordinate)
+ goto out;
+ nhi = pci_get_slot(sibling->subordinate, 0x0);
+ if (!nhi)
+ goto out;
+ if (nhi->vendor != PCI_VENDOR_ID_INTEL || nhi->device != 0x1547
+ || nhi->subsystem_vendor != 0x
+
[PATCH v2 14/14] thunderbolt: Add suspend/hibernate support
We use _noirq since we have to restore the pci tunnels before the pci
core wakes the tunneled devices.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/nhi.c| 32 +
drivers/thunderbolt/switch.c | 84
drivers/thunderbolt/tb.c | 61
drivers/thunderbolt/tb.h | 5 +++
4 files changed, 182 insertions(+)
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index fd2e3ee..426d280 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -7,6 +7,7 @@
* Copyright (c) 2014 Andreas Noever
*/
+#include
#include
#include
#include
@@ -492,6 +493,22 @@ static irqreturn_t nhi_msi(int irq, void *data)
return IRQ_HANDLED;
}
+static int nhi_suspend_noirq(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct tb *tb = pci_get_drvdata(pdev);
+ thunderbolt_suspend(tb);
+ return 0;
+}
+
+static int nhi_resume_noirq(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct tb *tb = pci_get_drvdata(pdev);
+ thunderbolt_resume(tb);
+ return 0;
+}
+
static void nhi_shutdown(struct tb_nhi *nhi)
{
int i;
@@ -600,6 +617,20 @@ static void nhi_remove(struct pci_dev *pdev)
nhi_shutdown(nhi);
}
+/*
+ * The tunneled pci bridges are siblings of us. Use _noirq such that the
tunnels
+ * can be reactivate asap after a suspend.
+ */
+static const struct dev_pm_ops nhi_pm_ops = {
+ .suspend_noirq = nhi_suspend_noirq,
+ .resume_noirq = nhi_resume_noirq,
+ .freeze_noirq = nhi_suspend_noirq, /*
+ * we just disable hotplug, the
+ * pci-tunnels stay alive.
+ */
+ .restore_noirq = nhi_resume_noirq,
+};
+
struct pci_device_id nhi_ids[] = {
{
/*
@@ -621,6 +652,7 @@ static struct pci_driver nhi_driver = {
.id_table = nhi_ids,
.probe = nhi_probe,
.remove = nhi_remove,
+ .driver.pm = _pm_ops,
};
static int __init nhi_init(void)
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index eef5f1c..2e19045 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -229,6 +229,30 @@ static void tb_dump_switch(struct tb *tb, struct
tb_regs_switch_header *sw)
sw->__unknown1, sw->__unknown4);
}
+/**
+ * reset_switch() - reconfigure route, enable and send TB_CFG_PKG_RESET
+ *
+ * Return: Returns 0 on success or an error code on failure.
+ */
+int tb_switch_reset(struct tb *tb, u64 route)
+{
+ struct tb_cfg_result res;
+ struct tb_regs_switch_header header = {
+ header.route_hi = route >> 32,
+ header.route_lo = route,
+ header.enabled = true,
+ };
+ tb_info(tb, "resetting switch at %llx\n", route);
+ res.err = tb_cfg_write(tb->ctl, ((u32 *) ) + 2, route,
+ 0, 2, 2, 2);
+ if (res.err)
+ return res.err;
+ res = tb_cfg_reset(tb->ctl, route, TB_CFG_DEFAULT_TIMEOUT);
+ if (res.err > 0)
+ return -EIO;
+ return res.err;
+}
+
struct tb_switch *get_switch_at_route(struct tb_switch *sw, u64 route)
{
u8 next_port = route; /*
@@ -406,3 +430,63 @@ void tb_sw_set_unpplugged(struct tb_switch *sw)
}
}
+int tb_switch_resume(struct tb_switch *sw)
+{
+ int i, err;
+ u64 uid;
+ tb_sw_info(sw, "resuming switch\n");
+
+ err = tb_eeprom_read_uid(sw, );
+ if (err) {
+ tb_sw_warn(sw, "uid read failed\n");
+ return err;
+ }
+ if (sw->uid != uid) {
+ tb_sw_info(sw,
+ "changed while suspended (uid %#llx -> %#llx)\n",
+ sw->uid, uid);
+ return -ENODEV;
+ }
+
+ /* upload configuration */
+ err = tb_sw_write(sw, 1 + (u32 *) >config, TB_CFG_SWITCH, 1, 3);
+ if (err)
+ return err;
+
+ err = tb_plug_events_active(sw, true);
+ if (err)
+ return err;
+
+ /* check for surviving downstream switches */
+ for (i = 1; i <= sw->config.max_port_number; i++) {
+ struct tb_port *port = >ports[i];
+ if (tb_is_upstream_port(port))
+ continue;
+ if (!port->remote)
+ continue;
+ if (tb_wait_for_port(port, true) <= 0
+ || tb_switch_resume(port->remote->sw)) {
+ tb_port_warn(port,
+"lost during suspend, disconnecting\n");
+ tb_sw_set_unpplugged(port->remote->sw);
+ }
+ }
+ return 0;
+}
+
+void tb_switch_suspend(struct tb_switch *sw)
+{
+ int i, err;
+ err =
Re: Possible issue with commit 6f008e72cd - locking/mutex: Fix debug checks.
On Thu, 2014-04-10 at 19:23 -0400, Valdis Kletnieks wrote: > So recent linux-next lock up on my laptop due to a third-party module. > Bisection finds this as the source of the issue: > > 6f008e72cd111a119b5d8de8c5438d892aae99eb is the first bad commit This was already reported, please refer to this thread: https://lkml.org/lkml/2014/4/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/
[PATCH v2 10/14] thunderbolt: Add path setup code.
A thunderbolt path is a unidirectional channel between two thunderbolt
ports. Two such paths are needed to establish a pci tunnel.
This patch introduces struct tb_path as well as a set of tb_path_*
methods which are used do activate & deactive paths.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/path.c | 215 +++
drivers/thunderbolt/switch.c | 34 +++
drivers/thunderbolt/tb.h | 62 +
4 files changed, 312 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/path.c
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 617b314..3532f36 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o
+thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o
diff --git a/drivers/thunderbolt/path.c b/drivers/thunderbolt/path.c
new file mode 100644
index 000..8fcf8a7
--- /dev/null
+++ b/drivers/thunderbolt/path.c
@@ -0,0 +1,215 @@
+/*
+ * Thunderbolt Cactus Ridge driver - path/tunnel functionality
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+#include
+
+#include "tb.h"
+
+
+static void tb_dump_hop(struct tb_port *port, struct tb_regs_hop *hop)
+{
+ tb_port_info(port, " Hop through port %d to hop %d (%s)\n",
+hop->out_port, hop->next_hop,
+hop->enable ? "enabled" : "disabled");
+ tb_port_info(port, " Weight: %d Priority: %d Credits: %d Drop: %d\n",
+hop->weight, hop->priority,
+hop->initial_credits, hop->drop_packages);
+ tb_port_info(port, " Counter enabled: %d Counter index: %d\n",
+hop->counter_enable, hop->counter);
+ tb_port_info(port, " Flow Control (In/Eg): %d/%d Shared Buffer
(In/Eg): %d/%d\n",
+hop->ingress_fc, hop->egress_fc,
+hop->ingress_shared_buffer, hop->egress_shared_buffer);
+ tb_port_info(port, " Unknown1: %#x Unknown2: %#x Unknown3: %#x\n",
+hop->unknown1, hop->unknown2, hop->unknown3);
+}
+
+/**
+ * tb_path_alloc() - allocate a thunderbolt path
+ *
+ * Return: Returns a tb_path on success or NULL on failure.
+ */
+struct tb_path *tb_path_alloc(struct tb *tb, int num_hops)
+{
+ struct tb_path *path = kzalloc(sizeof(*path), GFP_KERNEL);
+ if (!path)
+ return NULL;
+ path->hops = kcalloc(num_hops, sizeof(*path->hops), GFP_KERNEL);
+ if (!path->hops) {
+ kfree(path);
+ return NULL;
+ }
+ path->tb = tb;
+ path->path_length = num_hops;
+ return path;
+}
+
+/**
+ * tb_path_free() - free a deactivated path
+ */
+void tb_path_free(struct tb_path *path)
+{
+ if (path->activated) {
+ tb_WARN(path->tb, "trying to free an activated path\n")
+ return;
+ }
+ kfree(path->hops);
+ kfree(path);
+}
+
+static void __tb_path_deallocate_nfc(struct tb_path *path, int first_hop)
+{
+ int i, res;
+ for (i = first_hop; i < path->path_length; i++) {
+ res = tb_port_add_nfc_credits(path->hops[i].in_port,
+ -path->nfc_credits);
+ if (res)
+ tb_port_warn(path->hops[i].in_port,
+"nfc credits deallocation failed for hop
%d\n",
+i);
+ }
+}
+
+static void __tb_path_deactivate_hops(struct tb_path *path, int first_hop)
+{
+ int i, res;
+ struct tb_regs_hop hop = { };
+ for (i = first_hop; i < path->path_length; i++) {
+ res = tb_port_write(path->hops[i].in_port, , TB_CFG_HOPS,
+ 2 * path->hops[i].in_hop_index, 2);
+ if (res)
+ tb_port_warn(path->hops[i].in_port,
+"hop deactivation failed for hop %d, index
%d\n",
+i, path->hops[i].in_hop_index);
+ }
+}
+
+void tb_path_deactivate(struct tb_path *path)
+{
+ if (!path->activated) {
+ tb_WARN(path->tb, "trying to deactivate an inactive path\n");
+ return;
+ }
+ tb_info(path->tb,
+ "deactivating path from %llx:%x to %llx:%x\n",
+ tb_route(path->hops[0].in_port->sw),
+ path->hops[0].in_port->port,
+ tb_route(path->hops[path->path_length - 1].out_port->sw),
+ path->hops[path->path_length - 1].out_port->port);
+ __tb_path_deactivate_hops(path, 0);
+ __tb_path_deallocate_nfc(path, 0);
+ path->activated = false;
+}
+
+/**
+ * tb_path_activate() - activate a path
+ *
+ * Activate a path starting with the last hop and iterating backwards. The
+ * caller must fill
[PATCH v2 13/14] thunderbolt: Read switch uid from EEPROM
Add eeprom access code and read the uid during switch initialization.
The UID will be used to check device identity after suspend.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/eeprom.c | 189 +++
drivers/thunderbolt/switch.c | 5 ++
drivers/thunderbolt/tb.h | 3 +
4 files changed, 198 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/eeprom.c
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 0122ca6..5d1053c 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o
+thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o
eeprom.o
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
new file mode 100644
index 000..d1ae1e4
--- /dev/null
+++ b/drivers/thunderbolt/eeprom.c
@@ -0,0 +1,189 @@
+/*
+ * Thunderbolt Cactus Ridge driver - eeprom access
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include "tb.h"
+
+/**
+ * tb_eeprom_ctl_write() - write control word
+ */
+static int tb_eeprom_ctl_write(struct tb_switch *sw, struct tb_eeprom_ctl *ctl)
+{
+ return tb_sw_write(sw, ctl, TB_CFG_SWITCH, sw->cap_plug_events + 4, 1);
+}
+
+/**
+ * tb_eeprom_ctl_write() - read control word
+ */
+static int tb_eeprom_ctl_read(struct tb_switch *sw, struct tb_eeprom_ctl *ctl)
+{
+ return tb_sw_read(sw, ctl, TB_CFG_SWITCH, sw->cap_plug_events + 4, 1);
+}
+
+enum tb_eeprom_transfer {
+ TB_EEPROM_IN,
+ TB_EEPROM_OUT,
+};
+
+/**
+ * tb_eeprom_active - enable rom access
+ *
+ * WARNING: Always disable access after usage. Otherwise the controller will
+ * fail to reprobe.
+ */
+static int tb_eeprom_active(struct tb_switch *sw, bool enable)
+{
+ struct tb_eeprom_ctl ctl;
+ int res = tb_eeprom_ctl_read(sw, );
+ if (res)
+ return res;
+ if (enable) {
+ ctl.access_high = 1;
+ res = tb_eeprom_ctl_write(sw, );
+ if (res)
+ return res;
+ ctl.access_low = 0;
+ return tb_eeprom_ctl_write(sw, );
+ } else {
+ ctl.access_low = 1;
+ res = tb_eeprom_ctl_write(sw, );
+ if (res)
+ return res;
+ ctl.access_high = 0;
+ return tb_eeprom_ctl_write(sw, );
+ }
+}
+
+/**
+ * tb_eeprom_transfer - transfer one bit
+ *
+ * If TB_EEPROM_IN is passed, then the bit can be retrieved from ctl->data_in.
+ * IF TB_EEPROM_OUT is passed, then ctl->data_out will be written.
+ */
+static int tb_eeprom_transfer(struct tb_switch *sw, struct tb_eeprom_ctl *ctl,
+ enum tb_eeprom_transfer direction)
+{
+ int res;
+ if (direction == TB_EEPROM_OUT) {
+ res = tb_eeprom_ctl_write(sw, ctl);
+ if (res)
+ return res;
+ }
+ ctl->clock = 1;
+ res = tb_eeprom_ctl_write(sw, ctl);
+ if (res)
+ return res;
+ if (direction == TB_EEPROM_IN) {
+ res = tb_eeprom_ctl_read(sw, ctl);
+ if (res)
+ return res;
+ }
+ ctl->clock = 0;
+ return tb_eeprom_ctl_write(sw, ctl);
+}
+
+/**
+ * tb_eeprom_out - write one byte to the bus
+ */
+static int tb_eeprom_out(struct tb_switch *sw, u8 val)
+{
+ struct tb_eeprom_ctl ctl;
+ int i;
+ int res = tb_eeprom_ctl_read(sw, );
+ if (res)
+ return res;
+ for (i = 0; i < 8; i++) {
+ ctl.data_out = val & 0x80;
+ res = tb_eeprom_transfer(sw, , TB_EEPROM_OUT);
+ if (res)
+ return res;
+ val <<= 1;
+ }
+ return 0;
+}
+
+/**
+ * tb_eeprom_in - read one byte from the bus
+ */
+static int tb_eeprom_in(struct tb_switch *sw, u8 *val)
+{
+ struct tb_eeprom_ctl ctl;
+ int i;
+ int res = tb_eeprom_ctl_read(sw, );
+ if (res)
+ return res;
+ *val = 0;
+ for (i = 0; i < 8; i++) {
+ *val <<= 1;
+ res = tb_eeprom_transfer(sw, , TB_EEPROM_IN);
+ if (res)
+ return res;
+ *val |= ctl.data_in;
+ }
+ return 0;
+}
+
+/**
+ * tb_eeprom_read_n - read count bytes from offset into val
+ */
+static int tb_eeprom_read_n(struct tb_switch *sw, u16 offset, u8 *val,
+ size_t count)
+{
+ int i, res;
+ res = tb_eeprom_active(sw, true);
+ if (res)
+ return res;
+ res = tb_eeprom_out(sw, 3);
+ if (res)
+ return res;
+ res = tb_eeprom_out(sw, offset >> 8);
+ if (res)
+ return res;
+ res = tb_eeprom_out(sw, offset);
+ if (res)
+
[PATCH v2 11/14] thunderbolt: Add support for simple pci tunnels.
A pci downstream and pci upstream port can be connected through a
tunnel. To establish the tunnel we have to setup two unidirectional
paths between the two ports.
Right now we only support paths with two hops (i.e. no chaining) and at
most one pci device per thunderbolt device.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/tb.c | 135 +++
drivers/thunderbolt/tb.h | 1 +
drivers/thunderbolt/tunnel_pci.c | 232 +++
drivers/thunderbolt/tunnel_pci.h | 30 +
5 files changed, 399 insertions(+), 1 deletion(-)
create mode 100644 drivers/thunderbolt/tunnel_pci.c
create mode 100644 drivers/thunderbolt/tunnel_pci.h
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 3532f36..0122ca6 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o
+thunderbolt-objs := nhi.o ctl.o tb.o switch.o cap.o path.o tunnel_pci.o
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 1efcacc..177f61d 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -10,6 +10,7 @@
#include "tb.h"
#include "tb_regs.h"
+#include "tunnel_pci.h"
/* enumeration & hot plug handling */
@@ -51,6 +52,124 @@ static void tb_scan_port(struct tb_port *port)
tb_scan_switch(sw);
}
+/**
+ * tb_free_invalid_tunnels() - destroy tunnels of devices that have gone away
+ */
+static void tb_free_invalid_tunnels(struct tb *tb)
+{
+ struct tb_pci_tunnel *tunnel;
+ struct tb_pci_tunnel *n;
+ list_for_each_entry_safe(tunnel, n, >tunnel_list, list)
+ {
+ if (tb_pci_is_invalid(tunnel)) {
+ tb_pci_deactivate(tunnel);
+ tb_pci_free(tunnel);
+ }
+ }
+}
+
+/**
+ * find_pci_up_port() - return the first PCIe up port on @sw or NULL
+ */
+static struct tb_port *tb_find_pci_up_port(struct tb_switch *sw)
+{
+ int i;
+ for (i = 1; i <= sw->config.max_port_number; i++)
+ if (sw->ports[i].config.type == TB_TYPE_PCIE_UP)
+ return >ports[i];
+ return NULL;
+}
+
+/**
+ * find_unused_down_port() - return the first inactive PCIe down port on @sw
+ */
+static struct tb_port *tb_find_unused_down_port(struct tb_switch *sw)
+{
+ int i;
+ int cap;
+ int res;
+ int data;
+ for (i = 1; i <= sw->config.max_port_number; i++) {
+ if (tb_is_upstream_port(>ports[i]))
+ continue;
+ if (sw->ports[i].config.type != TB_TYPE_PCIE_DOWN)
+ continue;
+ cap = tb_find_cap(>ports[i], TB_CFG_PORT, TB_CAP_PCIE);
+ if (cap <= 0)
+ continue;
+ res = tb_port_read(>ports[i], , TB_CFG_PORT, cap, 1);
+ if (res < 0)
+ continue;
+ if (data & 0x8000)
+ continue;
+ return >ports[i];
+ }
+ return NULL;
+}
+
+/**
+ * tb_activate_pcie_devices() - scan for and activate PCIe devices
+ *
+ * This method is somewhat ad hoc. For now it only supports one device
+ * per port and only devices at depth 1.
+ */
+static void tb_activate_pcie_devices(struct tb *tb)
+{
+ int i;
+ int cap;
+ u32 data;
+ struct tb_switch *sw;
+ struct tb_port *up_port;
+ struct tb_port *down_port;
+ struct tb_pci_tunnel *tunnel;
+ /* scan for pcie devices at depth 1*/
+ for (i = 1; i <= tb->root_switch->config.max_port_number; i++) {
+ if (tb_is_upstream_port(>root_switch->ports[i]))
+ continue;
+ if (tb->root_switch->ports[i].config.type != TB_TYPE_PORT)
+ continue;
+ if (!tb->root_switch->ports[i].remote)
+ continue;
+ sw = tb->root_switch->ports[i].remote->sw;
+ up_port = tb_find_pci_up_port(sw);
+ if (!up_port) {
+ tb_sw_info(sw, "no PCIe devices found, aborting\n");
+ continue;
+ }
+
+ /* check whether port is already activated */
+ cap = tb_find_cap(up_port, TB_CFG_PORT, TB_CAP_PCIE);
+ if (cap <= 0)
+ continue;
+ if (tb_port_read(up_port, , TB_CFG_PORT, cap, 1))
+ continue;
+ if (data & 0x8000) {
+ tb_port_info(up_port,
+"PCIe port already activated, aborting\n");
+ continue;
+ }
+
+ down_port = tb_find_unused_down_port(tb->root_switch);
+ if (!down_port) {
+
Re: [PATCH v2] Documentation: dt: Reduce fragmentation of <..> placeholders
On Sat, Mar 8, 2014 at 3:09 PM, Rob Herring wrote: > On Fri, Mar 7, 2014 at 5:28 PM, Florian Vaussard > wrote: >> Placeholders <..> are sometimes used in the devicetree documentation >> to define family-wide compatible strings (like fsl,-ipu where >> chip can be any Freescale SoC). >> >> These placeholders are loosly defined. This lead to some >> fragmentation. Looking at the current placeholders, we have: >> >> 3 >> 32 >> 1 >> 1 >> 1 >> 30 >> 1 >> 1 >> >> This patch consolidates this to: >> >> 3 >> 33 >> 1 >> 1 >> 32 >> > > I would prefer to consolidate these into just board and chip. If we > have any oddballs, they can just document the exact strings. Florian, Do you plan to re-spin this? I can take it for 3.15 if it is early in the rc's. 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] include: replace asm headers to linux
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Paul McQuade
> Sent: Friday, April 11, 2014 7:28 AM
>
> Use #include instead of
> Use #include instead of
>
> Signed-off-by: Paul McQuade
> ---
> include/acpi/platform/aclinux.h | 2 +-
> include/asm-generic/bitops/__ffs.h| 2 +-
> include/asm-generic/bitops/__fls.h| 2 +-
> include/asm-generic/bitops/arch_hweight.h | 2 +-
> include/asm-generic/bitops/atomic.h | 6 +++---
> include/asm-generic/bitops/count_zeros.h | 2 +-
> include/asm-generic/bitops/fls64.h| 2 +-
> include/asm-generic/bitops/le.h | 2 +-
> include/asm-generic/bitops/non-atomic.h | 2 +-
> include/asm-generic/bitops/sched.h| 2 +-
> 10 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
> index 93c55ed..d52317f 100644
> --- a/include/acpi/platform/aclinux.h
> +++ b/include/acpi/platform/aclinux.h
> @@ -71,7 +71,7 @@
> #ifdef EXPORT_ACPI_INTERFACES
> #include
> #endif
> -#include
> +#include
>
> /* Host-dependent types and defines for in-kernel ACPICA */
>
This diff block is wrong.
The acpi/platform/aclinux.h is a "platform specific ACPICA environment header".
The linux/acpi.h is a "Top level header of Linux ACPI".
The asm/acpi.h is a combination of " architecture specific ACPICA environment
header" and "architecture specific Linux ACPI header".
The relationship between Linux ACPI and ACPICA is:
Linux ACPI is using ACPICA.
So linux ACPI header should __INCLUDE__ ACPICA header, which means linux/acpi.h
should include acpi/platform/aclinux.h.
You patch thus is wrong.
In fact, acpi/platform/aclinux.h is included by acpi/acpi.h and acpi/acpi.h is
included by linux/acpi.h.
For asm/acpi.h, there are really things messed up in it.
I have a series to split its role so that wrong "architecture specific Linux
ACPI header" can be sorted out from acpi/platform/aclinux.h.
Please refer to:
https://lkml.org/lkml/2014/4/8/57
The correct way to fix the issue you are trying to fix is this patch:
https://lkml.org/lkml/2014/4/8/60
So please drop this diff block and just wait for the above mentioned series to
be merged.
Thanks and best regards
-Lv
> diff --git a/include/asm-generic/bitops/__ffs.h
> b/include/asm-generic/bitops/__ffs.h
> index 937d7c4..8236f91 100644
> --- a/include/asm-generic/bitops/__ffs.h
> +++ b/include/asm-generic/bitops/__ffs.h
> @@ -1,7 +1,7 @@
> #ifndef _ASM_GENERIC_BITOPS___FFS_H_
> #define _ASM_GENERIC_BITOPS___FFS_H_
>
> -#include
> +#include
>
> /**
> * __ffs - find first bit in word.
> diff --git a/include/asm-generic/bitops/__fls.h
> b/include/asm-generic/bitops/__fls.h
> index a60a7cc..60e5360 100644
> --- a/include/asm-generic/bitops/__fls.h
> +++ b/include/asm-generic/bitops/__fls.h
> @@ -1,7 +1,7 @@
> #ifndef _ASM_GENERIC_BITOPS___FLS_H_
> #define _ASM_GENERIC_BITOPS___FLS_H_
>
> -#include
> +#include
>
> /**
> * __fls - find last (most-significant) set bit in a long word
> diff --git a/include/asm-generic/bitops/arch_hweight.h
> b/include/asm-generic/bitops/arch_hweight.h
> index 6a211f4..a9a48a8 100644
> --- a/include/asm-generic/bitops/arch_hweight.h
> +++ b/include/asm-generic/bitops/arch_hweight.h
> @@ -1,7 +1,7 @@
> #ifndef _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
> #define _ASM_GENERIC_BITOPS_ARCH_HWEIGHT_H_
>
> -#include
> +#include
>
> static inline unsigned int __arch_hweight32(unsigned int w)
> {
> diff --git a/include/asm-generic/bitops/atomic.h
> b/include/asm-generic/bitops/atomic.h
> index 9ae6c34..4469696 100644
> --- a/include/asm-generic/bitops/atomic.h
> +++ b/include/asm-generic/bitops/atomic.h
> @@ -1,12 +1,12 @@
> #ifndef _ASM_GENERIC_BITOPS_ATOMIC_H_
> #define _ASM_GENERIC_BITOPS_ATOMIC_H_
>
> -#include
> +#include
> #include
>
> #ifdef CONFIG_SMP
> -#include
> -#include/* we use L1_CACHE_BYTES */
> +#include
> +#include /* we use L1_CACHE_BYTES */
>
> /* Use an array of spinlocks for our atomic_ts.
> * Hash function to index into a different SPINLOCK.
> diff --git a/include/asm-generic/bitops/count_zeros.h
> b/include/asm-generic/bitops/count_zeros.h
> index 97520d2..7f8e1d0 100644
> --- a/include/asm-generic/bitops/count_zeros.h
> +++ b/include/asm-generic/bitops/count_zeros.h
> @@ -12,7 +12,7 @@
> #ifndef _ASM_GENERIC_BITOPS_COUNT_ZEROS_H_
> #define _ASM_GENERIC_BITOPS_COUNT_ZEROS_H_
>
> -#include
> +#include
>
> /**
> * count_leading_zeros - Count the number of zeros from the MSB back
> diff --git a/include/asm-generic/bitops/fls64.h
> b/include/asm-generic/bitops/fls64.h
> index b097cf8..3999f5c 100644
> --- a/include/asm-generic/bitops/fls64.h
> +++ b/include/asm-generic/bitops/fls64.h
> @@ -1,7 +1,7 @@
> #ifndef _ASM_GENERIC_BITOPS_FLS64_H_
> #define _ASM_GENERIC_BITOPS_FLS64_H_
>
> -#include
> +#include
>
> /**
> * fls64 - find last
[PATCH v2 01/14] thunderbolt: Add initial cactus ridge NHI support
Thunderbolt hotplug is supposed to be handled by the firmware. But Apple
decided to implement thunderbolt at the operating system level. The
firmare only initializes thunderbolt devices that are present at boot
time. This driver enables hotplug of thunderbolt of non-chained
thunderbolt devices on Apple systems with a cactus ridge 4C (2 ports)
controller (MacBookPro10,1).
This first patch adds the Kconfig file as well the parts of the driver
which talk directly to the hardware (that is pci device setup, interrupt
handling and RX/TX ring management).
Signed-off-by: Andreas Noever
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/thunderbolt/Kconfig| 12 +
drivers/thunderbolt/Makefile | 3 +
drivers/thunderbolt/nhi.c | 625 +
drivers/thunderbolt/nhi.h | 114
drivers/thunderbolt/nhi_regs.h | 101 +++
7 files changed, 858 insertions(+)
create mode 100644 drivers/thunderbolt/Kconfig
create mode 100644 drivers/thunderbolt/Makefile
create mode 100644 drivers/thunderbolt/nhi.c
create mode 100644 drivers/thunderbolt/nhi.h
create mode 100644 drivers/thunderbolt/nhi_regs.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 0a0a90f..07e3a73 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -174,4 +174,6 @@ source "drivers/powercap/Kconfig"
source "drivers/mcb/Kconfig"
+source "drivers/thunderbolt/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index e3ced91..8d328e4 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -157,3 +157,4 @@ obj-$(CONFIG_NTB) += ntb/
obj-$(CONFIG_FMC) += fmc/
obj-$(CONFIG_POWERCAP) += powercap/
obj-$(CONFIG_MCB) += mcb/
+obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
new file mode 100644
index 000..3a25529
--- /dev/null
+++ b/drivers/thunderbolt/Kconfig
@@ -0,0 +1,12 @@
+menuconfig THUNDERBOLT
+ tristate "Thunderbolt support for Apple devices"
+ default no
+ help
+ Cactus Ridge Thunderbolt Controller driver
+ This driver is required if you want to hotplug Thunderbolt devices on
+ Apple hardware.
+
+ Device chaining is currently not supported.
+
+ To compile this driver a module, choose M here. The module will be
+ called thunderbolt.
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
new file mode 100644
index 000..d473ab9
--- /dev/null
+++ b/drivers/thunderbolt/Makefile
@@ -0,0 +1,3 @@
+obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
+thunderbolt-objs := nhi.o
+
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
new file mode 100644
index 000..1c6adc7
--- /dev/null
+++ b/drivers/thunderbolt/nhi.c
@@ -0,0 +1,625 @@
+/*
+ * Thunderbolt Cactus Ridge driver - NHI driver
+ *
+ * The NHI (native host interface) is the pci device that allows us to send and
+ * receive frames from the thunderbolt bus.
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "nhi.h"
+#include "nhi_regs.h"
+
+#define RING_TYPE(ring) ((ring)->is_tx ? "TX ring" : "RX ring")
+
+
+static int ring_interrupt_index(struct tb_ring *ring)
+{
+ int bit = ring->hop;
+ if (!ring->is_tx)
+ bit += ring->nhi->hop_count;
+ return bit;
+}
+
+/**
+ * ring_interrupt_active() - activate/deactivate interrupts for a single ring
+ *
+ * ring->nhi->lock must be held.
+ */
+static void ring_interrupt_active(struct tb_ring *ring, bool active)
+{
+ int reg = REG_RING_INTERRUPT_BASE + ring_interrupt_index(ring) / 32;
+ int bit = ring_interrupt_index(ring) & 31;
+ int mask = 1 << bit;
+ u32 old, new;
+ old = ioread32(ring->nhi->iobase + reg);
+ if (active)
+ new = old | mask;
+ else
+ new = old & ~mask;
+
+ dev_info(>nhi->pdev->dev,
+"%s interrupt at register %#x bit %d (%#x -> %#x)\n",
+active ? "enabling" : "disabling", reg, bit, old, new);
+
+ if (new == old)
+ dev_WARN(>nhi->pdev->dev,
+"interrupt for %s %d is already %s\n",
+RING_TYPE(ring), ring->hop,
+active ? "enabled" : "disabled");
+ iowrite32(new, ring->nhi->iobase + reg);
+}
+
+/**
+ * nhi_disable_interrupts() - disable interrupts for all rings
+ *
+ * Use only during init and shutdown.
+ */
+static void nhi_disable_interrupts(struct tb_nhi *nhi)
+{
+ int i = 0;
+ /* disable interrupts */
+ for (i = 0; i < RING_INTERRUPT_REG_COUNT(nhi); i++)
+ iowrite32(0, nhi->iobase + REG_RING_INTERRUPT_BASE + 4 * i);
+
+ /* clear interrupt status bits */
+ for (i = 0; i < RING_NOTIFY_REG_COUNT(nhi); i++)
+
[Patch v2 00/14] Thunderbolt support for Apple MBP
Hi This is version 2 of my Thunderbolt driver for Apple hardware (see [1] for v1). The short story is that Apple decided to implement hotplug support in a driver instead of the firmware. The firmware will only initialize coldplugged devices. Hotplugged devices do not work. This series adds support for single device hotplug (no chaining) for the Cactus Ridge C4 Thunderbolt controller (device id 0x1547, present on MacBookPro10,1). As far as I can tell newer generations work quite similar and it should be possible to add support for more controllers with some work. Changes from v1: - suspend/hibernate support (yeah) - general cleanups and refactoring >From my perspective the driver is working quite well and is ready for merging (maybe someone can tell me whom I should ask to get a review?). I have taken some care to not stomp on tunnels setup by the firmware for coldplugged devices. If this works as intendend then there should be no regressions (coldplugged devices continue to work and simple hotplugged devices will start working). In particular the Apple Ethernet adapter works very well (and this is probably the most used TB device out there). Some notes: - The patch requires Matthew's acpi_osi fix [2] - @pci, Bjorn: I hope patch 12 is acceptable. If there is a better way to do this please let me know. - Thunderbolt displays: I have a pretty good idea on how they should work, but I did not yet write any code to support them. Also judging by the replies I got for v1 of the patch it seems that there are some graphics driver problems even with coldplugged tb displays (at least on MBP models with discrete graphics cards). - Hibernate gotcha: The amount of available memory reported by the firmware depends on whether a tb device is connected. This makes Linux refuse to restore the saved image. This has nothing to do with this driver, but you might run into it during testing. Thanks, Andreas Andreas Noever (14): thunderbolt: Add initial cactus ridge NHI support thunderbolt: Add control channel interface thunderbolt: Setup control channel thunderbolt: Add tb_regs.h thunderbolt: Initialize root switch and ports thunderbolt: Add thunderbolt capability handling thunderbolt: Enable plug events thunderbolt: Scan for downstream switches thunderbolt: Handle hotplug events thunderbolt: Add path setup code. thunderbolt: Add support for simple pci tunnels. pci: Suspend/resume support for appel thunderbolt thunderbolt: Read switch uid from EEPROM thunderbolt: Add suspend/hibernate support drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/pci/pcie/portdrv_pci.c | 117 +++ drivers/thunderbolt/Kconfig | 12 + drivers/thunderbolt/Makefile | 3 + drivers/thunderbolt/cap.c| 116 +++ drivers/thunderbolt/ctl.c| 731 +++ drivers/thunderbolt/ctl.h| 75 drivers/thunderbolt/eeprom.c | 189 ++ drivers/thunderbolt/nhi.c| 671 +++ drivers/thunderbolt/nhi.h| 114 ++ drivers/thunderbolt/nhi_regs.h | 101 ++ drivers/thunderbolt/path.c | 215 drivers/thunderbolt/switch.c | 492 ++ drivers/thunderbolt/tb.c | 431 +++ drivers/thunderbolt/tb.h | 266 ++ drivers/thunderbolt/tb_regs.h| 213 drivers/thunderbolt/tunnel_pci.c | 232 + drivers/thunderbolt/tunnel_pci.h | 30 ++ 19 files changed, 4011 insertions(+) create mode 100644 drivers/thunderbolt/Kconfig create mode 100644 drivers/thunderbolt/Makefile create mode 100644 drivers/thunderbolt/cap.c create mode 100644 drivers/thunderbolt/ctl.c create mode 100644 drivers/thunderbolt/ctl.h create mode 100644 drivers/thunderbolt/eeprom.c create mode 100644 drivers/thunderbolt/nhi.c create mode 100644 drivers/thunderbolt/nhi.h create mode 100644 drivers/thunderbolt/nhi_regs.h create mode 100644 drivers/thunderbolt/path.c create mode 100644 drivers/thunderbolt/switch.c create mode 100644 drivers/thunderbolt/tb.c create mode 100644 drivers/thunderbolt/tb.h create mode 100644 drivers/thunderbolt/tb_regs.h create mode 100644 drivers/thunderbolt/tunnel_pci.c create mode 100644 drivers/thunderbolt/tunnel_pci.h -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/14] thunderbolt: Setup control channel
Add struct tb which will contain our view of the thunderbolt bus. For
now it just contains a pointer to the control channel and a workqueue
for hotplug events.
Add thunderbolt_alloc_and_start() and thunderbolt_shutdown_and_free()
which are responsible for setup and teardown of struct tb.
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/Makefile | 2 +-
drivers/thunderbolt/nhi.c| 18 +-
drivers/thunderbolt/tb.c | 134 +++
drivers/thunderbolt/tb.h | 35 +++
4 files changed, 186 insertions(+), 3 deletions(-)
create mode 100644 drivers/thunderbolt/tb.c
create mode 100644 drivers/thunderbolt/tb.h
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 4b21c99..1f996bb 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -1,3 +1,3 @@
obj-${CONFIG_THUNDERBOLT} := thunderbolt.o
-thunderbolt-objs := nhi.o ctl.o
+thunderbolt-objs := nhi.o ctl.o tb.o
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 1c6adc7..fd2e3ee 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -16,6 +16,7 @@
#include "nhi.h"
#include "nhi_regs.h"
+#include "tb.h"
#define RING_TYPE(ring) ((ring)->is_tx ? "TX ring" : "RX ring")
@@ -517,6 +518,7 @@ static void nhi_shutdown(struct tb_nhi *nhi)
static int nhi_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct tb_nhi *nhi;
+ struct tb *tb;
int res;
res = pcim_enable_device(pdev);
@@ -575,14 +577,26 @@ static int nhi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
/* magic value - clock related? */
iowrite32(3906250 / 1, nhi->iobase + 0x38c00);
- pci_set_drvdata(pdev, nhi);
+ dev_info(>pdev->dev, "NHI initialized, starting thunderbolt\n");
+ tb = thunderbolt_alloc_and_start(nhi);
+ if (!tb) {
+ /*
+* At this point the RX/TX rings might already have been
+* activated. Do a proper shutdown.
+*/
+ nhi_shutdown(nhi);
+ return -EIO;
+ }
+ pci_set_drvdata(pdev, tb);
return 0;
}
static void nhi_remove(struct pci_dev *pdev)
{
- struct tb_nhi *nhi = pci_get_drvdata(pdev);
+ struct tb *tb = pci_get_drvdata(pdev);
+ struct tb_nhi *nhi = tb->nhi;
+ thunderbolt_shutdown_and_free(tb);
nhi_shutdown(nhi);
}
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
new file mode 100644
index 000..6920979
--- /dev/null
+++ b/drivers/thunderbolt/tb.c
@@ -0,0 +1,134 @@
+/*
+ * Thunderbolt Cactus Ridge driver - bus logic (NHI independent)
+ *
+ * Copyright (c) 2014 Andreas Noever
+ */
+
+#include
+#include
+#include
+
+#include "tb.h"
+
+/* hotplug handling */
+
+struct tb_hotplug_event {
+ struct work_struct work;
+ struct tb *tb;
+ u64 route;
+ u8 port;
+ bool unplug;
+};
+
+/**
+ * tb_handle_hotplug() - handle hotplug event
+ *
+ * Executes on tb->wq.
+ */
+static void tb_handle_hotplug(struct work_struct *work)
+{
+ struct tb_hotplug_event *ev = container_of(work, typeof(*ev), work);
+ struct tb *tb = ev->tb;
+ mutex_lock(>lock);
+ if (!tb->hotplug_active)
+ goto out; /* during init, suspend or shutdown */
+
+ /* do nothing for now */
+out:
+ mutex_unlock(>lock);
+ kfree(ev);
+}
+
+/**
+ * tb_schedule_hotplug_handler() - callback function for the control channel
+ *
+ * Delegates to tb_handle_hotplug.
+ */
+static void tb_schedule_hotplug_handler(void *data, u64 route, u8 port,
+ bool unplug)
+{
+ struct tb *tb = data;
+ struct tb_hotplug_event *ev = kmalloc(sizeof(*ev), GFP_KERNEL);
+ if (!ev)
+ return;
+ INIT_WORK(>work, tb_handle_hotplug);
+ ev->tb = tb;
+ ev->route = route;
+ ev->port = port;
+ ev->unplug = unplug;
+ queue_work(tb->wq, >work);
+}
+
+/**
+ * thunderbolt_shutdown_and_free() - shutdown everything
+ *
+ * Free all switches and the config channel.
+ *
+ * Used in the error path of thunderbolt_alloc_and_start.
+ */
+void thunderbolt_shutdown_and_free(struct tb *tb)
+{
+ mutex_lock(>lock);
+
+ if (tb->ctl) {
+ tb_ctl_stop(tb->ctl);
+ tb_ctl_free(tb->ctl);
+ }
+ tb->ctl = NULL;
+ tb->hotplug_active = false; /* signal tb_handle_hotplug to quit */
+
+ /* allow tb_handle_hotplug to acquire the lock */
+ mutex_unlock(>lock);
+ if (tb->wq) {
+ flush_workqueue(tb->wq);
+ destroy_workqueue(tb->wq);
+ tb->wq = NULL;
+ }
+ mutex_destroy(>lock);
+ kfree(tb);
+}
+
+/**
+ * thunderbolt_alloc_and_start() - setup the thunderbolt bus
+ *
+ * Allocates a tb_cfg control channel, initializes the root switch, enables
+ * plug events and
Re: [PATCH 2/6] shm: add sealing API
Hi On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby wrote: > For O_DIRECT the kernel pins the submitted pages in memory for DMA by > incrementing the page reference counts when the I/O is submitted, > allowing the pages to be modified by DMA even if they are no longer > mapped in the address space of the process. This is different from a > regular read(), which uses the CPU to copy the data and will fail if the > pages are not mapped. Can you please provide an example code-path? For instance, file_read_actor() does not pin any pages but only keeps the user-space address and resolves it once it has data to write. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 stat: Don't print bogus data for stalled-cycles
When the stalled-cycles-frontend event is requested without the cycles
event:
$ perf stat -e stalled-cycles-frontend -- git s
## acme...ram/acme
Performance counter stats for 'git s':
326,947,423 stalled-cycles-frontend #0.00% frontend cycles
idle
0.363599976 seconds time elapsed
The 0.00% frontend cycles idle comment in the output is totally bogus
and misleading. Omit printing it here, as well as in the
stalled-cycles-backend case.
Cc: Jiri Olsa
Cc: David Ahern
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Ramkumar Ramachandra
---
tools/perf/builtin-stat.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8b0e1c9..0bd98fa 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -797,14 +797,13 @@ static void print_stalled_cycles_frontend(int cpu,
total = avg_stats(_cycles_stats[cpu]);
- if (total)
+ if (total) {
ratio = avg / total * 100.0;
-
- color = get_ratio_color(GRC_STALLED_CYCLES_FE, ratio);
-
- fprintf(output, " # ");
- color_fprintf(output, color, "%6.2f%%", ratio);
- fprintf(output, " frontend cycles idle ");
+ color = get_ratio_color(GRC_STALLED_CYCLES_FE, ratio);
+ fprintf(output, " # ");
+ color_fprintf(output, color, "%6.2f%%", ratio);
+ fprintf(output, " frontend cycles idle ");
+ }
}
static void print_stalled_cycles_backend(int cpu,
@@ -816,14 +815,13 @@ static void print_stalled_cycles_backend(int cpu,
total = avg_stats(_cycles_stats[cpu]);
- if (total)
+ if (total) {
ratio = avg / total * 100.0;
-
- color = get_ratio_color(GRC_STALLED_CYCLES_BE, ratio);
-
- fprintf(output, " # ");
- color_fprintf(output, color, "%6.2f%%", ratio);
- fprintf(output, " backend cycles idle ");
+ color = get_ratio_color(GRC_STALLED_CYCLES_BE, ratio);
+ fprintf(output, " # ");
+ color_fprintf(output, color, "%6.2f%%", ratio);
+ fprintf(output, " backend cycles idle ");
+ }
}
static void print_branch_misses(int cpu,
--
1.9.2.667.ge5b74e1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 2/6] KVM: emulate: Remove ctxt->intercept and ctxt->check_perm checks
The same information can be gleaned from ctxt->d and avoids having
to zero/NULL initialize intercept and check_perm
Signed-off-by: Bandan Das
---
arch/x86/kvm/emulate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 8e2b866..a6d9892 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4615,7 +4615,7 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
fetch_possible_mmx_operand(ctxt, >dst);
}
- if (unlikely(ctxt->guest_mode) && ctxt->intercept) {
+ if (unlikely(ctxt->guest_mode) && (ctxt->d & Intercept)) {
rc = emulator_check_intercept(ctxt, ctxt->intercept,
X86_ICPT_PRE_EXCEPT);
if (rc != X86EMUL_CONTINUE)
@@ -4635,13 +4635,13 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
}
/* Do instruction specific permission checks */
- if (ctxt->check_perm) {
+ if (ctxt->d & CheckPerm) {
rc = ctxt->check_perm(ctxt);
if (rc != X86EMUL_CONTINUE)
goto done;
}
- if (unlikely(ctxt->guest_mode) && ctxt->intercept) {
+ if (unlikely(ctxt->guest_mode) && (ctxt->d & Intercept)) {
rc = emulator_check_intercept(ctxt, ctxt->intercept,
X86_ICPT_POST_EXCEPT);
if (rc != X86EMUL_CONTINUE)
@@ -4685,7 +4685,7 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
special_insn:
- if (unlikely(ctxt->guest_mode) && ctxt->intercept) {
+ if (unlikely(ctxt->guest_mode) && (ctxt->d & Intercept)) {
rc = emulator_check_intercept(ctxt, ctxt->intercept,
X86_ICPT_POST_MEMACCESS);
if (rc != X86EMUL_CONTINUE)
--
1.8.3.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/
[RFC PATCH v2 5/6] KVM: emulate: rework seg_override
x86_decode_insn already sets a default for seg_override,
so remove it from the zeroed area. Also replace set/get functions
with direct access to the field.
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 3 +--
arch/x86/kvm/emulate.c | 41 +++---
2 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index d2ec45d..08a7696 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -322,12 +322,10 @@ struct x86_emulate_ctxt {
struct operand dst;
int (*execute)(struct x86_emulate_ctxt *ctxt);
int (*check_perm)(struct x86_emulate_ctxt *ctxt);
- bool has_seg_override;
bool rip_relative;
u8 rex_prefix;
u8 lock_prefix;
u8 rep_prefix;
- u8 seg_override;
/* bitmaps of registers in _regs[] that can be read */
u32 regs_valid;
/* bitmaps of registers in _regs[] that have been written */
@@ -338,6 +336,7 @@ struct x86_emulate_ctxt {
u8 modrm_reg;
u8 modrm_rm;
u8 modrm_seg;
+ u8 seg_override;
u64 d;
unsigned long _eip;
struct operand memop;
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 5517dd2..b8affac 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -512,12 +512,6 @@ static u32 desc_limit_scaled(struct desc_struct *desc)
return desc->g ? (limit << 12) | 0xfff : limit;
}
-static void set_seg_override(struct x86_emulate_ctxt *ctxt, int seg)
-{
- ctxt->has_seg_override = true;
- ctxt->seg_override = seg;
-}
-
static unsigned long seg_base(struct x86_emulate_ctxt *ctxt, int seg)
{
if (ctxt->mode == X86EMUL_MODE_PROT64 && seg < VCPU_SREG_FS)
@@ -526,14 +520,6 @@ static unsigned long seg_base(struct x86_emulate_ctxt
*ctxt, int seg)
return ctxt->ops->get_cached_segment_base(ctxt, seg);
}
-static unsigned seg_override(struct x86_emulate_ctxt *ctxt)
-{
- if (!ctxt->has_seg_override)
- return 0;
-
- return ctxt->seg_override;
-}
-
static int emulate_exception(struct x86_emulate_ctxt *ctxt, int vec,
u32 error, bool valid)
{
@@ -4192,7 +4178,7 @@ static int decode_operand(struct x86_emulate_ctxt *ctxt,
struct operand *op,
op->bytes = (ctxt->d & ByteOp) ? 1 : ctxt->op_bytes;
op->addr.mem.ea =
register_address(ctxt, reg_read(ctxt, VCPU_REGS_RSI));
- op->addr.mem.seg = seg_override(ctxt);
+ op->addr.mem.seg = ctxt->seg_override;
op->val = 0;
op->count = 1;
break;
@@ -4203,7 +4189,7 @@ static int decode_operand(struct x86_emulate_ctxt *ctxt,
struct operand *op,
register_address(ctxt,
reg_read(ctxt, VCPU_REGS_RBX) +
(reg_read(ctxt, VCPU_REGS_RAX) & 0xff));
- op->addr.mem.seg = seg_override(ctxt);
+ op->addr.mem.seg = ctxt->seg_override;
op->val = 0;
break;
case OpImmFAddr:
@@ -4250,6 +4236,7 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void
*insn, int insn_len)
int mode = ctxt->mode;
int def_op_bytes, def_ad_bytes, goffset, simd_prefix;
bool op_prefix = false;
+ bool has_seg_override = false;
struct opcode opcode;
ctxt->memop.type = OP_NONE;
@@ -4303,11 +4290,13 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void
*insn, int insn_len)
case 0x2e: /* CS override */
case 0x36: /* SS override */
case 0x3e: /* DS override */
- set_seg_override(ctxt, (ctxt->b >> 3) & 3);
+ has_seg_override = true;
+ ctxt->seg_override = (ctxt->b >> 3) & 3;
break;
case 0x64: /* FS override */
case 0x65: /* GS override */
- set_seg_override(ctxt, ctxt->b & 7);
+ has_seg_override = true;
+ ctxt->seg_override = ctxt->b & 7;
break;
case 0x40 ... 0x4f: /* REX */
if (mode != X86EMUL_MODE_PROT64)
@@ -4438,17 +4427,19 @@ done_prefixes:
/* ModRM and SIB bytes. */
if (ctxt->d & ModRM) {
rc = decode_modrm(ctxt, >memop);
- if (!ctxt->has_seg_override)
- set_seg_override(ctxt, ctxt->modrm_seg);
+ if (!has_seg_override) {
+ has_seg_override = true;
+ ctxt->seg_override = ctxt->modrm_seg;
+ }
} else if (ctxt->d & MemAbs)
rc = decode_abs(ctxt, >memop);
if (rc !=
[RFC PATCH v2 1/6] KVM: emulate: move init_decode_cache to emulate.c
Core emulator functions all belong in emulator.c,
x86 should have no knowledge of emulator internals
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c | 13 +
arch/x86/kvm/x86.c | 13 -
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index d085f73..ad4cca8 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -436,6 +436,7 @@ bool x86_page_table_writing_insn(struct x86_emulate_ctxt
*ctxt);
#define EMULATION_OK 0
#define EMULATION_RESTART 1
#define EMULATION_INTERCEPTED 2
+void init_decode_cache(struct x86_emulate_ctxt *ctxt);
int x86_emulate_insn(struct x86_emulate_ctxt *ctxt);
int emulator_task_switch(struct x86_emulate_ctxt *ctxt,
u16 tss_selector, int idt_index, int reason,
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 8ca292c..8e2b866 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4550,6 +4550,19 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *))
return X86EMUL_CONTINUE;
}
+void init_decode_cache(struct x86_emulate_ctxt *ctxt)
+{
+ memset(>opcode_len, 0,
+ (void *)>_regs - (void *)>opcode_len);
+
+ ctxt->fetch.start = 0;
+ ctxt->fetch.end = 0;
+ ctxt->io_read.pos = 0;
+ ctxt->io_read.end = 0;
+ ctxt->mem_read.pos = 0;
+ ctxt->mem_read.end = 0;
+}
+
int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
{
const struct x86_emulate_ops *ops = ctxt->ops;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4fad05d..122410d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4951,19 +4951,6 @@ static void inject_emulated_exception(struct kvm_vcpu
*vcpu)
kvm_queue_exception(vcpu, ctxt->exception.vector);
}
-static void init_decode_cache(struct x86_emulate_ctxt *ctxt)
-{
- memset(>opcode_len, 0,
- (void *)>_regs - (void *)>opcode_len);
-
- ctxt->fetch.start = 0;
- ctxt->fetch.end = 0;
- ctxt->io_read.pos = 0;
- ctxt->io_read.end = 0;
- ctxt->mem_read.pos = 0;
- ctxt->mem_read.end = 0;
-}
-
static void init_emulate_ctxt(struct kvm_vcpu *vcpu)
{
struct x86_emulate_ctxt *ctxt = >arch.emulate_ctxt;
--
1.8.3.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/
[RFC PATCH v2 4/6] KVM: emulate: clean up initializations in init_decode_cache
A lot of initializations are unnecessary as they get set to
appropriate values before actually being used. Optimize
placement of fields in x86_emulate_ctxt
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 20 +++-
arch/x86/kvm/emulate.c | 7 ++-
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index ad4cca8..d2ec45d 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -315,30 +315,32 @@ struct x86_emulate_ctxt {
u8 opcode_len;
u8 b;
u8 intercept;
- u8 lock_prefix;
- u8 rep_prefix;
u8 op_bytes;
u8 ad_bytes;
- u8 rex_prefix;
struct operand src;
struct operand src2;
struct operand dst;
- bool has_seg_override;
- u8 seg_override;
- u64 d;
int (*execute)(struct x86_emulate_ctxt *ctxt);
int (*check_perm)(struct x86_emulate_ctxt *ctxt);
+ bool has_seg_override;
+ bool rip_relative;
+ u8 rex_prefix;
+ u8 lock_prefix;
+ u8 rep_prefix;
+ u8 seg_override;
+ /* bitmaps of registers in _regs[] that can be read */
+ u32 regs_valid;
+ /* bitmaps of registers in _regs[] that have been written */
+ u32 regs_dirty;
/* modrm */
u8 modrm;
u8 modrm_mod;
u8 modrm_reg;
u8 modrm_rm;
u8 modrm_seg;
- bool rip_relative;
+ u64 d;
unsigned long _eip;
struct operand memop;
- u32 regs_valid; /* bitmaps of registers in _regs[] that can be read */
- u32 regs_dirty; /* bitmaps of registers in _regs[] that have been
written */
/* Fields above regs are cleared together. */
unsigned long _regs[NR_VCPU_REGS];
struct operand *memopp;
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 9cbaba2..5517dd2 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4550,14 +4550,11 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *))
void init_decode_cache(struct x86_emulate_ctxt *ctxt)
{
- memset(>opcode_len, 0,
- (void *)>_regs - (void *)>opcode_len);
+ memset(>has_seg_override, 0,
+ (void *)>modrm - (void *)>has_seg_override);
- ctxt->fetch.start = 0;
- ctxt->fetch.end = 0;
ctxt->io_read.pos = 0;
ctxt->io_read.end = 0;
- ctxt->mem_read.pos = 0;
ctxt->mem_read.end = 0;
}
--
1.8.3.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/
[RFC PATCH v2 0/6] Emulator speedups - avoid initializations where possible
While initializing emulation context structure, kvm memsets to 0 a number of fields some of which are redundant since they get set eventually in x86_decode_insn. Cleanup unnecessary initializations and remove some fields. This is on top of Paolo's RFC KVM: x86: speedups for emulator memory accesses https://lkml.org/lkml/2014/4/1/494 Here are the new realmode.flat numbers with improvement wrt unpatched kernel - 639 cycles/emulated jump instruction (4.3%) 776 cycles/emulated move instruction (7.5%) 791 cycles/emulated arithmetic instruction (11%) 943 cycles/emulated memory load instruction (5.2%) 948 cycles/emulated memory store instruction (7.6%) 929 cycles/emulated memory RMW instruction (9.0%) v1 numbers - 639 cycles/emulated jump instruction 786 cycles/emulated move instruction 802 cycles/emulated arithmetic instruction 936 cycles/emulated memory load instruction 970 cycles/emulated memory store instruction 1000 cycles/emulated memory RMW instruction v2: All thanks and credit to Paolo! - 1/6 - no change - 2/6 - new patch, inercept and check_perm replaced with checks for bits in ctxt->d - 3/6 - new patch, remove if condition in decode_rm and rearrange bit operations - 4/6 - remove else conditions from v1 and misc cleanups - 5/6 - new patch, remove seg_override and related fields and functions - 6/6 - new patch, remove memopp and move rip_relative to a local variable in decode_modrm Bandan Das (6): KVM: emulate: move init_decode_cache to emulate.c KVM: emulate: Remove ctxt->intercept and ctxt->check_perm checks KVM: emulate: cleanup decode_rm KVM: emulate: clean up initializations in init_decode_cache KVM: emulate: rework seg_override KVM: emulate: remove memopp and rip_relative arch/x86/include/asm/kvm_emulate.h | 20 - arch/x86/kvm/emulate.c | 85 ++ arch/x86/kvm/x86.c | 13 -- 3 files changed, 50 insertions(+), 68 deletions(-) -- 1.8.3.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/
[RFC PATCH v2 6/6] KVM: emulate: remove memopp and rip_relative
Move typecast on "out of range value" of mem.ea to
decode_modrm. rip_relative is only set in decode_modrm,
change it to a local var
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_emulate.h | 2 --
arch/x86/kvm/emulate.c | 18 +++---
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 08a7696..813254b 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -322,7 +322,6 @@ struct x86_emulate_ctxt {
struct operand dst;
int (*execute)(struct x86_emulate_ctxt *ctxt);
int (*check_perm)(struct x86_emulate_ctxt *ctxt);
- bool rip_relative;
u8 rex_prefix;
u8 lock_prefix;
u8 rep_prefix;
@@ -342,7 +341,6 @@ struct x86_emulate_ctxt {
struct operand memop;
/* Fields above regs are cleared together. */
unsigned long _regs[NR_VCPU_REGS];
- struct operand *memopp;
struct fetch_cache fetch;
struct read_cache io_read;
struct read_cache mem_read;
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index b8affac..fcdf5b7 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1053,6 +1053,7 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
int index_reg, base_reg, scale;
int rc = X86EMUL_CONTINUE;
ulong modrm_ea = 0;
+ bool rip_relative = false;
index_reg = (ctxt->rex_prefix << 2) & 8; /* REX.X */
base_reg = (ctxt->rex_prefix << 3) & 8; /* REG.B */
@@ -1155,7 +1156,7 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
modrm_ea += reg_read(ctxt, index_reg) << scale;
} else if ((ctxt->modrm_rm & 7) == 5 && ctxt->modrm_mod == 0) {
if (ctxt->mode == X86EMUL_MODE_PROT64)
- ctxt->rip_relative = 1;
+ rip_relative = true;
} else {
base_reg = ctxt->modrm_rm;
modrm_ea += reg_read(ctxt, base_reg);
@@ -1175,6 +1176,9 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
}
}
op->addr.mem.ea = modrm_ea;
+ ctxt->memop.addr.mem.ea = (u32)ctxt->memop.addr.mem.ea;
+ if (rip_relative)
+ ctxt->memop.addr.mem.ea += ctxt->_eip;
done:
return rc;
}
@@ -4088,7 +4092,6 @@ static int decode_operand(struct x86_emulate_ctxt *ctxt,
struct operand *op,
ctxt->memop.bytes = (ctxt->d & ByteOp) ? 1 : ctxt->op_bytes;
mem_common:
*op = ctxt->memop;
- ctxt->memopp = op;
if (ctxt->d & BitOp)
fetch_bit_operand(ctxt);
op->orig_val = op->val;
@@ -4240,7 +4243,6 @@ int x86_decode_insn(struct x86_emulate_ctxt *ctxt, void
*insn, int insn_len)
struct opcode opcode;
ctxt->memop.type = OP_NONE;
- ctxt->memopp = NULL;
ctxt->_eip = ctxt->eip;
ctxt->fetch.start = ctxt->_eip;
ctxt->fetch.end = ctxt->fetch.start + insn_len;
@@ -4441,9 +4443,6 @@ done_prefixes:
ctxt->memop.addr.mem.seg = ctxt->seg_override;
- if (ctxt->memop.type == OP_MEM && ctxt->ad_bytes != 8)
- ctxt->memop.addr.mem.ea = (u32)ctxt->memop.addr.mem.ea;
-
/*
* Decode and fetch the source operand: register, memory
* or immediate.
@@ -4464,9 +4463,6 @@ done_prefixes:
rc = decode_operand(ctxt, >dst, (ctxt->d >> DstShift) & OpMask);
done:
- if (ctxt->memopp && ctxt->memopp->type == OP_MEM && ctxt->rip_relative)
- ctxt->memopp->addr.mem.ea += ctxt->_eip;
-
return (rc != X86EMUL_CONTINUE) ? EMULATION_FAILED : EMULATION_OK;
}
@@ -4541,8 +4537,8 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *))
void init_decode_cache(struct x86_emulate_ctxt *ctxt)
{
- memset(>rip_relative, 0,
- (void *)>modrm - (void *)>rip_relative);
+ memset(>rex_prefix, 0,
+ (void *)>modrm - (void *)>rex_prefix);
ctxt->io_read.pos = 0;
ctxt->io_read.end = 0;
--
1.8.3.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/
[RFC PATCH v2 3/6] KVM: emulate: cleanup decode_rm
Remove the if conditional - that will help us avoid
an "else initialize to 0" Also, rearrange operators
for slightly better code.
Signed-off-by: Bandan Das
---
arch/x86/kvm/emulate.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index a6d9892..9cbaba2 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1064,19 +1064,17 @@ static int decode_modrm(struct x86_emulate_ctxt *ctxt,
struct operand *op)
{
u8 sib;
- int index_reg = 0, base_reg = 0, scale;
+ int index_reg, base_reg, scale;
int rc = X86EMUL_CONTINUE;
ulong modrm_ea = 0;
- if (ctxt->rex_prefix) {
- ctxt->modrm_reg = (ctxt->rex_prefix & 4) << 1; /* REX.R */
- index_reg = (ctxt->rex_prefix & 2) << 2; /* REX.X */
- ctxt->modrm_rm = base_reg = (ctxt->rex_prefix & 1) << 3; /*
REG.B */
- }
+ index_reg = (ctxt->rex_prefix << 2) & 8; /* REX.X */
+ base_reg = (ctxt->rex_prefix << 3) & 8; /* REG.B */
- ctxt->modrm_mod |= (ctxt->modrm & 0xc0) >> 6;
- ctxt->modrm_reg |= (ctxt->modrm & 0x38) >> 3;
- ctxt->modrm_rm |= (ctxt->modrm & 0x07);
+ ctxt->modrm_mod = (ctxt->modrm & 0xc0) >> 6;
+ ctxt->modrm_reg = ((ctxt->rex_prefix << 1) & 8) | /* REX.R */
+ ((ctxt->modrm & 0x38) >> 3);
+ ctxt->modrm_rm = base_reg | (ctxt->modrm & 0x07);
ctxt->modrm_seg = VCPU_SREG_DS;
if (ctxt->modrm_mod == 3) {
--
1.8.3.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] gpio: bcm-kona: Add irq_set_wake method
If a consumer of a GPIO-based IRQ identifies itself as wanting to
have the capability to wake up the system through that interrupt,
update the flags to keep that interrupt enabled in suspend.
Signed-off-by: Tim Kryger
---
drivers/gpio/gpio-bcm-kona.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3f6b33c..b0e0971 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#define BCM_GPIO_PASSWD0x00a5a501
#define GPIO_PER_BANK 32
@@ -340,6 +341,23 @@ static void bcm_kona_gpio_irq_ack(struct irq_data *d)
spin_unlock_irqrestore(_gpio->lock, flags);
}
+#ifdef CONFIG_SUSPEND
+static int bcm_kona_gpio_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+
+ struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+ if (on)
+ desc->action->flags |= IRQF_NO_SUSPEND;
+ else
+ desc->action->flags &= ~IRQF_NO_SUSPEND;
+
+ return 0;
+}
+#else
+#define bcm_kona_gpio_irq_set_wake NULL
+#endif
+
static void bcm_kona_gpio_irq_mask(struct irq_data *d)
{
struct bcm_kona_gpio *kona_gpio;
@@ -494,6 +512,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
.irq_set_type = bcm_kona_gpio_irq_set_type,
.irq_request_resources = bcm_kona_gpio_irq_reqres,
.irq_release_resources = bcm_kona_gpio_irq_relres,
+ .irq_set_wake = bcm_kona_gpio_irq_set_wake,
};
static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
--
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/
[GIT PULL] Audit subsystem for v3.15
Linus, Please pull the audit tree for v3.15. You will have merge conflicts. I'll publish my branch "merge-test" where I attempted to resolve them the way you will. The main issue is an across tree change to syscall_get_arch(). I change it from taking a task_struct and pt_regs to take a void. Not a single arch used or needed either of these arguments. (For 3.16 we plan to implement the function on more arches) There are a couple of conflicts where I made changes to #includes and your tree also has some additions. Should be obvious. Two conflict issues with Kconfig changes. The first is just that your tree has some additional 'select' lines mine didn't. Obvious to resolve. The second is a conflict in init/Kconfig. I don't completely understand it. I believe it was the addition of ALPHA to the gigantic depends line. I cherry-picked the patch from your tree that introduced ALPHA before I made the switch to HAVE_ARCH_AUDITSYSCALL. I believed that would avoid the conflict, but I guess I was wrong. In any case, I have the 'select HAVE_ARCH_AUDITSYSCALL' in alpha. There is also a conflict given the last second EPERM->ECONNREFUSED switcheroo. My 3.15 is less restrictive. We return ECONNREFUSED only for non-init username. Should be another easy one... Please let me know if anything isn't easy/obvious for you! Thank you! -Eric The following changes since commit b7d3622a39fde7658170b7f3cf6c6889bb8db30d: Merge tag 'v3.13' into for-3.15 (2014-03-07 11:41:32 -0500) are available in the git repository at: git://git.infradead.org/users/eparis/audit.git master for you to fetch changes up to 312103d64d0fcadb332899a2c84b357ddb18f4e3: AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC (2014-04-10 17:51:29 -0400) AKASHI Takahiro (2): audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL audit: Add generic compat syscall support Chris Metcalf (1): AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC Eric Paris (7): audit: include subject in login records syscall_get_arch: remove useless function arguments audit: use uapi/linux/audit.h for AUDIT_ARCH declarations audit: define audit_is_compat in kernel internal header AUDIT: Allow login in non-init namespaces audit: do not cast audit_rule_data pointers pointlesly audit: renumber AUDIT_FEATURE_CHANGE into the 1300 range Eric W. Biederman (2): audit: Use struct net not pid_t to remember the network namespce to reply in audit: Send replies in the proper network namespace. Joe Perches (1): audit: remove stray newline from audit_log_execve_info() audit_panic() call Josh Boyer (1): audit: remove stray newlines from audit_log_lost messages Monam Agarwal (1): kernel: Use RCU_INIT_POINTER(x, NULL) in audit.c Richard Guy Briggs (9): audit: Use more current logging style again capabilities: add descriptions for AUDIT_CONTROL and AUDIT_WRITE audit: rename the misleading audit_get_context() to audit_take_context() pid: get pid_t ppid of task in init_pid_ns audit: convert PPIDs to the inital PID namespace. audit: anchor all pid references in the initial pid namespace audit: allow user processes to log from another PID namespace audit: remove superfluous new- prefix in AUDIT_LOGIN messages sched: declare pid_alive as inline William Roberts (3): mm: Create utility function for accessing a tasks commandline value proc: Update get proc_pid_cmdline() to use mm.h helpers audit: Audit proc//cmdline aka proctitle 蔡正龙 (1): alpha: Enable system-call auditing support. arch/alpha/Kconfig | 4 arch/alpha/include/asm/ptrace.h | 5 + arch/alpha/include/asm/thread_info.h | 2 ++ arch/alpha/kernel/Makefile | 1 + arch/alpha/kernel/audit.c| 60 +++ arch/alpha/kernel/entry.S| 6 +- arch/alpha/kernel/ptrace.c | 4 arch/arm/Kconfig | 1 + arch/arm/include/asm/syscall.h | 5 ++--- arch/ia64/Kconfig| 1 + arch/mips/include/asm/syscall.h | 4 ++-- arch/mips/kernel/ptrace.c| 2 +- arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/s390/Kconfig| 1 + arch/s390/include/asm/syscall.h | 7 +++ arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/um/Kconfig.common | 1 + arch/x86/Kconfig | 1 + arch/x86/include/asm/syscall.h | 10 -- drivers/tty/tty_audit.c | 3 ++- fs/proc/base.c | 36 ++-- include/asm-generic/syscall.h| 4 +--- include/linux/audit.h
Re: [PATCH -mm v2.2] mm: get rid of __GFP_KMEMCG
On Thu, 3 Apr 2014 19:05:59 +0400 Vladimir Davydov
wrote:
> Currently to allocate a page that should be charged to kmemcg (e.g.
> threadinfo), we pass __GFP_KMEMCG flag to the page allocator. The page
> allocated is then to be freed by free_memcg_kmem_pages. Apart from
> looking asymmetrical, this also requires intrusion to the general
> allocation path. So let's introduce separate functions that will
> alloc/free pages charged to kmemcg.
>
> The new functions are called alloc_kmem_pages and free_kmem_pages. They
> should be used when the caller actually would like to use kmalloc, but
> has to fall back to the page allocator for the allocation is large. They
> only differ from alloc_pages and free_pages in that besides allocating
> or freeing pages they also charge them to the kmem resource counter of
> the current memory cgroup.
>
> ...
>
> +void *kmalloc_order(size_t size, gfp_t flags, unsigned int order)
> +{
> + void *ret;
> + struct page *page;
> +
> + flags |= __GFP_COMP;
> + page = alloc_kmem_pages(flags, order);
> + ret = page ? page_address(page) : NULL;
> + kmemleak_alloc(ret, size, 1, flags);
> + return ret;
> +}
While we're in there it wouldn't hurt to document this: why it exists,
what it does, etc. And why it sets __GFP_COMP.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann wrote: > Hi > > On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski wrote: >> /proc/pid/fd is a really weird corner case in which the mode of an >> inode that doesn't have a name matters. I suspect that almost no one >> will ever want to open one of these things out of /proc/self/fd, and >> those who do should be made to think about it. > > I'm arguing in the context of memfd, and there's no security leak if > people get access to the underlying inode (at least I'm not aware of > any). I'm not sure what you mean. > As I said, context information is attached to the inode, not > file context, so I'm fine if people want to open multiple file > contexts via /proc. If someone wants to forbid open(), I want to hear > _why_. I assume the memfd object has uid==uid-of-creator and > mode==(777 & ~umask) (which usually results in X00, so no access for > non-owners). I cannot see how /proc is a security issue here. On further reflection, my argument for 000 is crap. As far as I can see, the only time that the mode matters at all when playing with /proc/pid/fd, and they only way to get a non-O_RDWR memfd is using /proc/pid/fd, so I'll argue for 0600 instead. Argument why 0600 is better than 0600 & ~umask: either callers don't care because the inode mode simply doesn't matter or they're using /proc/pid/fd to *reduce* permissions, in which case they'd probably like to avoid having to play with umask or call fchmod. Argument why 0600 is better than 0777 & ~umask: People /prod/pid/fd are the only ones who care, in which case they probably prefer for the permissions not be increased by other users if they give them a reduced-permission fd. Anyway, this is all mostly unimportant. Some text in the man page is probably sufficient, but I still think that 0600 is trivial to implement and a little bit more friendly. --Andy > > Thanks > David -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
