Re: Linux 3.10.69
diff --git a/Makefile b/Makefile
index dd67be657716..81ede20061cf 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 68
+SUBLEVEL = 69
EXTRAVERSION =
NAME = TOSSUG Baby Fish
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index cf2749488cd4..be9b5ca9a6c0 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -74,6 +74,8 @@ static inline u32 __attribute_const__
read_cpuid_cachetype(void)
return read_cpuid(ID_CTR_EL0);
}
+void cpuinfo_store_cpu(void);
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index add6ea616843..7cc551d1b0e1 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -97,6 +98,19 @@ void __init early_print(const char *str, ...)
printk("%s", buf);
}
+struct cpuinfo_arm64 {
+ struct cpu cpu;
+ u32 reg_midr;
+};
+
+static DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
+
+void cpuinfo_store_cpu(void)
+{
+ struct cpuinfo_arm64 *info = this_cpu_ptr(_data);
+ info->reg_midr = read_cpuid_id();
+}
+
static void __init setup_processor(void)
{
struct cpu_info *cpu_info;
@@ -127,6 +141,8 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
struct boot_param_header *devtree;
unsigned long dt_root;
+ cpuinfo_store_cpu();
+
/* Check we have a non-NULL DT pointer */
if (!dt_phys) {
early_print("\n"
@@ -290,14 +306,12 @@ static int __init arm64_device_init(void)
}
arch_initcall(arm64_device_init);
-static DEFINE_PER_CPU(struct cpu, cpu_data);
-
static int __init topology_init(void)
{
int i;
for_each_possible_cpu(i) {
- struct cpu *cpu = _cpu(cpu_data, i);
+ struct cpu *cpu = _cpu(cpu_data.cpu, i);
cpu->hotpluggable = 1;
register_cpu(cpu, i);
}
@@ -312,14 +326,41 @@ static const char *hwcap_str[] = {
NULL
};
+#ifdef CONFIG_COMPAT
+static const char *compat_hwcap_str[] = {
+ "swp",
+ "half",
+ "thumb",
+ "26bit",
+ "fastmult",
+ "fpa",
+ "vfp",
+ "edsp",
+ "java",
+ "iwmmxt",
+ "crunch",
+ "thumbee",
+ "neon",
+ "vfpv3",
+ "vfpv3d16",
+ "tls",
+ "vfpv4",
+ "idiva",
+ "idivt",
+ "vfpd32",
+ "lpae",
+ "evtstrm"
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i, j;
for_each_online_cpu(i) {
+ struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
+ u32 midr = cpuinfo->reg_midr;
+
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -328,27 +369,36 @@ static int c_show(struct seq_file *m, void *v)
#ifdef CONFIG_SMP
seq_printf(m, "processor\t: %d\n", i);
#endif
- seq_printf(m, "BogoMIPS\t: %lu.%02lu\n\n",
+ seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
loops_per_jiffy / (50UL/HZ),
loops_per_jiffy / (5000UL/HZ) % 100);
- }
-
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
-
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
- seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
- seq_printf(m, "CPU architecture: AArch64\n");
- seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
- seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
- seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
-
- seq_puts(m, "\n");
-
- seq_printf(m, "Hardware\t: %s\n", machine_name);
+ /*
+* Dump out the common processor features in a single line.
+* Userspace should read the hwcaps with getauxval(AT_HWCAP)
+* rather than attempting to parse this, but there's a body of
+* software which does already (at least for 32-bit).
+*/
+ seq_puts(m, "Features\t:");
+ if (personality(current->personality) == PER_LINUX32) {
+#ifdef CONFIG_COMPAT
+ for (j = 0; compat_hwcap_str[j]; j++)
+ if (COMPAT_ELF_HWCAP & (1 << j))
+ seq_printf(m, " %s",
compat_hwcap_str[j]);
+#endif /* CONFIG_COMPAT */
+ } else {
+ for (j =
Linux 3.10.69
I'm announcing the release of the 3.10.69 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm64/include/asm/cputype.h |2 arch/arm64/kernel/setup.c| 100 +-- arch/arm64/kernel/smp.c |5 + arch/mips/kernel/irq_cpu.c |4 + arch/mips/kernel/smp.c |2 arch/x86/include/uapi/asm/vmx.h |2 arch/x86/kvm/vmx.c | 25 - arch/x86/pci/common.c| 16 ++ crypto/crc32c.c |1 drivers/gpio/gpiolib.c |3 - fs/ext4/file.c |8 +-- fs/nilfs2/nilfs.h|2 fs/nilfs2/segment.c | 44 +++-- fs/nilfs2/segment.h |5 + include/sound/ak4113.h |2 include/sound/ak4114.h |2 kernel/smpboot.c |2 lib/checksum.c | 12 +++- mm/pagewalk.c|5 + sound/i2c/other/ak4113.c | 17 +++--- sound/i2c/other/ak4114.c | 18 +++ sound/soc/atmel/atmel_ssc_dai.c | 18 +-- sound/soc/codecs/sgtl5000.c |3 + 24 files changed, 220 insertions(+), 80 deletions(-) Andy Lutomirski (1): x86,kvm,vmx: Preserve CR4 across VM entry Bo Shen (1): ASoC: atmel_ssc_dai: fix start event for I2S mode Charlotte Richardson (1): PCI: Add NEC variants to Stratus ftServer PCIe DMI check Dmitry Monakhov (1): ext4: prevent bugon on race between write/fcntl Eric Nelson (1): ASoC: sgtl5000: add delay before first I2C access Felix Fietkau (1): MIPS: IRQ: Fix disable_irq on CPU IRQs Greg Kroah-Hartman (1): Linux 3.10.69 Hemmo Nieminen (1): MIPS: Fix kernel lockup or crash after CPU offline/online Johan Hovold (2): gpio: sysfs: fix memory leak in gpiod_export_link gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low Lai Jiangshan (1): smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() Mark Rutland (1): arm64: Fix up /proc/cpuinfo Mathias Krause (1): crypto: crc32c - add missing crypto module alias Petr Matousek (1): kvm: vmx: handle invvpid vm exit gracefully Ryusuke Konishi (1): nilfs2: fix deadlock of segment constructor over I_SYNC flag Shiraz Hashim (1): mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range Takashi Iwai (1): ALSA: ak411x: Fix stall in work callback karl beldan (2): lib/checksum.c: fix carry in csum_tcpudp_nofold lib/checksum.c: fix build for generic csum_tcpudp_nofold pgp2nZcPFISid.pgp Description: PGP signature
Re: Linux 3.14.33
diff --git a/Makefile b/Makefile
index 00fffa3f2310..b0963ca2895d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 14
-SUBLEVEL = 32
+SUBLEVEL = 33
EXTRAVERSION =
NAME = Remembering Coco
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index 6eb97b3a7481..4370933f16cd 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -144,21 +144,17 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
for_each_possible_cpu(i) {
- if (i == cpu) {
- asid = 0;
- } else {
- asid = atomic64_xchg(_cpu(active_asids, i), 0);
- /*
-* If this CPU has already been through a
-* rollover, but hasn't run another task in
-* the meantime, we must preserve its reserved
-* ASID, as this is the only trace we have of
-* the process it is still running.
-*/
- if (asid == 0)
- asid = per_cpu(reserved_asids, i);
- __set_bit(asid & ~ASID_MASK, asid_map);
- }
+ asid = atomic64_xchg(_cpu(active_asids, i), 0);
+ /*
+* If this CPU has already been through a
+* rollover, but hasn't run another task in
+* the meantime, we must preserve its reserved
+* ASID, as this is the only trace we have of
+* the process it is still running.
+*/
+ if (asid == 0)
+ asid = per_cpu(reserved_asids, i);
+ __set_bit(asid & ~ASID_MASK, asid_map);
per_cpu(reserved_asids, i) = asid;
}
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index c404fb0df3a6..64bc6c6efc6f 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -77,6 +77,8 @@ static inline u32 __attribute_const__
read_cpuid_cachetype(void)
return read_cpuid(CTR_EL0);
}
+void cpuinfo_store_cpu(void);
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 071c3822442b..1e01d80a1165 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -73,7 +74,6 @@ unsigned int compat_elf_hwcap __read_mostly =
COMPAT_ELF_HWCAP_DEFAULT;
#endif
static const char *cpu_name;
-static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
/*
@@ -193,6 +193,19 @@ static void __init smp_build_mpidr_hash(void)
}
#endif
+struct cpuinfo_arm64 {
+ struct cpu cpu;
+ u32 reg_midr;
+};
+
+static DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
+
+void cpuinfo_store_cpu(void)
+{
+ struct cpuinfo_arm64 *info = this_cpu_ptr(_data);
+ info->reg_midr = read_cpuid_id();
+}
+
static void __init setup_processor(void)
{
struct cpu_info *cpu_info;
@@ -213,6 +226,8 @@ static void __init setup_processor(void)
sprintf(init_utsname()->machine, ELF_PLATFORM);
elf_hwcap = 0;
+ cpuinfo_store_cpu();
+
/*
* ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
* The blocks we test below represent incremental functionality
@@ -257,8 +272,6 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
while (true)
cpu_relax();
}
-
- machine_name = of_flat_dt_get_machine_name();
}
/*
@@ -363,14 +376,12 @@ static int __init arm64_device_init(void)
}
arch_initcall(arm64_device_init);
-static DEFINE_PER_CPU(struct cpu, cpu_data);
-
static int __init topology_init(void)
{
int i;
for_each_possible_cpu(i) {
- struct cpu *cpu = _cpu(cpu_data, i);
+ struct cpu *cpu = _cpu(cpu_data.cpu, i);
cpu->hotpluggable = 1;
register_cpu(cpu, i);
}
@@ -391,14 +402,41 @@ static const char *hwcap_str[] = {
NULL
};
+#ifdef CONFIG_COMPAT
+static const char *compat_hwcap_str[] = {
+ "swp",
+ "half",
+ "thumb",
+ "26bit",
+ "fastmult",
+ "fpa",
+ "vfp",
+ "edsp",
+ "java",
+ "iwmmxt",
+ "crunch",
+ "thumbee",
+ "neon",
+ "vfpv3",
+ "vfpv3d16",
+ "tls",
+ "vfpv4",
+ "idiva",
+ "idivt",
+ "vfpd32",
+ "lpae",
+ "evtstrm"
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i,
Re: Linux 3.18.7
diff --git a/Makefile b/Makefile
index d2bff2d5ae25..0efae2279fbe 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 6
+SUBLEVEL = 7
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e0278ecbc816..98960b7bc518 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -368,7 +368,7 @@
};
i2s1: i2s@1396 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x1396 0x100>;
clocks = < CLK_I2S1>;
clock-names = "iis";
@@ -378,7 +378,7 @@
};
i2s2: i2s@1397 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x1397 0x100>;
clocks = < CLK_I2S2>;
clock-names = "iis";
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index 6eb97b3a7481..4370933f16cd 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -144,21 +144,17 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
for_each_possible_cpu(i) {
- if (i == cpu) {
- asid = 0;
- } else {
- asid = atomic64_xchg(_cpu(active_asids, i), 0);
- /*
-* If this CPU has already been through a
-* rollover, but hasn't run another task in
-* the meantime, we must preserve its reserved
-* ASID, as this is the only trace we have of
-* the process it is still running.
-*/
- if (asid == 0)
- asid = per_cpu(reserved_asids, i);
- __set_bit(asid & ~ASID_MASK, asid_map);
- }
+ asid = atomic64_xchg(_cpu(active_asids, i), 0);
+ /*
+* If this CPU has already been through a
+* rollover, but hasn't run another task in
+* the meantime, we must preserve its reserved
+* ASID, as this is the only trace we have of
+* the process it is still running.
+*/
+ if (asid == 0)
+ asid = per_cpu(reserved_asids, i);
+ __set_bit(asid & ~ASID_MASK, asid_map);
per_cpu(reserved_asids, i) = asid;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 64c4f0800ee3..38eead12f35b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -79,7 +80,6 @@ unsigned int compat_elf_hwcap2 __read_mostly;
#endif
static const char *cpu_name;
-static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
/*
@@ -311,8 +311,6 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
while (true)
cpu_relax();
}
-
- machine_name = of_flat_dt_get_machine_name();
}
/*
@@ -449,14 +447,50 @@ static const char *hwcap_str[] = {
NULL
};
+#ifdef CONFIG_COMPAT
+static const char *compat_hwcap_str[] = {
+ "swp",
+ "half",
+ "thumb",
+ "26bit",
+ "fastmult",
+ "fpa",
+ "vfp",
+ "edsp",
+ "java",
+ "iwmmxt",
+ "crunch",
+ "thumbee",
+ "neon",
+ "vfpv3",
+ "vfpv3d16",
+ "tls",
+ "vfpv4",
+ "idiva",
+ "idivt",
+ "vfpd32",
+ "lpae",
+ "evtstrm"
+};
+
+static const char *compat_hwcap2_str[] = {
+ "aes",
+ "pmull",
+ "sha1",
+ "sha2",
+ "crc32",
+ NULL
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i, j;
for_each_online_cpu(i) {
+ struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
+ u32 midr = cpuinfo->reg_midr;
+
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -465,24 +499,38 @@ static int c_show(struct seq_file *m, void *v)
#ifdef CONFIG_SMP
seq_printf(m, "processor\t: %d\n", i);
#endif
- }
-
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
-
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
-
- seq_printf(m, "\nCPU
Linux 3.14.33
I'm announcing the release of the 3.14.33 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/mm/context.c| 26 -- arch/arm64/include/asm/cputype.h |2 arch/arm64/kernel/setup.c| 99 --- arch/arm64/kernel/smp.c |5 + arch/mips/cavium-octeon/smp.c|2 arch/mips/kernel/irq_cpu.c |4 + arch/mips/kernel/smp.c |2 arch/x86/kvm/vmx.c | 16 +- arch/x86/pci/common.c| 16 ++ crypto/crc32c.c |1 drivers/gpio/gpiolib.c |3 - fs/cifs/file.c |6 +- fs/ext4/file.c |8 +-- fs/nilfs2/nilfs.h|2 fs/nilfs2/segment.c | 44 +++-- fs/nilfs2/segment.h |5 + include/sound/ak4113.h |2 include/sound/ak4114.h |2 kernel/smpboot.c |2 lib/checksum.c | 12 +++- mm/pagewalk.c|5 + scripts/kconfig/menu.c |4 - sound/i2c/other/ak4113.c | 17 +++--- sound/i2c/other/ak4114.c | 18 +++ sound/soc/atmel/atmel_ssc_dai.c | 18 +-- sound/soc/codecs/sgtl5000.c |3 + 27 files changed, 226 insertions(+), 100 deletions(-) Aaro Koskinen (1): MIPS: OCTEON: fix kernel crash when offlining a CPU Andy Lutomirski (1): x86,kvm,vmx: Preserve CR4 across VM entry Bo Shen (1): ASoC: atmel_ssc_dai: fix start event for I2S mode Charlotte Richardson (1): PCI: Add NEC variants to Stratus ftServer PCIe DMI check Dmitry Monakhov (1): ext4: prevent bugon on race between write/fcntl Eric Nelson (1): ASoC: sgtl5000: add delay before first I2C access Felix Fietkau (1): MIPS: IRQ: Fix disable_irq on CPU IRQs Greg Kroah-Hartman (1): Linux 3.14.33 Hemmo Nieminen (1): MIPS: Fix kernel lockup or crash after CPU offline/online Johan Hovold (2): gpio: sysfs: fix memory leak in gpiod_export_link gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low Lai Jiangshan (1): smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() Mark Rutland (1): arm64: Fix up /proc/cpuinfo Mathias Krause (1): crypto: crc32c - add missing crypto module alias Peter Kümmel (1): kconfig: Fix warning "‘jump’ may be used uninitialized" Ryusuke Konishi (1): nilfs2: fix deadlock of segment constructor over I_SYNC flag Sachin Prabhu (1): Complete oplock break jobs before closing file handle Shiraz Hashim (1): mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range Takashi Iwai (1): ALSA: ak411x: Fix stall in work callback Will Deacon (1): ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover karl beldan (2): lib/checksum.c: fix carry in csum_tcpudp_nofold lib/checksum.c: fix build for generic csum_tcpudp_nofold pgptCpVZQ4bIq.pgp Description: PGP signature
Linux 3.18.7
I'm announcing the release of the 3.18.7 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arm/boot/dts/exynos4.dtsi|4 - arch/arm/mm/context.c | 26 +++- arch/arm64/kernel/setup.c | 96 ++ arch/mips/cavium-octeon/smp.c |2 arch/mips/include/asm/mipsregs.h | 15 arch/mips/kernel/irq_cpu.c|4 + arch/mips/kernel/smp.c|2 arch/mips/kernel/traps.c |3 arch/mips/mm/tlb-r4k.c|2 arch/x86/kernel/cpu/microcode/core.c |2 arch/x86/mm/fault.c |8 -- arch/x86/pci/common.c | 16 + drivers/gpio/gpio-mcp23s08.c | 17 +++-- drivers/gpio/gpiolib-sysfs.c |3 drivers/gpu/drm/radeon/radeon_benchmark.c | 13 ++-- drivers/gpu/drm/radeon/radeon_display.c |3 drivers/gpu/drm/radeon/radeon_gem.c |6 + drivers/gpu/drm/radeon/radeon_kms.c | 16 ++--- drivers/gpu/drm/radeon/radeon_test.c |8 +- drivers/gpu/drm/radeon/radeon_vm.c|6 + drivers/md/raid5.c|5 + drivers/pci/host/pcie-designware.c|3 drivers/pci/quirks.c | 40 +++- drivers/scsi/sd.c |6 + drivers/spi/spi-fsl-dspi.c| 14 +++- drivers/spi/spi-imx.c |4 + fs/cifs/file.c|6 + fs/nilfs2/nilfs.h |2 fs/nilfs2/segment.c | 44 - fs/nilfs2/segment.h |5 + include/linux/tracepoint.h|2 include/sound/ak4113.h|2 include/sound/ak4114.h|2 include/trace/events/tlb.h|4 - kernel/smpboot.c |2 kernel/time/hrtimer.c |2 lib/checksum.c| 12 +++ mm/memcontrol.c |2 mm/pagewalk.c |5 + mm/shmem.c|2 scripts/kconfig/menu.c|4 - sound/i2c/other/ak4113.c | 17 ++--- sound/i2c/other/ak4114.c | 18 ++--- sound/soc/atmel/atmel_ssc_dai.c | 18 + sound/soc/codecs/sgtl5000.c |3 46 files changed, 335 insertions(+), 143 deletions(-) Aaro Koskinen (1): MIPS: OCTEON: fix kernel crash when offlining a CPU Alex Deucher (2): drm/radeon: don't init gpuvm if accel is disabled (v3) drm/radeon: properly set vm fragment size for TN/RL Bhuvanchandra DV (1): spi: spi-fsl-dspi: Remove usage of devm_kzalloc Bo Shen (1): ASoC: atmel_ssc_dai: fix start event for I2S mode Boris Ostrovsky (1): x86, microcode: Return error from driver init code when loader is disabled Brian King (1): sd: Fix max transfer length for 4k disks Charlotte Richardson (1): PCI: Add NEC variants to Stratus ftServer PCIe DMI check Christian König (1): drm/radeon: fix PLLs on RS880 and older v2 David Daney (1): MIPS: Fix C0_Pagegrain[IEC] support. Eric Nelson (1): ASoC: sgtl5000: add delay before first I2C access Felix Fietkau (1): MIPS: IRQ: Fix disable_irq on CPU IRQs Greg Kroah-Hartman (1): Linux 3.18.7 Hemmo Nieminen (1): MIPS: Fix kernel lockup or crash after CPU offline/online Ilija Hadzic (2): drm/radeon: fix the crash in benchmark functions drm/radeon: fix the crash in test functions James Hogan (2): MIPS: mipsregs.h: Add write_32bit_cp1_register() MIPS: traps: Fix inline asm ctc1 missing .set hardfloat Johan Hovold (2): gpio: sysfs: fix memory leak in gpiod_export_link gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low John Stultz (1): hrtimer: Fix incorrect tai offset calculation for non high-res timer systems Lai Jiangshan (1): smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread() Linus Torvalds (1): x86: mm: move mmap_sem unlock from mm_fault_error() to caller Lucas Stach (1): PCI: designware: Reject MSI-X IRQs Mark Rutland (1): arm64: Fix up /proc/cpuinfo Michal Hocko (1): memcg, shmem: fix shmem migration to use lrucare Myron Stowe (1): PCI: Handle read-only BARs on AMD CS553x devices NeilBrown (1): md/raid5: fix another livelock caused by non-aligned writes.
Re: [PATCHv2 1/2] pci: spear: Use platform_driver_probe instead of platform_driver_register
Hi,
On 02/11/2015 05:35 AM, Viresh Kumar wrote:
On 11 February 2015 at 00:31, Matwey V. Kornilov wrote:
Use platform_driver_probe instead of platform_driver_register
because the former allows us to use probe function placed into __init section
and the driver itself is not support hotplugging (yet?).
Signed-off-by: Matwey V. Kornilov
---
Changes from v1:
- Use platform_driver_probe instead of platform_driver_register to make
linker happy.
drivers/pci/host/pcie-spear13xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/host/pcie-spear13xx.c
b/drivers/pci/host/pcie-spear13xx.c
index 866465f..51e1344 100644
--- a/drivers/pci/host/pcie-spear13xx.c
+++ b/drivers/pci/host/pcie-spear13xx.c
@@ -371,7 +371,6 @@ static const struct of_device_id spear13xx_pcie_of_match[]
= {
MODULE_DEVICE_TABLE(of, spear13xx_pcie_of_match);
static struct platform_driver spear13xx_pcie_driver __initdata = {
- .probe = spear13xx_pcie_probe,
.driver = {
.name = "spear-pcie",
.of_match_table = of_match_ptr(spear13xx_pcie_of_match),
@@ -382,7 +381,7 @@ static struct platform_driver spear13xx_pcie_driver
__initdata = {
static int __init spear13xx_pcie_init(void)
{
- return platform_driver_register(_pcie_driver);
+ return platform_driver_probe(_pcie_driver,
spear13xx_pcie_probe);
}
module_init(spear13xx_pcie_init);
The problem here is that the driver is never registered. And we might never
see it in sysfs. Probably a better solution would be to just remove all __init
parts from this driver. Let it take space even after it is used. And don't care
about it.
Sorry was busy in a conference and couldn't reply to your earlier mail on this.
Using platform_driver_probe() prevents deferred probe which is problem
because you get phy, clocks from probe, and these calls could return
EPROBE_DEFFER.
Also dw_pcie_host_init() called from spear13xx_add_pcie_port() is
annotated as __init. I wanted send a patch which removes __init from
dw_pcie_host_init() but I haven't time, yet.
regards,
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Dell ALPS patches for Dell Latitude 7250 & 7450
Hi,
On 10-02-15 14:19, Pali Rohár wrote:
Hello,
now I found on Dell support website, that they also provide
psmouse/alps.c driver for new Dell Latitude 7250 & 7450 machines:
http://www.dell.com/support/home/gh/en/ghdhs1/Drivers/DriversDetails?driverId=N5V5D
It is again in Ubuntu support package and so users and developers
who do not use Ubuntu probably do not know about it...
Dell alps.c driver introduced ALPS protocol v8 and v9. I did not
found anything on linux-input ML about it, so to make sure that
support for new ALPS/Dell models for linux do not disappear I'm
sending diff against linux v3.14-rc1 version (which looks like to
be version of which Dell introduced they changes)...
Thanks for this and the other related mail. I also have an alps.c
directly from alps themselves which adds support for v8 and v9
protocols. The problem is that like with v7 the code is not really
in a state where we want to take it as is, e.g. it does clickpad
softbutton emulation in the kernel instead of leaving it to userspace.
I spend a considerable amount of time cleaning up the alps code itself
and then adding a cleaner version of the v7 code, we should do the same
for the v8 and v9 code probably but that requires someone with hardware
access so that we can actually test the end result.
Regards,
Hans
--- linux-3.14-rc1/drivers/input/mouse/alps.c 2015-02-08 12:38:06.507282067
+0100
+++
goliad-mlk-14_A03.fish.tar.gz/debs/touchpad-alps-trusty-dkms_20140325_all.deb/usr/src/touchpad-alps-trusty-20140325/alps.c
2014-06-06 04:21:48.0 +0200
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "psmouse.h"
#include "alps.h"
@@ -32,6 +33,11 @@
#define ALPS_REG_BASE_RUSHMORE0xc2c0
#define ALPS_REG_BASE_PINNACLE0x
+#define LEFT_BUTTON_BIT0x01
+#define RIGHT_BUTTON_BIT 0x02
+
+#define V7_LARGE_MOVEMENT 130
+
static const struct alps_nibble_commands alps_v3_nibble_commands[] = {
{ PSMOUSE_CMD_SETPOLL, 0x00 }, /* 0 */
{ PSMOUSE_CMD_RESET_DIS,0x00 }, /* 1 */
@@ -99,6 +105,10 @@ static const struct alps_nibble_commands
#define ALPS_FOUR_BUTTONS 0x40/* 4 direction button present */
#define ALPS_PS2_INTERLEAVED 0x80/* 3-byte PS/2 packet interleaved with
6-byte ALPS packet */
+#define ALPS_BTNLESS 0x100 /* ALPS ClickPad flag */
+
+#defineDOL_IS_APDATA(_BY) ((_BY[0]&0x01)==0x01)
+#defineDOL_IS_PROFDATA(_BY)((_BY[0]&0x20)==0x20)
static const struct alps_model_info alps_model_data[] = {
{ { 0x32, 0x02, 0x14 }, 0x00, ALPS_PROTO_V2, 0xf8, 0xf8, ALPS_PASS |
ALPS_DUALPOINT }, /* Toshiba Salellite Pro M10 */
@@ -140,6 +150,20 @@ static void alps_set_abs_params_mt(struc
* isn't valid per PS/2 spec.
*/
+static unsigned int alps_pt_distance(struct alps_abs_data *pt0,
+ struct alps_abs_data *pt1)
+{
+ int vect_x, vect_y;
+
+ if (!pt0 || !pt1)
+ return 0;
+
+ vect_x = pt0->x - pt1->x;
+ vect_y = pt0->y - pt1->y;
+
+ return int_sqrt(vect_x * vect_x + vect_y * vect_y);
+}
+
/* Packet formats are described in Documentation/input/alps.txt */
static bool alps_is_valid_first_byte(struct alps_data *priv,
@@ -296,8 +320,8 @@ static void alps_process_bitmap_dolphin(
y_map = fields->y_map;
if (!x_map || !y_map)
- return;
-
+return;
+
/* Get Most-significant and Least-significant bit */
x_msb = fls(x_map);
x_lsb = ffs(x_map);
@@ -306,8 +330,8 @@ static void alps_process_bitmap_dolphin(
/* Most-significant bit should never exceed max sensor line number */
if (x_msb > priv->x_bits || y_msb > priv->y_bits)
- return;
-
+return;
+
*x1 = *y1 = *x2 = *y2 = 0;
if (fields->fingers > 1) {
@@ -320,11 +344,11 @@ static void alps_process_bitmap_dolphin(
end_bit = y_msb - 1;
box_middle_y = (priv->y_max * (start_bit + end_bit)) /
(2 * (priv->y_bits - 1));
- *x1 = fields->x;
- *y1 = fields->y;
+ *x1 = fields->pt.x;
+ *y1 = fields->pt.y;
*x2 = 2 * box_middle_x - *x1;
*y2 = 2 * box_middle_y - *y1;
- }
+ }
}
/*
@@ -461,6 +485,55 @@ static void alps_report_semi_mt_data(str
alps_set_slot(dev, 1, num_fingers == 2, x2, y2);
}
+static void alps_report_semi_mt_data_ex(struct input_dev *dev, int num_fingers,
+struct alps_abs_data coord[])
+{
+ unsigned char i;
+
+ for (i = 0; i < num_fingers; i++) {
+ if (!coord[i].x || !coord[i].y || !coord[i].z) {
+ alps_set_slot(dev, i, 0, coord[i].x, coord[i].y);
+
Re: [PATCH] Input: ALPS: Move v7 packet info to Documentation and v6 packet info
Hi,
On 10-02-15 13:43, Pali Rohár wrote:
This patch move all packet info from driver source code to documentation
and adds info about v6 packet format (from driver source code).
Signed-off-by: Pali Rohár
Thanks for doing this:
Acked-by: Hans de Goede
Regards,
Hans
---
Documentation/input/alps.txt | 68 --
drivers/input/mouse/alps.c | 39
2 files changed, 66 insertions(+), 41 deletions(-)
diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index 90bca6f..a63e5e0 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -3,8 +3,8 @@ ALPS Touchpad Protocol
Introduction
-Currently the ALPS touchpad driver supports five protocol versions in use by
-ALPS touchpads, called versions 1, 2, 3, 4 and 5.
+Currently the ALPS touchpad driver supports seven protocol versions in use by
+ALPS touchpads, called versions 1, 2, 3, 4, 5, 6 and 7.
Since roughly mid-2010 several new ALPS touchpads have been released and
integrated into a variety of laptops and netbooks. These new touchpads
@@ -240,3 +240,67 @@ For mt, the format is:
byte 3:0 x23 x22 x21 x20 x19 x18 x17
byte 4:0 x9 x8x7 x6 x5 x4x3
byte 5:0 x16 x15 x14 x13 x12 x11 x10
+
+ALPS Absolute Mode - Protocol Version 6
+---
+
+For trackstick packet, the format is:
+
+ byte 0:11111111
+ byte 1:0 X6 X5 X4 X3 X2 X1 X0
+ byte 2:0 Y6 Y5 Y4 Y3 Y2 Y1 Y0
+ byte 3:? Y7 X7??MRL
+ byte 4: Z7 Z6 Z5 Z4 Z3 Z2 Z1 Z0
+ byte 5:01111111
+
+For touchpad packet, the format is:
+
+ byte 0:11111111
+ byte 1:0000 x3 x2 x1 x0
+ byte 2:0000 y3 y2 y1 y0
+ byte 3:? x7 x6 x5 x4?rl
+ byte 4:? y7 y6 y5 y4???
+ byte 5: z7 z6 z5 z4 z3 z2 z1 z0
+
+(v6 touchpad does not have middle button)
+
+ALPS Absolute Mode - Protocol Version 7
+---
+
+For trackstick packet, the format is:
+
+ byte 0:01001000
+ byte 1:11**1MRL
+ byte 2: X71 X5 X4 X3 X2 X1 X0
+ byte 3: Z61 Y6 X61 Y2 Y1 Y0
+ byte 4: Y70 Y5 Y4 Y3110
+ byte 5: T0 Z5 Z4 Z3 Z2 Z1 Z0
+
+For touchpad packet, the format is:
+
+ packet-fmt b7 b6 b5 b4 b3 b2 b1 b0
+ byte 0: TWO & MULTI L 1 R M 1 Y0-2 Y0-1 Y0-0
+ byte 0: NEW L 1 X1-5 1 1 Y0-2 Y0-1 Y0-0
+ byte 1: Y0-10 Y0-9 Y0-8 Y0-7 Y0-6 Y0-5 Y0-4 Y0-3
+ byte 2: X0-11 1 X0-10 X0-9 X0-8 X0-7 X0-6 X0-5
+ byte 3: X1-11 1 X0-4 X0-3 1 X0-2 X0-1 X0-0
+ byte 4: TWO X1-10TWO X1-9 X1-8 X1-7 X1-6 X1-5 X1-4
+ byte 4: MULTI X1-10TWO X1-9 X1-8 X1-7 X1-6 Y1-5 1
+ byte 4: NEW X1-10TWO X1-9 X1-8 X1-7 X1-6 0 0
+ byte 5: TWO & NEW Y1-10 0 Y1-9 Y1-8 Y1-7 Y1-6 Y1-5 Y1-4
+ byte 5: MULTI Y1-10 0 Y1-9 Y1-8 Y1-7 Y1-6F-1F-0
+
+ L: Left button
+ R / M: Non-clickpads: Right / Middle button
+Clickpads: When > 2 fingers are down, and some fingers
+are in the button area, then the 2 coordinates reported
+are for fingers outside the button area and these report
+extra fingers being present in the right / left button
+area. Note these fingers are not added to the F field!
+so if a TWO packet is received and R = 1 then there are
+3 fingers down, etc.
+ TWO: 1: Two touches present, byte 0/4/5 are in TWO fmt
+0: If byte 4 bit 0 is 1, then byte 0/4/5 are in MULTI fmt
+ otherwise byte 0 bit 4 must be set and byte 0/4/5 are
+ in NEW fmt
+ F: Number of fingers - 3, 0 means 3 fingers, 1 means 4 ...
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index d88d73d..5ac2a91 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -881,34 +881,6 @@ static void alps_get_finger_coordinate_v7(struct
input_mt_pos *mt,
unsigned char *pkt,
unsigned char pkt_id)
{
- /*
-* packet-fmtb7 b6b5 b4 b3 b2 b1 b0
-* Byte0 TWO & MULTIL1 RM1 Y0-2 Y0-1 Y0-0
-* Byte0 NEWL1 X1-511 Y0-2 Y0-1 Y0-0
-* Byte1Y0-10 Y0-9 Y0-8 Y0-7 Y0-6 Y0-5 Y0-4 Y0-3
-* Byte2X0-11
Re: [RFC] Making memcg track ownership per address_space or anon_vma
Hello Tejun, On Tue 10-02-15 21:19:06, Tejun Heo wrote: > On Sat, Feb 07, 2015 at 09:38:39AM -0500, Tejun Heo wrote: > > If we can argue that memcg and blkcg having different views is > > meaningful and characterize and justify the behaviors stemming from > > the deviation, sure, that'd be fine, but I don't think we have that as > > of now. ... > So, based on the assumption that write sharings are mostly incidental > and temporary (ie. we're basically declaring that we don't support > persistent write sharing), how about something like the following? > > 1. memcg contiues per-page tracking. > > 2. Each inode is associated with a single blkcg at a given time and >written out by that blkcg. > > 3. While writing back, if the number of pages from foreign memcg's is >higher than certain ratio of total written pages, the inode is >marked as disowned and the writeback instance is optionally >terminated early. e.g. if the ratio of foreign pages is over 50% >after writing out the number of pages matching 5s worth of write >bandwidth for the bdi, mark the inode as disowned. > > 4. On the following dirtying of the inode, the inode is associated >with the matching blkcg of the dirtied page. Note that this could >be the next cycle as the inode could already have been marked dirty >by the time the above condition triggered. In that case, the >following writeback would be terminated early too. > > This should provide sufficient corrective pressure so that incidental > and temporary sharing of an inode doesn't become a persistent issue > while keeping the complexity necessary for implementing such pressure > fairly minimal and self-contained. Also, the changes necessary for > individual filesystems would be minimal. I like this proposal. It looks simple enough and when inodes aren't pernamently write-shared it converges to the blkcg that is currently writing to the inode. So ack from me. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 答复: [LKP] [sched/fair] 638476007d1: +1.1% unixbench.score
On Wed, 2015-02-11 at 15:25 +0800, pang.xun...@zte.com.cn wrote:
> Hello,
>
> Does "+1.1% unixbench.score" mean better or worse?
>
> Anyway, this is a load bug fix, does can affect the load balancing
> behavior a little.
I think this means something better :)
Best Regards,
Huang, Ying
> Regards,
> Xunlei
>
>
>
> Huang Ying
> 2015-02-09 上午 11:27
>
> 收件人
> Xunlei Pang ,
> 抄送
> Ingo Molnar , LKML , LKP
> ML
> 主题
> [LKP] [sched/fair] 638476007d1: +1.1% unixbench.score
>
>
>
>
>
>
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> commit 638476007d13534b2ed4134bf0279ef44071140b ("sched/fair: Fix the
> dealing with decay_count in __synchronize_entity_decay()")
>
> It appears that your patch cause CPU usage increased a little, so that
> unixbench score increased.
>
> testbox/testcase/testparams: nhm-white/unixbench/spawn
>
> 7f1a169b88f513e3 638476007d13534b2ed4134bf0
> --
> %stddev %change %stddev
> \ |\
> 268908 ± 0% +4.6% 281320 ± 0%
> unixbench.time.involuntary_context_switches
> 1.147e+08 ± 0% +1.5% 1.164e+08 ± 0%
> unixbench.time.minor_page_faults
> 3607 ± 0% +1.1% 3648 ± 0% unixbench.score
>324 ± 0% +1.2%328 ± 0%
> unixbench.time.percent_of_cpu_this_job_got
>633 ± 0% +1.2%641 ± 0% unixbench.time.system_time
> 54100 ± 3% +51.0% 81705 ± 21%
> sched_debug.cpu#4.ttwu_local
> 65678 ± 7% +49.5% 98187 ± 16%
> sched_debug.cpu#6.ttwu_local
> 5624 ± 31% +52.1% 8553 ± 11% sched_debug.cpu#6.curr->pid
> 58 ± 20% +37.6% 80 ± 7%
> sched_debug.cfs_rq[3]:/.runnable_load_avg
> 61 ± 10% +22.5% 74 ± 14%
> sched_debug.cpu#2.cpu_load[3]
> 218479 ± 5% +15.4% 252190 ± 5%
> sched_debug.cpu#6.ttwu_count
>102 ± 17% -19.3% 82 ± 10%
> sched_debug.cpu#4.cpu_load[2]
> 423974 ± 4% +15.6% 490072 ± 5% sched_debug.cpu#5.avg_idle
> 62 ± 4% +16.9% 72 ± 9%
> sched_debug.cpu#2.cpu_load[4]
> 152298 ± 2% +9.7% 167037 ± 3%
> sched_debug.cfs_rq[5]:/.min_vruntime
> 156795 ± 1% +11.3% 174544 ± 1%
> sched_debug.cfs_rq[7]:/.min_vruntime
> 155535 ± 3% +11.8% 173813 ± 2%
> sched_debug.cfs_rq[6]:/.min_vruntime
> 9231 ± 0% +1.3% 9348 ± 0% vmstat.system.in
>
> nhm-white: Nehalem
> Memory: 6G
>
>
> unixbench.time.system_time
>
> 643
> ++---O+
> 642 ++O O O
> O O O O O O O O OO O O O O O O O OO O O O |
> 641 ++ O O O O |
> 640 ++ |
> | |
> 639 ++ |
> 638 ++ |
> 637 ++ |
> | |
> 636 ++ |
> 635 ++ .* |
> *.*.. .*..* + .*.. .*.*.. * |
> 634 ++ **..*.*..** + |
> 633
> ++*---+
>
>
> unixbench.time.involuntary_context_switches
>
> 286000
> ++-+
> 284000 ++ O |
> |OO |
> 282000 ++ O O
> O
> 28 O+OO O O O O O O OO O O |
> |O O O O O O OO |
> 278000 ++ O O O |
> 276000 ++ |
> 274000 ++ |
> | |
> 272000 ++ |
> 27 ++ .*.*. *.*.. .* |
> *.*. *..*. .* : *.*.*. |
> 268000 ++* +: |
> 266000
> ++*--*-+
>
>
>kmsg.tsc:Fast_TSC_calibration_failed
>
> 1
> ++-OO-+
> | |
> | |
> 0.8 ++ |
> | |
> | |
> 0.6 ++ |
> | |
> 0.4 ++ |
> | |
> | |
> 0.2 ++ |
> | |
> | |
> 0
> O+O--O-O--O-O-O--O-O--O-O--O-O-O--O-OO-O--OO-O--O-O-O--O-O--O-O
>
> [*] bisect-good sample
> [O] bisect-bad sample
>
> To reproduce:
>
> apt-get install ruby ruby-oj
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/setup-local job.yaml # the job file attached in this email
> bin/run-local job.yaml
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are
> provided
> for informational
Re: [PATCH v2] ARM: dts: exynos5420: Add maudio power domain
On pon, 2015-02-09 at 14:57 +0100, Krzysztof Kozlowski wrote:
> Add maudio power domain to Exynos 5420 DTSI file so its state could be
> tracked. This actually won't power down this domain because the pl330
> dmaengine driver (for adma channel) uses IRQ safe runtime PM. Thus the
> patch should not introduce any functional change except of visibility of
> this domain to the system.
I was wrong. There is a functional change during suspend.
The mau domain is powered off after suspending adma device (pl330 dma).
However later clk-exynos-audss receives syscore suspend notification and
tries to save mau clock registers. This results in imprecise abort
because mau power domain is turned off.
I think it is better to drop my patch.
Krzysztof
>
> Signed-off-by: Krzysztof Kozlowski
> Reviewed-by: Javier Martinez Canillas
>
> ---
>
> Changes sinve v1:
> 1. Use generic power domain bindings (suggested by Javier).
> 2. Add Javier's reviewed-by.
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 9dc2e9773b30..28c4a2f4b991 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -288,6 +288,12 @@
> "pclk1", "clk1", "pclk2", "clk2";
> };
>
> + mau_pd: power-domain@100440E0 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x100440E0 0x20>;
> + #power-domain-cells = <0>;
> + };
> +
> pinctrl_0: pinctrl@1340 {
> compatible = "samsung,exynos5420-pinctrl";
> reg = <0x1340 0x1000>;
> @@ -346,6 +352,7 @@
> #dma-cells = <1>;
> #dma-channels = <6>;
> #dma-requests = <16>;
> + power-domains = <_pd>;
> };
>
> pdma0: pdma@121A {
> @@ -415,6 +422,7 @@
> pinctrl-names = "default";
> pinctrl-0 = <_bus>;
> status = "disabled";
> + power-domains = <_pd>;
> };
>
> i2s1: i2s@12D6 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SMSDOM detected a violation in a document you authored.
Subject: Delivery reports about your e-mail The scanned document was classified as a mass-mailer and was deleted. The scanned document was deleted. Violation Information: The attachment letter.exe contained the risk W32.Mydoom.M@mm and was deleted. The type of attachment letter.exe violated the content filter rule Multimedia/Executable analysis and was deleted. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SMSDOM detected a violation in a document you authored.
Subject: Delivery reports about your e-mail The scanned document was classified as a mass-mailer and was deleted. The scanned document was deleted. Violation Information: The attachment letter.exe contained the risk W32.Mydoom.M@mm and was deleted. The type of attachment letter.exe violated the content filter rule Multimedia/Executable analysis and was deleted. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
Hi Philipp, On Fri, Feb 06, 2015 at 04:13:20PM +0800, Liu Ying wrote: > On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote: > > Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying: > > > This patch adds device tree bindings for Synopsys DesignWare MIPI DSI > > > host controller DRM bridge driver. > > > > > > Signed-off-by: Liu Ying > > > --- > > > v7->v8: > > > * None. > > > > > > v6->v7: > > > * None. > > > > > > v5->v6: > > > * Add the #address-cells and #size-cells properties in the example > > > 'ports' > > >node. > > > * Remove the useless input-port properties from the example port@0 and > > > port@1 > > >nodes. > > > > > > v4->v5: > > > * None. > > > > > > v3->v4: > > > * Newly introduced in v4. This is separated from the relevant driver > > > patch > > >in v3 to address Stefan Wahren's comment. > > > > > > .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 > > > ++ > > > 1 file changed, 73 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > > b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > > new file mode 100644 > > > index 000..f88a8d6 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt > > > @@ -0,0 +1,73 @@ > > > +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller > > > + > > > +The controller is a digital core that implements all protocol functions > > > +defined in the MIPI DSI specification, providing an interface between > > > +the system and the MIPI DPHY, and allowing communication with a MIPI DSI > > > +compliant display. > > > + > > > +Required properties: > > > + - #address-cells: Should be <1>. > > > + - #size-cells: Should be <0>. > > > + - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for > > > + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific > > > + device tree binding documentations. > > > > I think the compatible property should additionally contain > > "snps,dw-mipi-dsi". Also I think other SoCs using the same IP core > > should eventually list their compatibles here, but that's for later. > > > > How about: > > + - compatible: The compatible string contain "fsl,imx6q-mipi-dsi" for > > + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific > > + device tree binding documentations. A common compatible string > > + "snps,dw-mipi-dsi" should be appended for all SoCs. > > I'm not sure if "snps,dw-mipi-dsi" should be appended. > > Is it a compatible string that SoC specific drivers should actually use to > bind a device? > > As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C > bus, while i.MX6Q/DL is configured via ARM bus... > > Another concern is that if users only specify "snps,dw-mipi-dsi" in their > device tree sources and use a kernel which supports multiple platforms, > say ARM multi v7 platforms, could several enabled SoC specific drivers be > probed for a single DW MIPI DSI device? > > [1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html > > > > > > + - reg: Represent the physical address range of the controller. > > > + - interrupts: Represent the controller's interrupt to the CPU(s). > > > + - clocks, clock-names: Phandles to the controller pll reference and > > > + core configuration clocks, as described in [1]. > > > > From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and > > a cfg_clk input. So I suspect from the name of the "core_cfg" clock, > > that it actually represents two clock inputs, the "cfg_clk" wired to the > > D-PHY and a core clock wired to the MIPI DSI host controller. I am not > > sure if there are designs that control those clocks separately, but I > > think it'd be safer to split this into two clocks in the device tree. > Our internal MIPI DSI SoC owner gave me some feedbacks on the clock sources. According to him, the Synopsys DesignWare MIPI DSI host controller needs four clock sources from an application platform - pclk, refclk, cfg_clk and dpipclk. These clocks are mentioned in the "DesignWare Cores MIPI DSI Host Controller Databook, 1.01a1.30a.pdf" documentation. Quote some words from the documentation: pclk- APB clock signal. refclk - D-PHY reference clock used for Master-side serial clock generation in clock multiplying unit(PLL). cfg_clk - D-PHY Configuration clock used for the initialization of the PHY. It is also used for exiting ULPS state. dpipclk - Input Pixel clock signal. The below table reflects how does i.MX6Q/DL provide the pclk, refclk and cfg_clk for the DesignWare MIPI DSI host controller, according to the SoC owner. | Synopsys | i.MX6Q/DL MIPI DSI
Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On Wed, 11 Feb 2015, Ard Biesheuvel wrote: > > Given that Dom0 is not booted via EFI but as zImage, how are we going to > > pass the two EFI table pointers to Linux? Via Device Tree? It doesn't > > look like a great improvement to me. > > > > The EFI system table and memory map pointers shall be passed to the > kernel in the exact same way as the stub does: via the /chosen node. > This is currently documented in Documentation/arm/uefi.txt but it > should be promoted to a proper binding. Ah, right. > > Generating those two EFI tables shouldn't be a problem though. > > > > > > Good. > > >> As this basically promotes the stub<->kernel interface to an external > >> ABI, the current documentation about the /chosen node properties > >> should also be promoted to a proper binding, with the above mandated > >> minimal subset added as well. > >> > >> There are some minimal changes required to the current kernel code to > >> adhere to the above: primarlly to deal with a NULL runtime services > >> pointer, which is arguably an improvement anyway. > > > > This is not needed, if not for the first generation of patches > > > > > > It is needed: the UEFI code needs to understand that the runtime > pointer in the EFI system table may be NULL, in which case no virtual > remapping or installation of the runtime services should take place. > Whether Xen ends up installing its own runtime services is a separate > matter. > > >> Topic #2: how to identify an 'empty' DTB > >> > >> The proposed policy regarding whether DT or ACPI should be preferred > >> if both methods are available hinges on being able to identify a DTB > >> as containing a platform description or not. One suggested way of > >> doing this is to make the stub add a /chosen node property that > >> indicates that it didn't receive a DTB from the firmware, nor loaded > >> one from the file system, but created an empty one from scratch. > >> > >> Considering the previous topic, i.e., the promotion of the > >> stub<->kernel interface to external ABI, we should not be frivolous > >> about adding new properties, and adding a 'stub-generated-dtb' > >> property should be avoided if there is a better way to deal with this. > >> Also, e.g., when booting via GRUB, it may in fact be GRUB and not the > >> stub that creates the DTB (when booting with an initrd, for instance) > >> so GRUB would have to be modified as well. (If not, simply adding a > >> initrd= property to the command line would result in the kernel > >> preferring DT over ACPI all of a sudden, which surely, we all agree is > >> undesirable behavior) > >> > >> So instead, we propose to use a heuristic to decide whether a DTB > >> should be considered empty or not: > >> If /chosen is the only level 1 node in the tree, the DTB is empty, > >> otherwise it is not. > >> > >> This can be trivially implemented into the existing EFI early FDT > >> discovery code, and does not require any other changes to the stub or > >> GRUB. > >> > >> Please, could those affected by this comment whether this is feasible > >> or not? Other comments/remarks also highly appreciated, of course, > > > > Wouldn't it make sense to use the same interface between Xen and Dom0 > > and between stub and kernel? > > That is exactly the point: the stub communicates the EFI entry points > (system table and memmap) via the device tree. If you are not booting > via UEFI, there is no way you can execute the stub, so Xen needs to > add those properties to the /chosen node directly, and make them point > to data that the UEFI layer can understand. OK, it looks like the right way of doing it to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Mailbox changes for 3.20
Hi Linus, The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: http://git.linaro.org/landing-teams/working/fujitsu/integration.git mailbox-devel for you to fetch changes up to f62092f6d77dfd9214ae753a24b76ba4ecd801d7: mailbox: Add Altera mailbox driver (2015-02-06 10:58:27 +0530) Jassi Brar (1): mailbox: check for bit set before polling Ley Foon Tan (1): mailbox: Add Altera mailbox driver Wei Yongjun (1): Mailbox: Fix return value check in pcc_init() .../devicetree/bindings/mailbox/altera-mailbox.txt | 49 +++ MAINTAINERS| 6 + drivers/mailbox/Kconfig| 6 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox-altera.c | 388 + drivers/mailbox/mailbox.c | 2 +- drivers/mailbox/pcc.c | 4 +- 7 files changed, 454 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/altera-mailbox.txt create mode 100644 drivers/mailbox/mailbox-altera.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/
[PATCH RFC] blackfin: make timeout HZ independent
The timeout is in jiffies so the hard-coded numeric value becomes HZ
dependent, which is probably not the intent. To resolve this the
timeout is converted with msecs_to_jiffies.
Signed-off-by: Nicholas Mc Guire
---
Due to tool-chain problems this patch was not even compile tested, further
it is unclear if the interpretation of 5000 as 5000 milliseconds is even
correct it is based on looking at other archs (e.g arch/arm64/kernel/smp.c,
arch/arm/kernel/smp.c...) which use msecs_to_jiffies(5000), but other
architectures use completely different timeouts.
Patch is against 3.19.0 (localversion-next is -next-20150210)
arch/blackfin/mach-common/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/blackfin/mach-common/smp.c b/arch/blackfin/mach-common/smp.c
index 8ad3e90..8a05c32 100644
--- a/arch/blackfin/mach-common/smp.c
+++ b/arch/blackfin/mach-common/smp.c
@@ -417,7 +417,7 @@ static DECLARE_COMPLETION(cpu_killed);
int __cpu_die(unsigned int cpu)
{
- return wait_for_completion_timeout(_killed, 5000);
+ return wait_for_completion_timeout(_killed, msecs_to_jiffies(5000));
}
void cpu_die(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On 11 February 2015 at 14:33, Stefano Stabellini
wrote:
> On Wed, 11 Feb 2015, Ard Biesheuvel wrote:
>> On 9 February 2015 at 19:46, Mark Rutland wrote:
>> > On Sat, Feb 07, 2015 at 05:03:44AM +, Ard Biesheuvel wrote:
>> >> On 7 February 2015 at 03:36, Hanjun Guo wrote:
>> >> > On 2015年02月06日 18:34, G Gregory wrote:
>> >> > [...]
>> >> >
>> >> >>
>> >> >>
>> >> >> linux,uefi-stub-kern-ver | string | Copy of linux_banner from
>> >> >> build.
>> >> >>
>> >> >>
>> >> >> +linux,uefi-stub-generated-dtb | bool | Indication for no DTB
>> >> >> provided by
>> >> >> +| | firmware.
>> >> >>
>> >> >> +
>> >> >
>> >> >
>> >> > Apologies for the late bikeshedding, but the discussion on this
>> >> > topic
>> >> > previsously was lively enough that I thought I'd let it die down a
>> >> > bit
>> >> > before seeing if I had anything to add.
>> >> >
>> >> > That, and I just realised something:
>> >> > One alternative to this added DT entry is that we could treat the
>> >> > absence of a registered UEFI configuration table as the indication
>> >> > that no HW description was provided from firmware, since the stub
>> >> > does
>> >> > not call InstallConfigurationTable() on the DT it generates. This
>> >> > does
>> >> > move the ability to detect to after efi_init(), but this should be
>> >> > fine for ACPI-purposes.
>> >> >
>> >> That would not work as expected in the kexec/Xen use case though as
>> >> they
>> >> may genuinely boot with DT from an ACPI host without UEFI.
>> >> >>>
>> >> >>>
>> >> >>> I'm a little concerned by this case. How do we intend to pass stuff
>> >> >>> from
>> >> >>> Xen to the kernel in this case? When we initially discussed the stub
>> >> >>> prior to merging, we weren't quite sure if ACPI without UEFI was
>> >> >>> entirely safe.
>> >> >>>
>> >> >>> The linux,uefi-stub-kern-ver property was originally intended as a
>> >> >>> sanity-check feature to ensure nothing (including Xen) masqueraded as
>> >> >>> the stub, but for some reason the actual sanity check was never
>> >> >>> implemented.
>> >> >>>
>> >> > If that is deemed undesirable, I would still prefer Catalin's
>> >> > suggested name ("linux,bare-dtb"), which describes the state rather
>> >> > than the route we took to get there.
>> >> >
>> >> I agree.
>> >> >>>
>> >> >>>
>> >> >>> I guess this would be ok, though it would be nice to know which agent
>> >> >>> generated the DTB.
>> >> >>>
>> >> >>
>> >> >> The most obvious scheme then is
>> >> >>
>> >> >> linux,bare-dtb = "uefi-stub";
>> >> >>
>> >> >> otherwise we generate a new binding for every component in the boot
>> >> >> path.
>> >> >
>> >> >
>> >> > Leif, Mark, any comments on this?
>> >> >
>> >>
>> >> As far as I remember, we did not finalize the decision to go with a
>> >> stub generated property instead of some other means to infer that the
>> >> device tree is not suitable for booting and ACPI should be preferred.
>> >>
>> >> We will be discussing the 'stub<->kernel interface as a boot protocol'
>> >> topic this week at Connect, so let's discuss it in that context before
>> >> signing off on patches like these.
>> >
>> > As some of us (at least myself) aren't at connect, it would be nice if
>> > those discussions could be at least mirrored on the mailing list. I have
>> > some concerns regarding how this is going to work long-term, and I'd
>> > like to make sure we don't get stuck with something that limits what we
>> > can do long-term.
>> >
>> > Is there a session set aside for this, or is this a hallway track topic?
>> >
>>
>> Hello all,
>>
>> (added team-Xen to cc)
>>
>> We had our meeting yesterday: allow me to summarize what we discussed,
>> and we can proceed with the discussion on-list if desired.
>>
>> Present:
>> Grant Likely
>> Al Stone
>> Hanjun Guo
>> Leif Lindholm
>> Roy Franz
>> Ard Biesheuvel
>>
>> Topic #1: booting the arm64 kernel with ACPI but no UEFI
>>
>> We have identified Xen as the only use case: there is a need to boot
>> dom0 using the host's ACPI tables but without allowing the dom0 kernel
>> to interface directly with the UEFI firmware. There may be other valid
>> use cases, though, so this use case should be addressed generically
>> regardless.
>>
>> First, it was proposed to allow the ACPI root pointer to be added to a
>> /chosen node property, and the kernel would use this property instead
>> of going through the UEFI tables.
>> However, there is a similar case that could be made for SMBIOS: unlike
>> x86, where there is a 'legacy' method to locate either table by
>> scanning some special physical memory regions,
Re: [PATCH v3 1/2] time: Don't bother to run rtc_resume() for the nonstop clocksource
Hi John,
On 11 February 2015 at 08:01, John Stultz wrote:
> On Thu, Jan 29, 2015 at 11:59 PM, Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> If a system does not provide a persistent_clock(), the time
>> will be updated on resume by rtc_resume(). With the addition
>> of the non-stop clocksources for suspend timing, those systems
>> set the time on resume in timekeeping_resume(), but may not
>> provide a valid persistent_clock().
>>
>> This results in the rtc_resume() logic thinking no one has set
>> the time and it then will over-write the suspend time again,
>> which is not necessary and only increases clock error.
>>
>> So, fix this for rtc_resume().
>>
>> Signed-off-by: Xunlei Pang
>> ---
>> v2->v3:
>> Refine according to John's comments using internal variable.
>>
>> drivers/rtc/class.c | 2 +-
>> include/linux/timekeeping.h | 1 +
>> kernel/time/timekeeping.c | 32
>> 3 files changed, 22 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
>> index 472a5ad..6100af5 100644
>> --- a/drivers/rtc/class.c
>> +++ b/drivers/rtc/class.c
>> @@ -102,7 +102,7 @@ static int rtc_resume(struct device *dev)
>> struct timespec64 sleep_time;
>> int err;
>>
>> - if (has_persistent_clock())
>> + if (timekeeping_sleeptime_injected())
>> return 0;
>
> Took a closer look here.. So you're replacing has_persistent_clock()
> in the resume side, but not the suspend... Can we not cleanup
> has_persistent_clock and consolidate to one accessor for both sides of
> the suspend?
The sequential calls when the system is suspended are:
rtc_suspend(), then timekeeping_suspend().
The sequential calls when the system is resumed are:
timekeeping_resume(), then rtc_resume().
Obviously, timekeeping_sleeptime_injected() used by rtc_resume()
can be easily determined at timekeeping_resume().
And for nonstop clocksources, currently we have code below:
timekeeping_resume():
cycle_now = tk->tkr.read(clock);
if ((clock->flags & CLOCK_SOURCE_SUSPEND_NONSTOP) &&
cycle_now > tk->tkr.cycle_last) {
Here comes the confusing thing: "cycle_now > tk->tkr.cycle_last".
I can't quite catch what's the purpose by judging cycle_now and cycle_last here,
May Nonstop clocksource get wrapped or still can get disfunctional during
system suspend? If so, I think it would be hard to judge exactly whether
rtc_suspend() is needed for nonstop clocksource cases.
If we can get rid of this judgement, I think it would be easy to
consolidate this just
using read_persistent_clock() and CLOCK_SOURCE_SUSPEND_NONSTOP flag.
Any suggestion for this?
Thanks,
Xunlei
>
>>
>> rtc_hctosys_ret = -ENODEV;
>> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
>> index 9b63d13..17a460d 100644
>> --- a/include/linux/timekeeping.h
>> +++ b/include/linux/timekeeping.h
>> @@ -225,6 +225,7 @@ static inline void timekeeping_clocktai(struct timespec
>> *ts)
>> /*
>> * RTC specific
>> */
>> +extern bool timekeeping_sleeptime_injected(void);
>> extern void timekeeping_inject_sleeptime64(struct timespec64 *delta);
>>
>> /*
>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> index 6a93185..b02133e 100644
>> --- a/kernel/time/timekeeping.c
>> +++ b/kernel/time/timekeeping.c
>> @@ -1125,12 +1125,26 @@ static void __timekeeping_inject_sleeptime(struct
>> timekeeper *tk,
>> tk_debug_account_sleep_time(delta);
>> }
>>
>> +static bool sleeptime_inject;
>> +
>> +#if defined(CONFIG_RTC_CLASS) && \
>> + defined(CONFIG_PM_SLEEP) && \
>> + defined(CONFIG_RTC_HCTOSYS_DEVICE)
>
> This change wasn't explained in the commit message. Its fine as a
> small optimization, but probably should be split into its own patch.
>
> thanks
> -john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next 2/3] r8152: change rx early size when the mtu is changed
The rx early size is calculated with the mtu, so it has to be
re-calculated when the mtu is changed.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b043c7f..c5301ca 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3724,6 +3724,7 @@ out:
static int rtl8152_change_mtu(struct net_device *dev, int new_mtu)
{
struct r8152 *tp = netdev_priv(dev);
+ int ret;
switch (tp->version) {
case RTL_VER_01:
@@ -3736,9 +3737,22 @@ static int rtl8152_change_mtu(struct net_device *dev,
int new_mtu)
if (new_mtu < 68 || new_mtu > RTL8153_MAX_MTU)
return -EINVAL;
+ ret = usb_autopm_get_interface(tp->intf);
+ if (ret < 0)
+ return ret;
+
+ mutex_lock(>control);
+
dev->mtu = new_mtu;
- return 0;
+ if (netif_running(dev) && netif_carrier_ok(dev))
+ r8153_set_rx_early_size(tp);
+
+ mutex_unlock(>control);
+
+ usb_autopm_put_interface(tp->intf);
+
+ return ret;
}
static const struct net_device_ops rtl8152_netdev_ops = {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/3] r8152: separate USB_RX_EARLY_AGG
Separate USB_RX_EARLY_AGG into USB_RX_EARLY_TIMEOUT and USB_RX_EARLY_SIZE.
Replace r8153_set_rx_agg() with r8153_set_rx_early_timeout() and
r8153_set_rx_early_size().
Set the default timeout value according to the USB speed.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 55 ++---
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5980ac6..b043c7f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -97,7 +97,8 @@
#define USB_TX_AGG 0xd40a
#define USB_RX_BUF_TH 0xd40c
#define USB_USB_TIMER 0xd428
-#define USB_RX_EARLY_AGG 0xd42c
+#define USB_RX_EARLY_TIMEOUT 0xd42c
+#define USB_RX_EARLY_SIZE 0xd42e
#define USB_PM_CTRL_STATUS 0xd432
#define USB_TX_DMA 0xd434
#define USB_TOLERANCE 0xd490
@@ -325,10 +326,10 @@
/* USB_MISC_0 */
#define PCUT_STATUS0x0001
-/* USB_RX_EARLY_AGG */
-#define EARLY_AGG_SUPPER 0x0e832981
-#define EARLY_AGG_HIGH 0x0e837a12
-#define EARLY_AGG_SLOW 0x0e83
+/* USB_RX_EARLY_TIMEOUT */
+#define COALESCE_SUPER 85000U
+#define COALESCE_HIGH 25U
+#define COALESCE_SLOW 524280U
/* USB_WDT11_CTRL */
#define TIMER11_EN 0x0001
@@ -578,6 +579,7 @@ struct r8152 {
u32 saved_wolopts;
u32 msg_enable;
u32 tx_qlen;
+ u32 coalesce;
u16 ocp_base;
u8 *intr_buff;
u8 version;
@@ -2114,28 +2116,21 @@ static int rtl8152_enable(struct r8152 *tp)
return rtl_enable(tp);
}
-static void r8153_set_rx_agg(struct r8152 *tp)
+static void r8153_set_rx_early_timeout(struct r8152 *tp)
{
- u8 speed;
+ u32 ocp_data;
- speed = rtl8152_get_speed(tp);
- if (speed & _1000bps) {
- if (tp->udev->speed == USB_SPEED_SUPER) {
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH,
- RX_THR_SUPPER);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_EARLY_AGG,
- EARLY_AGG_SUPPER);
- } else {
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH,
- RX_THR_HIGH);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_EARLY_AGG,
- EARLY_AGG_HIGH);
- }
- } else {
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH, RX_THR_SLOW);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_EARLY_AGG,
- EARLY_AGG_SLOW);
- }
+ ocp_data = tp->coalesce / 8;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_TIMEOUT, ocp_data);
+}
+
+static void r8153_set_rx_early_size(struct r8152 *tp)
+{
+ struct net_device *dev = tp->netdev;
+ u32 ocp_data;
+
+ ocp_data = (agg_buf_sz - dev->mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
}
static int rtl8153_enable(struct r8152 *tp)
@@ -2145,7 +2140,8 @@ static int rtl8153_enable(struct r8152 *tp)
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
- r8153_set_rx_agg(tp);
+ r8153_set_rx_early_timeout(tp);
+ r8153_set_rx_early_size(tp);
return rtl_enable(tp);
}
@@ -3911,6 +3907,13 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->mii.reg_num_mask = 0x1f;
tp->mii.phy_id = R8152_PHY_ID;
+ if (udev->speed == USB_SPEED_SUPER)
+ tp->coalesce = COALESCE_SUPER;
+ else if (udev->speed == USB_SPEED_HIGH)
+ tp->coalesce = COALESCE_HIGH;
+ else
+ tp->coalesce = COALESCE_SLOW;
+
intf->needs_remote_wakeup = 1;
tp->rtl_ops.init(tp);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/3] r8152: support setting rx coalesce
Support setting the rx coalesce. Then someone could change the rx
agg timeout value through ethtool.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c5301ca..e4e7238 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3660,6 +3660,61 @@ out:
return ret;
}
+static int rtl8152_get_coalesce(struct net_device *netdev,
+ struct ethtool_coalesce *coalesce)
+{
+ struct r8152 *tp = netdev_priv(netdev);
+
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ return -EOPNOTSUPP;
+ default:
+ break;
+ }
+
+ coalesce->rx_coalesce_usecs = tp->coalesce;
+
+ return 0;
+}
+
+static int rtl8152_set_coalesce(struct net_device *netdev,
+ struct ethtool_coalesce *coalesce)
+{
+ struct r8152 *tp = netdev_priv(netdev);
+ int ret;
+
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ return -EOPNOTSUPP;
+ default:
+ break;
+ }
+
+ if (coalesce->rx_coalesce_usecs > COALESCE_SLOW)
+ return -EINVAL;
+
+ ret = usb_autopm_get_interface(tp->intf);
+ if (ret < 0)
+ return ret;
+
+ mutex_lock(>control);
+
+ if (tp->coalesce != coalesce->rx_coalesce_usecs) {
+ tp->coalesce = coalesce->rx_coalesce_usecs;
+
+ if (netif_running(tp->netdev) && netif_carrier_ok(netdev))
+ r8153_set_rx_early_timeout(tp);
+ }
+
+ mutex_unlock(>control);
+
+ usb_autopm_put_interface(tp->intf);
+
+ return ret;
+}
+
static struct ethtool_ops ops = {
.get_drvinfo = rtl8152_get_drvinfo,
.get_settings = rtl8152_get_settings,
@@ -3673,6 +3728,8 @@ static struct ethtool_ops ops = {
.get_strings = rtl8152_get_strings,
.get_sset_count = rtl8152_get_sset_count,
.get_ethtool_stats = rtl8152_get_ethtool_stats,
+ .get_coalesce = rtl8152_get_coalesce,
+ .set_coalesce = rtl8152_set_coalesce,
.get_eee = rtl_ethtool_get_eee,
.set_eee = rtl_ethtool_set_eee,
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/3] Adjust the settings about USB_RX_EARLY_AGG
The USB_RX_EARLY_AGG contains timeout and size. Separate them, and they could be set independently. Then, the ethtool could be used to change the timeout according to situation of the platform. Hayes Wang (3): r8152: separate USB_RX_EARLY_AGG r8152: change rx early size when the mtu is changed r8152: support setting rx coalesce drivers/net/usb/r8152.c | 128 ++-- 1 file changed, 101 insertions(+), 27 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] toshiba_acpi: Clean file plus some function renames
These patches are simply "cleaning" the file, making it more readable
and in the process, make it comply according to coding style.
--->8---
Darren,
I'm sending these patches now and let you decide if you want them for
3.20 as the merge window is still open or queue them up for 3.21 :-)
---8<---
Azael Avalos (5):
toshiba_acpi: Clean file according to coding style
Documentation/ABI: Add file describing the sysfs entries for
toshiba_acpi
toshiba_acpi: Move sysfs function and struct declarations further down
toshiba_acpi: Drop the toshiba_ prefix from sysfs function names
toshiba_acpi: Make use of DEVICE_ATTR_{RO, RW} macros
.../ABI/testing/sysfs-driver-toshiba_acpi | 114 +++
drivers/platform/x86/toshiba_acpi.c| 344 -
2 files changed, 237 insertions(+), 221 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-driver-toshiba_acpi
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Documentation/ABI: Add file describing the sysfs entries for toshiba_acpi
This patch adds a new file describing the sysfs entries for the
toshiba_acpi driver.
Signed-off-by: Azael Avalos
---
.../ABI/testing/sysfs-driver-toshiba_acpi | 114 +
1 file changed, 114 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-toshiba_acpi
diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
new file mode 100644
index 000..ca9c71a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
@@ -0,0 +1,114 @@
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_mode
+Date: June 8, 2014
+KernelVersion: 3.15
+Contact: Azael Avalos
+Description: This file controls the keyboard backlight operation mode, valid
+ values are:
+ * 0x1 -> FN-Z
+ * 0x2 -> AUTO (also called TIMER)
+ * 0x8 -> ON
+ * 0x10 -> OFF
+ Note that the kernel 3.16 onwards this file accepts all listed
+ parameters, kernel 3.15 only accepts the first two (FN-Z and
+ AUTO).
+Users: KToshiba
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
+Date: June 8, 2014
+KernelVersion: 3.15
+Contact: Azael Avalos
+Description: This file controls the timeout of the keyboard backlight
+ whenever the operation mode is set to AUTO (or TIMER),
+ valid values range from 0-60.
+ Note that the kernel 3.15 only had support for the first
+ keyboard type, the kernel 3.16 added support for the second
+ type and the range accepted for type 2 is 1-60.
+ See the entry named "kbd_type"
+Users: KToshiba
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/position
+Date: June 8, 2014
+KernelVersion: 3.15
+Contact: Azael Avalos
+Description: This file shows the absolute position of the built-in
+ accelereometer.
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/touchpad
+Date: June 8, 2014
+KernelVersion: 3.15
+Contact: Azael Avalos
+Description: This files controls the status of the touchpad and pointing
+ stick (if available), valid values are:
+ * 0 -> OFF
+ * 1 -> ON
+Users: KToshiba
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/available_kbd_modes
+Date: August 3, 2014
+KernelVersion: 3.16
+Contact: Azael Avalos
+Description: This file shows the supported keyboard backlight modes
+ the system supports, which can be:
+ * 0x1 -> FN-Z
+ * 0x2 -> AUTO (also called TIMER)
+ * 0x8 -> ON
+ * 0x10 -> OFF
+ Note that not all keyboard types support the listed modes.
+ See the entry named "available_kbd_modes"
+Users: KToshiba
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_type
+Date: August 3, 2014
+KernelVersion: 3.16
+Contact: Azael Avalos
+Description: This file shows the current keyboard backlight type,
+ which can be:
+ * 1 -> Type 1, supporting modes FN-Z and AUTO
+ * 2 -> Type 2, supporting modes TIMER, ON and OFF
+Users: KToshiba
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
+Date: February, 2015
+KernelVersion: 3.20
+Contact: Azael Avalos
+Description: This file shows the current version of the driver
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
+Date: February, 2015
+KernelVersion: 3.20
+Contact: Azael Avalos
+Description: This file controls the state of the internal fan, valid
+ values are:
+ * 0 -> OFF
+ * 1 -> ON
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
+Date: February, 2015
+KernelVersion: 3.20
+Contact: Azael Avalos
+Description: This file controls the Special Functions (hotkeys) operation
+ mode, valid values are:
+ * 0 -> Normal Operation
+ * 1 -> Special Functions
+ In the "Normal Operation" mode, the F{1-12} keys are as usual
+ and the hotkeys are accessed via FN-F{1-12}.
+ In the "Special Functions" mode, the F{1-12} keys trigger the
+ hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
+
+What:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
+Date: February,
linux-next: Tree for Feb 11
Hi all, Please do not add any material destined for v3.21 to your linux-next included trees until after v3.20-rc1 has been released. Changes since 20150210: The pm tree gained a conflict against the pci tree. Non-merge commits (relative to Linus' tree): 8078 7762 files changed, 339153 insertions(+), 182988 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" and checkout or reset to the new master. 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 206 trees (counting Linus' and 30 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. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3e8c04eb1174 Merge branch 'for-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the debian/ directory) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (8e6480667246 ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (531c94a9681b tcp: don't include Fast Open option in SYN-ACK on pure SYN-data) Merging ipsec/master (044a832a7779 xfrm: Fix local error reporting crash with interfamily tunnels) Merging sound-current/for-linus (d2255c016365 Merge tag 'asoc-fix-ac97-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (06cf35f903aa PCI: Handle read-only BARs on AMD CS553x devices) Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement that is no longer needed) Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6) Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5) Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7) Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in non-OF case) Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for RUGGEDCOM USB Serial Console) Merging staging.current/staging-linus (e36f014edff7 Linux 3.19-rc7) Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7) Merging input-current/for-linus (4ba24fef3eb3 Merge branch 'next' into for-linus) Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module aliases) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (d5db139ab376 module: make module_refcount() a signed integer.) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for transhuge-stress test) Merging drm-intel-fixes/for-linux-next-fixes (bfa76d495765 Linux 3.19) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/
[PATCH 5/5] toshiba_acpi: Make use of DEVICE_ATTR_{RO, RW} macros
This patch makes use of the DEVICE_ATTR_{RO, RW} macros to simplify
sysfs attributes declarations.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 42 +
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 0b5614c..eea3447 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1664,6 +1664,7 @@ static ssize_t version_show(struct device *dev,
{
return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
}
+static DEVICE_ATTR_RO(version);
static ssize_t fan_store(struct device *dev,
struct device_attribute *attr,
@@ -1703,6 +1704,7 @@ static ssize_t fan_show(struct device *dev,
return sprintf(buf, "%d\n", value);
}
+static DEVICE_ATTR_RW(fan);
static ssize_t kbd_backlight_mode_store(struct device *dev,
struct device_attribute *attr,
@@ -1773,6 +1775,7 @@ static ssize_t kbd_backlight_mode_show(struct device *dev,
return sprintf(buf, "%i\n", time & SCI_KBD_MODE_MASK);
}
+static DEVICE_ATTR_RW(kbd_backlight_mode);
static ssize_t kbd_type_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -1781,6 +1784,7 @@ static ssize_t kbd_type_show(struct device *dev,
return sprintf(buf, "%d\n", toshiba->kbd_type);
}
+static DEVICE_ATTR_RO(kbd_type);
static ssize_t available_kbd_modes_show(struct device *dev,
struct device_attribute *attr,
@@ -1795,6 +1799,7 @@ static ssize_t available_kbd_modes_show(struct device
*dev,
return sprintf(buf, "%x %x %x\n",
SCI_KBD_MODE_AUTO, SCI_KBD_MODE_ON, SCI_KBD_MODE_OFF);
}
+static DEVICE_ATTR_RO(available_kbd_modes);
static ssize_t kbd_backlight_timeout_store(struct device *dev,
struct device_attribute *attr,
@@ -1851,6 +1856,7 @@ static ssize_t kbd_backlight_timeout_show(struct device
*dev,
return sprintf(buf, "%i\n", time >> HCI_MISC_SHIFT);
}
+static DEVICE_ATTR_RW(kbd_backlight_timeout);
static ssize_t touchpad_store(struct device *dev,
struct device_attribute *attr,
@@ -1887,6 +1893,7 @@ static ssize_t touchpad_show(struct device *dev,
return sprintf(buf, "%i\n", state);
}
+static DEVICE_ATTR_RW(touchpad);
static ssize_t position_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -1908,6 +1915,7 @@ static ssize_t position_show(struct device *dev,
return sprintf(buf, "%d %d %d\n", x, y, z);
}
+static DEVICE_ATTR_RO(position);
static ssize_t usb_sleep_charge_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -1957,6 +1965,7 @@ static ssize_t usb_sleep_charge_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(usb_sleep_charge);
static ssize_t sleep_functions_on_battery_show(struct device *dev,
struct device_attribute *attr,
@@ -2018,6 +2027,7 @@ static ssize_t sleep_functions_on_battery_store(struct
device *dev,
return count;
}
+static DEVICE_ATTR_RW(sleep_functions_on_battery);
static ssize_t usb_rapid_charge_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -2053,6 +2063,7 @@ static ssize_t usb_rapid_charge_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(usb_rapid_charge);
static ssize_t usb_sleep_music_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -2088,6 +2099,7 @@ static ssize_t usb_sleep_music_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(usb_sleep_music);
static ssize_t kbd_function_keys_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -2129,6 +2141,7 @@ static ssize_t kbd_function_keys_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(kbd_function_keys);
static ssize_t panel_power_on_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -2166,6 +2179,7 @@ static ssize_t panel_power_on_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(panel_power_on);
static ssize_t usb_three_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -2207,33 +2221,7 @@ static ssize_t usb_three_store(struct device *dev,
return count;
}
-
-static DEVICE_ATTR(version, S_IRUGO, version_show, NULL);
-static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR, fan_show, fan_store);
-static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
- kbd_backlight_mode_show,
[PATCH 3/5] toshiba_acpi: Move sysfs function and struct declarations further down
Commit 93f8c16d635e ("toshiba_acpi: Support new keyboard backlight
type") moved all the sysfs structs and function declarations further
up in order to make use of sysfs_update_group, however,
commit 805469053ba9 ("toshiba_acpi: Add keyboard backlight mode
change event") made use of that function unnecesary.
This patch moves all the sysfs structs and function declarations
further down, making the file shorther in lines and better readable.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 196 +++-
1 file changed, 58 insertions(+), 138 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 016d7ab..818d184 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1660,144 +1660,6 @@ static const struct backlight_ops
toshiba_backlight_data = {
* Sysfs files
*/
static ssize_t toshiba_version_show(struct device *dev,
- struct device_attribute *attr, char *buf);
-static ssize_t toshiba_fan_store(struct device *dev,
-struct device_attribute *attr,
-const char *buf, size_t count);
-static ssize_t toshiba_fan_show(struct device *dev,
- struct device_attribute *attr, char *buf);
-static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
-struct device_attribute *attr,
-const char *buf, size_t count);
-static ssize_t toshiba_kbd_bl_mode_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t toshiba_kbd_type_show(struct device *dev,
-struct device_attribute *attr,
-char *buf);
-static ssize_t toshiba_available_kbd_modes_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t toshiba_kbd_bl_timeout_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static ssize_t toshiba_kbd_bl_timeout_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t toshiba_touchpad_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static ssize_t toshiba_touchpad_show(struct device *dev,
-struct device_attribute *attr,
-char *buf);
-static ssize_t toshiba_position_show(struct device *dev,
-struct device_attribute *attr,
-char *buf);
-static ssize_t toshiba_usb_sleep_charge_show(struct device *dev,
-struct device_attribute *attr,
-char *buf);
-static ssize_t toshiba_usb_sleep_charge_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static ssize_t sleep_functions_on_battery_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t sleep_functions_on_battery_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static ssize_t toshiba_usb_rapid_charge_show(struct device *dev,
-struct device_attribute *attr,
-char *buf);
-static ssize_t toshiba_usb_rapid_charge_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static ssize_t toshiba_usb_sleep_music_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t toshiba_usb_sleep_music_store(struct device *dev,
-struct device_attribute *attr,
-const char *buf, size_t count);
-static ssize_t toshiba_kbd_function_keys_show(struct device *dev,
- struct device_attribute *attr,
- char *buf);
-static ssize_t
[PATCH 1/5] toshiba_acpi: Clean file according to coding style
This patch simply cleans the the driver out of 2 errors and 17
warnings according to "checkpatch -f", no functionality was changed,
simply a cleanup.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 38 ++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 52e4647..016d7ab 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -57,7 +57,7 @@
#include
#include
#include
-#include
+#include
MODULE_AUTHOR("John Belmonte");
MODULE_DESCRIPTION("Toshiba Laptop ACPI Extras Driver");
@@ -288,7 +288,7 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
/* utility
*/
-static __inline__ void _set_bit(u32 * word, u32 mask, int value)
+static inline void _set_bit(u32 *word, u32 mask, int value)
{
*word = (*word & ~mask) | (mask * value);
}
@@ -331,9 +331,8 @@ static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
(char *)dev->method_hci, ,
);
if ((status == AE_OK) && (out_objs->package.count <= TCI_WORDS)) {
- for (i = 0; i < out_objs->package.count; ++i) {
+ for (i = 0; i < out_objs->package.count; ++i)
out[i] = out_objs->package.elements[i].integer.value;
- }
}
return status;
@@ -359,6 +358,7 @@ static u32 hci_read1(struct toshiba_acpi_dev *dev, u32 reg,
u32 *out1)
u32 in[TCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+
if (ACPI_FAILURE(status))
return TOS_FAILURE;
@@ -376,11 +376,13 @@ static u32 hci_write2(struct toshiba_acpi_dev *dev, u32
reg, u32 in1, u32 in2)
return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
}
-static u32 hci_read2(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1, u32
*out2)
+static u32 hci_read2(struct toshiba_acpi_dev *dev,
+u32 reg, u32 *out1, u32 *out2)
{
u32 in[TCI_WORDS] = { HCI_GET, reg, *out1, *out2, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+
if (ACPI_FAILURE(status))
return TOS_FAILURE;
@@ -455,6 +457,7 @@ static u32 sci_read(struct toshiba_acpi_dev *dev, u32 reg,
u32 *out1)
u32 in[TCI_WORDS] = { SCI_GET, reg, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+
if (ACPI_FAILURE(status))
return TOS_FAILURE;
@@ -713,7 +716,8 @@ static int toshiba_eco_mode_available(struct
toshiba_acpi_dev *dev)
return 1;
}
-static enum led_brightness toshiba_eco_mode_get_status(struct led_classdev
*cdev)
+static enum led_brightness
+toshiba_eco_mode_get_status(struct led_classdev *cdev)
{
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, eco_led);
@@ -1235,7 +1239,7 @@ static int set_tr_backlight_status(struct
toshiba_acpi_dev *dev, bool enable)
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
-static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
+static struct proc_dir_entry *toshiba_proc_dir /*= 0*/;
static int __get_lcd_brightness(struct toshiba_acpi_dev *dev)
{
@@ -1246,6 +1250,7 @@ static int __get_lcd_brightness(struct toshiba_acpi_dev
*dev)
if (dev->tr_backlight_supported) {
bool enabled;
int ret = get_tr_backlight_status(dev, );
+
if (ret)
return ret;
if (enabled)
@@ -1263,6 +1268,7 @@ static int __get_lcd_brightness(struct toshiba_acpi_dev
*dev)
static int get_lcd_brightness(struct backlight_device *bd)
{
struct toshiba_acpi_dev *dev = bl_get_data(bd);
+
return __get_lcd_brightness(dev);
}
@@ -1299,6 +1305,7 @@ static int set_lcd_brightness(struct toshiba_acpi_dev
*dev, int value)
if (dev->tr_backlight_supported) {
bool enable = !value;
int ret = set_tr_backlight_status(dev, enable);
+
if (ret)
return ret;
if (value)
@@ -1313,6 +1320,7 @@ static int set_lcd_brightness(struct toshiba_acpi_dev
*dev, int value)
static int set_lcd_status(struct backlight_device *bd)
{
struct toshiba_acpi_dev *dev = bl_get_data(bd);
+
return set_lcd_brightness(dev, bd->props.brightness);
}
@@ -1370,6 +1378,7 @@ static int video_proc_show(struct seq_file *m, void *v)
int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0;
int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0;
int is_tv = (value & HCI_VIDEO_OUT_TV) ? 1 : 0;
+
seq_printf(m, "lcd_out: %d\n", is_lcd);
seq_printf(m, "crt_out: %d\n", is_crt);
[PATCH 4/5] toshiba_acpi: Drop the toshiba_ prefix from sysfs function names
This patch removes the toshiba_ prefix from all the sysfs function
names and adapted the code according to coding style.
Also a few functions were renamed to match the sysfs entry, as this
patch is a preparation for the next patch to switch to
DEVICE_ATTR_{RO, RW, WO} macros.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 166 +---
1 file changed, 76 insertions(+), 90 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 818d184..0b5614c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1659,15 +1659,15 @@ static const struct backlight_ops
toshiba_backlight_data = {
/*
* Sysfs files
*/
-static ssize_t toshiba_version_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
}
-static ssize_t toshiba_fan_store(struct device *dev,
-struct device_attribute *attr,
-const char *buf, size_t count)
+static ssize_t fan_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
u32 result;
@@ -1690,8 +1690,8 @@ static ssize_t toshiba_fan_store(struct device *dev,
return count;
}
-static ssize_t toshiba_fan_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t fan_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
u32 value;
@@ -1704,9 +1704,9 @@ static ssize_t toshiba_fan_show(struct device *dev,
return sprintf(buf, "%d\n", value);
}
-static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
-struct device_attribute *attr,
-const char *buf, size_t count)
+static ssize_t kbd_backlight_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
int mode;
@@ -1761,9 +1761,9 @@ static ssize_t toshiba_kbd_bl_mode_store(struct device
*dev,
return count;
}
-static ssize_t toshiba_kbd_bl_mode_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t kbd_backlight_mode_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
u32 time;
@@ -1774,18 +1774,17 @@ static ssize_t toshiba_kbd_bl_mode_show(struct device
*dev,
return sprintf(buf, "%i\n", time & SCI_KBD_MODE_MASK);
}
-static ssize_t toshiba_kbd_type_show(struct device *dev,
-struct device_attribute *attr,
-char *buf)
+static ssize_t kbd_type_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
return sprintf(buf, "%d\n", toshiba->kbd_type);
}
-static ssize_t toshiba_available_kbd_modes_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t available_kbd_modes_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
@@ -1797,9 +1796,9 @@ static ssize_t toshiba_available_kbd_modes_show(struct
device *dev,
SCI_KBD_MODE_AUTO, SCI_KBD_MODE_ON, SCI_KBD_MODE_OFF);
}
-static ssize_t toshiba_kbd_bl_timeout_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t kbd_backlight_timeout_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
int time;
@@ -1840,9 +1839,9 @@ static ssize_t toshiba_kbd_bl_timeout_store(struct device
*dev,
return count;
}
-static ssize_t
Re: [PATCH] module: Annotate nested sleep in resolve_symbol()
Dave Jones writes: > On Tue, Feb 10, 2015 at 06:12:55PM +0100, Peter Zijlstra wrote: > > On which, we should probably do this. > > > > --- > > Subject: module: Replace over-engineered nested sleep > > > > Since the introduction of the nested sleep warning; we've established > > that the occasional sleep inside a wait_event() is fine. > > > > wait_event() loops are invariant wrt. spurious wakeups, and the > > occasional sleep has a similar effect on them. As long as its occasional > > its harmless. > > > > Therefore replace the 'correct' but verbose wait_woken() thing with > > a simple annotation to shut up the warning. > > > > Cc: Rusty Russell > > Signed-off-by: Peter Zijlstra (Intel) > > Seems to suppress the warning, and modules still work. > > Tested-by: Dave Jones OK, applied. Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fsnotify: Fix handling of renames in audit
On Tue 10-02-15 19:58:35, Paul Moore wrote: > On Tuesday, February 10, 2015 04:00:12 PM Jan Kara wrote: > > Commit e9fd702a58c4 (audit: convert audit watches to use fsnotify > > instead of inotify) broke handling of renames in audit. Audit code wants > > to update inode number of an inode corresponding to watched name in a > > directory. When something gets renamed into a directory to a watched > > name, inotify previously passed moved inode to audit code however new > > fsnotify code passes directory inode where the change happened. That > > confuses audit and it starts watching parent directory instead of a file > > in a directory. > > > > This can be observed for example by doing: > > cd /tmp > > touch foo bar > > auditctl -w /tmp/foo > > touch foo > > mv bar foo > > touch foo > > > > In audit log we see events like: > > type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 > > op="updated rules" path="/tmp/foo" key=(null) list=4 res=1 > > ... > > type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 > > dev=08:0 > > 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE > > type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 > > dev=08:0 > > 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE > > type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 > > dev=08:0 > > 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE > > ... > > and that's it - we see event for the first touch after creating the > > audit rule, we see events for rename but we don't see any event for the > > last touch. However we start seeing events for unrelated stuff happening > > in /tmp. > > > > Fix the problem by passing moved inode as data in the FS_MOVED_FROM and > > FS_MOVED_TO events instead of the directory where the change happens. > > This doesn't introduce any new problems because noone besides > > audit_watch.c cares about the passed value: > > fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events. > > fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all. > > fs/notify/inotify/inotify_fsnotify.c uses 'data' only for > > FSNOTIFY_EVENT_PATH. kernel/audit_tree.c doesn't care about passed 'data' > > at all. > > kernel/audit_watch.c expects moved inode as 'data'. > > > > CC: linux-au...@redhat.com > > CC: Paul Moore > > CC: Eric Paris > > CC: sta...@vger.kernel.org > > Fixes: e9fd702a58c49dbb14481dca88dad44758da393a > > Signed-off-by: Jan Kara > > --- > > include/linux/fsnotify.h | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > I can confirm this is indeed broken. > > Thanks for the patch. I'm building a test kernel as I type this, assuming > all > goes well I'll send this to Linus with the other audit patches for v3.20. Actually, Andrew has picked up the patch and already sent it to Linus. So you don't have to put it in your tree. I sent it to Andrew since he usually takes care of pushing fsnotify fixes to Linus and although this was an audit bug, the problem was really in fsnotify... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] virtio: Introducing virtio_pci.no_mmio, the worst boot option in history.
Sometimes, devices are just too damn fast. Wouldn't it be nice if we
could (1) have an option to access them in the most baroque way
possible, and (2) ensure that even the normal case caused extra bloat?
Well, wish no longer: This patch does exactly that! Since every
complaint virtio 1.0 device has to have a capability to allow backdoor
access into the BARs, we can use that:
4.1.4.7.1 Device Requirements: PCI configuration access capability
The device MUST present at least one VIRTIO_PCI_CAP_PCI_CFG
capability.
Upon detecting driver write access to pci_cfg_data, the device
MUST execute a write access at offset cap.offset at BAR
selected by cap.bar using the first cap.length bytes from
pci_cfg_data.
Upon detecting driver read access to pci_cfg_data, the device
MUST execute a read access of length cap.length at offset
cap.offset at BAR selected by cap.bar and store the first
cap.length bytes in pci_cfg_data.
Signed-off-by: Rusty Russell
---
drivers/virtio/virtio_pci_common.c | 31 ++-
drivers/virtio/virtio_pci_common.h | 21 +
drivers/virtio/virtio_pci_legacy.c | 1 +
drivers/virtio/virtio_pci_modern.c | 183 ++---
4 files changed, 221 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index 4e6132dd0ca3..0030180411cc 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -29,45 +29,68 @@ MODULE_PARM_DESC(force_legacy,
u8 vp_read_isr(const struct virtio_pci_device *dev)
{
+ if (dev->no_mmio)
+ return dev->no_mmio->read8(dev, dev->isr, 0);
return ioread8(dev->isr);
}
void vp_write_notify(const struct virtqueue *vq, u16 vqindex)
{
- iowrite16(vqindex, (void __iomem *)vq->priv);
+ struct virtio_pci_device *vp_dev = to_vp_device(vq->vdev);
+
+ if (vp_dev->no_mmio)
+ vp_dev->no_mmio->write16(vp_dev, (void __iomem *)vq->priv,
+0, vqindex);
+ else
+ iowrite16(vqindex, (void __iomem *)vq->priv);
}
u32 __vp_read_common32(const struct virtio_pci_device *dev, size_t offset)
{
+ if (dev->no_mmio)
+ return dev->no_mmio->read32(dev, dev->common, offset);
return ioread32((void __iomem *)dev->common + offset);
}
u16 __vp_read_common16(const struct virtio_pci_device *dev, size_t offset)
{
+ if (dev->no_mmio)
+ return dev->no_mmio->read16(dev, dev->common, offset);
return ioread16((void __iomem *)dev->common + offset);
}
u8 __vp_read_common8(const struct virtio_pci_device *dev, size_t offset)
{
+ if (dev->no_mmio)
+ return dev->no_mmio->read8(dev, dev->common, offset);
return ioread8((void __iomem *)dev->common + offset);
}
void __vp_write_common32(const struct virtio_pci_device *dev,
size_t offset, u32 val)
{
- iowrite32(val, (void __iomem *)dev->common + offset);
+ if (dev->no_mmio)
+ dev->no_mmio->write32(dev, dev->common, offset, val);
+ else
+ iowrite32(val, (void __iomem *)dev->common + offset);
}
void __vp_write_common16(const struct virtio_pci_device *dev,
size_t offset, u16 val)
{
- iowrite16(val, (void __iomem *)dev->common + offset);
+ if (dev->no_mmio)
+ dev->no_mmio->write16(dev, dev->common, offset, val);
+ else
+ iowrite16(val, (void __iomem *)dev->common + offset);
}
void __vp_write_common8(const struct virtio_pci_device *dev,
size_t offset, u8 val)
{
- iowrite8(val, (void __iomem *)dev->common + offset);
+ if (dev->no_mmio)
+ dev->no_mmio->write8(dev, dev->common, offset, val);
+ else
+ iowrite8(val, (void __iomem *)dev->common + offset);
}
/* wait for pending irq handlers */
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index 15a20c968ae7..d891e3123cdd 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -53,6 +53,9 @@ struct virtio_pci_device {
struct virtio_device vdev;
struct pci_dev *pci_dev;
+ /* This is only valid for modern devices. */
+ const struct virtio_pci_no_mmio_ops *no_mmio;
+
/* In legacy mode, these two point to within ->legacy. */
/* Where to read and clear interrupt */
u8 __iomem *isr;
@@ -75,6 +78,9 @@ struct virtio_pci_device {
/* Multiply queue_notify_off by this value. (non-legacy mode). */
u32 notify_offset_multiplier;
+ /* PCI config window for BAR access (non-legacy mode). */
+ int window;
+
/* Legacy only field */
/* the IO mapping for the PCI config space */
void __iomem *ioaddr;
@@ -113,6 +119,21 @@
[PATCH 1/2] virtio_pci: abstract all MMIO accesses.
This is in preparation for testing the virtio pci config mmio backdoor.
Signed-off-by: Rusty Russell
---
drivers/virtio/virtio_pci_common.c | 47 -
drivers/virtio/virtio_pci_common.h | 41 +++
drivers/virtio/virtio_pci_modern.c | 140 -
3 files changed, 177 insertions(+), 51 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.c
b/drivers/virtio/virtio_pci_common.c
index e894eb278d83..4e6132dd0ca3 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -27,6 +27,49 @@ MODULE_PARM_DESC(force_legacy,
"Force legacy mode for transitional virtio 1 devices");
#endif
+u8 vp_read_isr(const struct virtio_pci_device *dev)
+{
+ return ioread8(dev->isr);
+}
+
+void vp_write_notify(const struct virtqueue *vq, u16 vqindex)
+{
+ iowrite16(vqindex, (void __iomem *)vq->priv);
+}
+
+u32 __vp_read_common32(const struct virtio_pci_device *dev, size_t offset)
+{
+ return ioread32((void __iomem *)dev->common + offset);
+}
+
+u16 __vp_read_common16(const struct virtio_pci_device *dev, size_t offset)
+{
+ return ioread16((void __iomem *)dev->common + offset);
+}
+
+u8 __vp_read_common8(const struct virtio_pci_device *dev, size_t offset)
+{
+ return ioread8((void __iomem *)dev->common + offset);
+}
+
+void __vp_write_common32(const struct virtio_pci_device *dev,
+size_t offset, u32 val)
+{
+ iowrite32(val, (void __iomem *)dev->common + offset);
+}
+
+void __vp_write_common16(const struct virtio_pci_device *dev,
+size_t offset, u16 val)
+{
+ iowrite16(val, (void __iomem *)dev->common + offset);
+}
+
+void __vp_write_common8(const struct virtio_pci_device *dev,
+ size_t offset, u8 val)
+{
+ iowrite8(val, (void __iomem *)dev->common + offset);
+}
+
/* wait for pending irq handlers */
void vp_synchronize_vectors(struct virtio_device *vdev)
{
@@ -45,7 +88,7 @@ bool vp_notify(struct virtqueue *vq)
{
/* we write the queue's selector into the notification register to
* signal the other end */
- iowrite16(vq->index, (void __iomem *)vq->priv);
+ vp_write_notify(vq, vq->index);
return true;
}
@@ -89,7 +132,7 @@ static irqreturn_t vp_interrupt(int irq, void *opaque)
/* reading the ISR has the effect of also clearing it so it's very
* important to save off the value. */
- isr = ioread8(vp_dev->isr);
+ isr = vp_read_isr(vp_dev);
/* It's definitely not us if the ISR was not high */
if (!isr)
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index 28ee4e56badf..15a20c968ae7 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -113,6 +113,47 @@ struct virtio_pci_device {
u16 (*config_vector)(struct virtio_pci_device *vp_dev, u16 vector);
};
+/* Accessor functions. */
+u8 vp_read_isr(const struct virtio_pci_device *dev);
+void vp_write_notify(const struct virtqueue *vq, u16 vqindex);
+u32 __vp_read_common32(const struct virtio_pci_device *dev, size_t offset);
+u16 __vp_read_common16(const struct virtio_pci_device *dev, size_t offset);
+u8 __vp_read_common8(const struct virtio_pci_device *dev, size_t offset);
+void __vp_write_common32(const struct virtio_pci_device *dev,
+size_t offset, u32 val);
+void __vp_write_common16(const struct virtio_pci_device *dev,
+size_t offset, u16 val);
+void __vp_write_common8(const struct virtio_pci_device *dev,
+ size_t offset, u8 val);
+
+#define vp_read_common32(dev, fieldname) \
+ __vp_read_common32((dev), \
+ offsetof(struct virtio_pci_common_cfg, fieldname) + \
+ BUILD_BUG_ON_ZERO(sizeof((dev)->common->fieldname) != 4))
+#define vp_read_common16(dev, fieldname) \
+ __vp_read_common16((dev), \
+ offsetof(struct virtio_pci_common_cfg, fieldname) + \
+ BUILD_BUG_ON_ZERO(sizeof((dev)->common->fieldname) != 2))
+#define vp_read_common8(dev, fieldname)\
+ __vp_read_common8((dev),\
+ offsetof(struct virtio_pci_common_cfg, fieldname) + \
+ BUILD_BUG_ON_ZERO(sizeof((dev)->common->fieldname) != 1))
+#define vp_write_common32(dev, fieldname, val) \
+ __vp_write_common32((dev), \
+ offsetof(struct virtio_pci_common_cfg, fieldname) + \
+ BUILD_BUG_ON_ZERO(sizeof((dev)->common->fieldname) != 4), \
+ (val))
+#define vp_write_common16(dev, fieldname, val) \
+
Re: [PATCH RFC v5 net-next 1/6] virtio_ring: fix virtqueue_enable_cb() when only 1 buffers were pending
"Michael S. Tsirkin" writes: > On Tue, Feb 10, 2015 at 11:33:52AM +1030, Rusty Russell wrote: >> Jason Wang writes: >> > We currently does: >> > >> > bufs = (avail->idx - last_used_idx) * 3 / 4; >> > >> > This is ok now since we only try to enable the delayed callbacks when >> > the queue is about to be full. This may not work well when there is >> > only one pending buffer in the virtqueue (this may be the case after >> > tx interrupt was enabled). Since virtqueue_enable_cb() will return >> > false which may cause unnecessary triggering of napis. This patch >> > correct this by only calculate the four thirds when bufs is not one. >> >> I mildly prefer to avoid the branch, by changing the calculation like >> so: >> >> /* Set bufs >= 1, even if there's only one pending buffer */ >> bufs = (bufs + 1) * 3 / 4; > > Or bus * 3/4 + 1 > >> But it's not clear to me how much this happens. I'm happy with the >> patch though, as currently virtqueue_enable_cb_delayed() is the same >> as virtqueue_enable_cb() if there's only been one buffer added. >> >> Cheers, >> Rusty. > > But isn't this by design? > The documentation says: > > * This re-enables callbacks but hints to the other side to delay > * interrupts until most of the available buffers have been processed; > > Clearly, this implies that when there's one buffer it must behave > exactly the same. Yes, my mistake. We could hit the "never gets notified" case with this change, and that's a much bigger problem. So I don't think we can accept this patch... Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined.
Rusty Russell writes:
> "Michael S. Tsirkin" writes:
>> On Fri, Feb 06, 2015 at 03:36:54PM +1030, Rusty Russell wrote:
>>> In particular, the virtio header always has the u16 num_buffers field.
>>> We define a new 'struct virtio_net_modern_hdr' for this (rather than
>>> simply calling it 'struct virtio_net_hdr', to avoid nasty type errors
>>> if some parts of a project define VIRTIO_NET_NO_LEGACY and some don't.
>>>
>>> Signed-off-by: Rusty Russell
>>> ---
>>> include/uapi/linux/virtio_net.h | 30 --
>>> 1 file changed, 28 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/virtio_net.h
>>> b/include/uapi/linux/virtio_net.h
>>> index b5f1677b291c..32754f3000e8 100644
>>> --- a/include/uapi/linux/virtio_net.h
>>> +++ b/include/uapi/linux/virtio_net.h
>>> @@ -35,7 +35,6 @@
>>> #define VIRTIO_NET_F_CSUM 0 /* Host handles pkts w/ partial csum */
>>> #define VIRTIO_NET_F_GUEST_CSUM1 /* Guest handles pkts w/
>>> partial csum */
>>> #define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
>>> -#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
>>> #define VIRTIO_NET_F_GUEST_TSO47 /* Guest can handle TSOv4 in. */
>>> #define VIRTIO_NET_F_GUEST_TSO68 /* Guest can handle TSOv6 in. */
>>> #define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/
>>> ECN in. */
>>> @@ -56,6 +55,10 @@
>>> * Steering */
>>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>>>
>>> +#ifndef VIRTIO_NET_NO_LEGACY
>>> +#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
>>> +#endif /* VIRTIO_NET_NO_LEGACY */
>>> +
>>> #define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
>>> #define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
>>>
>>> @@ -71,8 +74,9 @@ struct virtio_net_config {
>>> __u16 max_virtqueue_pairs;
>>> } __attribute__((packed));
>>>
>>> +#ifndef VIRTIO_NET_NO_LEGACY
>>> /* This header comes first in the scatter-gather list.
>>> - * If VIRTIO_F_ANY_LAYOUT is not negotiated, it must
>>> + * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
>>> * be the first element of the scatter-gather list. If you don't
>>> * specify GSO or CSUM features, you can simply ignore the header. */
>>> struct virtio_net_hdr {
>>> @@ -97,6 +101,28 @@ struct virtio_net_hdr_mrg_rxbuf {
>>> struct virtio_net_hdr hdr;
>>> __virtio16 num_buffers; /* Number of merged rx buffers */
>>> };
>>> +#else /* ... VIRTIO_NET_NO_LEGACY */
>>> +/*
>>> + * This header comes first in the scatter-gather list. If you don't
>>> + * specify GSO or CSUM features, you can simply ignore the header.
>>> + */
>>> +struct virtio_net_modern_hdr {
>>> +#define VIRTIO_NET_HDR_F_NEEDS_CSUM1 /* Use csum_start,
>>> csum_offset */
>>> +#define VIRTIO_NET_HDR_F_DATA_VALID2 /* Csum is valid */
>>> + __u8 flags;
>>> +#define VIRTIO_NET_HDR_GSO_NONE0 /* Not a GSO frame */
>>> +#define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
>>> +#define VIRTIO_NET_HDR_GSO_UDP 3 /* GSO frame, IPv4 UDP
>>> (UFO) */
>>> +#define VIRTIO_NET_HDR_GSO_TCPV6 4 /* GSO frame, IPv6 TCP */
>>> +#define VIRTIO_NET_HDR_GSO_ECN 0x80/* TCP has ECN set */
>>> + __u8 gso_type;
>>> + __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
>>> + __virtio16 gso_size;/* Bytes to append to hdr_len per frame */
>>> + __virtio16 csum_start; /* Position to start checksumming from */
>>> + __virtio16 csum_offset; /* Offset after that to place checksum */
>>> + __virtio16 num_buffers; /* Number of merged rx buffers */
>>> +};
>>> +#endif /* ...VIRTIO_NET_NO_LEGACY */
>>
>> This kind of masks the fact that it's the same as
>> virtio_net_hdr_mrg_rxbuf. So it's forcing people to duplicate
>> code for transitional devices.
>
> It's a hard problem to solve; someone suffers. My preference is to make
> non-legacy implementations as "clean" as possible, even if transitional
> devices suffer (since their suffering should be shorter-lived).
>
> Transitional devices can't define VIRTIO_NET_NO_LEGACY, so they'll
> have to use virtio_net_hdr_mrg_rxbuf anyway.
Here's what I ended up with. In effect, it's just the name change
and a comment that it's the same as the legacy virtio_net_hdr_mrg_rxbuf:
Subject: virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY
defined.
In particular, the virtio header always has the u16 num_buffers field.
We define a new 'struct virtio_net_hdr_v1' for this (rather than
simply calling it 'struct virtio_net_hdr', to avoid nasty type errors
if some parts of a project define VIRTIO_NET_NO_LEGACY and some don't.
Transitional devices (which can't define VIRTIO_NET_NO_LEGACY) will
have to keep using struct virtio_net_hdr_mrg_rxbuf, which has the same
byte layout as struct
Re: [PATCH v12 06/28] module: Do not inline do_init_module
Jan Kiszka writes:
> This provides a reliable breakpoint target, required for automatic
> symbol loading via the gdb helper command 'lx-symbols'.
>
> CC: Rusty Russell
Acked-by: Rusty Russell
Thanks,
Rusty.
> Signed-off-by: Jan Kiszka
> ---
> kernel/module.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index d856e96..2df6cec 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3011,8 +3011,13 @@ static void do_free_init(struct rcu_head *head)
> kfree(m);
> }
>
> -/* This is where the real work happens */
> -static int do_init_module(struct module *mod)
> +/*
> + * This is where the real work happens.
> + *
> + * Keep it uninlined to provide a reliable breakpoint target, e.g. for the
> gdb
> + * helper command 'lx-symbols'.
> + */
> +static noinline int do_init_module(struct module *mod)
> {
> int ret = 0;
> struct mod_initfree *freeinit;
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/2] virtio_pci: patches never to apply.
This should allow testing when QEMU gets VIRTIO_PCI_CAP_PCI_CFG support, but I'm pretty sure we should never allow these patches upstream. Tested with lguest (in virtio-next), which supports VIRTIO_PCI_CAP_PCI_CFG. Rusty Russell (2): virtio_pci: abstract all MMIO accesses. virtio: Introducing virtio_pci.no_mmio, the worst boot option in history. drivers/virtio/virtio_pci_common.c | 70 +++- drivers/virtio/virtio_pci_common.h | 62 drivers/virtio/virtio_pci_legacy.c | 1 + drivers/virtio/virtio_pci_modern.c | 317 ++--- 4 files changed, 391 insertions(+), 59 deletions(-) -- 2.1.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 v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On Wed, 11 Feb 2015, Ard Biesheuvel wrote:
> On 9 February 2015 at 19:46, Mark Rutland wrote:
> > On Sat, Feb 07, 2015 at 05:03:44AM +, Ard Biesheuvel wrote:
> >> On 7 February 2015 at 03:36, Hanjun Guo wrote:
> >> > On 2015年02月06日 18:34, G Gregory wrote:
> >> > [...]
> >> >
> >> >>
> >> >>
> >> >> linux,uefi-stub-kern-ver | string | Copy of linux_banner from
> >> >> build.
> >> >>
> >> >>
> >> >> +linux,uefi-stub-generated-dtb | bool | Indication for no DTB
> >> >> provided by
> >> >> +| | firmware.
> >> >>
> >> >> +
> >> >
> >> >
> >> > Apologies for the late bikeshedding, but the discussion on this topic
> >> > previsously was lively enough that I thought I'd let it die down a
> >> > bit
> >> > before seeing if I had anything to add.
> >> >
> >> > That, and I just realised something:
> >> > One alternative to this added DT entry is that we could treat the
> >> > absence of a registered UEFI configuration table as the indication
> >> > that no HW description was provided from firmware, since the stub
> >> > does
> >> > not call InstallConfigurationTable() on the DT it generates. This
> >> > does
> >> > move the ability to detect to after efi_init(), but this should be
> >> > fine for ACPI-purposes.
> >> >
> >> That would not work as expected in the kexec/Xen use case though as
> >> they
> >> may genuinely boot with DT from an ACPI host without UEFI.
> >> >>>
> >> >>>
> >> >>> I'm a little concerned by this case. How do we intend to pass stuff
> >> >>> from
> >> >>> Xen to the kernel in this case? When we initially discussed the stub
> >> >>> prior to merging, we weren't quite sure if ACPI without UEFI was
> >> >>> entirely safe.
> >> >>>
> >> >>> The linux,uefi-stub-kern-ver property was originally intended as a
> >> >>> sanity-check feature to ensure nothing (including Xen) masqueraded as
> >> >>> the stub, but for some reason the actual sanity check was never
> >> >>> implemented.
> >> >>>
> >> > If that is deemed undesirable, I would still prefer Catalin's
> >> > suggested name ("linux,bare-dtb"), which describes the state rather
> >> > than the route we took to get there.
> >> >
> >> I agree.
> >> >>>
> >> >>>
> >> >>> I guess this would be ok, though it would be nice to know which agent
> >> >>> generated the DTB.
> >> >>>
> >> >>
> >> >> The most obvious scheme then is
> >> >>
> >> >> linux,bare-dtb = "uefi-stub";
> >> >>
> >> >> otherwise we generate a new binding for every component in the boot
> >> >> path.
> >> >
> >> >
> >> > Leif, Mark, any comments on this?
> >> >
> >>
> >> As far as I remember, we did not finalize the decision to go with a
> >> stub generated property instead of some other means to infer that the
> >> device tree is not suitable for booting and ACPI should be preferred.
> >>
> >> We will be discussing the 'stub<->kernel interface as a boot protocol'
> >> topic this week at Connect, so let's discuss it in that context before
> >> signing off on patches like these.
> >
> > As some of us (at least myself) aren't at connect, it would be nice if
> > those discussions could be at least mirrored on the mailing list. I have
> > some concerns regarding how this is going to work long-term, and I'd
> > like to make sure we don't get stuck with something that limits what we
> > can do long-term.
> >
> > Is there a session set aside for this, or is this a hallway track topic?
> >
>
> Hello all,
>
> (added team-Xen to cc)
>
> We had our meeting yesterday: allow me to summarize what we discussed,
> and we can proceed with the discussion on-list if desired.
>
> Present:
> Grant Likely
> Al Stone
> Hanjun Guo
> Leif Lindholm
> Roy Franz
> Ard Biesheuvel
>
> Topic #1: booting the arm64 kernel with ACPI but no UEFI
>
> We have identified Xen as the only use case: there is a need to boot
> dom0 using the host's ACPI tables but without allowing the dom0 kernel
> to interface directly with the UEFI firmware. There may be other valid
> use cases, though, so this use case should be addressed generically
> regardless.
>
> First, it was proposed to allow the ACPI root pointer to be added to a
> /chosen node property, and the kernel would use this property instead
> of going through the UEFI tables.
> However, there is a similar case that could be made for SMBIOS: unlike
> x86, where there is a 'legacy' method to locate either table by
> scanning some special physical memory regions, the respective
> specifications only provide a single method to perform table
> discovery, which is through UEFI. This means that passing the ACPI
> root pointer to the kernel using a
Re: doubt about sm7xxfb
On Wed, Feb 11, 2015 at 11:58:18AM +0530, Sudip Mukherjee wrote: > On Wed, Feb 11, 2015 at 12:36:36PM +0800, Greg Kroah-Hartman wrote: > > On Tue, Feb 10, 2015 at 07:37:47PM +0530, Sudip Mukherjee wrote: > > > Hi Greg, > > > we have this sm7xxfb in drivers/staging now which is supporting SM710, > > > SM712, SM721 and SM722. I am also working on another new hardware > > > SM750, which will be ready for staging in next 1 -2 weeks. > > > this SM750 is entirely different hardware and these two drivers will > > > have nothing in common. > > > > Then make a new driver! > ok, but then won't the name sm7xxfb will be misleading? Sure, but really, who cares :) > > But why would a new driver go into staging? Anything new you create > > should just go into the "correct" part of the kernel. Don't waste your > > time on staging. > > this code has been given to me by Silicon Motion, and will require a > few changes before it can be used with current kernel version. And to > merge it into video/fbdev it will require many changes and cleanups. > But to be frank this will have much less work to do compared to > sm7xxfb, but as this is not part of my dayjob i can not give my full > time to it. So I was thinking of staging. Ok, that makes sense, I was thinking this was a "new" driver, instead of a vendor driver crud. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Tue, Feb 10, 2015 at 8:31 PM, Steven Rostedt wrote:
>> > Again, this would mean they become invisible to ftrace, and even
>> > ftrace_dump_on_oops.
>>
>> yes, since these new tracepoints have no meat inside them.
>> They're placeholders sitting idle and waiting for bpf to do
>> something useful with them.
>
> Hmm, I have a patch somewhere (never posted it), that add
> TRACE_MARKER(), which basically would just print that it was hit. But
> no data was passed to it. Something like that I would be more inclined
> to take. Then the question is, what can bpf access there? Could just be
> a place holder to add a "fast kprobe". This way, it can show up in
> trace events with enable and and all that, it just wont have any data
> to print out besides the normal pid, flags, etc.
>
> But because it will inject a nop, that could be converted to a jump, it
> will give you the power of kprobes but with the speed of a tracepoint.
fair enough.
Something like TRACE_MARKER(arg1, arg2) that prints
it was hit without accessing the args would be enough.
Without any args it is indeed a 'fast kprobe' only.
Debug info would still be needed to access
function arguments.
On x64 function entry point and x64 abi make it easy
to access args, but i386 or kprobe in the middle
lose visibility when debug info is not available.
TRACE_MARKER (with few key args that function
is operating on) is enough to achieve roughly the same
as kprobe without debug info.
>> > I'm not fully understanding what is to be exported by this new ABI. If
>> > the fields available, will always be available, then why can't the
>> > appear in a TP_printk()?
>>
>> say, we define trace_netif_rx_entry() as this new tracepoint_bpf.
>> It will have only one argument 'skb'.
>> bpf program will read and print skb fields the way it likes
>> for particular tracing scenario.
>> So instead of making
>> TP_printk("dev=%s napi_id=%#x queue_mapping=%u skbaddr=%p
>> vlan_tagged=%d vlan_proto=0x%04x vlan_tci=0x%04x protocol=0x%04x
>> ip_summed=%d hash=0x%08x l4_hash=%d len=%u data_len=%u truesize=%u
>> mac_header_valid=%d mac_header=%d nr_frags=%d gso_size=%d
>> gso_type=%#x",...
>> the abi exposed via trace_pipe (as it is today),
>> the new tracepoint_bpf abi is presence of 'skb' pointer as one
>> and only argument to bpf program.
>> Future refactoring of netif_rx would need to guarantee
>> that trace_netif_rx_entry(skb) is called. that's it.
>> imo such tracepoints are much easier to deal with during
>> code changes.
>
> But what can you access from that skb that is guaranteed to be there?
> If you say anything, then there's no reason it can't be added to the
> printk as well.
programs can access any field via bpf_fetch*() helpers which
make them kernel layout dependent or via user-ized sk_buff
with few fields which is portable.
In both cases kernel/user abi is only 'skb' pointer.
whether it's debugging program that needs full access
via fetch* helpers or portable program that uses stable api
it's up to program author.
Just like kprobes, it's clear, that if program is using
fetch* helpers it's doing it without any abi guarantees.
'perf probe' and 'bpf with fetch* helpers are the same.
perf probe creates wrappers on top of probe_kernel_read and
bpf_fetch* helpers are wrappers on top of probe_kernel_read.
Complains that 'my kprobe with flags=%cx mode=+4($stack)
stopped working in new kernel' are equivalent to complains
that program with bpf_fetch* stopped working.
Whereas if program is using user-ized structs it will work
across kernel versions, though it will be able to see
only very limited slice of in-kernel data.
>> May be some of the existing tracepoints like this one that
>> takes one argument can be marked 'bpf-ready', so that
>> programs can attach to them only.
>
> I really hate the idea of adding tracepoints that ftrace can't use. It
> basically kills the entire busy box usage scenario, as boards that have
> extremely limited userspace still make full use of ftrace via the
> existing tracepoints.
agree. I think your trace_marker with few args is a good
middle ground.
> I still don't see the argument that adding data via the bpf functions
> is any different than adding those same items to fields in an event.
> Once you add a bpf function, then you must maintain those fields.
>
> Look, you can always add more to a TP_printk(), as that is standard
> with all text file kernel parsing. Like stat in /proc. Fields can not
> be removed, but more can always be appended to the end.
>
> Any tool that parses trace_pipe is broken if it can't handle extended
> fields. The api can be extended, and for text files, that is by
> appending to them.
I agree that any text parsing script should be able to cope
with additional args without problems. I think it's a fear of
<1% breakage is causing maintainers to avoid any changes
to tracepoints even when they just add few args to the end
of TP_printk.
When tracepoints stop printing and the only thing they see
is single pointer to a
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
Tejun Heo writes: > Hey, > > On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote: >> A slightly off topic comment, for where this thread has gone but >> relevant if we are talking about cgroup namespaces. >> >> If don't implement compatibility with existing userspace, they get a >> nack. A backwards-incompatible change should figure out how to remove >> the need for any namespaces. >> >> Because that is what namespaces are about backwards compatibility. > > Are you claiming that namespaces are soley about backwards > compatibility? ie. to trick userland into scoping without letting it > notice? That's a very restricted view and namespaces do provide > further isolation capabilties in addition to what can be achieved > otherwise and it is logical to collect simliar funtionalities there. In principle a namespace is an additional layer of indirection from names to objects. A namespace does not invent new kinds of objects. A namespace takes things that were previously global and gives them a scope. In princple after name resolution a namespace should impose no overhead. In general namespaces are not necessary if your scope of names already has hierarchy. Which means that new interfaces can almost always be designed in such a way that you can support containers without needing to add any special namespace support. Which typically results in more flexible and useful APIs for everyone, with no real code cost. Further in the cgroup namespace patchset I looked at a while ago, the only reason for having a cgroup namespace was to provide a measure of backwards compatibility with existing userspace. I expect removing the /proc//cgroup file and replacing it with something in cgroupfs itself would serve just as well if backwards compatibility is not the objective. Or possibly replacincg /proc//cgroup into a magic symlink onto somewhere in the unified cgroupfs itself. I just don't see any point in doing weird silly namespace things to keep existing userspace working when the existing userspace won't work. As such if a namespace doesn't implement compatibility with the existing userspace it gets my nack. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: doubt about sm7xxfb
On Wed, Feb 11, 2015 at 12:36:36PM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 07:37:47PM +0530, Sudip Mukherjee wrote: > > Hi Greg, > > we have this sm7xxfb in drivers/staging now which is supporting SM710, > > SM712, SM721 and SM722. I am also working on another new hardware > > SM750, which will be ready for staging in next 1 -2 weeks. > > this SM750 is entirely different hardware and these two drivers will > > have nothing in common. > > Then make a new driver! ok, but then won't the name sm7xxfb will be misleading? > > But why would a new driver go into staging? Anything new you create > should just go into the "correct" part of the kernel. Don't waste your > time on staging. this code has been given to me by Silicon Motion, and will require a few changes before it can be used with current kernel version. And to merge it into video/fbdev it will require many changes and cleanups. But to be frank this will have much less work to do compared to sm7xxfb, but as this is not part of my dayjob i can not give my full time to it. So I was thinking of staging. regards sudip > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
Hi Yinghai,
Could you please help to have a look at a problem which I encountered?
I am trying to make kaslr randomize on both kernel physical and virtual
address separately. Now the separate randomization has been done,
kernel physical address can be randomized to [16M, 4G], and virtual
address can be randomzed to [16M, 1G]. Below is the post.
http://thread.gmane.org/gmane.linux.kernel/1870532
Now I am trying to make kernel physical address randomize anywhere, not
limited to below 4G. As you know in arch/x86/boot/compressed/head_64.S a
identity mapping of 0~4G has been built, for address above 4G I added an
IDT and #PF handler. Then I hardcoded the output address of
choose_kernel_location as 5G, the #PF handler worked, however it will
reboot in arch/x86/kernel/head_64.S.
I don't know how to debug asm code, and have no idea why it has been in
64 bit mode while it can't be in above 4G in boot/compressed/head_64.S.
Now for debugging this issue, I made a small debug patch as below. Four
more pages are added as pmd page table, so identity mapping cover
0~8G. Then hardcode the output address as 5G, and disable the relocation
handling to filter unnecessary interference.
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index 6b1766c..74da678 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -123,7 +123,7 @@ ENTRY(startup_32)
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
- movl$((4096*6)/4), %ecx
+ movl$((4096*10)/4), %ecx
rep stosl
/* Build Level 4 */
@@ -134,7 +134,7 @@ ENTRY(startup_32)
/* Build Level 3 */
lealpgtable + 0x1000(%ebx), %edi
leal0x1007(%edi), %eax
- movl$4, %ecx
+ movl$8, %ecx
1: movl%eax, 0x00(%edi)
addl$0x1000, %eax
addl$8, %edi
@@ -144,7 +144,7 @@ ENTRY(startup_32)
/* Build Level 2 */
lealpgtable + 0x2000(%ebx), %edi
movl$0x0183, %eax
- movl$2048, %ecx
+ movl$4096, %ecx
1: movl%eax, 0(%edi)
addl$0x0020, %eax
addl$8, %edi
@@ -476,4 +476,4 @@ boot_stack_end:
.section ".pgtable","a",@nobits
.balign 4096
pgtable:
- .fill 6*4096, 1, 0
+ .fill 10*4096, 1, 0
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a950864..47c8c80 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -404,6 +404,7 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
output = choose_kernel_location(input_data, input_len, output,
output_len > run_size ? output_len
: run_size);
+ output = 0x14000;
/* Validate memory location choices. */
if ((unsigned long)output & (MIN_KERNEL_ALIGN - 1))
@@ -427,8 +428,10 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
* 32-bit always performs relocations. 64-bit relocations are only
* needed if kASLR has chosen a different load address.
*/
+#if 0
if (!IS_ENABLED(CONFIG_X86_64) || output != output_orig)
handle_relocations(output, output_len);
+#endif
debug_putstr("done.\nBooting the kernel.\n");
return output;
}
Thanks
Baoquan
On 02/03/15 at 06:03pm, Yinghai Lu wrote:
> Now could use kexec to place kernel/boot_params/cmd_line/initrd
> above 4G, but that is with legacy interface with startup_64 directly.
>
> This patch will allow 64bit EFI kernel to be loaded above 4G
> and use EFI HANDOVER PROTOCOL to start the kernel.
>
> Current code32_start is used for passing around loading address,
> so it will overflow when kernel is loaded abover 4G.
>
> The patch mainly add ext_code32_start to take address high 32bit.
>
> After this patch, could use patched grub2-x86_64.efi to place
> kernel/boot_params/cmd_line/initrd all above 4G and execute the kernel
> above 4G.
>
> bootlog like:
>
> params: [1618fc000,1618f]
> cmdline: [1618fb000,1618fb7fe]
> kernel: [15e00,161385fff]
> kernel: done [ linux 9.25MiB 100% 6.66MiB/s ]
> initrd: [15bcbe000,15dbb]
> initrd: 1 file done [ initrd.img 35.26MiB 100% 11.93MiB/s ]
> early console in decompress_kernel
> decompress_kernel:
> input: [0x15fd0b3b4-0x16063c803], output: 0x15e00, heap:
> [0x160645b00-0x16064daff]
>
> Decompressing Linux... xz... Parsing ELF... done.
> Booting the kernel.
> [0.00] bootconsole [uart0] enabled
> [0.00]real_mode_data : phys 0001618fc000
> [0.00]real_mode_data : virt 8801618fc000
> [0.00] Kernel Layout:
> [0.00] .text: [0x15e00-0x15f08f72c]
> [0.00] .rodata:
[Patch v3 1/2] dt/bindings: qcom_adm: Fix channel specifiers
This patch removes the crci information from the dma channel property. At least one client device requires using more than one CRCI value for a channel. This does not match the current binding and the crci information needs to be removed. Instead, the client device will provide this information via other means. Signed-off-by: Andy Gross --- Documentation/devicetree/bindings/dma/qcom_adm.txt | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/qcom_adm.txt b/Documentation/devicetree/bindings/dma/qcom_adm.txt index 9bcab91..38d45f8 100644 --- a/Documentation/devicetree/bindings/dma/qcom_adm.txt +++ b/Documentation/devicetree/bindings/dma/qcom_adm.txt @@ -4,8 +4,7 @@ Required properties: - compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960 - reg: Address range for DMA registers - interrupts: Should contain one interrupt shared by all channels -- #dma-cells: must be <2>. First cell denotes the channel number. Second cell - denotes CRCI (client rate control interface) flow control assignment. +- #dma-cells: must be <1>. First cell denotes the channel number. - clocks: Should contain the core clock and interface clock. - clock-names: Must contain "core" for the core clock and "iface" for the interface clock. @@ -22,7 +21,7 @@ Example: compatible = "qcom,adm"; reg = <0x1830 0x10>; interrupts = <0 170 0>; - #dma-cells = <2>; + #dma-cells = <1>; clocks = < ADM0_CLK>, < ADM0_PBUS_CLK>; clock-names = "core", "iface"; @@ -35,15 +34,12 @@ Example: qcom,ee = <0>; }; -DMA clients must use the format descripted in the dma.txt file, using a three +DMA clients must use the format descripted in the dma.txt file, using a two cell specifier for each channel. -Each dmas request consists of 3 cells: +Each dmas request consists of two cells: 1. phandle pointing to the DMA controller 2. channel number - 3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0. -The CRCI is used for flow control. It identifies the peripheral device that -is the source/destination for the transferred data. Example: @@ -56,7 +52,7 @@ Example: cs-gpios = <_pinmux 20 0>; - dmas = <_dma 6 9>, - <_dma 5 10>; + dmas = <_dma 6>, + <_dma 5>; dma-names = "rx", "tx"; }; -- 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/
[Patch v3 0/2] Add Qualcomm ADM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Application Data Mover (ADM) DMA controller present on MSM8x60, APQ8064, and IPQ8064 devices. The initial version of this driver will only support slave DMA operations between system memory and peripherals. Flow control via the CRCI (client rate control interface) is supported and can be configured via device tree configuration. Flow control usage is required for some peripheral devices. Changes from v2: - Removed extraneous achan variable from xlate function - Reworked crci check in slave_sg function - Added mux field to async_desc structure. - Reworked dma start function to use crci and mux values directly from structure. - Added disable of clocks in probe error paths. - Changed to use #define for fixed number of channels. Changes since v1: - Fixed various review comments - Fixed some descriptor programming issues. - Added single descriptors to support sub burst length transactions. Selection of single or box descriptors depends on the sg length and burst size. - Removed use of crci in the dmas property. CRCI is now designated via the slave_config structure and will be stored in slave_id. Andy Gross (2): dt/bindings: qcom_adm: Fix channel specifiers dmaengine: Add ADM driver Documentation/devicetree/bindings/dma/qcom_adm.txt | 16 +- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 902 4 files changed, 919 insertions(+), 10 deletions(-) create mode 100644 drivers/dma/qcom_adm.c -- 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/
[Patch v3 2/2] dmaengine: Add ADM driver
Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA controller found in the MSM8x60 and IPQ/APQ8064 platforms. The ADM supports both memory to memory transactions and memory to/from peripheral device transactions. The controller also provides flow control capabilities for transactions to/from peripheral devices. The initial release of this driver supports slave transfers to/from peripherals and also incorporates CRCI (client rate control interface) flow control. Signed-off-by: Andy Gross --- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 902 3 files changed, 913 insertions(+) create mode 100644 drivers/dma/qcom_adm.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index f2b2c4e..69bc15e 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -464,4 +464,14 @@ config QCOM_BAM_DMA Enable support for the QCOM BAM DMA controller. This controller provides DMA capabilities for a variety of on-chip devices. +config QCOM_ADM + tristate "Qualcomm ADM support" + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the Qualcomm ADM DMA controller. This controller + provides DMA capabilities for both general purpose and on-chip + peripheral devices. + endif diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 2022b54..3b7ead6 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -50,3 +50,4 @@ obj-y += xilinx/ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o +obj-$(CONFIG_QCOM_ADM) += qcom_adm.o diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c new file mode 100644 index 000..7381c38 --- /dev/null +++ b/drivers/dma/qcom_adm.c @@ -0,0 +1,902 @@ +/* + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dmaengine.h" +#include "virt-dma.h" + +/* ADM registers - calculated from channel number and security domain */ +#define HI_CH_CMD_PTR(chan, ee)(4*chan + 0x20800*ee) +#define HI_CH_RSLT(chan, ee) (0x40 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE0(chan, ee) (0x80 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE1(chan, ee) (0xc0 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE2(chan, ee) (0x100 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE3(chan, ee) (0x140 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE4(chan, ee) (0x180 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE5(chan, ee) (0x1c0 + 4*chan + 0x20800*ee) +#define HI_CH_STATUS_SD(chan, ee) (0x200 + 4*chan + 0x20800*ee) +#define HI_CH_CONF(chan) (0x240 + 4*chan) +#define HI_CH_RSLT_CONF(chan, ee) (0x300 + 4*chan + 0x20800*ee) +#define HI_SEC_DOMAIN_IRQ_STATUS(ee) (0x380 + 0x20800*ee) +#define HI_CI_CONF(ci) (0x390 + 4*ci) +#define HI_CRCI_CONF0 0x3d0 +#define HI_CRCI_CONF1 0x3d4 +#define HI_GP_CTL 0x3d8 +#define HI_CRCI_CTL(crci, ee) (0x400 + 0x4*crci + 0x20800*ee) + +/* channel status */ +#define CH_STATUS_VALIDBIT(1) + +/* channel result */ +#define CH_RSLT_VALID BIT(31) +#define CH_RSLT_ERRBIT(3) +#define CH_RSLT_FLUSH BIT(2) +#define CH_RSLT_TPDBIT(1) + +/* channel conf */ +#define CH_CONF_MPU_DISABLEBIT(11) +#define CH_CONF_PERM_MPU_CONF BIT(9) +#define CH_CONF_FLUSH_RSLT_EN BIT(8) +#define CH_CONF_FORCE_RSLT_EN BIT(7) +#define CH_CONF_IRQ_EN BIT(6) + +/* channel result conf */ +#define CH_RSLT_CONF_FLUSH_EN BIT(1) +#define CH_RSLT_CONF_IRQ_ENBIT(0) + +/* CRCI CTL */ +#define CRCI_CTL_MUX_SEL BIT(18) +#define CRCI_CTL_RST BIT(17) + +/* CI configuration */ +#define CI_RANGE_END(x)(x << 24) +#define CI_RANGE_START(x) (x << 16) +#define CI_BURST_4_WORDS 0x4 +#define CI_BURST_8_WORDS 0x8 + +/* GP CTL */ +#define GP_CTL_LP_EN BIT(12) +#define GP_CTL_LP_CNT(x) (x << 8) + +/* Command pointer list entry */ +#define CPLE_LPBIT(31) +#define CPLE_CMD_PTR_LIST BIT(29) + +/* Command list entry */
Re: [PATCH RFC v5 net-next 2/6] virtio_ring: try to disable event index callbacks in virtqueue_disable_cb()
On Tue, Feb 10, 2015 at 6:24 PM, Michael S. Tsirkin wrote: On Mon, Feb 09, 2015 at 03:39:21AM -0500, Jason Wang wrote: Currently, we do nothing to prevent the callbacks in virtqueue_disable_cb() when event index is used. This may cause spurious interrupts which may damage the performance. This patch tries to publish avail event as the used even to prevent the callbacks. Signed-off-by: Jason Wang I'm surprised that this ever happens though. Normally we call this after getting an interrupt, and interrupts won't trigger again until the rings wraps around. It was used to disable tx interrupt during start_xmit(). When I tested this, touching an extra cache line was more expensive. Does this really reduce number of interrupts? Could you pls share some numbers with and without this patch? Yes. It does reduce, see the following test results on multiple sessions of TCP_RR Datacopy: /size/sessions/+-throughput%/+-cpu%/+-per_cpu_throughput%/+-tx_interrupts%/ /1/50/+0.1/+0.7/-0.6/-72.3/ /64/50/+1.7/+1.0/+0.7/-72.2/ /256/50/+0.0/-0.8/+0.9/-72.4/ Zerocopy: /size/sessions/+-throughput%/+-cpu%/+-per_cpu_throughput%/+-tx_interrupts%/ /1/50/+3.2/-1.3/+4.6/-71.7/ /64/50/+1.9/-0.2/+2.1/-70.8/ /256/50/+4.4/+0.6/+3.9/-84.2/ No obvious changes for stream rx and tx. --- drivers/virtio/virtio_ring.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 545fed5..e9ffbfb 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -539,6 +539,8 @@ void virtqueue_disable_cb(struct virtqueue *_vq) struct vring_virtqueue *vq = to_vvq(_vq); vq->vring.avail->flags |= cpu_to_virtio16(_vq->vdev, VRING_AVAIL_F_NO_INTERRUPT); + vring_used_event(>vring) = cpu_to_virtio16(_vq->vdev, + vq->vring.avail->idx); Hmm in fact, can't this actually cause an extra interrupt when avail->idx is completed? We need to try best to avoid any interrupt after this and virtqueue_disable_cb() were always need virtqueue_enable_cb() or virtqueue_enable_cb_delayed() afterwards. Those two function will check the pending used buffers and set a proper used event. I think that if you really can show disabling interrupts like this helps, you should set some invalid value like 0xf, or move it back to vq->vring.avail->idx - 1. No? I tested avail->idx + vq.num but not obvious changes in the performance compared to just use avail->idx here. So 0x probably won't help much. Since we call virtqueue_enable_cb() or virtqueue_disable_cb_delayed() afterwards, it doesn't matter that whether avail->idx or avail->idx - 1 is used. } EXPORT_SYMBOL_GPL(virtqueue_disable_cb); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Tue, Feb 10, 2015 at 9:28 PM, David Miller wrote: > > I've put Al's version of the fix into my tree and here is > a new respun pull request: Heh. I already faked that myself - fetched your branch, then locally added my fix on top of it, and merged that instead. So I have "pulled" the networking branch, even if it was a slightly edited one. Btw, I like your summaries for the networking pulls, but they don't tend to mention a lot of the stuff that I assume you pull from others. For example, there seems to have been a lot of bluetooth stuff this round and obviously there's just a ton of network driver work, but those tend to not be mentioned in your summary - presumablty because most of that is a few people removed. I'm wondering if you could add *some* mention of things like that to the summaries too? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v10 0/2] ns, procfs: pid conversion between ns
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Friday, February 06, 2015 6:46 PM > To: Eric W. Biederman; Andrew Morton > Cc: Jonathan Corbet; contain...@lists.linux-foundation.org; Serge Hallyn; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan Scott > Subject: [PATCH v10 0/2] ns, procfs: pid conversion between ns > > > Chen Hanxiao (1): > /proc/PID/status: show all sets of pid according to ns > > Nathan Scott (1): > docs: add missing and new /proc/PID/status file entries, fix typos > > Documentation/filesystems/proc.txt | 11 --- > fs/proc/array.c| 16 > 2 files changed, 24 insertions(+), 3 deletions(-) > Hi Eric, Could please pick this series up for 3.20? Thanks, - Chen
[PATCH v2 2/6] staging: rtl8188eu: hal: removed code indent error
This patch removed indentation with a tab error
ERROR: code indent should use tabs where possible
Signed-off-by: Pushpendra Singh
---
drivers/staging/rtl8188eu/hal/rf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/rf.c
b/drivers/staging/rtl8188eu/hal/rf.c
index 88a026c..d6daaca 100644
--- a/drivers/staging/rtl8188eu/hal/rf.c
+++ b/drivers/staging/rtl8188eu/hal/rf.c
@@ -101,7 +101,8 @@ void rtl88eu_phy_rf6052_set_cck_txpower(struct adapter
*adapt, u8 *powerlevel)
ptr++;
}
}
- rtl88eu_dm_txpower_track_adjust(_data->odmpriv, 1, ,
_value);
+ rtl88eu_dm_txpower_track_adjust(_data->odmpriv, 1,
+ , _value);
if (direction == 1) {
/* Increase TX power */
--
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] ASoC: fsl_ssi: Fix the incorrect limitation of the bit clock rate
On Tue, Feb 10, 2015 at 09:31:43PM -0800, Nicolin Chen wrote: > According to i.MX Reference Manual, the bit-clock frequency generated > by SSI must be never greater than 1/5 of the peripheral clock frequency. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH RFC v5 net-next 1/6] virtio_ring: fix virtqueue_enable_cb() when only 1 buffers were pending
On Tue, Feb 10, 2015 at 6:18 PM, Michael S. Tsirkin wrote: On Tue, Feb 10, 2015 at 11:33:52AM +1030, Rusty Russell wrote: Jason Wang writes: > We currently does: > > bufs = (avail->idx - last_used_idx) * 3 / 4; > > This is ok now since we only try to enable the delayed callbacks when > the queue is about to be full. This may not work well when there is > only one pending buffer in the virtqueue (this may be the case after > tx interrupt was enabled). Since virtqueue_enable_cb() will return > false which may cause unnecessary triggering of napis. This patch > correct this by only calculate the four thirds when bufs is not one. I mildly prefer to avoid the branch, by changing the calculation like so: /* Set bufs >= 1, even if there's only one pending buffer */ bufs = (bufs + 1) * 3 / 4; Or bus * 3/4 + 1 But it's not clear to me how much this happens. I'm happy with the patch though, as currently virtqueue_enable_cb_delayed() is the same as virtqueue_enable_cb() if there's only been one buffer added. Cheers, Rusty. But isn't this by design? The documentation says: * This re-enables callbacks but hints to the other side to delay * interrupts until most of the available buffers have been processed; Clearly, this implies that when there's one buffer it must behave exactly the same. So I'm not very happy - this changes the meaning of the API without updating the documentation. Think hard about this. And looks like your are right. And the patch may in fact cause more trouble e.g the only pending buffer were consumed before the final check between used idx and last_used_idx. Will drop this. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 04/57] vm: add VM_FAULT_SIGSEGV handling support
On Wed, Feb 11, 2015 at 6:43 AM, Greg Kroah-Hartman
wrote:
> On Tue, Feb 10, 2015 at 12:22:41PM +0400, Konstantin Khlebnikov wrote:
>> I've found regression:
>>
>> [ 257.139907]
>> [ 257.139909] [ BUG: lock held when returning to user space! ]
>> [ 257.139912] 3.18.6-debug+ #161 Tainted: G U
>> [ 257.139914]
>> [ 257.139916] python/22843 is leaving the kernel with locks still held!
>> [ 257.139918] 1 lock held by python/22843:
>> [ 257.139920] #0: (>mmap_sem){++}, at: []
>> __do_page_fault+0x162/0x570
>>
>> upstream commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 must be backported
>> too.
>
> Ah, nice, I missed that one. How did you test this?
I've catched hang on mmap_sem in some python self-test inside exherbo chroot.
With that patch test has finished successfully.
It seems the only way to tigger this is stack-overflow: for now VM_FAULT_SIGSEGV
is returned only if kernel cannot add guard page when stack expands.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: fsl_ssi: Fix the incorrect limitation of the bit clock rate
According to i.MX Reference Manual, the bit-clock frequency generated
by SSI must be never greater than 1/5 of the peripheral clock frequency.
This peripheral clock, however, is not baudclk but the IPG clock (i.e.
ssi_private->clk in the fsl_ssi driver).
So this patch just simply fixes the incorrect limitation applied to
the bit clock (baudclk) rate.
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_ssi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 059496e..d7365c5 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -603,10 +603,6 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
factor = (div2 + 1) * (7 * psr + 1) * 2;
for (i = 0; i < 255; i++) {
- /* The bclk rate must be smaller than 1/5 sysclk rate */
- if (factor * (i + 1) < 5)
- continue;
-
tmprate = freq * factor * (i + 2);
if (baudclk_is_used)
@@ -614,6 +610,13 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
else
clkrate = clk_round_rate(ssi_private->baudclk, tmprate);
+ /*
+* Hardware limitation: The bclk rate must be
+* never greater than 1/5 IPG clock rate
+*/
+ if (clkrate * 5 > clk_get_rate(ssi_private->clk))
+ continue;
+
clkrate /= factor;
afreq = clkrate / (i + 1);
--
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 v2 1/2] dmaengine: Add ADM driver
On Fri, Jan 30, 2015 at 05:17:51PM +0530, Pramod Gurav wrote: > > + > > + achan = to_adm_chan(chan); > Could not understand the use of achan here. unused code? yeah its unnecessary now. will remove. Thanks! > > > + -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
Hey, On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote: > A slightly off topic comment, for where this thread has gone but > relevant if we are talking about cgroup namespaces. > > If don't implement compatibility with existing userspace, they get a > nack. A backwards-incompatible change should figure out how to remove > the need for any namespaces. > > Because that is what namespaces are about backwards compatibility. Are you claiming that namespaces are soley about backwards compatibility? ie. to trick userland into scoping without letting it notice? That's a very restricted view and namespaces do provide further isolation capabilties in addition to what can be achieved otherwise and it is logical to collect simliar funtionalities there. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
Hello, On Wed, Feb 11, 2015 at 05:29:42AM +0100, Serge E. Hallyn wrote: > > There shouldn't be a "freezer" cgroup. The processes are categorized > > according to their logical structure and controllers are applied to > > the hierarchy as necessary. > > But there can well be cgroups for which only freezer is enabled. If > I'm wrong about that, then I am suffering a fundamental misunderstanding. Ah, sure, I was mostly arguing semantics. It's just weird to call it "freezer" cgroup. > > The semantics is that the parent enables distribution of its given > > type of resource by enabling the controller in its subtree_control. > > This scoping isn't necessary for freezer and I'm debating whether to > > enable controllers which don't need granularity control to be enabled > > unconditionally. Right now, I'm leaning against it mostly for > > consistency. > > Yeah, IIUC (i.e. freezer would always be enabled?) that would be > even-more-confusing. Right, freezer is kinda weird tho. Its feature can almost be considered a utility feature of cgroups core rather than a separate controller. That said, it's most likely that it'll remain in its current form although how it blocks tasks should definitely be reimplemented. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
A slightly off topic comment, for where this thread has gone but relevant if we are talking about cgroup namespaces. If don't implement compatibility with existing userspace, they get a nack. A backwards-incompatible change should figure out how to remove the need for any namespaces. Because that is what namespaces are about backwards compatibility. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ALSA: line6: Improve line6_read/write_data() interfaces
Use explicit types to reflect the range of valid values.
Signed-off-by: Chris Rorvick
---
sound/usb/line6/driver.c | 10 +-
sound/usb/line6/driver.h | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 1e58e92..aac1e35 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -299,8 +299,8 @@ static void line6_data_received(struct urb *urb)
/*
Read data from device.
*/
-int line6_read_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen)
+int line6_read_data(struct usb_line6 *line6, u16 address, void *data,
+ u8 datalen)
{
struct usb_device *usbdev = line6->usbdev;
int ret;
@@ -309,7 +309,7 @@ int line6_read_data(struct usb_line6 *line6, int address,
void *data,
/* query the serial number: */
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
- (datalen << 8) | 0x21, address,
+ ((u16) datalen << 8) | 0x21, address,
NULL, 0, LINE6_TIMEOUT * HZ);
if (ret < 0) {
@@ -357,8 +357,8 @@ EXPORT_SYMBOL_GPL(line6_read_data);
/*
Write data to device.
*/
-int line6_write_data(struct usb_line6 *line6, int address, void *data,
-size_t datalen)
+int line6_write_data(struct usb_line6 *line6, u16 address, void *data,
+u16 datalen)
{
struct usb_device *usbdev = line6->usbdev;
int ret;
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 8247a6b..603bdc4 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -147,8 +147,8 @@ struct usb_line6 {
extern char *line6_alloc_sysex_buffer(struct usb_line6 *line6, int code1,
int code2, int size);
-extern int line6_read_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen);
+extern int line6_read_data(struct usb_line6 *line6, u16 address, void *data,
+ u8 datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
int *serial_number);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
@@ -161,8 +161,8 @@ extern void line6_start_timer(struct timer_list *timer,
unsigned int msecs,
void (*function)(unsigned long),
unsigned long data);
extern int line6_version_request_async(struct usb_line6 *line6);
-extern int line6_write_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen);
+extern int line6_write_data(struct usb_line6 *line6, u16 address, void *data,
+ u16 datalen);
int line6_probe(struct usb_interface *interface,
const struct usb_device_id *id,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ALSA: line6: Return EIO if read/write not successful
Signed-off-by: Chris Rorvick
---
sound/usb/line6/driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 2a33f3e..f8e2eb0 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -349,7 +349,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
void *data,
dev_err(line6->ifcdev,
"length mismatch (expected %d, got %d)\n",
(int)datalen, (int)len);
- return -EINVAL;
+ return -EIO;
}
/* receive the result: */
@@ -415,7 +415,7 @@ int line6_write_data(struct usb_line6 *line6, u16 address,
void *data,
return -EIO;
} else if (status != 0) {
dev_err(line6->ifcdev, "write failed (error %d)\n", ret);
- return -EINVAL;
+ return -EIO;
}
return 0;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] Cleanup reads/writes to Line 6 device memory
The primary fix here is to throttle the requests for status after a read or write operation. In some cases I was seeing more than 1000 before the device was ready with a response. The remainder are smaller improvements related to the read/write logic. All of this seems pretty straightforward with the possible exception of changing the returned error from EINVAL to EIO. The EINVAL seems wrong to me but maybe not? Regards, Chris Chris Rorvick (6): ALSA: line6: Improve line6_read/write_data() interfaces ALSA: line6: Add delay before reading status ALSA: line6: Return error if device not responding ALSA: line6: Return EIO if read/write not successful ALSA: line6: Use explicit type for serial number ALSA: line6: toneport: Use explicit type for firmware version sound/usb/line6/driver.c | 51 +- sound/usb/line6/driver.h | 10 - sound/usb/line6/pod.c | 4 ++-- sound/usb/line6/toneport.c | 4 ++-- 4 files changed, 46 insertions(+), 23 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ALSA: line6: Add delay before reading status
The device indicates the result of a read/write operation by making the
status available on a subsequent request from the driver. This is not
ready immediately, though, so the driver is currently slamming the
device with hundreds of pointless requests before getting the expected
response. Add a two millisecond delay before each attempt. This is
approximately the behavior observed with version 4.2.7.1 of the Windows
driver.
Signed-off-by: Chris Rorvick
---
sound/usb/line6/driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index aac1e35..222c14f 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -296,6 +296,8 @@ static void line6_data_received(struct urb *urb)
line6_start_listen(line6);
}
+#define LINE6_READ_WRITE_STATUS_DELAY 2 /* milliseconds */
+
/*
Read data from device.
*/
@@ -319,6 +321,8 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
void *data,
/* Wait for data length. We'll get 0xff until length arrives. */
do {
+ mdelay(LINE6_READ_WRITE_STATUS_DELAY);
+
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
@@ -376,6 +380,8 @@ int line6_write_data(struct usb_line6 *line6, u16 address,
void *data,
}
do {
+ mdelay(LINE6_READ_WRITE_STATUS_DELAY);
+
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ALSA: line6: Use explicit type for serial number
The serial number (aka ESN) is a 32-bit value.
Signed-off-by: Chris Rorvick
---
sound/usb/line6/driver.c | 2 +-
sound/usb/line6/driver.h | 2 +-
sound/usb/line6/pod.c | 4 ++--
sound/usb/line6/toneport.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index f8e2eb0..d31ceb8 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -426,7 +426,7 @@ EXPORT_SYMBOL_GPL(line6_write_data);
Read Line 6 device serial number.
(POD, TonePort, GuitarPort)
*/
-int line6_read_serial_number(struct usb_line6 *line6, int *serial_number)
+int line6_read_serial_number(struct usb_line6 *line6, u32 *serial_number)
{
return line6_read_data(line6, 0x80d0, serial_number,
sizeof(*serial_number));
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 603bdc4..b281bff 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -150,7 +150,7 @@ extern char *line6_alloc_sysex_buffer(struct usb_line6
*line6, int code1,
extern int line6_read_data(struct usb_line6 *line6, u16 address, void *data,
u8 datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
- int *serial_number);
+ u32 *serial_number);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/pod.c b/sound/usb/line6/pod.c
index c4246ad..425d22d 100644
--- a/sound/usb/line6/pod.c
+++ b/sound/usb/line6/pod.c
@@ -73,7 +73,7 @@ struct usb_line6_pod {
int startup_progress;
/* Serial number of device */
- int serial_number;
+ u32 serial_number;
/* Firmware version (x 100) */
int firmware_version;
@@ -247,7 +247,7 @@ static ssize_t serial_number_show(struct device *dev,
struct usb_interface *interface = to_usb_interface(dev);
struct usb_line6_pod *pod = usb_get_intfdata(interface);
- return sprintf(buf, "%d\n", pod->serial_number);
+ return sprintf(buf, "%u\n", pod->serial_number);
}
/*
diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
index 1a0a485..ddf7368 100644
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -49,7 +49,7 @@ struct usb_line6_toneport {
int source;
/* Serial number of device */
- int serial_number;
+ u32 serial_number;
/* Firmware version (x 100) */
int firmware_version;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ALSA: line6: Return error if device not responding
Put an upper bound on how long we will wait for the device to respond to
a read/write request (i.e., 100 milliseconds) and return an error if
this is reached.
Signed-off-by: Chris Rorvick
---
sound/usb/line6/driver.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 222c14f..2a33f3e 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -297,6 +297,7 @@ static void line6_data_received(struct urb *urb)
}
#define LINE6_READ_WRITE_STATUS_DELAY 2 /* milliseconds */
+#define LINE6_READ_WRITE_MAX_RETRIES 50
/*
Read data from device.
@@ -307,6 +308,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
void *data,
struct usb_device *usbdev = line6->usbdev;
int ret;
unsigned char len;
+ unsigned count;
/* query the serial number: */
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
@@ -320,7 +322,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
void *data,
}
/* Wait for data length. We'll get 0xff until length arrives. */
- do {
+ for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
mdelay(LINE6_READ_WRITE_STATUS_DELAY);
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
@@ -333,9 +335,16 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
void *data,
"receive length failed (error %d)\n", ret);
return ret;
}
- } while (len == 0xff);
- if (len != datalen) {
+ if (len != 0xff)
+ break;
+ }
+
+ if (len == 0xff) {
+ dev_err(line6->ifcdev, "read failed after %d retries\n",
+ count);
+ return -EIO;
+ } else if (len != datalen) {
/* should be equal or something went wrong */
dev_err(line6->ifcdev,
"length mismatch (expected %d, got %d)\n",
@@ -367,6 +376,7 @@ int line6_write_data(struct usb_line6 *line6, u16 address,
void *data,
struct usb_device *usbdev = line6->usbdev;
int ret;
unsigned char status;
+ int count;
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
@@ -379,7 +389,7 @@ int line6_write_data(struct usb_line6 *line6, u16 address,
void *data,
return ret;
}
- do {
+ for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
mdelay(LINE6_READ_WRITE_STATUS_DELAY);
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
@@ -394,9 +404,16 @@ int line6_write_data(struct usb_line6 *line6, u16 address,
void *data,
"receiving status failed (error %d)\n", ret);
return ret;
}
- } while (status == 0xff);
- if (status != 0) {
+ if (status != 0xff)
+ break;
+ }
+
+ if (status == 0xff) {
+ dev_err(line6->ifcdev, "write failed after %d retries\n",
+ count);
+ return -EIO;
+ } else if (status != 0) {
dev_err(line6->ifcdev, "write failed (error %d)\n", ret);
return -EINVAL;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ALSA: line6: toneport: Use explicit type for firmware version
The firmware version is a single byte so have the variable type agree.
Since the address to this member is passed to the read function, using
an int is not even portable.
Signed-off-by: Chris Rorvick
---
sound/usb/line6/toneport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
index ddf7368..6d4c50c 100644
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -52,7 +52,7 @@ struct usb_line6_toneport {
u32 serial_number;
/* Firmware version (x 100) */
- int firmware_version;
+ u8 firmware_version;
/* Timer for delayed PCM startup */
struct timer_list timer;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: of: pci: remove duplicate kfree in of_pci_get_host_bridge_resources
Commit d2be00c0fb5a ("of/pci: Free resources on failure in
of_pci_get_host_bridge_resources()") fixed the error code path in
of_pci_get_host_bridge_resources() by adding code that runs through the
resources list to free all resources in it and then calls kfree on the
bus_range resource pointer to complete the memory deallocation.
Since the bus_range resource is added to the resources list through
pci_add_resource, the resource_list_for_each_entry loop in the error
exit path frees it already and freeing it anew could trigger a double
free, hence this patch removes the superfluos kfree call on the bus_range
resource.
Fixes: d2be00c0fb5a ("of/pci: Free resources on failure in
of_pci_get_host_bridge_resources()")
Signed-off-by: Lorenzo Pieralisi
Reported-by: Jiang Liu
Cc: Bjorn Helgaas
Cc: Rafael J. Wysocki
---
drivers/of/of_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 110fece..62426d8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -229,7 +229,6 @@ parse_failed:
resource_list_for_each_entry(window, resources)
kfree(window->res);
pci_free_resource_list(resources);
- kfree(bus_range);
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
--
2.2.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] mtd:spi-nor: Add Altera EPCQ Driver
From: Viet Nga Dao
Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and
EPCS flash chips. This patch adds driver for these devices.
Signed-off-by: VIET NGA DAO
---
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
drivers/mtd/spi-nor/Kconfig| 12 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera_epcq.c | 507
drivers/mtd/spi-nor/altera_epcq.h | 116 +
drivers/mtd/spi-nor/spi-nor.c | 86 -
include/linux/mtd/spi-nor.h|3 +-
7 files changed, 764 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
create mode 100644 drivers/mtd/spi-nor/altera_epcq.c
create mode 100644 drivers/mtd/spi-nor/altera_epcq.h
diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
new file mode 100644
index 000..b6b5e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
@@ -0,0 +1,45 @@
+* MTD Altera EPCQ driver
+
+Required properties:
+- compatible: Should be "altr,epcq-1.0"
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ "csr_base": Should contain the register configuration base address
+ "data_base": Should contain the data base address
+- is-epcs: boolean type.
+If present, the device contains EPCS flashes.
+Otherwise, it contains EPCQ flashes.
+- #address-cells: Must be <1>.
+- #size-cells: Must be <0>.
+- flash device tree subnode, there must be a node with the following fields:
+- compatible: Should contain the flash name
+- #address-cells: please refer to /mtd/partition.txt
+- #size-cells: please refer to /mtd/partition.txt
+For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+epcq_controller_0: epcq@0x0 {
+compatible = "altr,epcq-1.0";
+reg = <0x0001 0x 0x0020>,
+<0x 0x 0x0200>;
+reg-names = "csr_base", "data_base";
+#address-cells = <1>;
+#size-cells = <0>;
+flash0: epcq256@0 {
+compatible = "epcq256";
+#address-cells = <1>;
+#size-cells = <1>;
+partition@0 {
+/* 16 MB for raw data. */
+label = "EPCQ Flash 0 raw data";
+reg = <0x0 0x100>;
+};
+partition@100 {
+/* 16 MB for jffs2 data. */
+label = "EPCQ Flash 0 JFFS 2";
+reg = <0x100 0x100>;
+};
+};
+}; //end epcq@0x0 (epcq_controller_0)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64a4f0e..83178b9 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -28,4 +28,16 @@ config SPI_FSL_QUADSPI
This enables support for the Quad SPI controller in master mode.
We only connect the NOR to this controller now.
+config SPI_ALTERA_EPCQ
+tristate "Support Altera EPCQ/EPCS Flash chips"
+depends on OF
+help
+ This enables access to Altera EPCQ/EPCS flash chips, used for data
+ storage. See the driver source for the current list,
+ or to add other chips.
+
+ If you want to compile this driver as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want),
+ say M here and read .
+
endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 6a7ce14..ff9437b 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
+obj-$(CONFIG_SPI_ALTERA_EPCQ)+= altera_epcq.o
diff --git a/drivers/mtd/spi-nor/altera_epcq.c
b/drivers/mtd/spi-nor/altera_epcq.c
new file mode 100644
index 000..9db0d05
--- /dev/null
+++ b/drivers/mtd/spi-nor/altera_epcq.c
@@ -0,0 +1,507 @@
+/*
+ * Copyright (C) 2014 Altera Corporation. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without
Re: linux-next: build failure after merge of the net-next tree
On Tue, 2015-02-10 at 22:02 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (i386
> allmodconfig and a few others) failed like this:
>
> drivers/net/ethernet/intel/i40e/i40e_txrx.c: In function
> 'i40e_setup_rx_descriptors':
> drivers/net/ethernet/intel/i40e/i40e_txrx.c:1101:3: error:
> incompatible type for argument 1 of '__seqcount_init'
> include/linux/seqlock.h:53:20: note: expected 'struct seqcount_t *'
> but argument is of type 'seqcount_t'
>
> Caused by commit 638702bd59a3 ("i40e/i40evf: Add call to
> u64_stats_init
> to init").
>
> Discovered after the release, so no fix done.
>
> The indentation of the lines added by that patch is also a bit
> strange.
Yeah, this was fixed with the follow on patch:
commit c07a213db1437a8fd40c328e6a2c426723caec65
Author: Carolyn Wyborny
Date: Tue Feb 10 07:33:15 2015 +
i40e: Fix for stats init function call in Rx setup
This patch fixes indentation issue and error found in argument
reported by static analysis. Without this patch, sparse and other
static analysis errors will be found.
Reported-by: Fengguang Wu
Reported-by: Julia Lawall
Signed-off-by: Carolyn Wyborny
Signed-off-by: Jeff Kirsher
signature.asc
Description: This is a digitally signed message part
Re: [RFC] pstore-ram: remove superfluous memory size check
On Tue, Feb 10, 2015 at 10:38 PM, Mark Salyzyn wrote:
>
> Please refer to '[PATCH v2 2/5] pstore: remove superfluous memory size check'
Cool,thanks for pointing.
Regards,
Kiran
>
> Sincerely -- Mark Salyzyn
>
> On 02/10/2015 02:26 AM, Kiran Raparthy wrote:
>>
>> From: Mark Salyzyn
>>
>> pstore-ram: remove superfluous memory size check
>>
>> All previous checks will fail with error if memory size
>> is not sufficient to register a zone, so this legacy
>> check has become redundant.
>>
>> Cc: Anton Vorontsov
>> Cc: Colin Cross
>> Cc: Kees Cook
>> Cc: Tony Luck
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Mark Salyzyn
>> [Kiran: Added Context]
>> Signed-off-by: Kiran Raparthy
>>
>> ---
>> This is one of the number of patches from the Android AOSP common.git tree,
>> which is used on Android devices. I wanted to submit it for review
>> to see if it should go upstream.
>> [PATCH v2 2/5] pstore: remove superfluous memory size check
>>
>> fs/pstore/ram.c | 9 -
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 8613e5b..34ed8f8 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -474,14 +474,6 @@ static int ramoops_probe(struct platform_device *pdev)
>> if (err)
>> goto fail_init_fprz;
>> - if (!cxt->przs && !cxt->cprz && !cxt->fprz) {
>> - pr_err("memory size too small, minimum is %zu\n",
>> - cxt->console_size + cxt->record_size +
>> - cxt->ftrace_size);
>> - err = -EINVAL;
>> - goto fail_cnt;
>> - }
>> -
>> cxt->pstore.data = cxt;
>> /*
>> * Console can handle any buffer size, so prefer LOG_LINE_MAX. If we
>> @@ -525,7 +517,6 @@ fail_buf:
>> kfree(cxt->pstore.buf);
>> fail_clear:
>> cxt->pstore.bufsize = 0;
>> -fail_cnt:
>> kfree(cxt->fprz);
>> fail_init_fprz:
>> kfree(cxt->cprz);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] slub: Support for array operations
On Tue, 10 Feb 2015 13:48:06 -0600 Christoph Lameter wrote:
> The major portions are there but there is no support yet for
> directly allocating per cpu objects. There could also be more
> sophisticated code to exploit the batch freeing.
>
> Signed-off-by: Christoph Lameter
>
[...]
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c
> +++ linux/mm/slub.c
[...]
> @@ -2516,8 +2521,78 @@ EXPORT_SYMBOL(kmem_cache_alloc_node_trac
> #endif
> #endif
>
> +int slab_array_alloc_from_partial(struct kmem_cache *s,
> + size_t nr, void **p)
> +{
> + void **end = p + nr;
> + struct kmem_cache_node *n = get_node(s, numa_mem_id());
> + int allocated = 0;
> + unsigned long flags;
> + struct page *page, *page2;
> +
> + if (!n->nr_partial)
> + return 0;
> +
> +
> + spin_lock_irqsave(>list_lock, flags);
This is quite an expensive lock with irqsave.
> + list_for_each_entry_safe(page, page2, >partial, lru) {
> + void *freelist;
> +
> + if (page->objects - page->inuse > end - p)
> + /* More objects free in page than we want */
> + break;
> + list_del(>lru);
> + slab_lock(page);
Yet another lock cost.
> + freelist = page->freelist;
> + page->inuse = page->objects;
> + page->freelist = NULL;
> + slab_unlock(page);
> + /* Grab all available objects */
> + while (freelist) {
> + *p++ = freelist;
> + freelist = get_freepointer(s, freelist);
> + allocated++;
> + }
> + }
> + spin_unlock_irqrestore(>list_lock, flags);
> + return allocated;
I estimate (on my CPU) the locking cost itself is more than 32ns, plus
the irqsave (which I've also found quite expensive, alone 14ns). Thus,
estimated 46ns. Single elem slub fast path cost is 18-19ns. Thus 3-4
elem bulking should be enough to amortized the cost, guess we are still
good :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: process_backlog interruptions with 3.10.47-rt50
On Tue, 2015-02-10 at 13:43 -0800, trevor_davenp...@selinc.com wrote: > I've recently encountered a problem after upgrading from 3.0.57-rt82 to > 3.10.47-rt50 where process_backlog gets interrupted and does not resume > for a while, which results in packets not being processed in time. I see > net_rx_action, which then calls process_backlog (as the poll method to > process the backlog of packets queued up the netif_rx) but then after the > interruption, it does not finish for about 5ms. In the older kernel it > would finish based on the priority of ksoftirqd. This is no longer the > case. > > I have priorities configured so that hard interrupts are highest, > ksoftirqd next (both are SCHED_FIFO) and then my program is currently > SCHED_OTHER but I still do not see the rx softirq finish before my program > runs. > > This is all on a single core powerpc device. I do not see these problems > with a net device which uses NAPI directly (as such i'm updating my driver > to use NAPI) but it seems like there is a real bug here somewhere. I have > not been able to find any mention of similar problems (perhaps few people > are using netif_rx these days). > > I've attached a recording from perf which shows the problem. Specifically, > you see net_rx_action run at time 213.079014 and then it doesn't finish > until about 5ms later at time 213.084953 which i not the case on the older > kernels. It seems something has changed with softirq handling or > process_backlog needed adapted for it. My suspicion is this has something > to do with the work mentioned in 210dc110063cf040d3209fddf766f6fcafccdc34 > but I'm not an expert with this area of the kernel. Your suspicion is correct. Your net traffic is being handled by your SCHED_OTHER database task, which lost the CPU for a while due to it being a SCHED_OTHER task. It's a behavior change from previous rt kernels, but not a bad one. At the rt mini-summit of whatever year that was, this change was shown to be a massive win. Low priority network traffic now won't hinder a high priority task getting to the CPU, and should a high priority task block due to your low priority task having been preempted while holding the sirq lock it wants, PI will kick in. -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 v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Tue, 10 Feb 2015 19:04:55 -0800
Alexei Starovoitov wrote:
> > You mean to be completely invisible to ftrace? And the debugfs/tracefs
> > directory?
>
> I mean it will be seen in tracefs to get 'id', but without
> enable/format/filter
In other words, invisible to ftrace. I'm not sure I'll be on board to
work with that.
> > Again, this would mean they become invisible to ftrace, and even
> > ftrace_dump_on_oops.
>
> yes, since these new tracepoints have no meat inside them.
> They're placeholders sitting idle and waiting for bpf to do
> something useful with them.
Hmm, I have a patch somewhere (never posted it), that add
TRACE_MARKER(), which basically would just print that it was hit. But
no data was passed to it. Something like that I would be more inclined
to take. Then the question is, what can bpf access there? Could just be
a place holder to add a "fast kprobe". This way, it can show up in
trace events with enable and and all that, it just wont have any data
to print out besides the normal pid, flags, etc.
But because it will inject a nop, that could be converted to a jump, it
will give you the power of kprobes but with the speed of a tracepoint.
>
> > I'm not fully understanding what is to be exported by this new ABI. If
> > the fields available, will always be available, then why can't the
> > appear in a TP_printk()?
>
> say, we define trace_netif_rx_entry() as this new tracepoint_bpf.
> It will have only one argument 'skb'.
> bpf program will read and print skb fields the way it likes
> for particular tracing scenario.
> So instead of making
> TP_printk("dev=%s napi_id=%#x queue_mapping=%u skbaddr=%p
> vlan_tagged=%d vlan_proto=0x%04x vlan_tci=0x%04x protocol=0x%04x
> ip_summed=%d hash=0x%08x l4_hash=%d len=%u data_len=%u truesize=%u
> mac_header_valid=%d mac_header=%d nr_frags=%d gso_size=%d
> gso_type=%#x",...
> the abi exposed via trace_pipe (as it is today),
> the new tracepoint_bpf abi is presence of 'skb' pointer as one
> and only argument to bpf program.
> Future refactoring of netif_rx would need to guarantee
> that trace_netif_rx_entry(skb) is called. that's it.
> imo such tracepoints are much easier to deal with during
> code changes.
But what can you access from that skb that is guaranteed to be there?
If you say anything, then there's no reason it can't be added to the
printk as well.
>
> May be some of the existing tracepoints like this one that
> takes one argument can be marked 'bpf-ready', so that
> programs can attach to them only.
I really hate the idea of adding tracepoints that ftrace can't use. It
basically kills the entire busy box usage scenario, as boards that have
extremely limited userspace still make full use of ftrace via the
existing tracepoints.
I still don't see the argument that adding data via the bpf functions
is any different than adding those same items to fields in an event.
Once you add a bpf function, then you must maintain those fields.
Look, you can always add more to a TP_printk(), as that is standard
with all text file kernel parsing. Like stat in /proc. Fields can not
be removed, but more can always be appended to the end.
Any tool that parses trace_pipe is broken if it can't handle extended
fields. The api can be extended, and for text files, that is by
appending to them.
-- 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/
[PATCH v3 1/2] coresight: Adding coresight support for arm64 architecture
From: Mathieu Poirier Most CoreSight blocks are 64-bit ready. As such move configuration entries from "arch/arm/Kconfig.config" to the driver's subdirectory and source the newly created Kconfig from architecture specific Kconfig.debug files. Signed-off-by: Mathieu Poirier --- Change for v3: - Separating Kconfig work from compilation warnings fixes. --- arch/arm/Kconfig.debug| 55 +- arch/arm64/Kconfig.debug | 2 ++ drivers/coresight/Kconfig | 61 +++ 3 files changed, 64 insertions(+), 54 deletions(-) create mode 100644 drivers/coresight/Kconfig diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 5ddd4906f7a7..4fdbb0c012e6 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1478,59 +1478,6 @@ config DEBUG_SET_MODULE_RONX against certain classes of kernel exploits. If in doubt, say "N". -menuconfig CORESIGHT - bool "CoreSight Tracing Support" - select ARM_AMBA - help - This framework provides a kernel interface for the CoreSight debug - and trace drivers to register themselves with. It's intended to build - a topological view of the CoreSight components based on a DT - specification and configure the right serie of components when a - trace source gets enabled. - -if CORESIGHT -config CORESIGHT_LINKS_AND_SINKS - bool "CoreSight Link and Sink drivers" - help - This enables support for CoreSight link and sink drivers that are - responsible for transporting and collecting the trace data - respectively. Link and sinks are dynamically aggregated with a trace - entity at run time to form a complete trace path. - -config CORESIGHT_LINK_AND_SINK_TMC - bool "Coresight generic TMC driver" - depends on CORESIGHT_LINKS_AND_SINKS - help - This enables support for the Trace Memory Controller driver. Depending - on its configuration the device can act as a link (embedded trace router - - ETR) or sink (embedded trace FIFO). The driver complies with the - generic implementation of the component without special enhancement or - added features. - -config CORESIGHT_SINK_TPIU - bool "Coresight generic TPIU driver" - depends on CORESIGHT_LINKS_AND_SINKS - help - This enables support for the Trace Port Interface Unit driver, responsible - for bridging the gap between the on-chip coresight components and a trace - port collection engine, typically connected to an external host for use - case capturing more traces than the on-board coresight memory can handle. - -config CORESIGHT_SINK_ETBV10 - bool "Coresight ETBv1.0 driver" - depends on CORESIGHT_LINKS_AND_SINKS - help - This enables support for the Embedded Trace Buffer version 1.0 driver - that complies with the generic implementation of the component without - special enhancement or added features. +source "drivers/coresight/Kconfig" -config CORESIGHT_SOURCE_ETM3X - bool "CoreSight Embedded Trace Macrocell 3.x driver" - select CORESIGHT_LINKS_AND_SINKS - help - This driver provides support for processor ETM3.x and PTM1.x modules, - which allows tracing the instructions that a processor is executing - This is primarily useful for instruction level tracing. Depending - the ETM version data tracing may also be available. -endif endmenu diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug index 5fdd6dce8061..650e46056c55 100644 --- a/arch/arm64/Kconfig.debug +++ b/arch/arm64/Kconfig.debug @@ -66,4 +66,6 @@ config DEBUG_SET_MODULE_RONX against certain classes of kernel exploits. If in doubt, say "N". +source "drivers/coresight/Kconfig" + endmenu diff --git a/drivers/coresight/Kconfig b/drivers/coresight/Kconfig new file mode 100644 index ..fc1f1ae7a49d --- /dev/null +++ b/drivers/coresight/Kconfig @@ -0,0 +1,61 @@ +# +# Coresight configuration +# +menuconfig CORESIGHT + bool "CoreSight Tracing Support" + select ARM_AMBA + help + This framework provides a kernel interface for the CoreSight debug + and trace drivers to register themselves with. It's intended to build + a topological view of the CoreSight components based on a DT + specification and configure the right serie of components when a + trace source gets enabled. + +if CORESIGHT +config CORESIGHT_LINKS_AND_SINKS + bool "CoreSight Link and Sink drivers" + help + This enables support for CoreSight link and sink drivers that are + responsible for transporting and collecting the trace data + respectively. Link and sinks are dynamically aggregated with a trace + entity at run time to form a complete trace path. + +config
[PATCH v3 2/2] coresight: fixing compilation warnings picked up by 64bit compiler
From: Mathieu Poirier Compiling coresight drivers with a 64-bit compiler highlights a couple of formatting issues, which are fixed by this patch. Signed-off-by: Mathieu Poirier --- Changes for v3: - Splitting Kconfig work from compilation warnings fixes. --- drivers/coresight/coresight-etb10.c | 4 ++-- drivers/coresight/coresight-tmc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/coresight/coresight-etb10.c b/drivers/coresight/coresight-etb10.c index c9acd406f0d0..40049869aecd 100644 --- a/drivers/coresight/coresight-etb10.c +++ b/drivers/coresight/coresight-etb10.c @@ -313,8 +313,8 @@ static ssize_t etb_read(struct file *file, char __user *data, *ppos += len; - dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n", - __func__, len, (int) (depth * 4 - *ppos)); + dev_dbg(drvdata->dev, "%s: %zu bytes copied, %d bytes left\n", + __func__, len, (int)(depth * 4 - *ppos)); return len; } diff --git a/drivers/coresight/coresight-tmc.c b/drivers/coresight/coresight-tmc.c index 3ff232f9ddf7..030e097c4fb2 100644 --- a/drivers/coresight/coresight-tmc.c +++ b/drivers/coresight/coresight-tmc.c @@ -533,8 +533,8 @@ static ssize_t tmc_read(struct file *file, char __user *data, size_t len, *ppos += len; - dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n", - __func__, len, (int) (drvdata->size - *ppos)); + dev_dbg(drvdata->dev, "%s: %zu bytes copied, %d bytes left\n", + __func__, len, (int)(drvdata->size - *ppos)); return len; } -- 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: doubt about sm7xxfb
On Tue, Feb 10, 2015 at 07:37:47PM +0530, Sudip Mukherjee wrote: > Hi Greg, > we have this sm7xxfb in drivers/staging now which is supporting SM710, > SM712, SM721 and SM722. I am also working on another new hardware > SM750, which will be ready for staging in next 1 -2 weeks. > this SM750 is entirely different hardware and these two drivers will > have nothing in common. Then make a new driver! But why would a new driver go into staging? Anything new you create should just go into the "correct" part of the kernel. Don't waste your time on staging. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
Quoting Tejun Heo (t...@kernel.org): > On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote: > > 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used > > to start with 1. I expect many userspace parsers to be broken by this. > > This is intentional. The unified hierarchy will always have the > hierarchy number zero. Userland needs to be updated anyway and the > unified hierarchy won't show up unless explicitly enabled. > > > 2. After creating every non-leaf cgroup, we must fill in the > > cgroup.subtree_cgroups file. This is extra work which userspace > > doesn't have to do right now. > > Again, by design. This is how organization and control are separated > and the differing levels of granularity is achieved. > > > 3. Let's say we want to create a freezer cgroup /foo/bar for some set of > > There shouldn't be a "freezer" cgroup. The processes are categorized > according to their logical structure and controllers are applied to > the hierarchy as necessary. But there can well be cgroups for which only freezer is enabled. If I'm wrong about that, then I am suffering a fundamental misunderstanding. > > tasks, which they will administer. In fact let's assume we are going to > > use cgroup namespaces. We have to put the tasks into /foo/bar, unshare > > the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf, > > and then write 'freezer' into /foo/bar. (If we're not using cgroup > > namespaces, then we have to do a similar thing to let the tasks administer > > /foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing > > to is where the tasks have to know that they can create cgroups in "..". > > > > For containers this becomes odd. We tend to group containers by the > > tasks in and under a cgroup. We now will have to assume a convention > > where we know to check for tasks in and under "..", since by definition > > pid 1's cgroup (in a container) cannot have children. > > The semantics is that the parent enables distribution of its given > type of resource by enabling the controller in its subtree_control. > This scoping isn't necessary for freezer and I'm debating whether to > enable controllers which don't need granularity control to be enabled > unconditionally. Right now, I'm leaning against it mostly for > consistency. Yeah, IIUC (i.e. freezer would always be enabled?) that would be even-more-confusing. > > 4. The per-cgroup "tasks" file not existing seems odd, although certainly > > unexpected by much current software. > > And, yes, everything is per-process for reasons described in > unified-hierarchy.txt. > > > So, if the unified hierarchy is going to not cause undue pain, existing > > software really needs to start working now to use it. It's going to be > > a sizeable task for lxc. > > Yes, this isn't gonna be a trivial conversion. The usage model > changes and so will a lot of controller knobs and behaviors. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] kprobes: x86: mark 2 bytes NOP as boostable.
Hi Andrew,
Could you please queue this patch onto your -mm tree? Masami has given an
Acked-by already.
Thank you!
On 2015/2/10 9:34, Wang Nan wrote:
> Currently, x86 kprobes is unable to boost 2 bytes nop like:
>
> nopl 0x0(%rax,%rax,1)
>
> which is 0x0f 0x1f 0x44 0x00 0x00.
>
> Such nops have exactly 5 bytes to hold a relative jmp instruction.
> Boosting them should be obviously safe.
>
> This patch enable boosting such nops by simply updating
> twobyte_is_boostable[] array.
>
> Signed-off-by: Wang Nan
> Acked-by: Masami Hiramatsu
> ---
> arch/x86/kernel/kprobes/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 98f654d..6a1146e 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -84,7 +84,7 @@ static volatile u32 twobyte_is_boostable[256 / 32] = {
> /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> /* -- */
> W(0x00, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0) | /* 00 */
> - W(0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) , /* 10 */
> + W(0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1) , /* 10 */
> W(0x20, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) | /* 20 */
> W(0x30, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) , /* 30 */
> W(0x40, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 40 */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.18 04/57] vm: add VM_FAULT_SIGSEGV handling support
On Tue, Feb 10, 2015 at 07:49:27PM -0800, Linus Torvalds wrote: > On Tue, Feb 10, 2015 at 7:43 PM, Greg Kroah-Hartman > wrote: > > > > Ah, nice, I missed that one. > > Ugh, to be fair, I missed it too. > > The alternative to backporting 7fb08eca4527 is to make the backport of > commit 33692f27597f use "bad_area()" instead of > "bad_area_nosemaphore()". 33692f27597f already showed up in 3.18.6, so I can't go back and change that version :( I'll just queue this one up, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/6] toshiba_acpi: Add new features plus some procfs ports
These patches add five new files to sysfs. With the first two files we are paving the way to the (hopefully) future removal of the (now deprecated) proc entries. The remaining entries were not ported due to the fact that they duplicate existing kernel functionality (eg.: lcd <-> backlight, keys <-> input). The rest add support for new features found on recent Toshiba laptops. And the last one simply bump up the driver version. Changes since v1: - Added a pr_info message informing the user that the laptop needs to reboot Azael Avalos (6): toshiba_acpi: Add version entry to sysfs toshiba_acpi: Add fan entry to sysfs toshiba_acpi: Add support for Keyboard functions mode toshiba_acpi: Add support for Panel Power ON toshiba_acpi: Add support to enable/disable USB 3 toshiba_acpi: Bump version number to 0.21 drivers/platform/x86/toshiba_acpi.c | 370 +++- 1 file changed, 366 insertions(+), 4 deletions(-) -- 2.2.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 2/6] toshiba_acpi: Add fan entry to sysfs
This patch adds a fan entry to sysfs, enabling the user to get and
set the fan status.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 334b65e..413af60 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1516,6 +1516,11 @@ static const struct backlight_ops toshiba_backlight_data
= {
*/
static ssize_t toshiba_version_show(struct device *dev,
struct device_attribute *attr, char *buf);
+static ssize_t toshiba_fan_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count);
+static ssize_t toshiba_fan_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
@@ -1569,6 +1574,8 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
+static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
+ toshiba_fan_show, toshiba_fan_store);
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
@@ -1594,6 +1601,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
+ _attr_fan.attr,
_attr_kbd_backlight_mode.attr,
_attr_kbd_type.attr,
_attr_available_kbd_modes.attr,
@@ -1621,6 +1629,45 @@ static ssize_t toshiba_version_show(struct device *dev,
return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
}
+static ssize_t toshiba_fan_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 result;
+ int state;
+ int ret;
+
+ ret = kstrtoint(buf, 0, );
+ if (ret)
+ return ret;
+
+ if (state != 0 && state != 1)
+ return -EINVAL;
+
+ result = hci_write1(toshiba, HCI_FAN, state);
+ if (result == TOS_FAILURE)
+ return -EIO;
+ else if (result == TOS_NOT_SUPPORTED)
+ return -ENODEV;
+
+ return count;
+}
+
+static ssize_t toshiba_fan_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 value;
+ int ret;
+
+ ret = get_fan_status(toshiba, );
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%d\n", value);
+}
+
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -2017,7 +2064,9 @@ static umode_t toshiba_sysfs_is_visible(struct kobject
*kobj,
struct toshiba_acpi_dev *drv = dev_get_drvdata(dev);
bool exists = true;
- if (attr == _attr_kbd_backlight_mode.attr)
+ if (attr == _attr_fan.attr)
+ exists = (drv->fan_supported) ? true : false;
+ else if (attr == _attr_kbd_backlight_mode.attr)
exists = (drv->kbd_illum_supported) ? true : false;
else if (attr == _attr_kbd_backlight_timeout.attr)
exists = (drv->kbd_mode == SCI_KBD_MODE_AUTO) ? true : false;
--
2.2.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 3/6] toshiba_acpi: Add support for Keyboard functions mode
Recent Toshiba laptops that come with the new keyboard layout have
the Special Functions (hotkeys) enabled by default, which, in order to
access the F{1-12} keys, you need to press the FN-F{1-12} key to
access such key.
This patch adds support to toggle the Keyboard Functions operation
mode by creating the sysfs entry "kbd_functions_keys", accepting only
two parameters, 0 to set the "Normal Operation" mode and 1 to set the
"Special Functions" mode, however, everytime the mode is toggled, a
restart is needed.
In the "Normal Operation" mode, the F{1-12} keys are as usual and
the hotkeys are accessed via FN-F{1-12}.
In the "Special Functions" mode, the F{1-12} keys trigger the hotkey
and the F{1-12} keys are accessed via FN-F{1-12}.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 100
1 file changed, 100 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 413af60..13b4a2b 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -126,6 +126,7 @@ MODULE_LICENSE("GPL");
#define SCI_KBD_ILLUM_STATUS 0x015c
#define SCI_USB_SLEEP_MUSIC0x015e
#define SCI_TOUCHPAD 0x050e
+#define SCI_KBD_FUNCTION_KEYS 0x0522
/* field definitions */
#define HCI_ACCEL_MASK 0x7fff
@@ -192,6 +193,7 @@ struct toshiba_acpi_dev {
unsigned int usb_sleep_charge_supported:1;
unsigned int usb_rapid_charge_supported:1;
unsigned int usb_sleep_music_supported:1;
+ unsigned int kbd_function_keys_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -988,6 +990,47 @@ static int toshiba_usb_sleep_music_set(struct
toshiba_acpi_dev *dev, u32 state)
return 0;
}
+/* Keyboard function keys */
+static int toshiba_function_keys_get(struct toshiba_acpi_dev *dev, u32 *mode)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_KBD_FUNCTION_KEYS, mode);
+ sci_close(dev);
+ if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
+ pr_err("ACPI call to get KBD function keys failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("KBD function keys not supported\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_function_keys_set(struct toshiba_acpi_dev *dev, u32 mode)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_KBD_FUNCTION_KEYS, mode);
+ sci_close(dev);
+ if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
+ pr_err("ACPI call to set KBD function keys failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("KBD function keys not supported\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1572,6 +1615,12 @@ static ssize_t toshiba_usb_sleep_music_show(struct
device *dev,
static ssize_t toshiba_usb_sleep_music_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_kbd_function_keys_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_kbd_function_keys_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1598,6 +1647,9 @@ static DEVICE_ATTR(usb_rapid_charge, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
toshiba_usb_sleep_music_show,
toshiba_usb_sleep_music_store);
+static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
+ toshiba_kbd_function_keys_show,
+ toshiba_kbd_function_keys_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1612,6 +1664,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_sleep_functions_on_battery.attr,
_attr_usb_rapid_charge.attr,
_attr_usb_sleep_music.attr,
+ _attr_kbd_function_keys.attr,
NULL,
};
@@ -2057,6 +2110,48 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_kbd_function_keys_show(struct device *dev,
+ struct
Re: [GIT] Networking
On Tue, Feb 10, 2015 at 8:02 PM, Al Viro wrote: > > Anyway, what userland do you have? I have regular Fedora 21, nothing special. I'm *assuming* that the thing that triggers this is that I use disk encryption on this machine, as that's the only even remotely unusual thing that isn't just a bog-standard "default install"). The kernel oops happens basically immediately after I've typed in my decryption key. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] toshiba_acpi: Add support for Panel Power ON
Toshiba laptops come with a feature called "Panel Open - Power ON",
which makes the laptop turn on whenever the LID is opened.
This patch adds support for such feature, by creating a sysfs entry
named "panel_power_on", accepting only two values, 0 to disable and
1 to enable such feature, however, a reboot is needed on every mode
change.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 100
1 file changed, 100 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 13b4a2b..41f58f2 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -121,6 +121,7 @@ MODULE_LICENSE("GPL");
#define HCI_KBD_ILLUMINATION 0x0095
#define HCI_ECO_MODE 0x0097
#define HCI_ACCELEROMETER2 0x00a6
+#define SCI_PANEL_POWER_ON 0x010d
#define SCI_ILLUMINATION 0x014e
#define SCI_USB_SLEEP_CHARGE 0x0150
#define SCI_KBD_ILLUM_STATUS 0x015c
@@ -194,6 +195,7 @@ struct toshiba_acpi_dev {
unsigned int usb_rapid_charge_supported:1;
unsigned int usb_sleep_music_supported:1;
unsigned int kbd_function_keys_supported:1;
+ unsigned int panel_power_on_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -1031,6 +1033,51 @@ static int toshiba_function_keys_set(struct
toshiba_acpi_dev *dev, u32 mode)
return 0;
}
+/* Panel Power ON */
+static int toshiba_panel_power_on_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_PANEL_POWER_ON, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to get Panel Power ON failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("Panel Power on not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int toshiba_panel_power_on_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_PANEL_POWER_ON, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to set Panel Power ON failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("Panel Power ON not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1621,6 +1668,12 @@ static ssize_t toshiba_kbd_function_keys_show(struct
device *dev,
static ssize_t toshiba_kbd_function_keys_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_panel_power_on_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_panel_power_on_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1650,6 +1703,9 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
toshiba_kbd_function_keys_show,
toshiba_kbd_function_keys_store);
+static DEVICE_ATTR(panel_power_on, S_IRUGO | S_IWUSR,
+ toshiba_panel_power_on_show,
+ toshiba_panel_power_on_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1665,6 +1721,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_usb_rapid_charge.attr,
_attr_usb_sleep_music.attr,
_attr_kbd_function_keys.attr,
+ _attr_panel_power_on.attr,
NULL,
};
@@ -2152,6 +2209,44 @@ static ssize_t toshiba_kbd_function_keys_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_panel_power_on_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_panel_power_on_get(toshiba, );
+ if (ret < 0)
+ return ret;
+
+
Re: [GIT] Networking
On Wed, Feb 11, 2015 at 04:01:13AM +, Al Viro wrote: > I hoped LTP would have them, but it doesn't ;-/ The best I'd been able to > find had been in libkcapi, modulo bunch of > let result=($result + 1) > (in a bash script; ... which I'd been running with sh test.sh ;-/ I really need more coffee... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/6] toshiba_acpi: Add version entry to sysfs
This patch adds a new entry to the sysfs, showing the version of the
driver.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 4e8a8cf..334b65e 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1514,6 +1514,8 @@ static const struct backlight_ops toshiba_backlight_data
= {
/*
* Sysfs files
*/
+static ssize_t toshiba_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
@@ -1566,6 +1568,7 @@ static ssize_t toshiba_usb_sleep_music_store(struct
device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_type, S_IRUGO, toshiba_kbd_type_show, NULL);
@@ -1590,6 +1593,7 @@ static DEVICE_ATTR(usb_sleep_music, S_IRUGO | S_IWUSR,
toshiba_usb_sleep_music_store);
static struct attribute *toshiba_attributes[] = {
+ _attr_version.attr,
_attr_kbd_backlight_mode.attr,
_attr_kbd_type.attr,
_attr_available_kbd_modes.attr,
@@ -1611,6 +1615,12 @@ static struct attribute_group toshiba_attr_group = {
.attrs = toshiba_attributes,
};
+static ssize_t toshiba_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%s\n", TOSHIBA_ACPI_VERSION);
+}
+
static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
--
2.2.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: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote: > 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used > to start with 1. I expect many userspace parsers to be broken by this. This is intentional. The unified hierarchy will always have the hierarchy number zero. Userland needs to be updated anyway and the unified hierarchy won't show up unless explicitly enabled. > 2. After creating every non-leaf cgroup, we must fill in the > cgroup.subtree_cgroups file. This is extra work which userspace > doesn't have to do right now. Again, by design. This is how organization and control are separated and the differing levels of granularity is achieved. > 3. Let's say we want to create a freezer cgroup /foo/bar for some set of There shouldn't be a "freezer" cgroup. The processes are categorized according to their logical structure and controllers are applied to the hierarchy as necessary. > tasks, which they will administer. In fact let's assume we are going to > use cgroup namespaces. We have to put the tasks into /foo/bar, unshare > the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf, > and then write 'freezer' into /foo/bar. (If we're not using cgroup > namespaces, then we have to do a similar thing to let the tasks administer > /foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing > to is where the tasks have to know that they can create cgroups in "..". > > For containers this becomes odd. We tend to group containers by the > tasks in and under a cgroup. We now will have to assume a convention > where we know to check for tasks in and under "..", since by definition > pid 1's cgroup (in a container) cannot have children. The semantics is that the parent enables distribution of its given type of resource by enabling the controller in its subtree_control. This scoping isn't necessary for freezer and I'm debating whether to enable controllers which don't need granularity control to be enabled unconditionally. Right now, I'm leaning against it mostly for consistency. > 4. The per-cgroup "tasks" file not existing seems odd, although certainly > unexpected by much current software. And, yes, everything is per-process for reasons described in unified-hierarchy.txt. > So, if the unified hierarchy is going to not cause undue pain, existing > software really needs to start working now to use it. It's going to be > a sizeable task for lxc. Yes, this isn't gonna be a trivial conversion. The usage model changes and so will a lot of controller knobs and behaviors. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] toshiba_acpi: Add support to enable/disable USB 3
Toshiba laptops that come with USB 3 ports have a feature that lets
them disable USB 3 functionality and act as a regular USB 2 port, and
thus, saving power.
This patch adds support to that feature, by creating a sysfs entry
named "usb_three", acceptig only two parameters, 0 to disable the
USB 3 (acting as a USB 2) and 1 to enable it, however, a reboot is
needed everytime this is toggled.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 103
1 file changed, 103 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 41f58f2..09921de 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -126,6 +126,7 @@ MODULE_LICENSE("GPL");
#define SCI_USB_SLEEP_CHARGE 0x0150
#define SCI_KBD_ILLUM_STATUS 0x015c
#define SCI_USB_SLEEP_MUSIC0x015e
+#define SCI_USB_THREE 0x0169
#define SCI_TOUCHPAD 0x050e
#define SCI_KBD_FUNCTION_KEYS 0x0522
@@ -196,6 +197,7 @@ struct toshiba_acpi_dev {
unsigned int usb_sleep_music_supported:1;
unsigned int kbd_function_keys_supported:1;
unsigned int panel_power_on_supported:1;
+ unsigned int usb_three_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -1078,6 +1080,51 @@ static int toshiba_panel_power_on_set(struct
toshiba_acpi_dev *dev, u32 state)
return 0;
}
+/* USB Three */
+static int toshiba_usb_three_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_read(dev, SCI_USB_THREE, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to get USB 3 failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("USB 3 not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int toshiba_usb_three_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ result = sci_write(dev, SCI_USB_THREE, state);
+ sci_close(dev);
+ if (result == TOS_FAILURE) {
+ pr_err("ACPI call to set USB 3 failed\n");
+ return -EIO;
+ } else if (result == TOS_NOT_SUPPORTED) {
+ pr_info("USB 3 not supported\n");
+ return -ENODEV;
+ } else if (result == TOS_INPUT_DATA_ERROR) {
+ return -EIO;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1674,6 +1721,12 @@ static ssize_t toshiba_panel_power_on_show(struct device
*dev,
static ssize_t toshiba_panel_power_on_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
+static ssize_t toshiba_usb_three_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+static ssize_t toshiba_usb_three_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
static DEVICE_ATTR(version, S_IRUGO, toshiba_version_show, NULL);
static DEVICE_ATTR(fan, S_IRUGO | S_IWUSR,
@@ -1706,6 +1759,8 @@ static DEVICE_ATTR(kbd_function_keys, S_IRUGO | S_IWUSR,
static DEVICE_ATTR(panel_power_on, S_IRUGO | S_IWUSR,
toshiba_panel_power_on_show,
toshiba_panel_power_on_store);
+static DEVICE_ATTR(usb_three, S_IRUGO | S_IWUSR,
+ toshiba_usb_three_show, toshiba_usb_three_store);
static struct attribute *toshiba_attributes[] = {
_attr_version.attr,
@@ -1722,6 +1777,7 @@ static struct attribute *toshiba_attributes[] = {
_attr_usb_sleep_music.attr,
_attr_kbd_function_keys.attr,
_attr_panel_power_on.attr,
+ _attr_usb_three.attr,
NULL,
};
@@ -2247,6 +2303,48 @@ static ssize_t toshiba_panel_power_on_store(struct
device *dev,
return count;
}
+static ssize_t toshiba_usb_three_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_usb_three_get(toshiba, );
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%d\n", state);
+}
+
+static ssize_t toshiba_usb_three_store(struct device *dev,
+ struct device_attribute *attr,
+
[PATCH v2 6/6] toshiba_acpi: Bump version number to 0.21
Several new features were added on previous patches, so lets bump up the driver version. And also, update the copyright year. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 09921de..52e4647 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -5,7 +5,7 @@ * Copyright (C) 2002-2004 John Belmonte * Copyright (C) 2008 Philip Langdale * Copyright (C) 2010 Pierre Ducroquet - * Copyright (C) 2014 Azael Avalos + * Copyright (C) 2014-2015 Azael Avalos * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -38,7 +38,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define TOSHIBA_ACPI_VERSION "0.20" +#define TOSHIBA_ACPI_VERSION "0.21" #define PROC_INTERFACE_VERSION 1 #include -- 2.2.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/
[LKP] [ipmi] d9b7e4f717a: +52.5% turbostat.%Busy
FYI, we noticed the below changes on
commit d9b7e4f717a167610a49ceb9e5969e80146c89a8 ("ipmi: Periodically check to
see if irqs and messages are set right")
testbox/testcase/testparams: avoton3/idle/performance-10m
6a11e5c67a397e9a d9b7e4f717a167610a49ceb9e5
--
%stddev %change %stddev
\ |\
0.10 ± 0% +52.5% 0.15 ± 2% turbostat.%Busy
2 ± 0% +50.0% 3 ± 0% turbostat.Avg_MHz
turbostat.%Busy
0.2 ++O-O+
||
0.18 ++ |
||
||
0.16 ++ O O O O O O O O O O O O O O |
O O O O OO O O |
0.14 ++ |
||
0.12 ++*.* * |
| .. + : + |
| .* + : +|
0.1 *+ *.. .*.*.. .*..**..*..*.*..*..*..*.*..*..*..*.*..*..*
| *. *. |
0.08 ++---+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
---
testcase: idle
default-monitors:
latency_stats:
interrupts:
softirqs:
cpuidle:
turbostat:
pmeter:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor: performance
commit: f876f0cff6d460f03cd937104314f366dfa92261
model: Avoton
memory: 8G
hdd_partitions: "/dev/disk/by-id/ata-ST9250610NS_9XE0BSWH-part2"
swap_partitions:
rootfs_partition: "/dev/disk/by-id/ata-ST9250610NS_9XE0BSWH-part1"
user: wfg
rootfs: debian-x86_64-2015-02-07.cgz
pmeter_server: lkp-wildcat
pmeter_device: yokogawa-wt310
stop_daemons:
sleep: 10m
testbox: avoton3
tbox_group: avoton3
kconfig: x86_64-rhel
enqueue_time: 2015-02-07 15:27:31.085931347 +08:00
head_commit: f876f0cff6d460f03cd937104314f366dfa92261
base_commit: e36f014edff70fc02b3d3d79cead1d58f289332e
branch: linux-devel/devel-hourly-2015020522
kernel:
"/kernel/x86_64-rhel/f876f0cff6d460f03cd937104314f366dfa92261/vmlinuz-3.19.0-rc7-gf876f0c"
queue: cyclic
result_root:
"/result/avoton3/idle/performance-10m/debian-x86_64-2015-02-07.cgz/x86_64-rhel/f876f0cff6d460f03cd937104314f366dfa92261/0"
job_file:
"/lkp/scheduled/avoton3/cyclic_idle-performance-10m-debian-x86_64.cgz-x86_64-rhel-HEAD-f876f0cff6d460f03cd937104314f366dfa92261-0-20150207-95893-1i1o2km.yaml"
dequeue_time: 2015-02-07 15:47:35.590497559 +08:00
nr_cpu: "$(nproc)"
job_state: finished
loadavg: 0.00 0.04 0.05 1/93 680
start_time: '1423295378'
end_time: '1423295978'
version: "/lkp/wfg/.src-20150207-125134"
___
LKP mailing list
l...@linux.intel.com
[PATCH] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup
panic.
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:
de57b950 6113
[59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
df4bbcd0
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
6133
[59014.085233] [] (__irq_svc+0x3b/0x5c) from []
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
[] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
[] (tasklet_action+0x3b/0x98)
[59014.134132] [] (tasklet_action+0x3b/0x98) from []
(__do_softirq+0x99/0x16c)
[59014.147784] [] (__do_softirq+0x99/0x16c) from []
(irq_exit+0x5b/0x5c)
[59014.160653] [] (irq_exit+0x5b/0x5c) from []
(handle_IRQ+0x37/0x78)
[59014.173124] [] (handle_IRQ+0x37/0x78) from []
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
[](__irq_svc+0x3b/0x5c)
This bug can be see with low performance board, such as uniprocessor beagle
bone board. Add some debug message in the ath9k_hif_usb_rx_cb
function may trigger this bug quickly.
Signed-off-by: Yuwei Zheng
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 78 +++---
drivers/net/wireless/ath/ath9k/hif_usb.h | 13 +
drivers/net/wireless/ath/ath9k/htc.h | 19 +++
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 58 +++
5 files changed, 214 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..2e73e19 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
int ret;
+ int delay;
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb->actual_length != 0)) {
skb_put(skb, urb->actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,23 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
- usb_anchor_urb(urb, _dev->rx_submitted);
- ret = usb_submit_urb(urb, GFP_ATOMIC);
- if (ret) {
- usb_unanchor_urb(urb);
- goto free;
+ spin_lock(_dev->aurfc_lock);
+ /* submit the urb more slowly for flow control */
+ if (atomic_read(_dev->aurfc_submit_delay) > 0 &&
+ hif_dev->aurfc_active == 1) {
+ usb_anchor_urb(urb, _dev->rx_delayed_submitted);
+ delay = atomic_read(_dev->aurfc_submit_delay);
+ schedule_delayed_work(_dev->aurfc_delayed_work,
+ msecs_to_jiffies(delay));
+ spin_unlock(_dev->aurfc_lock);
+ } else {
+ spin_unlock(_dev->aurfc_lock);
+ usb_anchor_urb(urb, _dev->rx_submitted);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret) {
+ usb_unanchor_urb(urb);
+ goto free;
+ }
}
return;
@@ -818,9 +829,53 @@ err:
return -ENOMEM;
}
+static void aurfc_submit_handler(struct work_struct *work)
+{
+ struct hif_device_usb *hif_dev =
+ container_of(work,
+struct hif_device_usb,
+aurfc_delayed_work.work);
+ struct urb *urb = NULL;
+ struct sk_buff *skb = NULL;
+ int ret;
+ int loop_times = 0;
+
+ AURFC_STAT_INC(aurfc_called);
+ while (true) {
+ loop_times++;
+ if (loop_times > MAX_RX_URB_NUM)
+ atomic_add(AURFC_STEP,
+ _dev->aurfc_submit_delay);
+
+ urb = usb_get_from_anchor(
+ _dev->rx_delayed_submitted);
+
Re: [GIT] Networking
On Tue, Feb 10, 2015 at 07:58:22PM -0800, Linus Torvalds wrote: > On Tue, Feb 10, 2015 at 6:01 PM, Linus Torvalds > wrote: > > > > Are there no tests for that crypto interface? > > Oh well. > > With the attached, it at least does boot and work for me. Heh... Looks like your variant is identical to mine, including the "let's move the assignment to 'used' past that 'maybe we need to wait' thing"... Anyway, what userland do you have? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Tue, Feb 10, 2015 at 06:01:32PM -0800, Linus Torvalds wrote:
> On Tue, Feb 10, 2015 at 5:45 PM, Al Viro wrote:
> >
> > Could you check if
> >
> > diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> > index eb78fe8..5b11d64 100644
> > --- a/crypto/af_alg.c
> > +++ b/crypto/af_alg.c
> > @@ -348,7 +348,7 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct
> > iov_iter *iter, int len)
> > if (n < 0)
> > return n;
> >
> > - npages = PAGE_ALIGN(off + n);
> > + npages = DIV_ROUND_UP(off + n, PAGE_SIZE);
> > if (WARN_ON(npages == 0))
> > return -EINVAL;
> >
> > on top of what went into Dave's tree is enough to fix what you are seeing?
>
> So quite frankly, considering that we already know that 'used' was
> also calculated wrong (it stays at zero) and that the one-liner above
> is not sufficient on its own, by now I'd like somebody with an actual
> test-case to check this thing out., and send me a proper tested patch.
> That somebody preferably being you.
>
> Are there no tests for that crypto interface?
I hoped LTP would have them, but it doesn't ;-/ The best I'd been able to
find had been in libkcapi, modulo bunch of
let result=($result + 1)
(in a bash script; replacing with result=$(($result+1)) has dealt with that)
and algif-aead module it supplies and wants to test.
It reproduces the oopsen just fine and patch below seems to fix things.
> Also, I'm unhappy that you made these unrelated and broken changes at
> all. Both wrt 'used' and this 'npages' thing, the original code wasn't
> wrong, and the pointless changes to correct code not only broke
> things, but had nothing to do with the iovec conversion that was the
> stated reason for the commit.
I've fucked up on those, no arguments, but they *were* very much related
to the conversion in question - original code in skcipher_recvmsg()
was a loop over iovec segments, with inner loop over each segment.
With iov_iter conversion we need a flat loop, and I'd screwed up while
massaging the code into that form. And af_alg_make_sg() change had been
a consequence of the same - we used to feed it the next subset of the
range covered by ->msg_iter.iov[...] in the inner loop there.
npages thing is _not_ a replacement of (similar) line you've picked out
of that diff - it replaced
npages = err;
after get_user_pages_fast(). Calling conventions of iov_iter_get_pages()
differ - it returns offset of the beginning within the first page (via
*start) and amount of data it picked from iterator (as return value).
> Grr. I really hate it when I find bugs during the merge window. My
> test environment is *not* odd. If _I_ end up being the one finding the
> bugs, that means that things must have gotten basically no testing at
> all.
Out of curiosity - what has triggered that oops on your userland? I certainly
_did_ the "allmodconfig and see if it boots" on those; in my usual test
image (jessie-amd64 in KVM) nothing has stepped into that one. Again,
I'm not trying to excuse the fuckup - just wondering what to add to tests...
The patch below appears to fix the problems on the reproducer I'd
been able to find.
Signed-off-by: Al Viro
---
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index eb78fe8..5b11d64 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -348,7 +348,7 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter
*iter, int len)
if (n < 0)
return n;
- npages = PAGE_ALIGN(off + n);
+ npages = DIV_ROUND_UP(off + n, PAGE_SIZE);
if (WARN_ON(npages == 0))
return -EINVAL;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 37110fd..0eb31a6 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -427,11 +427,11 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
socket *sock,
struct skcipher_sg_list *sgl;
struct scatterlist *sg;
int err = -EAGAIN;
- int used;
long copied = 0;
lock_sock(sk);
while (iov_iter_count(>msg_iter)) {
+ int used;
sgl = list_first_entry(>tsgl,
struct skcipher_sg_list, list);
sg = sgl->sg;
@@ -439,14 +439,13 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
socket *sock,
while (!sg->length)
sg++;
- used = ctx->used;
- if (!used) {
+ if (!ctx->used) {
err = skcipher_wait_for_data(sk, flags);
if (err)
goto unlock;
}
- used = min_t(unsigned long, used,
iov_iter_count(>msg_iter));
+ used = min_t(unsigned long, ctx->used,
iov_iter_count(>msg_iter));
used = af_alg_make_sg(>rsgl, >msg_iter, used);
err = used;
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] spi: fsl-quadspi: cleanup wait_for_completion return handling
On Sun, Feb 1, 2015 at 5:15 AM, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int, this
> patch uses the return value of wait_for_completion_timeout in the condition
> directly rather than adding a additional appropriately typed variable.
>
> Signed-off-by: Nicholas Mc Guire
> ---
>
> As the returnvalue of wait_for_completion_timeout is logically treated here
> as a boolean (timeout occured or not) it can be wrapped into the if condition
> directly and no additional variable is needed.
>
> This patch was only compile tested with imx_v6_v7_defconfig
> (implies CONFIG_SPI_FSL_QUADSPI=y)
>
> Patch is against 3.19.0-rc6 -next-20150130
>
> drivers/mtd/spi-nor/fsl-quadspi.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index a46bea3..2543b5c 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -455,8 +455,7 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int
> addr, int len)
> writel((seqid << QUADSPI_IPCR_SEQID_SHIFT) | len, base +
> QUADSPI_IPCR);
>
> /* Wait for the interrupt. */
> - err = wait_for_completion_timeout(>c, msecs_to_jiffies(1000));
> - if (!err) {
> + if (!wait_for_completion_timeout(>c, msecs_to_jiffies(1000))) {
> dev_err(q->dev,
> "cmd 0x%.2x timeout, addr@%.8x, FR:0x%.8x,
> SR:0x%.8x\n",
> cmd, addr, readl(base + QUADSPI_FR),
> --
> 1.7.10.4
>
Acked-by: Han Xu
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Tue, Feb 10, 2015 at 6:01 PM, Linus Torvalds
wrote:
>
> Are there no tests for that crypto interface?
Oh well.
With the attached, it at least does boot and work for me.
Linus
crypto/af_alg.c | 2 +-
crypto/algif_skcipher.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index eb78fe8a60c8..3e80d8b8be45 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -348,7 +348,7 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter
*iter, int len)
if (n < 0)
return n;
- npages = PAGE_ALIGN(off + n);
+ npages = (off + n + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (WARN_ON(npages == 0))
return -EINVAL;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 37110fd68adf..6fc12c3fc4b9 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -439,14 +439,13 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
socket *sock,
while (!sg->length)
sg++;
- used = ctx->used;
- if (!used) {
+ if (!ctx->used) {
err = skcipher_wait_for_data(sk, flags);
if (err)
goto unlock;
}
- used = min_t(unsigned long, used,
iov_iter_count(>msg_iter));
+ used = min_t(unsigned long, ctx->used,
iov_iter_count(>msg_iter));
used = af_alg_make_sg(>rsgl, >msg_iter, used);
err = used;
Re: [PATCH 3.18 04/57] vm: add VM_FAULT_SIGSEGV handling support
On Tue, Feb 10, 2015 at 7:43 PM, Greg Kroah-Hartman wrote: > > Ah, nice, I missed that one. Ugh, to be fair, I missed it too. The alternative to backporting 7fb08eca4527 is to make the backport of commit 33692f27597f use "bad_area()" instead of "bad_area_nosemaphore()". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
Quoting Tejun Heo (t...@kernel.org): > On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote: > > >> The -o SUBSYS option doesn't exist. Jesus, at least get yourself > > >> familiar with the basics before claiming random stuff. > > > > Oh let's see I got that command line option out of /proc/mounts and yes > > it works. Perhaps it doesn't if I invoke unified hiearchies but the > > option does in fact exist and work. > > I meant the -o SUBSYS doesn't exist for unified hierarchy. > > > Now I really do need to test report regressions, and send probably send > > regression fixes. If I understand your strange ranting I think you just > > told me that option that -o SUBSYS does work with unified hierarchies. > > What? Why would -O SUBSYS exist for unified hierarchy? It's unified > for all controllers. > > > Tejun. I asked you specifically about this case 2 years ago at plumbers > > and you personally told me this would continue to work. I am going to > > hold you to that. > > I have no idea what you're talking about in *THIS* thread. I'm fully > aware of what was discussed *THEN*. > > > Fixing bugs is one thing. Gratuitious regressions that make supporting > > existing user space applications insane is another. > > Can you explain what problem you're actually trying to talk about > without spouting random claims about regressions? A few weeks ago, in order to test the cgroup namespace patchset with lxc, I went through the motions of getting lxc to work with unified hierarchy. A few of the things I had to change: 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used to start with 1. I expect many userspace parsers to be broken by this. 2. After creating every non-leaf cgroup, we must fill in the cgroup.subtree_cgroups file. This is extra work which userspace doesn't have to do right now. 3. Let's say we want to create a freezer cgroup /foo/bar for some set of tasks, which they will administer. In fact let's assume we are going to use cgroup namespaces. We have to put the tasks into /foo/bar, unshare the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf, and then write 'freezer' into /foo/bar. (If we're not using cgroup namespaces, then we have to do a similar thing to let the tasks administer /foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing to is where the tasks have to know that they can create cgroups in "..". For containers this becomes odd. We tend to group containers by the tasks in and under a cgroup. We now will have to assume a convention where we know to check for tasks in and under "..", since by definition pid 1's cgroup (in a container) cannot have children. 4. The per-cgroup "tasks" file not existing seems odd, although certainly unexpected by much current software. So, if the unified hierarchy is going to not cause undue pain, existing software really needs to start working now to use it. It's going to be a sizeable task for lxc. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
From: Rafael J. Wysocki
Add an ->enter_freeze callback routine, intel_idle_freeze(), to
the intel_idle driver and point the ->enter_freeze callback
pointers of all of the driver's state objects to it.
Signed-off-by: Rafael J. Wysocki
---
drivers/idle/intel_idle.c | 179 --
1 file changed, 125 insertions(+), 54 deletions(-)
Index: linux-pm/drivers/idle/intel_idle.c
===
--- linux-pm.orig/drivers/idle/intel_idle.c
+++ linux-pm/drivers/idle/intel_idle.c
@@ -97,6 +97,8 @@ static const struct idle_cpu *icpu;
static struct cpuidle_device __percpu *intel_idle_cpuidle_devices;
static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
+static void intel_idle_freeze(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index);
static int intel_idle_cpu_init(int cpu);
static struct cpuidle_state *cpuidle_state_table;
@@ -131,28 +133,32 @@ static struct cpuidle_state nehalem_csta
.flags = MWAIT2flg(0x00),
.exit_latency = 3,
.target_residency = 6,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C1E-NHM",
.desc = "MWAIT 0x01",
.flags = MWAIT2flg(0x01),
.exit_latency = 10,
.target_residency = 20,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C3-NHM",
.desc = "MWAIT 0x10",
.flags = MWAIT2flg(0x10) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 20,
.target_residency = 80,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C6-NHM",
.desc = "MWAIT 0x20",
.flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 200,
.target_residency = 800,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.enter = NULL }
};
@@ -164,35 +170,40 @@ static struct cpuidle_state snb_cstates[
.flags = MWAIT2flg(0x00),
.exit_latency = 2,
.target_residency = 2,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C1E-SNB",
.desc = "MWAIT 0x01",
.flags = MWAIT2flg(0x01),
.exit_latency = 10,
.target_residency = 20,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C3-SNB",
.desc = "MWAIT 0x10",
.flags = MWAIT2flg(0x10) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 80,
.target_residency = 211,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C6-SNB",
.desc = "MWAIT 0x20",
.flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 104,
.target_residency = 345,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C7-SNB",
.desc = "MWAIT 0x30",
.flags = MWAIT2flg(0x30) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 109,
.target_residency = 345,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.enter = NULL }
};
@@ -204,42 +215,48 @@ static struct cpuidle_state byt_cstates[
.flags = MWAIT2flg(0x00),
.exit_latency = 1,
.target_residency = 1,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C1E-BYT",
.desc = "MWAIT 0x01",
.flags = MWAIT2flg(0x01),
.exit_latency = 15,
.target_residency = 30,
- .enter = _idle },
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
{
.name = "C6N-BYT",
.desc = "MWAIT 0x58",
.flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 40,
.target_residency = 275,
- .enter = _idle },
+
[PATCH 4/6] PM / sleep: Make it possible to quiesce timers during suspend-to-idle
From: Rafael J. Wysocki
The efficiency of suspend-to-idle depends on being able to keep CPUs
in the deepest available idle states for as much time as possible.
Ideally, they should only be brought out of idle by system wakeup
interrupts.
However, timer interrupts occurring periodically prevent that from
happening and it is not practical to chase all of the "misbehaving"
timers in a whack-a-mole fashion. A much more effective approach is
to suspend the local ticks for all CPUs and the entire timekeeping
along the lines of what is done during full suspend, which also
helps to keep suspend-to-idle and full suspend reasonably similar.
The idea is to suspend the local tick on each CPU executing
cpuidle_enter_freeze() and to make the last of them suspend the
entire timekeeping. That should prevent timer interrupts from
triggering until an IO interrupt wakes up one of the CPUs. It
needs to be done with interrupts disabled on all of the CPUs,
though, because otherwise the suspended clocksource might be
accessed by an interrupt handler which might lead to fatal
consequences.
Unfortunately, the existing ->enter callbacks provided by cpuidle
drivers generally cannot be used for implementing that, because some
of them re-enable interrupts temporarily and some idle entry methods
cause interrupts to be re-enabled automatically on exit. Also some
of these callbacks manipulate local clock event devices of the CPUs
which really shouldn't be done after suspending their ticks.
To overcome that difficulty, introduce a new cpuidle state callback,
->enter_freeze, that will be guaranteed (1) to keep interrupts
disabled all the time (and return with interrupts disabled) and (2)
not to touch the CPU timer devices. Modify cpuidle_enter_freeze() to
look for the deepest available idle state with ->enter_freeze present
and to make the CPU execute that callback with suspended tick (and the
last of the online CPUs to execute it with suspended timekeeping).
Suggested-by: Thomas Gleixner
Signed-off-by: Rafael J. Wysocki
---
drivers/cpuidle/cpuidle.c | 48 +++-
include/linux/cpuidle.h |4 +++
include/linux/tick.h |2 +
kernel/time/tick-common.c | 50 ++
kernel/time/timekeeping.c |4 +--
kernel/time/timekeeping.h |2 +
6 files changed, 103 insertions(+), 7 deletions(-)
Index: linux-pm/include/linux/tick.h
===
--- linux-pm.orig/include/linux/tick.h
+++ linux-pm/include/linux/tick.h
@@ -226,5 +226,7 @@ static inline void tick_nohz_task_switch
__tick_nohz_task_switch(tsk);
}
+extern void tick_freeze(void);
+extern void tick_unfreeze(void);
#endif
Index: linux-pm/kernel/time/tick-common.c
===
--- linux-pm.orig/kernel/time/tick-common.c
+++ linux-pm/kernel/time/tick-common.c
@@ -394,6 +394,56 @@ void tick_resume(void)
}
}
+static DEFINE_RAW_SPINLOCK(tick_freeze_lock);
+static unsigned int tick_freeze_depth;
+
+/**
+ * tick_freeze - Suspend the local tick and (possibly) timekeeping.
+ *
+ * Check if this is the last online CPU executing the function and if so,
+ * suspend timekeeping. Otherwise suspend the local tick.
+ *
+ * Call with interrupts disabled. Must be balanced with %tick_unfreeze().
+ * Interrupts must not be enabled before the subsequent %tick_unfreeze().
+ */
+void tick_freeze(void)
+{
+ raw_spin_lock(_freeze_lock);
+
+ tick_freeze_depth++;
+ if (tick_freeze_depth == num_online_cpus()) {
+ timekeeping_suspend();
+ } else {
+ tick_suspend();
+ tick_suspend_broadcast();
+ }
+
+ raw_spin_unlock(_freeze_lock);
+}
+
+/**
+ * tick_unfreeze - Resume the local tick and (possibly) timekeeping.
+ *
+ * Check if this is the first CPU executing the function and if so, resume
+ * timekeeping. Otherwise resume the local tick.
+ *
+ * Call with interrupts disabled. Must be balanced with %tick_freeze().
+ * Interrupts must not be enabled after the preceding %tick_freeze().
+ */
+void tick_unfreeze(void)
+{
+ raw_spin_lock(_freeze_lock);
+
+ if (tick_freeze_depth == num_online_cpus())
+ timekeeping_resume();
+ else
+ tick_resume();
+
+ tick_freeze_depth--;
+
+ raw_spin_unlock(_freeze_lock);
+}
+
/**
* tick_init - initialize the tick control
*/
Index: linux-pm/kernel/time/timekeeping.h
===
--- linux-pm.orig/kernel/time/timekeeping.h
+++ linux-pm/kernel/time/timekeeping.h
@@ -16,5 +16,7 @@ extern int timekeeping_inject_offset(str
extern s32 timekeeping_get_tai_offset(void);
extern void timekeeping_set_tai_offset(s32 tai_offset);
extern void timekeeping_clocktai(struct timespec *ts);
+extern int timekeeping_suspend(void);
+extern void timekeeping_resume(void);
