Re: [linux-sunxi] Re: [PATCH v2 17/20] ARM: sunxi: Introduce Allwinner A23 support
On Wed, Jun 18, 2014 at 8:26 PM, Maxime Ripard
wrote:
> On Tue, Jun 17, 2014 at 10:52:54PM +0800, Chen-Yu Tsai wrote:
>> The Allwinner A23 is a dual-core Cortex-A7-based SoC. It re-uses most of
>> the IPs found in previous SoCs, notably the A31.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/mach-sunxi/Kconfig | 8
>> arch/arm/mach-sunxi/sunxi.c | 10 ++
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>> index 0fbd4f1..6434e3b 100644
>> --- a/arch/arm/mach-sunxi/Kconfig
>> +++ b/arch/arm/mach-sunxi/Kconfig
>> @@ -35,4 +35,12 @@ config MACH_SUN7I
>> select HAVE_ARM_ARCH_TIMER
>> select SUN5I_HSTIMER
>>
>> +config MACH_SUN8I
>> + bool "Allwinner A23 (sun8i) SoCs support"
>> + default ARCH_SUNXI
>> + select ARCH_HAS_RESET_CONTROLLER
>> + select ARM_GIC
>> + select MFD_SUN6I_PRCM
>> + select RESET_CONTROLLER
>> +
>> endif
>> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
>> index 3f9587b..962ff30 100644
>> --- a/arch/arm/mach-sunxi/sunxi.c
>> +++ b/arch/arm/mach-sunxi/sunxi.c
>> @@ -53,3 +53,13 @@ static const char * const sun7i_board_dt_compat[] = {
>> DT_MACHINE_START(SUN7I_DT, "Allwinner sun7i (A20) Family")
>> .dt_compat = sun7i_board_dt_compat,
>> MACHINE_END
>> +
>> +static const char * const sun8i_board_dt_compat[] = {
>> + "allwinner,sun8i-a23",
>> + NULL,
>> +};
>> +
>> +DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i (A23) Family")
>> + .init_time = sun6i_timer_init,
>
> I haven't seen anything in your code that needed to use this
> function. Am I missing something?
My mistake. From the log I thought all timers needed the reset
controller. Turns out only the high speed timer does.
I'll remove the call in the next version.
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Documentation: Document Hisilicon hix5hd2 sata PHY
Dear Mark On 06/18/2014 01:13 AM, Mark Rutland wrote: On Tue, Jun 17, 2014 at 08:58:00AM +0100, Zhangfei Gao wrote: From: Jiancheng Xue Add necessary binding documentation SATA PHY on Hisilicon hix5hd2 soc. Signed-off-by: Jiancheng Xue Signed-off-by: Zhangfei Gao --- .../devicetree/bindings/phy/hix5hd2-sata-phy.txt | 26 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/hix5hd2-sata-phy.txt diff --git a/Documentation/devicetree/bindings/phy/hix5hd2-sata-phy.txt b/Documentation/devicetree/bindings/phy/hix5hd2-sata-phy.txt new file mode 100644 index 000..ed15123 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hix5hd2-sata-phy.txt @@ -0,0 +1,26 @@ +Hisilicon hix5hd2 SATA PHY +--- + +Required properties: +- compatible: should be "hisilicon,hix5hd2-sata-phy" +- reg: offset and length of the PHY registers +- #phy-cells: must be 0 +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +Optional Properties: +- hisilicon,peri-syscon: phandle of syscon used to control peripheral. "peri" is a rather strange contraction of "peripheral". Will use hisilicon,peripheral-syscon instead, just thought it is too long. +- hisilicon,power-reg: offset and bit number of the sata power supply register. + Only effective when hisilicon,peri-syscon is supplied. This is the offset within the system controller? It would be good to state that. Change to - hisilicon,power-reg: offset and bit number within peripheral-syscon, register of controlling sata power supply. +- hisilicon,reg-init: one of more sets of 4 cells. The first cell + is the register offset address, the second cell is the start bit in register, + the third cell means the bit width, and the fourth cell is the value to set. Which registers is this meant to be initialising? Why does this need to be in the DT? How much is this expected to vary? Double checked with hardware guy, the registers required to be set are same in different board, the value maybe different. Will move to phy-hix5hd2-sata.c directly and remove hisilicon,reg-init. Thanks for the suggestions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, Jun 20, 2014 at 03:27:15PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> defconfig) failed like this:
>
> In file included from /scratch/sfr/next/arch/arm/mm/dma-mapping.c:29:0:
> /scratch/sfr/next/include/linux/cma.h:8:28: error: 'CONFIG_CMA_AREAS'
> undeclared here (not in a function)
> #define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
> ^
> /scratch/sfr/next/arch/arm/mm/dma-mapping.c:434:54: note: in expansion of
> macro 'MAX_CMA_AREAS'
> static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS]
> __initdata;
> ^
>
> Caused by commit f495d267b2e0 ("CMA: generalize CMA reserved area
> management functionality").
>
> I have reverted that commit and these commits that depend on it
>
> 57d551e70a38 ("mm, CMA: clean-up log message")
> d75ab106aef5 ("mm, CMA: change cma_declare_contiguous() to obey coding
> convention")
> f693a5424631 ("mm, CMA: clean-up CMA allocation error path")
> e58e263e5254 ("PPC, KVM, CMA: use general CMA reserved area management
> framework")
>
Hello,
If below patch fixes above problem, is it possible to retain above patches
in linux-next?
Thanks.
-8<
>From e5c519c4b74914067e43cb55e232f19de9967324 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Fri, 20 Jun 2014 13:30:56 +0900
Subject: [PATCH] CMA: fix ARM build failure related to MAX_CMA_AREAS
definition
If CMA is disabled, CONFIG_CMA_AREAS isn't defined so compile error
happens. To fix it, define MAX_CMA_AREAS if CONFIG_CMA_AREAS
isn't defined.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 32cab7a..371b930 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -5,8 +5,14 @@
* There is always at least global CMA area and a few optional
* areas configured in kernel .config.
*/
+#ifdef CONFIG_CMA_AREAS
#define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
+#else
+#define MAX_CMA_AREAS (0)
+
+#endif
+
struct cma;
extern phys_addr_t cma_get_base(struct cma *cma);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] clk: spear3xx: Set proper clock parent of uart1/2
On Fri, Jun 20, 2014 at 3:22 AM, Thomas Gleixner wrote: > The uarts only work when the parent is ras_ahb_clk. The stale 3.5 > based ST tree does this in the board file. > > Add it to the clk init function. Not pretty, but the mess there is > amazing anyway. I still feel that board file is the right place to do it. Similar stuff might be required for some other peripheral clocks later and this solution wouldn't be scalable then. But if you insist on doing it this way: Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jun 20
Hi all, The powerpc allyesconfig is again broken more than usual. Changes since 20140619: The mfd-lj tree lost its build failure. The staging tree gained a build failure for which I disabled a driver. The akpm-current tree gained a build failure for which I reverted some commits. Non-merge commits (relative to Linus' tree): 1729 1581 files changed, 51622 insertions(+), 28729 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 219 trees (counting Linus' and 29 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 (894e552cfaa3 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security) Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6) Merging kbuild-current/rc-fixes (c14105628b2e kbuild: fix a typo in a kbuild document) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (6a78371acebf ARM: perf: fix compiler warning with gcc 4.6.4 (and tidy code)) Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to pr_foo()) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging powerpc-merge/merge (68986c9f0f45 Revert "offb: Add palette hack for little endian") Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in arch/sparc/kernel/sysfs.c) Merging net/master (6f9a093b66ce net: filter: fix upper BPF instruction limit) Merging ipsec/master (7171511eaec5 Linux 3.16-rc1) Merging sound-current/for-linus (8d42fda9ea98 Merge branch 'topic/core-vuln-fixes' into for-linus) Merging pci-current/for-linus (d066c946a866 PCI: Fix unaligned access in AF transaction pending test) Merging wireless/master (616a8394b5df rt2x00: fix rfkill regression on rt2500pci) Merging driver-core.current/driver-core-linus (7171511eaec5 Linux 3.16-rc1) Merging tty.current/tty-linus (60efcf0414be tty/serial: fix 8250 early console option passing to regular console) Merging usb.current/usb-linus (32b36eeae6a8 USB: usbtest: add a timeout for scatter-gather tests) Merging usb-gadget-fixes/fixes (5d881802c407 usb: musb: core: Handle Babble condition only in HOST mode) Merging staging.current/staging-linus (88513624be04 staging: comedi: addi_apci_1564: add addi_watchdog dependency) Merging char-misc.current/char-misc-linus (b29f680c4fe3 Revert "uio: fix vma io range check in mmap") Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about incorrect spelling) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode concurrency finding.) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6) Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting module removal.) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling delayed works) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging drm-intel-fixes/for-linux-next-fixes (4a11e398b39b drm/i915: cache hw power well enabled state) Merging asm-generic/master (fb9de7ebc3a2 xtensa: Use generic asm/mmu.h for nommu) Mer
Re: linux-next: build warning after merge of the akpm-current tree
On Thu, Jun 19, 2014 at 10:27 PM, Stephen Rothwell
wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> Introduced by commit 8d9dfa4b0125 ("initramfs: support initramfs that
> is more than 2G"). Grep is your friend :-(
Please check if attached patch fix the problem.
Yinghai
diff --git a/crypto/zlib.c b/crypto/zlib.c
index 06b62e5..c9ee681 100644
--- a/crypto/zlib.c
+++ b/crypto/zlib.c
@@ -168,7 +168,7 @@ static int zlib_compress_update(struct crypto_pcomp *tfm,
}
ret = req->avail_out - stream->avail_out;
- pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+ pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
stream->avail_in, stream->avail_out,
req->avail_in - stream->avail_in, ret);
req->next_in = stream->next_in;
@@ -198,7 +198,7 @@ static int zlib_compress_final(struct crypto_pcomp *tfm,
}
ret = req->avail_out - stream->avail_out;
- pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+ pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
stream->avail_in, stream->avail_out,
req->avail_in - stream->avail_in, ret);
req->next_in = stream->next_in;
@@ -283,7 +283,7 @@ static int zlib_decompress_update(struct crypto_pcomp *tfm,
}
ret = req->avail_out - stream->avail_out;
- pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+ pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
stream->avail_in, stream->avail_out,
req->avail_in - stream->avail_in, ret);
req->next_in = stream->next_in;
@@ -331,7 +331,7 @@ static int zlib_decompress_final(struct crypto_pcomp *tfm,
}
ret = req->avail_out - stream->avail_out;
- pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+ pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
stream->avail_in, stream->avail_out,
req->avail_in - stream->avail_in, ret);
req->next_in = stream->next_in;
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 0b9a1e4..11ea1ee 100644
--- a/fs/jffs2/compr_zlib.c
+++ b/fs/jffs2/compr_zlib.c
@@ -94,11 +94,11 @@ static int jffs2_zlib_compress(unsigned char *data_in,
while (def_strm.total_out < *dstlen - STREAM_END_SPACE && def_strm.total_in < *sourcelen) {
def_strm.avail_out = *dstlen - (def_strm.total_out + STREAM_END_SPACE);
- def_strm.avail_in = min((unsigned)(*sourcelen-def_strm.total_in), def_strm.avail_out);
- jffs2_dbg(1, "calling deflate with avail_in %d, avail_out %d\n",
+ def_strm.avail_in = min((unsigned long)(*sourcelen-def_strm.total_in), def_strm.avail_out);
+ jffs2_dbg(1, "calling deflate with avail_in %ld, avail_out %ld\n",
def_strm.avail_in, def_strm.avail_out);
ret = zlib_deflate(_strm, Z_PARTIAL_FLUSH);
- jffs2_dbg(1, "deflate returned with avail_in %d, avail_out %d, total_in %ld, total_out %ld\n",
+ jffs2_dbg(1, "deflate returned with avail_in %ld, avail_out %ld, total_in %ld, total_out %ld\n",
def_strm.avail_in, def_strm.avail_out,
def_strm.total_in, def_strm.total_out);
if (ret != Z_OK) {
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/printk.h:257:0,
from include/linux/kernel.h:13,
from arch/x86/include/asm/percpu.h:44,
from arch/x86/include/asm/preempt.h:5,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from crypto/zlib.c:26:
crypto/zlib.c: In function 'zlib_compress_update':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
crypto/zlib.c: In function 'zlib_compress_final':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
^
crypto/zlib.c: In function 'zlib_decompress_update':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of
type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
crypto/zlib.c:286:2: note: in
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
defconfig) failed like this:
In file included from /scratch/sfr/next/arch/arm/mm/dma-mapping.c:29:0:
/scratch/sfr/next/include/linux/cma.h:8:28: error: 'CONFIG_CMA_AREAS'
undeclared here (not in a function)
#define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
^
/scratch/sfr/next/arch/arm/mm/dma-mapping.c:434:54: note: in expansion of macro
'MAX_CMA_AREAS'
static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS] __initdata;
^
Caused by commit f495d267b2e0 ("CMA: generalize CMA reserved area
management functionality").
I have reverted that commit and these commits that depend on it
57d551e70a38 ("mm, CMA: clean-up log message")
d75ab106aef5 ("mm, CMA: change cma_declare_contiguous() to obey coding
convention")
f693a5424631 ("mm, CMA: clean-up CMA allocation error path")
e58e263e5254 ("PPC, KVM, CMA: use general CMA reserved area management
framework")
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: new mailing list for union/overlay filesystems?
BTW, unionfs isn’t inactive (http://unionfs.filesystems.org, http://git.fsl.cs.sunysb.edu/?o=age). Cheers, Erez. On Jun 19, 2014, at 8:36 AM, Miklos Szeredi wrote: > Hi Dave, > > There's interest in having a mailing list specifically for "union > filesystem" like solutions (currently active projects are aufs, > union-mounts and overlayfs). > > Would it be possible to create one on vger for this purpose? > > Thanks, > Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: tegra: TN7: relax some regulators
On 06/20/2014 02:56 AM, Mark Brown wrote:
* PGP Signed by an unknown key
On Thu, Jun 19, 2014 at 09:59:04AM -0600, Stephen Warren wrote:
On 06/19/2014 01:49 AM, Alexandre Courbot wrote:
Remove the regulator-always-on property from some regulators that do not
need it. On recent kernels fixed regulators which supply is always on
fail registration.
That sounds like a bug in the regulator core, which should be fixed there.
Please actually describe the problem you believe you are seeing - I've
seen no reports and I can't tell anything from what you've described,
nor can I see any obvious way that a regulator being fixed would have
any effect on its supply.
Here is some more information about what happens.
We have a fixed regulator defined as follows:
vdd_lcd: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "VD_LCD_1V8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
gpio = <_gpio 4 GPIO_ACTIVE_HIGH>;
enable-active-high;
vin-supply = <_1v8>;
regulator-boot-on;
};
Its vin-supply is part of the palmas device:
vdd_1v8: smps8 {
regulator-name = "vs-pmu-1v8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
};
When vdd_lcd is registered, set_supply() is called, which creates a new
regulator for vdd_1v8. In create_regulator(),
_regulator_can_change_status() returns false (as it should since the
regulator is always_on) and _regulator_is_enabled() *also* returns
false, so as a result regulator->always_on remains false for vdd_1v8.
Later in regulator_register(), we try to enable the supply. Since
regulator->always_on is false, _regulator_enable() is called on vdd_1v8,
and the pair _regulator_is_enabled() / _regulator_can_change_status() is
called again with the same result, which causes _regulator_enable() to
return -EPERM. This prevents vdd_lcd from being registered.
So I can see three questions here:
1) Why does _regulator_enable() on vdd_1v8 return 0 while everything
suggests that it is enabled (this regulator powers lot of devices, like
eMMC, which are working fine). This may be an issue with the palmas driver.
2) When an always-on regulator that is not yet enabled is registered,
shouldn't it be switched on by the regulator framework?
3) When a boot-on regulator is registered and _regulator_is_enabled()
returns contradictory information, what should be done?
Note that whether the regulator-boot-on property is present or not does
not change anything.
I tried to find a recent patch that could have introduced a change of
behavior, but could not find anything so far. Bisecting is made harder
by the fact this happens on a newly-introduced board which requires a
bunch of patches of its own, but it we need more information I can try
to do it anyway.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Coccinelle: Script to drop parenthesis in the return statements
On Thu, 19 Jun 2014, Joe Perches wrote:
> On Thu, 2014-06-19 at 18:49 +0200, Julia Lawall wrote:
> > On Thu, 19 Jun 2014, Joe Perches wrote:
> > > On Thu, 2014-06-19 at 21:59 +0530, Himangi Saraogi wrote:
> > > > This script detects the use of a parenthesis around return value ot the
> > > > return statements and removes them as they are unnecessary and against
> > > > the CodingStyle. A new directory called checkpatch is added for semantic
> > > > patches that just make patches for what checkpatch does. This will help
> > > > developers having checkpatch problems, to run the semantic patches in
> > > > this
> > > > directory on their code and fix some of them automatically.
> > >
> > > checkpatch already has --fix and --fix-inplace options that
> > > do something similar.
> >
> > OK. Then it is not worth adding coccinelle scripts for simple changes
> > like this one.
> >
> > I guess that some of the more complex changes, like choosing an
> > appropriate error message function, checkpatch does not do?
>
> I'm not quite sure what you're suggesting.
>
> You mean choosing pr_err vs pr_notice or something
> like finding an active struct and converting
> printks to _(, fmt, ...)
>
> from:
> {
> struct device *dev;
> ...
> printk(KERN_ERR "msg", ...)
> to:
> dev_err(dev, "msg", ...)
>
> checkpatch definitely can not do that.
>
> Is it something else?
Yes, that is what I was thinking of. Anyway, we can just test whether
checkpatch --fix can d the change before proposing a semantic patch for
it.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: Ignore email headers better
There are some patches created by git format-patch
that when scanned by checkpatch report errors on
lines like
To: address.tld
This is a checkpatch false positive.
Improve the logic a bit to ignore folded email headers
to avoid emitting these messages.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd845b9..1e17de2 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1637,7 +1637,7 @@ sub process {
my $signoff = 0;
my $is_patch = 0;
- my $in_header_lines = 1;
+ my $in_header_lines = $file ? 0 : 1;
my $in_commit_log = 0; #Scanning lines before patch
my $non_utf8_charset = 0;
@@ -1993,7 +1993,8 @@ sub process {
# Check if it's the start of a commit log
# (not a header line and we haven't seen the patch filename)
if ($in_header_lines && $realfile =~ /^$/ &&
- $rawline !~ /^(commit\b|from\b|[\w-]+:).+$/i) {
+ !($rawline =~ /^\s+\S/ ||
+ $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {
$in_header_lines = 0;
$in_commit_log = 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] staging: dgap: make dgap_found_board() return a brd pointer
Make dgap_found_board() return a brd pointer and that brd pointer
assign to dgap_board[] in the end of the dgap_init_one().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 5c8e622..55c9761 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -70,7 +70,8 @@ MODULE_SUPPORTED_DEVICE("dgap");
static int dgap_start(void);
static void dgap_init_globals(void);
-static int dgap_found_board(struct pci_dev *pdev, int id, int boardnum);
+static struct board_t *dgap_found_board(struct pci_dev *pdev, int id,
+ int boardnum);
static void dgap_cleanup_board(struct board_t *brd);
static void dgap_poll_handler(ulong dummy);
static int dgap_init_pci(void);
@@ -582,11 +583,10 @@ static int dgap_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (rc)
return -EIO;
- rc = dgap_found_board(pdev, ent->driver_data, dgap_numboards);
- if (rc)
+ brd = dgap_found_board(pdev, ent->driver_data, dgap_numboards);
+ if (IS_ERR(brd))
return rc;
- brd = dgap_board[dgap_numboards++];
rc = dgap_firmware_load(pdev, ent->driver_data, brd);
if (rc)
goto cleanup_brd;
@@ -617,6 +617,8 @@ static int dgap_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
brd->state = BOARD_READY;
brd->dpastatus = BD_RUNNING;
+ dgap_board[dgap_numboards++] = brd;
+
return 0;
tty_free:
@@ -717,7 +719,8 @@ static void dgap_cleanup_board(struct board_t *brd)
*
* A board has been found, init it.
*/
-static int dgap_found_board(struct pci_dev *pdev, int id, int boardnum)
+static struct board_t *dgap_found_board(struct pci_dev *pdev, int id,
+ int boardnum)
{
struct board_t *brd;
unsigned int pci_irq;
@@ -727,9 +730,7 @@ static int dgap_found_board(struct pci_dev *pdev, int id,
int boardnum)
/* get the board structure and prep it */
brd = kzalloc(sizeof(struct board_t), GFP_KERNEL);
if (!brd)
- return -ENOMEM;
-
- dgap_board[boardnum] = brd;
+ return ERR_PTR(-ENOMEM);
/* store the info for the board we've found */
brd->magic = DGAP_BOARD_MAGIC;
@@ -828,13 +829,12 @@ static int dgap_found_board(struct pci_dev *pdev, int id,
int boardnum)
pr_info("dgap: board %d: %s (rev %d), irq %ld\n",
boardnum, brd->name, brd->rev, brd->irq);
- return 0;
+ return brd;
free_brd:
kfree(brd);
- dgap_board[boardnum] = NULL;
- return ret;
+ return ERR_PTR(ret);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver
On Wed, Jun 18, 2014 at 9:44 AM, Kevin Hilman wrote: [...] > Thinking more about what this RPM driver actually does, and since you > mentioned patterns across SoCs, it seems to me the RPM driver bascially > just doing the IPC. > Yes, technically this is IPC. But it's all exposed in memory as if it was hardware, so there's no messages or packets to be interpreted by the other side. > So, rather than MFD or drivers/soc, it seems to me that it should be > implmented as a controller in the new common mailbox framwork[1] being > worked on by Jassi Brar (added to Cc.) > > IIUC, RPM is actually only doing one-way IPC (it only exposes a write() > interface to clients) so it seems like a rather simple implementation of > a mailbox controller. > What I think you miss here is the detail of that what the regulator writes is not what is passed over the IPC, but rather is just an interface to abstract away how things are spread our in the register space. So the only place where we do have a "mailbox" here is the actual function call between the regulator and the rpm drivers; not between the rpm driver and the rpm. > I believe Bjorn is already on the list of folks Cc'd on the common > mailbox framework, so it would be good to hear from him why RPM wouldn't > fit under that framework. > In a separate group of Qualcomm platforms the communication with the RPM is done by passing messages over a shared memory channel; as this requires a completely different implementation of the rpm driver, I have started to look at Jassi's patch series. Unfortunately at this point it does not look like the proposed mailbox framework would reduce the complexity of the implementation nor provide any additional benefits when it comes to being able to exchange the underlaying communication methods. But I will continue to follow the development of the mailbox framework. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cleanups] x86/tsc: Get rid of custom DIV_ROUND() macro
Commit-ID: 891715793f0451e5114d200be932ac14ce8521a3
Gitweb: http://git.kernel.org/tip/891715793f0451e5114d200be932ac14ce8521a3
Author: Michal Nazarewicz
AuthorDate: Thu, 19 Jun 2014 03:58:36 +0200
Committer: H. Peter Anvin
CommitDate: Thu, 19 Jun 2014 22:04:50 -0700
x86/tsc: Get rid of custom DIV_ROUND() macro
When invoced for positive values, DIV_ROUND macro defined in
arch/x86/kernel/tsc.c behaves exactly like DIV_ROUND_CLOSEST from
include/linux/kernel.h file, so remove the custom macro in favour
of the shared one.
[ hpa: changed line breaks ]
Signed-off-by: Michal Nazarewicz
Link:
http://lkml.kernel.org/r/1403143116-21755-1-git-send-email-min...@mina86.com
Acked-by: David Rientjes
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/tsc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 57e5ce1..8764232 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -234,9 +234,6 @@ static inline unsigned long long cycles_2_ns(unsigned long
long cyc)
return ns;
}
-/* XXX surely we already have this someplace in the kernel?! */
-#define DIV_ROUND(n, d) (((n) + ((d) / 2)) / (d))
-
static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
{
unsigned long long tsc_now, ns_now;
@@ -259,7 +256,9 @@ static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
* time function is continuous; see the comment near struct
* cyc2ns_data.
*/
- data->cyc2ns_mul = DIV_ROUND(NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR,
cpu_khz);
+ data->cyc2ns_mul =
+ DIV_ROUND_CLOSEST(NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR,
+ cpu_khz);
data->cyc2ns_shift = CYC2NS_SCALE_FACTOR;
data->cyc2ns_offset = ns_now -
mul_u64_u32_shr(tsc_now, data->cyc2ns_mul, CYC2NS_SCALE_FACTOR);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
On Fri, Jun 20, 2014 at 06:57:04AM +0200, Olaf Hering wrote:
> On Thu, Jun 19, Haiyang Zhang wrote:
>
> > The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host
> > sleep or hibernation. We refresh network at this time.
>
> > + char *argv[] = { "/etc/init.d/network", "restart", NULL };
>
> What happens if that file does not exist? Dead network in the guest?
> I tend to think if a VM with PV drivers goes to sleep it has to go
> through the whole suspend/resume cycle, very much like the "LID closed"
> event. So I think this and the other fbdev change that is floating
> around is wrong.
Ah, and what about systems with no /etc/init.d/ at all (like
systemd-based ones)? You can't have a kernel driver ask userspace to
restart all networking connections, that seems really wrong.
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: [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/
On Thu, 19 Jun 2014 17:33:30 -0400 Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> The trace_seq functions are rather useful outside of tracing. Instead
> of having it be dependent on CONFIG_TRACING, move the code into lib/
> and allow other users to have access to it even when tracing is not
> configured.
What LT said. It's pileon time!
> Signed-off-by: Steven Rostedt
> ---
> include/linux/trace_seq.h | 68 ++
> kernel/trace/trace.c| 24
> kernel/trace/trace_output.c | 268 ---
> kernel/trace/trace_output.h | 16 ---
> lib/Makefile| 2 +-
> lib/trace_seq.c | 303
>
Putting it in there makes me look at it ;)
> --- a/include/linux/trace_seq.h
> +++ b/include/linux/trace_seq.h
>
> ...
>
> +#define SEQ_PUT_FIELD_RET(s, x) \
> +do { \
> + if (!trace_seq_putmem(s, &(x), sizeof(x))) \
hm, does sizeof(x++) increment x? I guess it does.
> + return TRACE_TYPE_PARTIAL_LINE; \
> +} while (0)
>
>
> ...
>
> +#define SEQ_PUT_HEX_FIELD_RET(s, x) \
> +do { \
> + BUILD_BUG_ON(sizeof(x) > MAX_MEMHEX_BYTES); \
> + if (!trace_seq_putmem_hex(s, &(x), sizeof(x))) \
> + return TRACE_TYPE_PARTIAL_LINE; \
> +} while (0)
Also has side-effects.
> #endif /* _LINUX_TRACE_SEQ_H */
>
> ...
>
> --- /dev/null
> +++ b/lib/trace_seq.c
> @@ -0,0 +1,303 @@
> +/*
> + * trace_seq.c
> + *
> + * Copyright (C) 2008-2014 Red Hat Inc, Steven Rostedt
> + *
> + */
> +#include
> +#include
> +#include
> +
> +int trace_print_seq(struct seq_file *m, struct trace_seq *s)
-ENODOC
> +{
> + int len = s->len >= PAGE_SIZE ? PAGE_SIZE - 1 : s->len;
int = uint >= ulong ? ulog : uint
that's spastic. Can we choose a type and stick to it?
Also, min().
> + int ret;
> +
> + ret = seq_write(m, s->buffer, len);
> +
> + /*
> + * Only reset this buffer if we successfully wrote to the
> + * seq_file buffer.
why?
> + */
> + if (!ret)
> + trace_seq_init(s);
> +
> + return ret;
> +}
> +
> +/**
> + * trace_seq_printf - sequence printing of trace information
> + * @s: trace sequence descriptor
> + * @fmt: printf format string
> + *
> + * It returns 0 if the trace oversizes the buffer's free
> + * space, 1 otherwise.
s/oversizes/would overrun/?
> + * The tracer may use either sequence operations or its own
> + * copy to user routines. To simplify formating of a trace
> + * trace_seq_printf is used to store strings into a special
> + * buffer (@s). Then the output may be either used by
> + * the sequencer or pulled into another buffer.
> + */
> +int
> +trace_seq_printf(struct trace_seq *s, const char *fmt, ...)
unneeded newline
> +{
> + int len = (PAGE_SIZE - 1) - s->len;
int = ulong - uint;
> + va_list ap;
> + int ret;
> +
> + if (s->full || !len)
> + return 0;
> +
> + va_start(ap, fmt);
> + ret = vsnprintf(s->buffer + s->len, len, fmt, ap);
> + va_end(ap);
> +
> + /* If we can't write it all, don't bother writing anything */
This is somewhat unusual behavior for a write()-style thing. Comment
should explain "why", not "what".
> + if (ret >= len) {
> + s->full = 1;
> + return 0;
> + }
> +
> + s->len += ret;
> +
> + return 1;
> +}
> +EXPORT_SYMBOL_GPL(trace_seq_printf);
> +
> +/**
> + * trace_seq_bitmask - put a list of longs as a bitmask print output
Is that grammatical?
> + * @s: trace sequence descriptor
> + * @maskp: points to an array of unsigned longs that represent a bitmask
> + * @nmaskbits: The number of bits that are valid in @maskp
> + *
> + * It returns 0 if the trace oversizes the buffer's free
> + * space, 1 otherwise.
Ditto
> + * Writes a ASCII representation of a bitmask string into @s.
> + */
> +int
> +trace_seq_bitmask(struct trace_seq *s, const unsigned long *maskp,
> + int nmaskbits)
> +{
> + int len = (PAGE_SIZE - 1) - s->len;
> + int ret;
> +
> + if (s->full || !len)
> + return 0;
> +
> + ret = bitmap_scnprintf(s->buffer, len, maskp, nmaskbits);
> + s->len += ret;
> +
> + return 1;
> +}
> +EXPORT_SYMBOL_GPL(trace_seq_bitmask);
More dittos.
> +/**
> + * trace_seq_vprintf - sequence printing of trace information
> + * @s: trace sequence descriptor
> + * @fmt: printf format string
> + *
> + * The tracer may use either sequence operations or its own
> + * copy to user routines. To simplify formating of a trace
> + * trace_seq_printf is used to store strings into a special
"trace_seq_printf()". Apparently it makes the kerneldoc output come
out right.
> + * buffer (@s). Then the output may be either used by
> + * the sequencer or pulled into
Re: [PATCH] initramfs: Support initrd that is bigger then 2G.
On 06/19/2014 10:02 PM, Yinghai Lu wrote: > On Thu, Jun 19, 2014 at 9:29 PM, H. Peter Anvin wrote: >> On 06/19/2014 07:12 PM, Yinghai Lu wrote: >>> >>> Also need to use that in write_buffer path for cpio that have file is >>> more than file. >> >> That sentence doesn't make sense. > > I mean this path: >unpack_to_rootfs ===> write_buffer ===> actions[].../do_copy > and image is uncompressed cpio, and there is one big file (>2G) in that cpio. Don't tell me, make the description clear so someone can understand it 10 years from now. >> >> It would be nice in order to support very large initrd/initramfs, to >> free the memory as it becomes available instead of requiring two copies >> of the data in memory at the same time. > > for initramfs, it is from ramdisk_image/ramdisk_size to tmpfs directly. > and ramdisk_image/ramdisk_size get freed. > > for initrd, it is transferred to /initrd.image in tmpfs at first, and > ramdisk_image/ramdisk_size > get freed, at last /initrd.image is decompressed/copied to /dev/ram0 > and get removed > from tempfs. > > So what do you mean "free the memory"? > For each of those transfers, we don't free the source memory until the very end. We could free that memory as we process the input, requiring less total memory. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Write down design and intentions in English for proportial scan
On Thu, Jun 19, 2014 at 08:53:57PM -0700, Andrew Morton wrote: > On Fri, 20 Jun 2014 12:00:02 +0900 Minchan Kim wrote: > > > By suggestion from Andrew, first of all, I try to add only comment > > but I believe we could make it more clear by some change like this. > > https://lkml.org/lkml/2014/6/16/750 > > > > Anyway, push this patch firstly. > > Thanks. > > > = &< = > > > > >From b1fd007097064db34a211ffeacfe4da9fb22d49e Mon Sep 17 00:00:00 2001 > > From: Minchan Kim > > Date: Fri, 20 Jun 2014 11:37:52 +0900 > > Subject: [PATCH] mm: Write down design and intentions in English for > > proportial scan > > > > Quote from Andrew > > " > > That code is absolutely awful :( It's terribly difficult to work out > > what the design is - what the code is actually setting out to achieve. > > One is reduced to trying to reverse-engineer the intent from the > > implementation and that becomes near impossible when the > > implementation has bugs! > > > > > > > > The only way we're going to fix all this up is to stop looking at the > > code altogether. Write down the design and the intentions in English. > > Review that. Then implement that design in C > > " > > > > One thing I know it might not be English Andrew expected but other > > thing I know is there are lots of native people in here so one of them > > will spend his time to make this horrible English smooth. > > > > I alreday spent my time to try to fix this situation so it's your > > turn. It's good time balance between non-native and native people > > so open source community is fair for all of us. > > > > I can do that ;) But not yet. > > > --- > > mm/vmscan.c | 37 +++-- > > 1 file changed, 31 insertions(+), 6 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 521f7eab1798..3a9862895a64 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2071,6 +2071,22 @@ static void shrink_lruvec(struct lruvec *lruvec, > > struct scan_control *sc) > > > > get_scan_count(lruvec, sc, nr); > > > > + /* > > +* Basically, VM scans file/anon LRU list proportionally > > OK > > > depending > > +* on the value of vm.swappiness > > "depending" in what fashion? Higher swappiness leads to lengthier > scans. But there's this: Higher swappiness leads to scan for *anon* pages more while it leads to file pages less. But thing we should keep in mind is it's not a absolute value but relative value based on each LRU size. > > /* >* With swappiness at 100, anonymous and file have the same priority. The default is 60 so it turns out Linux prefers file to anon for scanning (ie, chace of reclaiming) but if we set it to 100, it means VM can give a same ratio to them(file and anon LRU list) so we could call it "it's same prioirty". >* This scanning priority is essentially the inverse of IO cost. >*/ > anon_prio = sc->swappiness; > file_prio = 200 - anon_prio; > > > > but doesn't want to reclaim > > +* excessive pages. So, it might be better to stop scan as soon as > > +* we meet nr_to_reclaim > > "scanning" does not equal "reclaiming", as not all scanned pages are > reclaimed. I guess we mean "stop scanning when nr_reclaimed pages have > been reclaimed". No objection but use nr_to_reclaim instead of nr_reclaimed. > > > but it breaks aging balance between LRU lists > > Why does it do this? Let's assume that anon LRU size is 100 and file is 1000 and our mission (ie, nr_to_reclaim) is 20. get_scan_count decides scanning 20:80 ratio for anon:file. In this case, target[anon] is 20 and target[file] is 800. If we scan 10 pages(actually, it's 32 but I'd like to make it simple) as batch unit for each LRU, only one loop would be enough to meet nr_to_reclaim(ie, 20) if we assume our reclaim efficiency is 100%. IOW, we reclaimed 10 pages from anon LRU and another 10 pages from file LRU, which meet our target 20 pages. But what happens if we stop in here? For anon LRU list, 10 pages scanning is 10%(ie, 10/100) with considering anon LRU size but 10 pages scanning for file LRU list is 0.0125%(ie, 10/800). It's really unfair so this logic want to make 0.0125 to 10%. > > > +* To keep the balance, what we do is as follows. > > +* > > +* If we reclaim pages requested, we stop scanning first and > > +* investigate which LRU should be scanned more depending on > > +* remained lru size(ie, nr[xxx]). We will scan bigger one more > > +* so, final goal is > > +* > > +* scanned[xxx] = targets[xxx] - nr[xxx] > > +* targets[anon] : targets[file] = scanned[anon] : scanned[file] > > +*/ > > hm, what's going on here. Something like this? > > "after having scanned sufficient pages to reclaim nr_to_reclaim pages, > the LRUs will now be out of balance if many more pages were reclaimed > from one LRU than from the others. We now bring the LRUs back into > balance by ...". > > I'm not
Re: [PATCH] initramfs: Support initrd that is bigger then 2G.
On Thu, Jun 19, 2014 at 9:29 PM, H. Peter Anvin wrote: > On 06/19/2014 07:12 PM, Yinghai Lu wrote: >> >> Also need to use that in write_buffer path for cpio that have file is >> more than file. > > That sentence doesn't make sense. I mean this path: unpack_to_rootfs ===> write_buffer ===> actions[].../do_copy and image is uncompressed cpio, and there is one big file (>2G) in that cpio. > > > I would call this function xwrite(), which is usually called in userspace. Good, will change that. > > It would be nice in order to support very large initrd/initramfs, to > free the memory as it becomes available instead of requiring two copies > of the data in memory at the same time. for initramfs, it is from ramdisk_image/ramdisk_size to tmpfs directly. and ramdisk_image/ramdisk_size get freed. for initrd, it is transferred to /initrd.image in tmpfs at first, and ramdisk_image/ramdisk_size get freed, at last /initrd.image is decompressed/copied to /dev/ram0 and get removed from tempfs. So what do you mean "free the memory"? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging: lustre: ldlm: ldlm_resource.c removed unecessary braces
drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) > Doesn't apply :( Thanks - Its probably because I have included a patch already sent earlier, will redo this set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] Qualcomm Resource Power Manager driver
On Thu, Jun 19, 2014 at 1:01 PM, Jassi Brar wrote: [...] > Mailbox isn't about how you program the h/w. Do whatever is needed to > send a message across. > But there are no messages to get across here, each individual resource is exposed directly in the address space of the Linux system. > BTW I haven't looked closely, but probably you could push the data tables in > DT? > The first RFC for this had all configuration in devicetree; we decided not to go that path as this gave a cleaner abstraction and is less error prone. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
On Thu, Jun 19, Haiyang Zhang wrote:
> The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host
> sleep or hibernation. We refresh network at this time.
> + char *argv[] = { "/etc/init.d/network", "restart", NULL };
What happens if that file does not exist? Dead network in the guest?
I tend to think if a VM with PV drivers goes to sleep it has to go
through the whole suspend/resume cycle, very much like the "LID closed"
event. So I think this and the other fbdev change that is floating
around is wrong.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] use snprintf instead of sprintf in rcu_torture_printk
On Thu, Jun 19, 2014 at 08:13:22PM -0400, Pranith Kumar wrote:
> On 06/19/2014 07:49 PM, Paul E. McKenney wrote:
> > On Thu, Jun 19, 2014 at 07:24:48PM -0400, Pranith Kumar wrote:
> >> (dropping some CCs)
> >>
> >> On 06/19/2014 05:00 PM, Paul E. McKenney wrote:
> >>> On Wed, Jun 18, 2014 at 12:49:42PM -0700, Joe Perches wrote:
>
> I believe the function doesn't work well.
>
> static void
> rcu_torture_stats_print(void)
> {
> int size = nr_cpu_ids * 200 + 8192;
> char *buf;
>
> buf = kmalloc(size, GFP_KERNEL);
> if (!buf) {
> pr_err("rcu-torture: Out of memory, need: %d\n", size);
> return;
> }
> rcu_torture_printk(buf);
> pr_alert("%s", buf);
> kfree(buf);
> }
>
> rcu_torture_printk simply fills buf
>
> btw: I believe the arguments should pass size and
> rcu_torture_printk should use snprintf/size
>
> but all printks are limited to a maximum of 1024
> bytes so the large allocation is senseless and
> would even if it worked, would likely need to be
> vmalloc/vfree
> >>>
> >>> Fair point!
> >>>
> >>> Pranith, Romanov, if you would like part of RCU that is less touchy
> >>> about random hacking, this would be a good place to start. Scripts in
> >>> tools/testing/selftests/rcutorture/bin do care about some of the format,
> >>> but the variable-length portion generated by cur_ops->stats() is as far
> >>> as I know only parsed by human eyes.
> >>>
> >>
> >> Here is a first run of the change. Please let me know if I am totally off.
> >> RFC. :)
> >
> > Thank you for taking this on!
>
> You are most welcome :)
>
> >
> >> Three things on Todo list:
> >>
> >> * We need to check that we are using less than the allocated size of the
> >> buffer (used > size). (we are allocating a big buffer, so not sure if
> >> necessary)
> >> * Need to check with the scripts if they are working.
> >> * I used a loop for pr_alert(). I am not sure this is right, there should
> >> be a better way for printing large buffers
> >>
> >> If the overall structure is ok I will go ahead and check how the scripts
> >> are handling these changes.
> >
> > One other thing... Convince this function (and a few others that it
> > calls) that the system really has 4096 CPUs, run this code, and see what
> > actually happens both before and after. Just to get a bit of practice
> > mixed in with the theory. ;-)
> >
>
> OK. I think to do this I need to use 4096 instead of nr_cpu_ids. I will try
> this and see how it goes :)
That's the spirit! You will probably have to adjust a few other things
as well.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] clk: spear3xx: Use proper control register offset
On Fri, Jun 20, 2014 at 3:22 AM, Thomas Gleixner wrote: > The control register is at offset 0x10, not 0x0. This is wreckaged > since commit 5df33a62c (SPEAr: Switch to common clock framework). > > Signed-off-by: Thomas Gleixner > Cc: sta...@vger.kernel.org > --- > drivers/clk/spear/spear3xx_clock.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux/drivers/clk/spear/spear3xx_clock.c > === > --- linux.orig/drivers/clk/spear/spear3xx_clock.c > +++ linux/drivers/clk/spear/spear3xx_clock.c > @@ -211,7 +211,7 @@ static inline void spear310_clk_init(voi > /* array of all spear 320 clock lookups */ > #ifdef CONFIG_MACH_SPEAR320 > > -#define SPEAR320_CONTROL_REG (soc_config_base + 0x) > +#define SPEAR320_CONTROL_REG (soc_config_base + 0x0010) > #define SPEAR320_EXT_CTRL_REG (soc_config_base + 0x0018) > > #define SPEAR320_UARTX_PCLK_MASK0x1 Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] dts: spear: Fix sdhci compatible
On Fri, Jun 20, 2014 at 3:26 AM, Thomas Gleixner wrote:
> Make it match the bindings and the implementation.
>
> Signed-off-by: Thomas Gleixner
> ---
> arch/arm/boot/dts/spear320.dtsi |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/arch/arm/boot/dts/spear320.dtsi
> ===
> --- linux.orig/arch/arm/boot/dts/spear320.dtsi
> +++ linux/arch/arm/boot/dts/spear320.dtsi
> @@ -48,7 +48,7 @@
> };
>
> sdhci@7000 {
> - compatible = "st,sdhci-spear";
> + compatible = "st,spear300-sdhci";
> reg = <0x7000 0x100>;
> interrupts = <10>;
> interrupt-parent = <>;
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/3] trace_seq: Move the trace_seq code to lib/
On Thu, Jun 19, 2014 at 11:33 AM, Steven Rostedt wrote: > From: "Steven Rostedt (Red Hat)" > > The trace_seq functions are rather useful outside of tracing. They are? Why and where? And why are they still called "trace_xyz()" then? That commit message is useless and contains no actual information. 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 2/2] dts: spear: Add missing i2c1 interrupt
On Fri, Jun 20, 2014 at 3:26 AM, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> ---
> arch/arm/boot/dts/spear320.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
> Index: linux/arch/arm/boot/dts/spear320.dtsi
> ===
> --- linux.orig/arch/arm/boot/dts/spear320.dtsi
> +++ linux/arch/arm/boot/dts/spear320.dtsi
> @@ -123,6 +123,11 @@
> status = "disabled";
> };
>
> + i2c1: i2c@a700 {
> + interrupts = <21>;
> + interrupt-parent = <>;
> + };
Isn't this already available ?
i2c1: i2c@a700 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,designware-i2c";
reg = <0xa700 0x1000>;
interrupts = <21>;
interrupt-parent = <>;
status = "disabled";
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kernel BUG at /src/linux-dev/mm/mempolicy.c:1738! on v3.16-rc1
On Thu, 19 Jun 2014, Naoya Horiguchi wrote: > Hi, > > I triggered the following bug on v3.16-rc1 when I did mbind() testing > where multiple processes repeat calling mbind() for a shared mapped file > (causing pingpong of page migration.) The shared mapped file on shmem/tmpfs? So involving shared policy stuff? > > In my investigation, it seems that some vma accidentally has vma->vm_start > = 0, which makes new_vma_page() choose a wrong vma and results in breaking > the assumption that the address passed to alloc_pages_vma() should be > inside a given vma. I've not heard of that before. What evidence led you there? > I'm suspecting that mbind_range() do something wrong around vma handling, > but I don't have enough luck yet. Anyone has an idea? No idea at present. Please send disassembly (objdump -d, or objdump -ld if you had DEBUG_INFO) of policy_zonelist() - the Code line isn't enough to go on, since it just shows where the BUG jumped to out-of-line, with no clue as to what might be in the registers - thanks. Hugh > > Thanks, > Naoya Horiguchi > > [ 339.133960] [ cut here ] > [ 339.134893] kernel BUG at /src/linux-dev/mm/mempolicy.c:1738! > [ 339.134893] invalid opcode: [#1] SMP > [ 339.134893] Modules linked in: > stap_2acbad8c3ba47062dbdc6f227d00f8f4__1958(O) bnep bluetooth cfg80211 rfkill > ip6t_rpfilter ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack > ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables > ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack > iptable_mangle iptable_security iptable_raw ppdev microcode i2c_piix4 pcspkr > i2c_core virtio_balloon parport_pc parport serio_raw nfsd auth_rpcgss > oid_registry nfs_acl lockd sunrpc virtio_blk virtio_net floppy ata_generic > pata_acpi > [ 339.134893] CPU: 2 PID: 2840 Comm: mbind_fuzz Tainted: G O > 3.16.0-rc1-140619-1205-3-g80aa6b64a44e #157 > [ 339.134893] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [ 339.134893] task: 88007c133b60 ti: 88007dd28000 task.ti: > 88007dd28000 > [ 339.134893] RIP: 0010:[] [] > policy_zonelist+0x50/0xb0 > [ 339.134893] RSP: :88007dd2bcf8 EFLAGS: 00010293 > [ 339.134893] RAX: RBX: 88007c133b60 RCX: > > [ 339.134893] RDX: 0002 RSI: 88011bd3fad0 RDI: > 000200da > [ 339.134893] RBP: 88007dd2bd00 R08: 0002 R09: > 0002 > [ 339.134893] R10: 88007d8f3958 R11: 0001 R12: > 000200da > [ 339.134893] R13: R14: 88011bd3fad0 R15: > > [ 339.134893] FS: 7f457cf90740() GS:8800bec0() > knlGS: > [ 339.134893] CS: 0010 DS: ES: CR0: 80050033 > [ 339.134893] CR2: 70184000 CR3: 7959b000 CR4: > 06e0 > [ 339.134893] Stack: > [ 339.134893] 88007c133b60 88007dd2bd68 811eeac8 > 88007c133b60 > [ 339.134893] 88007c133b60 0002000c > > [ 339.134893] 88007c387e60 88007c387e60 eae19340 > 88007d8f3958 > [ 339.134893] Call Trace: > [ 339.134893] [] alloc_pages_vma+0x88/0x1a0 > [ 339.134893] [] new_vma_page+0x9b/0xb0 > [ 339.134893] [] unmap_and_move+0x3d/0x200 > [ 339.134893] [] migrate_pages+0xe5/0x1e0 > [ 339.134893] [] ? alloc_pages_vma+0x1a0/0x1a0 > [ 339.134893] [] do_mbind+0x1f2/0x3a0 > [ 339.134893] [] SyS_mbind+0x9b/0xb0 > [ 339.134893] [] tracesys+0xdd/0xe2 > [ 339.134893] Code: 63 d2 31 c0 85 db 48 8b 14 d5 00 2d d6 81 0f 95 c0 48 69 > c0 20 22 01 00 5b 5d 48 8d 84 02 00 1d 00 00 c3 0f 1f 84 00 00 00 00 00 <0f> > 0b 66 0f 1f 44 00 00 f6 46 06 02 75 12 89 fb 48 0f bf 56 08 > [ 339.134893] RIP [] policy_zonelist+0x50/0xb0 > [ 339.134893] RSP > [ 339.178924] ---[ end trace 37c12438b6936769 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the tip tree
Hi Peter,
On Thu, 19 Jun 2014 21:30:49 -0700 "H. Peter Anvin" wrote:
>
> On 06/19/2014 09:24 PM, Stephen Rothwell wrote:
> >
> > On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell
> > wrote:
> >>
> >> After merging the tip tree, today's linux-next build (x86_64
> >> allmodconfig) produced this warning:
> >>
> >> In file included from
> >> arch/x86/crypto/camellia_aesni_avx_glue.c:23:0:
> >> arch/x86/include/asm/xsave.h:73:12: warning:
> >> 'xsave_state_booting' defined but not used [-Wunused-function]
> >> static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
> >> ^
> >>
> >> Lots of these ...
> >>
> >> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and
> >> xrstors support for booting time"). Forgotten "inline" :-(
> >
> > Ping?
>
> I already applied an equivalent patch from Borislav.
Thanks. I look forward to it filtering out :-)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: pull request: wireless 2014-06-18
From: "John W. Linville" Date: Wed, 18 Jun 2014 14:54:14 -0400 > Please pull this batch of fixes intended for the 3.16 stream! Pulled, thanks a lot 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/
Re: linux-next: build warning after merge of the tip tree
On 06/19/2014 09:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell
> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>>
>> In file included from
>> arch/x86/crypto/camellia_aesni_avx_glue.c:23:0:
>> arch/x86/include/asm/xsave.h:73:12: warning:
>> 'xsave_state_booting' defined but not used [-Wunused-function]
>> static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
>> ^
>>
>> Lots of these ...
>>
>> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and
>> xrstors support for booting time"). Forgotten "inline" :-(
>
> Ping?
>
I already applied an equivalent patch from Borislav.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] initramfs: Support initrd that is bigger then 2G.
On 06/19/2014 07:12 PM, Yinghai Lu wrote: > When initrd (compressed or not) is used, kernel report data corrupted > with /dev/ram0. > > The root cause: > During initramfs checking, if it is initrd, it will be transferred to > /initrd.image with sys_write. > sys_write only support 2G-4K write, so if the initrd ram is more than > that, /initrd.image will not complete at all. > > Add local sys_write_large to loop calling sys_write to workaround the > problem. > > Also need to use that in write_buffer path for cpio that have file is > more than file. That sentence doesn't make sense. > At the same time, we don't need to worry about sys_read/sys_write in > do_mounts_rd.c::crd_load. As decompressor will have fill/flush that > means it will allocate buffer and buffer is smaller than 2G. > > Test with uncompressed initrd, and compressed with gz, bz2, lzma,xz, > lzop. > > Signed-off-by: Yinghai Lu I would call this function xwrite(), which is usually called in userspace. It would be nice in order to support very large initrd/initramfs, to free the memory as it becomes available instead of requiring two copies of the data in memory at the same time. Otherwise, Acked-by: H. Peter Anvin -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers/net/irda/kingsun-sir.c: remove null test before kfree
From: Fabian Frederick Date: Tue, 17 Jun 2014 21:22:50 +0200 > Fix checkpatch warning: > WARNING: kfree(NULL) is safe this check is probably not required > > Cc: Samuel Ortiz > Cc: net...@vger.kernel.org > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c: remove null test before kfree
From: Fabian Frederick Date: Tue, 17 Jun 2014 21:32:53 +0200 > Fix checkpatch warning: > WARNING: kfree(NULL) is safe this check is probably not required > > Cc: Ariel Elior > Cc: net...@vger.kernel.org > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the tip tree
Hi all,
On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell
wrote:
>
> After merging the tip tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from arch/x86/crypto/camellia_aesni_avx_glue.c:23:0:
> arch/x86/include/asm/xsave.h:73:12: warning: 'xsave_state_booting' defined
> but not used [-Wunused-function]
> static int xsave_state_booting(struct xsave_struct *fx, u64 mask)
> ^
>
> Lots of these ...
>
> Introduced by commit adb9d526e982 ("x86/xsaves: Add xsaves and xrstors
> support for booting time"). Forgotten "inline" :-(
Ping?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
From: Haiyang Zhang Date: Thu, 19 Jun 2014 18:34:36 -0700 > The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host > sleep or hibernation. We refresh network at this time. > MS-TFS: 135162 > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware: fix the compiller warning
When I compile the kernel, found this warning:
In file included from arch/arm64/kernel/efi-stub.c:44:0:
arch/arm64/kernel/../../../drivers/firmware/efi/fdt.c: In function update_fdt:
arch/arm64/kernel/../../../drivers/firmware/efi/fdt.c:66:22: warning: unused
variable name [-Wunused-variable]
const char *type, *name;
so remove the unused variable and clean this warning.
Signed-off-by: Ding Tianhong
---
drivers/firmware/efi/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/fdt.c b/drivers/firmware/efi/fdt.c
index 5c6a8e8..82d7741 100644
--- a/drivers/firmware/efi/fdt.c
+++ b/drivers/firmware/efi/fdt.c
@@ -63,7 +63,7 @@ static efi_status_t update_fdt(efi_system_table_t *sys_table,
void *orig_fdt,
*/
prev = 0;
for (;;) {
- const char *type, *name;
+ const char *type;
int len;
node = fdt_next_node(fdt, prev, NULL);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/staging/board/board.c: In function 'find_by_address':
drivers/staging/board/board.c:14:3: error: implicit declaration of function
'of_can_translate_address' [-Werror=implicit-function-declaration]
if (of_can_translate_address(dn)
^
Caused by commit 382063d91e15 ("staging: board: Initial board staging
support").
I have disabled that driver for today.
From: Stephen Rothwell
Date: Fri, 20 Jun 2014 14:14:17 +1000
Subject: [PATCH] staging: board: disable
Signed-off-by: Stephen Rothwell
---
drivers/staging/board/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
index 09d94b48c9c9..7eda0b8b7aab 100644
--- a/drivers/staging/board/Kconfig
+++ b/drivers/staging/board/Kconfig
@@ -1,6 +1,7 @@
config STAGING_BOARD
boolean "Staging Board Support"
depends on OF_ADDRESS
+ depends on BROKEN
help
Select to enable per-board staging support code.
--
2.0.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] iovec: move memcpy_from/toiovecend to lib/iovec.c
From: "Michael S. Tsirkin" Date: Thu, 19 Jun 2014 21:22:56 +0300 > ERROR: "memcpy_fromiovecend" [drivers/vhost/vhost_scsi.ko] undefined! > > commit 9f977ef7b671f6169eca78bf40f230fe84b7c7e5 > vhost-scsi: Include prot_bytes into expected data transfer length > in target-pending makes drivers/vhost/scsi.c call memcpy_fromiovecend(). > This function is not available when CONFIG_NET is not enabled. > > socket.h already includes uio.h, so no callers need updating. > > Reported-by: Randy Dunlap > Cc: Stephen Rothwell > Cc: "David S. Miller" > Signed-off-by: Michael S. Tsirkin > --- > > David, could you please ack merging this through > target-pending to avoid dependency issues? Yep, this looks fine: Signed-off-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
staging driver patch queue is empty
Hi all, I've now caught up with all pending staging driver patches that I had, with the exception of 2 android binder patches that I want to get some review / acks from some android developers on before applying. If you have sent me a patch for the staging tree that has not been applied, consider it lost and please resend. 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: linux-next: the selinux tree needs cleaning up
Hi Serge, On Fri, 20 Jun 2014 05:43:56 +0200 "Serge E. Hallyn" wrote: > > The duplicates were the result of several misunderstandings and general > naivity all on my part. I'm actually still not clear on what usually > happens with the selinux tree - it feeds into linux-next, then gets > 'pull'ed by James into security-next for a pull request? Do you usually > send a request to James when ready, he pulls, then he sends pull request > to Linus? (Or am I wrong, and you usually send your own requests to > Linus?) If "you" is Paul, then I am pretty sure he asks James to pull and then James in turn asks Linus to pull. If "you" is me, then no :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH] mm: Write down design and intentions in English for proportial scan
On Fri, 20 Jun 2014 12:00:02 +0900 Minchan Kim wrote:
> By suggestion from Andrew, first of all, I try to add only comment
> but I believe we could make it more clear by some change like this.
> https://lkml.org/lkml/2014/6/16/750
>
> Anyway, push this patch firstly.
Thanks.
> = &< =
>
> >From b1fd007097064db34a211ffeacfe4da9fb22d49e Mon Sep 17 00:00:00 2001
> From: Minchan Kim
> Date: Fri, 20 Jun 2014 11:37:52 +0900
> Subject: [PATCH] mm: Write down design and intentions in English for
> proportial scan
>
> Quote from Andrew
> "
> That code is absolutely awful :( It's terribly difficult to work out
> what the design is - what the code is actually setting out to achieve.
> One is reduced to trying to reverse-engineer the intent from the
> implementation and that becomes near impossible when the
> implementation has bugs!
>
>
>
> The only way we're going to fix all this up is to stop looking at the
> code altogether. Write down the design and the intentions in English.
> Review that. Then implement that design in C
> "
>
> One thing I know it might not be English Andrew expected but other
> thing I know is there are lots of native people in here so one of them
> will spend his time to make this horrible English smooth.
>
> I alreday spent my time to try to fix this situation so it's your
> turn. It's good time balance between non-native and native people
> so open source community is fair for all of us.
>
I can do that ;) But not yet.
> ---
> mm/vmscan.c | 37 +++--
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 521f7eab1798..3a9862895a64 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2071,6 +2071,22 @@ static void shrink_lruvec(struct lruvec *lruvec,
> struct scan_control *sc)
>
> get_scan_count(lruvec, sc, nr);
>
> + /*
> + * Basically, VM scans file/anon LRU list proportionally
OK
> depending
> + * on the value of vm.swappiness
"depending" in what fashion? Higher swappiness leads to lengthier
scans. But there's this:
/*
* With swappiness at 100, anonymous and file have the same priority.
* This scanning priority is essentially the inverse of IO cost.
*/
anon_prio = sc->swappiness;
file_prio = 200 - anon_prio;
> but doesn't want to reclaim
> + * excessive pages. So, it might be better to stop scan as soon as
> + * we meet nr_to_reclaim
"scanning" does not equal "reclaiming", as not all scanned pages are
reclaimed. I guess we mean "stop scanning when nr_reclaimed pages have
been reclaimed".
> but it breaks aging balance between LRU lists
Why does it do this?
> + * To keep the balance, what we do is as follows.
> + *
> + * If we reclaim pages requested, we stop scanning first and
> + * investigate which LRU should be scanned more depending on
> + * remained lru size(ie, nr[xxx]). We will scan bigger one more
> + * so, final goal is
> + *
> + * scanned[xxx] = targets[xxx] - nr[xxx]
> + * targets[anon] : targets[file] = scanned[anon] : scanned[file]
> + */
hm, what's going on here. Something like this?
"after having scanned sufficient pages to reclaim nr_to_reclaim pages,
the LRUs will now be out of balance if many more pages were reclaimed
from one LRU than from the others. We now bring the LRUs back into
balance by ...".
I'm not sure this really makes sense from a *design* aspect. Is the
amount of scanning which we do here sufficiently large to have a
significant impact on the LRU sizes? I suppose yes, in rare cases.
How do we define "balance" anyway? Can we make some statement explaining
how the LRUs will appear when they are in a "balanced" state?
> /* Record the original scan target for proportional adjustments later */
> memcpy(targets, nr, sizeof(nr));
>
> @@ -2091,8 +2107,14 @@ static void shrink_lruvec(struct lruvec *lruvec,
> struct scan_control *sc)
> blk_start_plug();
> while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
> nr[LRU_INACTIVE_FILE]) {
> - unsigned long nr_anon, nr_file, percentage;
> + unsigned long nr_anon, nr_file;
> unsigned long nr_scanned;
> + /*
> + * How many pages we should scan to meet target
> + * calculated by get_scan_count. It means that
> + * (100 - percentage) = already scanned ratio
> + */
> + unsigned percentage;
Well, "percentage" is a ratio. So maybe "what proportion of the LRUs
we should scan to..."?
> for_each_evictable_lru(lru) {
> if (nr[lru]) {
> @@ -2108,11 +2130,10 @@ static void shrink_lruvec(struct lruvec *lruvec,
> struct scan_control *sc)
> continue;
>
> /*
> - * For kswapd and
Re: [PATCH] staging: rtl8192 Check for Null return from dev_skb_alloc
Our you Guys just removing me from your emails I have checked this patch
and it seems right. If you don't want to accept it , the less you can
do is give me a reply.
Nick
On Thu, Jun 19, 2014 at 10:12 PM, Nick Krause wrote:
> If anyone able to check this patch it would be great.
> Thanks Nick
>
> On Thu, Jun 19, 2014 at 5:18 PM, Nicholas Krause wrote:
>> Checks for Null return from dev_skb_alloc if it returns Null,
>> fw_download returns false. Otherwise it returns true.Also
>> removed rt_status due to returning true of false directly.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> index 1a95d1f..affa89a 100644
>> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
>> @@ -36,7 +36,6 @@ static bool fw_download_code(struct net_device *dev, u8
>> *code_virtual_address,
>> u32 buffer_len)
>> {
>> struct r8192_priv *priv = rtllib_priv(dev);
>> - boolrt_status = true;
>> u16 frag_threshold;
>> u16 frag_length, frag_offset = 0;
>> int i;
>> @@ -59,7 +58,9 @@ static bool fw_download_code(struct net_device *dev, u8
>> *code_virtual_address,
>> bLastIniPkt = 1;
>>
>> }
>>skb = dev_alloc_skb(frag_length + 4);
>> + if (!skb)
>> + return false;
>> memcpy((unsigned char *)(skb->cb), , sizeof(dev));
>> tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>> @@ -99,7 +100,7 @@ static bool fw_download_code(struct net_device *dev, u8
>> *code_virtual_address,
>>
>> write_nic_byte(dev, TPPoll, TPPoll_CQ);
>>
>> - return rt_status;
>> + return true;
>> }
>>
>> static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)
>> --
>> 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 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb
On 18 June 2014 12:14, Doug Anderson wrote: > From: Andrew Bresticker > > If we receive EC interrupts after the cros_ec driver has probed, but > before the cros_ec_keyb driver has probed, the cros_ec IRQ handler > will not run the cros_ec_keyb notifier and the EC will leave the IRQ > line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and > the resulting flood of interrupts causes the machine to hang. > > Since the EC interrupt is currently only used for the keyboard, move > the setup and handling of the EC interrupt to the cros_ec_keyb driver. > > Signed-off-by: Andrew Bresticker > Signed-off-by: Doug Anderson Reviewed-by: Simon Glass We never needed an EC-level interrupt, and have shipped at least three products now that use this code, so I think it is safe enough to declare that we won't need it. Regards, Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Quoting Stephen Rothwell (s...@canb.auug.org.au): > Hi Paul, > > On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore wrote: > > > > I want to avoid use a -rcX release as the foundation of any of my trees; > > the - > > rc releases aren't as stable and it goes against what we're trying to do > > with > > the different Linux Security trees. Unfortunately, based on what I've read > > above, this seems to be incompatible with linux-next. > > The problem with basing your development for v3.17 on v3.15 is that > you do not take into account any of the changes done by others during > v3.16-rc1 (or even your upstream tree) some of which may be core API > changes. > > > While I hate to split my development branch from the #next branch, it seems > > I don't want that either ... > > > like that is the only way to accomplish both a reasonably current and > > stable > > development tree and get the patches into linux-next. Unless you, or > > anyone > > else for that matter, has a different suggestion I'm going to go ahead and > > turn the current SELinux #next branch into a development branch and create > > a > > new #next branch that will be based on the most current -rc1, this new > > #next > > branch will be created new for each major release. Not exactly what I was > > hoping for, but will that work? > > Do you mean that your #next branch will just be a merge of -rc1 and > your development branch? That would not actually change anything > (except that you would possibly take care of some conflicts for me). > > At the core, what is in linux-next should just be exactly what will be > merged by your upstream. My real point here is that that is not what > has happened recently. The patches in your tree have been > cherry-picked or rebased into James' or Serge's trees, not merged so we > now have duplication. This is what you need to solve with James and > Serge. linux-next is a side issue - I can cope with a lot. The duplicates were the result of several misunderstandings and general naivity all on my part. I'm actually still not clear on what usually happens with the selinux tree - it feeds into linux-next, then gets 'pull'ed by James into security-next for a pull request? Do you usually send a request to James when ready, he pulls, then he sends pull request to Linus? (Or am I wrong, and you usually send your own requests to Linus?) -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/
Re: [PATCH v2 08/10] mfd: cros_ec: Check result code from EC messages
On 18 June 2014 12:14, Doug Anderson wrote: > From: Bill Richardson > > Just because the host was able to talk to the EC doesn't mean that the EC > was happy with what it was told. Errors in communincation are not the same > as error messages from the EC itself. > > This change lets the EC report its errors separately. > > [dianders: Added common function to cros_ec.c] > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson This is better. Reviewed-by: Simon Glass -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 05/10] mfd: cros_ec: Use struct cros_ec_command to communicate with the EC
On 18 June 2014 12:14, Doug Anderson wrote: > From: Bill Richardson > > This is some internal structure reorganization / renaming to prepare > for future patches that will add a userspace API to cros_ec. There > should be no visible changes. > > Signed-off-by: Bill Richardson > Signed-off-by: Doug Anderson > Acked-by: Lee Jones Reviewed-by: Simon Glass -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv2] of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch
On Thu, 19 Jun 2014, Laura Abbott wrote:
> The common early_init_dt_add_memory_arch takes the base and size
> of a memory region as u64 types. The function never checks if
> the base and size can actually fit in a phys_addr_t which may
> be smaller than 64-bits. This may result in incorrect memory
> being passed to memblock_add if the memory falls outside the
> range of phys_addr_t. Add range checks for the base and size if
> phys_addr_t is smaller than u64.
>
> Reported-by: Geert Uytterhoeven
> Tested-by: Geert Uytterhoeven
> Signed-off-by: Laura Abbott
Acked-by: Nicolas Pitre
> ---
> v2: Switched to sizeof(phys_addr_t) < sizeof(u64) instead of macros.
> Sending to right e-mails/mailing lists this time.
>
> drivers/of/fdt.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index c4cddf0..b777d8f 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -880,6 +880,21 @@ void __init __weak early_init_dt_add_memory_arch(u64
> base, u64 size)
> const u64 phys_offset = __pa(PAGE_OFFSET);
> base &= PAGE_MASK;
> size &= PAGE_MASK;
> +
> + if (sizeof(phys_addr_t) < sizeof(u64)) {
> + if (base > ULONG_MAX) {
> + pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
> + base, base + size);
> + return;
> + }
> +
> + if (base + size > ULONG_MAX) {
> + pr_warning("Ignoring memory range 0x%lx - 0x%llx\n",
> + ULONG_MAX, base + size);
> + size = ULONG_MAX - base;
> + }
> + }
> +
> if (base + size < phys_offset) {
> pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
> base, base + size);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 03/10] x86, mpx: add macro cpu_has_mpx
On 06/19/2014 11:50 AM, Dave Hansen wrote: > On 06/19/2014 11:02 AM, H. Peter Anvin wrote: >> On 06/18/2014 09:25 AM, Dave Hansen wrote: >>> How about something like the attached patch? >>> >>> This lets us use static_cpu_has() for the checks, and allows us to >>> easily add new checks for other features that might be compile-time >>> disabled. >> >> Hmm... I would like something similar to required-features.h which >> reflect features which *cannot* be enabled or will always be ignored; we >> actually already have a handful of those > > Could you elaborate a bit? I'll try and include them in the approach to > make sure it works broadly. > > Is there a benefit to the required-features.h approach that's missing > from mine? I _believe_ all of the compiler optimization around > __builtin_constant_p() continues to work with the inline function > instead of the #defines and bitmasks. I think the inline function > approach is a bit easier to work with. > > Could the required-features.h approach just be from a time before > __builtin_constant_p() worked well across inlines? > Not so much. What I don't want is one approach for doing things in one direction and another approach for the other direction. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] NFC: Read frag at a time when sending packets
Right now userspace can pass a large chunk of data and the kernel
will attempt to allocate all of it to copy it in from userspace.
The problem is that there is no upper limit on the size userspace
can pass. Right now userspace can even force a machine to run out
of memory by forcing the kernel to allocate large chunks of memory.
To avoid imposing a limit, instead of allocating the entire block,
we can allocate just the size of the biggest frag possible and read
it from userspace one frag at a time.
Signed-off-by: Sasha Levin
---
** WARNING: COMPLETELY UNTESTED ** (I don't have the hardware).
net/nfc/llcp_commands.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index a3ad69a..da68924 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -727,27 +727,27 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8
ssap, u8 dsap,
if (local == NULL)
return -ENODEV;
- msg_data = kzalloc(len, GFP_KERNEL);
+ remote_miu = sock->remote_miu > LLCP_MAX_MIU ?
+ local->remote_miu : sock->remote_miu;
+
+ msg_data = kzalloc(remote_miu, GFP_KERNEL);
if (msg_data == NULL)
return -ENOMEM;
- if (memcpy_fromiovec(msg_data, msg->msg_iov, len)) {
- kfree(msg_data);
- return -EFAULT;
- }
-
remaining_len = len;
msg_ptr = msg_data;
do {
- remote_miu = sock->remote_miu > LLCP_MAX_MIU ?
- local->remote_miu : sock->remote_miu;
-
frag_len = min_t(size_t, remote_miu, remaining_len);
pr_debug("Fragment %zd bytes remaining %zd",
frag_len, remaining_len);
+ if (memcpy_fromiovec(msg_data, msg->msg_iov, frag_len)) {
+ kfree(msg_data);
+ return -EFAULT;
+ }
+
pdu = nfc_alloc_send_skb(sock->dev, >sk, MSG_DONTWAIT,
frag_len + LLCP_HEADER_SIZE, );
if (pdu == NULL) {
--
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] vfio: Fix endianness handling for emulated BARs
On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote: > On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote: > > On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote: > >> On 06/19/2014 04:35 AM, Alex Williamson wrote: > >>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote: > VFIO exposes BARs to user space as a byte stream so userspace can > read it using pread()/pwrite(). Since this is a byte stream, VFIO should > not do byte swapping and simply return values as it gets them from > PCI device. > > Instead, the existing code assumes that byte stream in read/write is > little-endian and it fixes endianness for values which it passes to > ioreadXX/iowriteXX helpers. This works for little-endian as PCI is > little endian and le32_to_cpu/... are stubs. > >>> > >>> vfio read32: > >>> > >>> val = cpu_to_le32(ioread32(io + off)); > >>> > >>> Where the typical x86 case, ioread32 is: > >>> > >>> #define ioread32(addr) readl(addr) > >>> > >>> and readl is: > >>> > >>> __le32_to_cpu(__raw_readl(addr)); > >>> > >>> So we do canceling byte swaps, which are both nops on x86, and end up > >>> returning device endian, which we assume is little endian. > >>> > >>> vfio write32 is similar: > >>> > >>> iowrite32(le32_to_cpu(val), io + off); > >>> > >>> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel > >>> out, so input data is device endian, which is assumed little. > >>> > This also works for big endian but rather by an accident: it reads 4 > bytes > from the stream (@val is big endian), converts to CPU format (which > should > be big endian) as it was little endian (@val becomes actually little > endian) and calls iowrite32() which does not do swapping on big endian > system. > >>> > >>> Really? > >>> > >>> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around > >>> writel(), which seems to use the generic implementation, which does > >>> include a cpu_to_le32. > >> > >> > >> Ouch, wrong comment. iowrite32() does swapping. My bad. > >> > >> > >>> > >>> I also see other big endian archs like parisc doing cpu_to_le32 on > >>> iowrite32, so I don't think this statement is true. I imagine it's > >>> probably working for you because the swap cancel. > >>> > This removes byte swapping and makes use ioread32be/iowrite32be > (and 16bit versions) on big-endian systems. The "be" helpers take > native endian values and do swapping at the moment of writing to a PCI > register using one of "store byte-reversed" instructions. > >>> > >>> So now you want iowrite32() on little endian and iowrite32be() on big > >>> endian, the former does a cpu_to_le32 (which is a nop on little endian) > >>> and the latter does a cpu_to_be32 (which is a nop on big endian)... > >>> should we just be using __raw_writel() on both? > >> > >> > >> We can do that too. The beauty of iowrite32be on ppc64 is that it does not > >> swap and write separately, it is implemented via the "Store Word > >> Byte-Reverse Indexed X-form" single instruction. > >> > >> And some archs (do not know which ones) may add memory barriers in their > >> implementations of ioread/iowrite. __raw_writel is too raw :) > >> > >>> There doesn't actually > >>> seem to be any change in behavior here, it just eliminates back-to-back > >>> byte swaps, which are a nop on x86, but not power, right? > >> > >> Exactly. No dependency for QEMU. > > > > How about that: > > === > > > > VFIO exposes BARs to user space as a byte stream so userspace can > > read it using pread()/pwrite(). Since this is a byte stream, VFIO should > > not do byte swapping and simply return values as it gets them from > > PCI device. > > > > Instead, the existing code assumes that byte stream in read/write is > > little-endian and it fixes endianness for values which it passes to > > ioreadXX/iowriteXX helpers in native format. The IO helpers do swapping > > again. Since both byte swaps are nops on little-endian host, this works. > > > > This also works for big endian but rather by an accident: it reads 4 bytes > > from the stream (@val is big endian), converts to CPU format (which should > > be big endian) as it was little endian (and @val becomes actually little > > endian) and calls iowrite32() which does swapping on big endian > > system again. So byte swap gets cancelled, __raw_writel() receives > > a native value and then > > *(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v; > > just does the right thing. > > I am wrong here, sorry. This is what happens when you watch soccer between > 2am and 4am :) > > > > > > This removes byte swaps and makes use of ioread32be/iowrite32be > > (and 16bit versions) which do explicit byte swapping at the moment > > of write to a PCI register. PPC64 uses a special "Store Word > > Byte-Reverse Indexed X-form" instruction which does swap and store. > > No swapping is done here if we use ioread32be as it
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hello Tomasz,
On 20 June 2014 06:00, Tomasz Figa wrote:
> On 20.06.2014 02:28, Chanwoo Choi wrote:
>> On 06/20/2014 09:24 AM, Tomasz Figa wrote:
>>> On 20.06.2014 02:22, Chanwoo Choi wrote:
Hi Tomasz,
On 06/18/2014 04:58 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk
>> framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to
>> internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc'
>> clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
>> 'sclk_adc'
>> clock in FSYS_BLK.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 93
>> ++--
>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index c30def6..6b026ac 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -41,7 +41,8 @@
>>
>> enum adc_version {
>> ADC_V1,
>> - ADC_V2
>> + ADC_V2,
>> + ADC_V2_EXYNOS3250,
>> };
>>
>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>> @@ -85,9 +86,11 @@ enum adc_version {
>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>
>> struct exynos_adc {
>> + struct device *dev;
>> void __iomem*regs;
>> void __iomem*enable_reg;
>> struct clk *clk;
>> + struct clk *sclk;
>> unsigned intirq;
>> struct regulator*vdd;
>> struct exynos_adc_ops *ops;
>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>
>> u32 value;
>> unsigned intversion;
>> + boolneeds_sclk;
>
> This should be rather a part of the variant struct. See my comments to
> patch 1/4.
OK, I'll include 'needs_sclk' in "variant" structure.
>
>> };
>>
>> struct exynos_adc_ops {
>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>> void (*clear_irq)(struct exynos_adc *info);
>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> void (*stop_conv)(struct exynos_adc *info);
>> + void (*disable_clk)(struct exynos_adc *info);
>> + int (*enable_clk)(struct exynos_adc *info);
>> };
>>
>> static const struct of_device_id exynos_adc_match[] = {
>> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> + {
>> + .compatible = "samsung,exynos-adc-v1",
>> + .data = (void *)ADC_V1,
>> + }, {
>> + .compatible = "samsung,exynos-adc-v2",
>> + .data = (void *)ADC_V2,
>> + }, {
>> + .compatible = "samsung,exynos3250-adc-v2",
>> + .data = (void *)ADC_V2_EXYNOS3250,
>> + },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
>> exynos_adc *info)
>> writel(con, ADC_V1_CON(info->regs));
>> }
>>
>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>> +{
>> + if (info->needs_sclk)
>> + clk_disable_unprepare(info->sclk);
>> + clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>> +{
>> + int ret;
>> +
>> + ret = clk_prepare_enable(info->clk);
>> + if (ret) {
>> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (info->needs_sclk) {
>> + ret = clk_prepare_enable(info->sclk);
>> + if (ret) {
>> + clk_disable_unprepare(info->clk);
>> + dev_err(info->dev,
>> + "failed enabling sclk_tsadc clock: %d\n", ret);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>> .init_hw= exynos_adc_v1_init_hw,
>> .clear_irq = exynos_adc_v1_clear_irq,
>> .start_conv = exynos_adc_v1_start_conv,
>> .stop_conv = exynos_adc_v1_stop_conv,
>> + .disable_clk= exynos_adc_disable_clk,
>> + .enable_clk =
RE: [PATCH v6 07/10] x86, mpx: decode MPX instruction to get bound violation information
On 2014-06-20, H. Peter Anvin wrote: > On 06/19/2014 10:04 AM, Dave Hansen wrote: >> >> Could you please support this position with some data? I'm a bit >> skeptical that instruction decoding is going to be a >> performance-critical path. >> >> I also don't see the extra field that you talked about in the >> previous thread? What's the extra field? I see a 'limit' vs. >> 'length', but you don't use 'length' at all, so I think you can use >> it instead, or at least union it. >> >> I've taken a quick stab at trying to consolidate things. I think I >> may have screwed up this: >> >> insn->limit = MAX_MPX_INSN_SIZE - bytes; >> >> Qiaowei, is there anything fundamentally broken with what I've got here? >> > Firstly instructions will be got from user pointer stored in 'ip', and then validate_next() will use 'limit' to make sure that next sizeof(t) bytes can be on the same instruction. As hpa said, generic decoder, including struct insn and implementation of decoding, is very heavyweight because it has to. So MPX specific decoding should be better choice. > So I encouraged Qiaowei to do a limited special-purpose decoder, > simply because the glue to use the generic decoder was almost as > large. I am overall not a huge fan of using the generic decoder in > constrained situation, because the generic decoder is very heavyweight > not just in terms of performance but in terms of interface -- because it has > to. > Thanks, Qiaowei
Re: [RFC PATCH 1/1] Move two pinned pages to non-movable node in kvm.
Hi Marcelo, Thanks for your reply. Please see below. On 06/20/2014 03:00 AM, Marcelo Tosatti wrote: .. Remove pinning is preferable. In fact looks like for identity pagetable it should be trivial, just don't pin. APIC access page is a little bit more complicated since its physical address needs to be tracked to be updated in VMCS. Yes, and there are new users of page pinning as well soon (see PEBS threads on kvm-devel). Was thinking of notifiers scheme. Perhaps: ->begin_page_unpin(struct page *page) - Remove any possible access to page. ->end_page_unpin(struct page *page) - Reinstantiate any possible access to page. For KVM: ->begin_page_unpin() - Remove APIC-access page address from VMCS. or - Remove spte translation to pinned page. - Put vcpu in state where no VM-entries are allowed. ->end_page_unpin() - Setup APIC-access page, ... - Allow vcpu to VM-entry. Because allocating APIC access page from distant NUMA node can be a performance problem, i believe. Yes, I understand this. I'd be happy to know why notifiers are overkill. The notifiers are not overkill. I have been thinking about a similar idea. In fact, we have met the same pinned pages problem in AIO subsystem. The aio ring pages are pinned in memory, and cannot be migrated. And in kernel, I believe, there are some other places where pages are pinned. So I was thinking a notifier framework to solve this problem. But I can see some problems: 1. When getting a page, migration thread doesn't know who is using this page and how. So we need a callback for each page to be called before and after it is migrated. (A little over thinking, maybe. Please see below.) 2. When migrating a shared page, one callback is not enouch because the page could be shared by different subsystems. They may have different ways to pin and unpin the page. 3. Where should we put the callback? Only file backing pages have one and only one address_space->address_space_operations->migratepage(). For anonymous pages, nowhere to put the callback. (A basic idea: define a global radix tree or hash table to manage the pinned pages and their callbacks. Mel Gorman mentioned this idea when handling the aio ring page problem. I'm not sure if this is acceptable.) The idea above may be a little over thinking. Actually we can reuse the memory hotplug notify chain if the pinned page migration is only used by memory hotplug subsystem. The basic idea is: Each subsystem register a callback to memory hotplug notify chain, and unpin and repin the pages before and after page migration. But I think, finally we will met this problem: How to remember/manage the pinned pages in each subsystem. For example, for kvm, ept identity pagetable page and apic page are pinned. Since these two pages' struct_page pointer and user_addr are remember in kvm, they are easy to handle. If we pin a page and remember it only in a stack variable, it could be difficult to handle. For now for kvm, I think notifiers can solve this problem. Thanks for the advice. If you guys have any idea about this probelm, please share with me. 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 -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts
(2014/06/19 23:18), Josh Poimboeuf wrote:
> On Thu, Jun 19, 2014 at 02:03:31PM +0900, Masami Hiramatsu wrote:
>> (2014/06/19 11:08), Josh Poimboeuf wrote:
>>> On Tue, Jun 17, 2014 at 11:04:36AM +, Masami Hiramatsu wrote:
Hi,
Here is the version 2 of the series of patches which introduces
IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
who can modify regs->ip in their handler.
In this version, I fixed some bugs in previous version and
added a patch which made kprobe itself free from IPMODIFY
except for jprobe.
>>>
>>> Hi Masami,
>>>
>>> This seems better, but I still saw a few issues. I'm not sure if the
>>> issues are specific to stap or kprobes. For the following issues I used
>>> this command to set a kprobe:
>>>
>>> stap -v -e 'probe kernel.function("meminfo_proc_show")
>>> {printf("meminfo_proc_show called\n");}'
>>>
>>> With patches 1-2, when I used stap to kprobe the function after it was
>>> already kpatched, stap didn't return an error and instead acted like it
>>> succeeded (though the probe didn't work):
>>>
>>> $ sudo stap -v -e 'probe kernel.function("meminfo_proc_show")
>>> {printf("meminfo_proc_show called\n");}'
>>> Pass 1: parsed user script and 112 library script(s) using
>>> 221516virt/41612res/6028shr/36228data kb, in 130usr/0sys/132real ms.
>>> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0
>>> global(s) using 255840virt/77132res/7132shr/70552data kb, in
>>> 510usr/20sys/577real ms.
>>> Pass 3: translated to C into
>>> "/tmp/stap3Qunba/stap_2690192fea570fb7bba78c7ed7fa1e0d_898_src.c" using
>>> 255840virt/77392res/7392shr/70552data kb, in 10usr/0sys/4real ms.
>>> Pass 4: compiled C into "stap_2690192fea570fb7bba78c7ed7fa1e0d_898.ko" in
>>> 5020usr/640sys/7105real ms.
>>> Pass 5: starting run.
>>> (no error)
>>
>> Yeah, I guess you can see some warning messages in dmesg (by
>> arm_kprobe) at this point.
>
> Ah, you're right:
>
> Jun 19 08:03:10 treble kernel: [ cut here ]
> Jun 19 08:03:10 treble kernel: WARNING: CPU: 1 PID: 17991 at
> kernel/kprobes.c:953 arm_kprobe+0xa7/0xe0()
> Jun 19 08:03:10 treble kernel: Failed to init kprobe-ftrace (-16)
> Jun 19 08:03:10 treble kernel: Modules linked in:
> stap_1faf9cc0ccf85c0d203c74ab6f604b_17991(OE) ...defra
> Jun 19 08:03:10 treble kernel: videobuf2_vmalloc serio_raw microcode
> sdhci_pci bluetooth videobuf2_m...
> Jun 19 08:03:10 treble kernel: CPU: 1 PID: 17991 Comm: stapio Tainted: G
> U W OE 3.15.0+ #1
> Jun 19 08:03:10 treble kernel: Hardware name: LENOVO 2356BH8/2356BH8, BIOS
> G7ET63WW (2.05 ) 11/12/2012
> Jun 19 08:03:10 treble kernel: 9023f19e
> 8803dcce7d80 816f31fd
> Jun 19 08:03:10 treble kernel: 8803dcce7dc8 8803dcce7db8
> 8108914d a08248e0
> Jun 19 08:03:10 treble kernel: a08248f0
>
> Jun 19 08:03:10 treble kernel: Call Trace:
> Jun 19 08:03:10 treble kernel: [] dump_stack+0x45/0x56
> Jun 19 08:03:10 treble kernel: []
> warn_slowpath_common+0x7d/0xa0
> Jun 19 08:03:10 treble kernel: []
> warn_slowpath_fmt+0x5c/0x80
> Jun 19 08:03:10 treble kernel: [] arm_kprobe+0xa7/0xe0
> Jun 19 08:03:10 treble kernel: []
> register_kprobe+0x557/0x5d0
> Jun 19 08:03:10 treble kernel: [] ?
> meminfo_proc_open+0x30/0x30
> Jun 19 08:03:10 treble kernel: []
> _stp_ctl_write_cmd+0x8d5/0x930 [stap_1faf9c...7991]
> Jun 19 08:03:10 treble kernel: [] vfs_write+0xba/0x1e0
> Jun 19 08:03:10 treble kernel: [] SyS_write+0x55/0xd0
> Jun 19 08:03:10 treble kernel: []
> system_call_fastpath+0x16/0x1b
> Jun 19 08:03:10 treble kernel: ---[ end trace 19615ed55413a30d ]---
>
> Why not change arm_kprobe() to return an error?
Actually, arm_kprobe() is widely used at deeper point.
And the 3rd patch will solve the problem. So I decided just adding
IPMODIFY flag at the 2nd patch.
>>> With all 3 patches, I expected kprobes and kpatch to be able to ftrace
>>> the same function. But when I tried to kpatch the function after it was
>>> kprobed, I got the following oops in stap:
>>>
>>> [ 455.842797] BUG: unable to handle kernel NULL pointer dereference at
>>> 0020
>>> [ 455.843388] IP: [] _stp_module_notifier+0x1e/0x320
>>> [stap_2690192fea570fb7bba78c7ed7fa1e_20189]
>>
>> Hmm, since this happens in _stp_module_notifier() which is a code in
>> systemtap,
>> I guess it's a systemtap problem.
>>
>> Could you test it with kprobe-tracer as below?
>>
>> # (do something kpatch related activation)
>> # echo p meminfo_proc_show > /sys/kernel/debug/tracing/kprobe_events
>> # echo 1 > /sys/kernel/debug/tracing/events/kprobe/enable
>
> That worked, thanks.
Moreover, I couldn't reproduced the stap case on my fedora20.
Perhaps, Maybe a different version of systemtap I used.
Thank you,
--
Masami HIRAMATSU
Software Platform Research
[PATCHv2] of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch
The common early_init_dt_add_memory_arch takes the base and size
of a memory region as u64 types. The function never checks if
the base and size can actually fit in a phys_addr_t which may
be smaller than 64-bits. This may result in incorrect memory
being passed to memblock_add if the memory falls outside the
range of phys_addr_t. Add range checks for the base and size if
phys_addr_t is smaller than u64.
Reported-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Laura Abbott
---
v2: Switched to sizeof(phys_addr_t) < sizeof(u64) instead of macros.
Sending to right e-mails/mailing lists this time.
drivers/of/fdt.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..b777d8f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,6 +880,21 @@ void __init __weak early_init_dt_add_memory_arch(u64 base,
u64 size)
const u64 phys_offset = __pa(PAGE_OFFSET);
base &= PAGE_MASK;
size &= PAGE_MASK;
+
+ if (sizeof(phys_addr_t) < sizeof(u64)) {
+ if (base > ULONG_MAX) {
+ pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
+ base, base + size);
+ return;
+ }
+
+ if (base + size > ULONG_MAX) {
+ pr_warning("Ignoring memory range 0x%lx - 0x%llx\n",
+ ULONG_MAX, base + size);
+ size = ULONG_MAX - base;
+ }
+ }
+
if (base + size < phys_offset) {
pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
base, base + size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] perf bench: Add --repeat option
On Thu, 2014-06-19 at 23:51 +, Namhyung Kim wrote: > Hi Davidlohr, > > On Thu, Jun 19, 2014 at 11:45 AM, Davidlohr Bueso wrote: > > Hi Namhyung, > > > > On Thu, 2014-06-19 at 15:14 +0900, Namhyung Kim wrote: > >> By adding a top-level option, I think it should be applied to all > >> benchmaks - but I guess it only supports sched messaging and futex, > >> right? > > > > Yes, for now only those. While there is opportunity for others to use it > > as well (perhaps shed-pipe & memcpy/memset), I don't think *all* > > benchmarks need multiple runs, ie: numa. > > Hmm.. but it'd make users confusing if one runs the numa benchmark > with -r 5 option but it only do a single run.. Yeah, it crossed my mind. For that to be addressed, we would have to come up with a way to determine if the argument was passed, and just inform the user that it is not [currently(?)] supported. Some alternatives would be to (i) explicitly document it, and/or (ii) print out the amount of runs that will be made and if that option is supported. All in all I think we need a better infrastructure for such things. I feel perf-bench suffers fundamental design issues and tries to cover too much. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: Write down design and intentions in English for proportial scan
On Thu, Jun 19, 2014 at 01:13:22PM -0700, Andrew Morton wrote:
> On Thu, 19 Jun 2014 10:02:39 +0900 Minchan Kim wrote:
>
> > > > @@ -2057,8 +2057,7 @@ out:
> > > > static void shrink_lruvec(struct lruvec *lruvec, struct scan_control
> > > > *sc)
> > > > {
> > > > unsigned long nr[NR_LRU_LISTS];
> > > > - unsigned long targets[NR_LRU_LISTS];
> > > > - unsigned long nr_to_scan;
> > > > + unsigned long file_target, anon_target;
> > > >
> > > > >From the above snippet, we can know that the "percent" locals come from
> > > > targets[NR_LRU_LISTS]. So this fix does not increase the stack.
> > >
> > > OK. But I expect the stack use could be decreased by using more
> > > complex expressions.
> >
> > I didn't look at this patch yet but want to say.
> >
> > The expression is not easy to follow since several people already
> > confused/discuss/fixed a bit so I'd like to put more concern to clarity
> > rather than stack footprint.
>
> That code is absolutely awful :( It's terribly difficult to work out
> what the design is - what the code is actually setting out to achieve.
> One is reduced to trying to reverse-engineer the intent from the
> implementation and that becomes near impossible when the
> implementation has bugs!
>
> Look at this miserable comment:
>
> /*
>* For kswapd and memcg, reclaim at least the number of pages
>* requested. Ensure that the anon and file LRUs are scanned
>* proportionally what was requested by get_scan_count(). We
>* stop reclaiming one LRU and reduce the amount scanning
>* proportional to the original scan target.
>*/
>
>
> > For kswapd and memcg, reclaim at least the number of pages
> > requested.
>
> *why*?
>
> > Ensure that the anon and file LRUs are scanned
> > proportionally what was requested by get_scan_count().
>
> Ungramattical. Lacks specificity. Fails to explain *why*.
>
> > We stop reclaiming one LRU and reduce the amount scanning
> > proportional to the original scan target.
>
> Ungramattical. Lacks specificity. Fails to explain *why*.
>
>
> The only way we're going to fix all this up is to stop looking at the
> code altogether. Write down the design and the intentions in English.
> Review that. Then implement that design in C.
>
> So review and understanding of this code then is a two-stage thing.
> First, we review and understand the *design*, as written in English.
> Secondly, we check that the code faithfully implements that design.
> This second step becomes quite trivial.
>
>
> That may all sound excessively long-winded and formal, but
> shrink_lruvec() of all places needs such treatment. I am completely
> fed up with peering at the code trying to work out what on earth people
> were thinking when they typed it in :(
>
>
> So my suggestion is: let's stop fiddling with the code. Someone please
> prepare a patch which fully documents the design and let's get down and
> review that. Once that patch is complete, let's then start looking at
> the implementation.
>
By suggestion from Andrew, first of all, I try to add only comment
but I believe we could make it more clear by some change like this.
https://lkml.org/lkml/2014/6/16/750
Anyway, push this patch firstly.
= &< =
>From b1fd007097064db34a211ffeacfe4da9fb22d49e Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Fri, 20 Jun 2014 11:37:52 +0900
Subject: [PATCH] mm: Write down design and intentions in English for
proportial scan
Quote from Andrew
"
That code is absolutely awful :( It's terribly difficult to work out
what the design is - what the code is actually setting out to achieve.
One is reduced to trying to reverse-engineer the intent from the
implementation and that becomes near impossible when the
implementation has bugs!
The only way we're going to fix all this up is to stop looking at the
code altogether. Write down the design and the intentions in English.
Review that. Then implement that design in C
"
One thing I know it might not be English Andrew expected but other
thing I know is there are lots of native people in here so one of them
will spend his time to make this horrible English smooth.
I alreday spent my time to try to fix this situation so it's your
turn. It's good time balance between non-native and native people
so open source community is fair for all of us.
Signed-off-by: Minchan Kim
---
mm/vmscan.c | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 521f7eab1798..3a9862895a64 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2071,6 +2071,22 @@ static void shrink_lruvec(struct lruvec *lruvec, struct
scan_control *sc)
get_scan_count(lruvec, sc, nr);
+ /*
+* Basically, VM scans file/anon LRU list proportionally depending
+* on the value of vm.swappiness but
Re: [PATCH 0/3] Remove devm_request_and_ioremap()
On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote: > On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote: > > > > Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of > > devm_request_and_ioremap, yet some remains are still left. Remove the last > > two > > users, and let the function rest in peace. I'd suggest that this series is > > picked up as a whole to have that case finally closed. Greg? Are you > > interested > > in picking it up? > > (+cc Greg Kroah-Hartman) > > I already sent the same patch as one single patch to Greg Kroah-Hartman. [1] > Also, it was accepted by Greg Kroah-Hartman. [2] Thank you. > > [1] https://lkml.org/lkml/2014/6/11/26 > [2] https://lkml.org/lkml/2014/6/11/649 Yeah, I'll go apply that right now while I'm remembering it :) 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 -tip v2 2/3] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict
On Tue, 17 Jun 2014 11:04:49 +
Masami Hiramatsu wrote:
> Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
> ftrace users who may modify regs->ip to change the execution
> path. This also adds the flag to kprobe_ftrace_ops, since
> ftrace-based kprobes already modifies regs->ip. Thus, if
> another user modifies the regs->ip on the same function entry,
> one of them will be broken. So both should add IPMODIFY flag
> and make sure that ftrace_set_filter_ip() succeeds.
>
> Note that currently conflicts of IPMODIFY are detected on the
> filter hash. It does NOT care about the notrace hash. This means
> that if you set filter hash all functions and notrace(mask)
> some of them, the IPMODIFY flag will be applied to all
> functions.
Hmm, this worries me. I'm not sure I care about ignoring the notrace
hash.
>
> Changes in v2:
> - Add a description how __ftrace_hash_update_ipmodify() will
>handle the given hashes (NULL and EMPTY_HASH cases).
> - Clear FTRACE_OPS_FL_ENABLED after calling
>__unregister_ftrace_function() in error path.
>
> Signed-off-by: Masami Hiramatsu
> Cc: Ananth N Mavinakayanahalli
> Cc: Steven Rostedt
> Cc: Josh Poimboeuf
> Cc: Namhyung Kim
> ---
> Documentation/trace/ftrace.txt |5 ++
> include/linux/ftrace.h | 10 ++-
> kernel/kprobes.c |2 -
> kernel/trace/ftrace.c | 133
> +++-
> 4 files changed, 145 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
> index 2479b2a..0fcad7d 100644
> --- a/Documentation/trace/ftrace.txt
> +++ b/Documentation/trace/ftrace.txt
> @@ -234,6 +234,11 @@ of ftrace. Here is a list of some of the key files:
> will be displayed on the same line as the function that
> is returning registers.
>
> + If the callback registered to be traced by a function with
> + the "ip modify" attribute (thus the regs->ip can be changed),
> + a 'I' will be displayed on the same line as the function that
> + can be overridden.
> +
>function_profile_enabled:
>
> When set it will enable all functions with either the function
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 404a686..5a43f8f 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -90,6 +90,9 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned
> long parent_ip,
> * INITIALIZED - The ftrace_ops has already been initialized (first use time
> *register_ftrace_function() is called, it will initialized the
> ops)
> * DELETED - The ops are being deleted, do not let them be registered again.
> + * IPMODIFY - The ops can modify IP register. This must be set with SAVE_REGS
> + *and if the other ops has been set this on same function, filter
> + *update must be failed.
> */
> enum {
> FTRACE_OPS_FL_ENABLED = 1 << 0,
> @@ -101,6 +104,7 @@ enum {
> FTRACE_OPS_FL_STUB = 1 << 6,
> FTRACE_OPS_FL_INITIALIZED = 1 << 7,
> FTRACE_OPS_FL_DELETED = 1 << 8,
> + FTRACE_OPS_FL_IPMODIFY = 1 << 9,
> };
>
> /*
> @@ -306,6 +310,7 @@ extern int ftrace_nr_registered_ops(void);
> * the dyn_ftrace descriptor represents.
> *
> * The second part is a mask:
> + * IPMODIFY - the record wants to change IP address.
> * ENABLED - the function is being traced
> * REGS- the record wants the function to save regs
> * REGS_EN - the function is set up to save regs.
> @@ -317,13 +322,14 @@ extern int ftrace_nr_registered_ops(void);
> * from tracing that function.
> */
> enum {
> + FTRACE_FL_IPMODIFY = (1UL << 28),
> FTRACE_FL_ENABLED = (1UL << 29),
> FTRACE_FL_REGS = (1UL << 30),
> FTRACE_FL_REGS_EN = (1UL << 31)
> };
>
> -#define FTRACE_FL_MASK (0x7UL << 29)
> -#define FTRACE_REF_MAX ((1UL << 29) - 1)
> +#define FTRACE_FL_MASK (0xfUL << 28)
> +#define FTRACE_REF_MAX ((1UL << 28) - 1)
Note, this is going to conflict with my queue for 3.17, as I'm starting
to write individual trampolines.
You can take a look at my ftrace/next branch, but be warned, it will
rebase.
>
> struct dyn_ftrace {
> unsigned long ip; /* address of mcount call-site */
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3214289..e52d86f 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -915,7 +915,7 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> #ifdef CONFIG_KPROBES_ON_FTRACE
> static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> .func = kprobe_ftrace_handler,
> - .flags = FTRACE_OPS_FL_SAVE_REGS,
> + .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
We probably should comment somewhere that once you set the IPMODIFY
flag (or do not set it), it should
[PATCH] staging: ion: fixup invalid kfree() calls on heap destroy
I've noticed that the last commit to ion_system_heap.c ('staging: ion:
optimize struct ion_system_heap') has an omission, so an invalid kfree()
gets called on ion_system_heap_destroy(). As ION system heap is never
destroyed until system shutdown, it may not cause any harm, but should
be fixed. I should have caught this before the merge, my bad.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_system_heap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index c826b4c..6b77c51 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -304,7 +304,6 @@ void ion_system_heap_destroy(struct ion_heap *heap)
for (i = 0; i < num_orders; i++)
ion_page_pool_destroy(sys_heap->pools[i]);
- kfree(sys_heap->pools);
kfree(sys_heap);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Remove devm_request_and_ioremap()
On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote: > > Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of > devm_request_and_ioremap, yet some remains are still left. Remove the last two > users, and let the function rest in peace. I'd suggest that this series is > picked up as a whole to have that case finally closed. Greg? Are you > interested > in picking it up? (+cc Greg Kroah-Hartman) I already sent the same patch as one single patch to Greg Kroah-Hartman. [1] Also, it was accepted by Greg Kroah-Hartman. [2] Thank you. [1] https://lkml.org/lkml/2014/6/11/26 [2] https://lkml.org/lkml/2014/6/11/649 Best regards, Jingoo Han > >Wolfram > > > Tushar Behera (2): > DRM: Armada: Use devm_ioremap_resource > lib: devres: Remove deprecated devm_request_and_ioremap > > Wolfram Sang (1): > bus: brcmstb_gisb: Use devm_ioremap_resource > > Documentation/driver-model/devres.txt | 1 - > drivers/bus/brcmstb_gisb.c| 6 +++--- > drivers/gpu/drm/armada/armada_crtc.c | 8 +++- > include/linux/device.h| 2 -- > lib/devres.c | 28 > 5 files changed, 6 insertions(+), 39 deletions(-) > > -- > 2.0.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: [RFD] sched/deadline: EDF dynamic quota design
On 2014/6/19 17:13, Luca Abeni wrote: On 06/18/2014 09:01 AM, xiaofeng.yan wrote: [...] I also had an implementation of the GRUB algorithm (based on a modification of my old CBS scheduler for Linux), but the computational complexity of the algorithm was too high. That's why I never proposed to merge it in SCHED_DEADLINE. But maybe there can be some trade-off between the "exact compliance with the GRUB algorithm" and implementation efficiency that can make it acceptable... Has these codes been opened about the implementation in some community or not ? The old GRUB scheduler for Linux was used for some experiments published in a paper at RTLWS 2007, and of course the code was open-source (released under GPL). It required a patch for the Linux kernel (I used a 2.6.something kernel) which allowed to load the scheduler as a kernel module (yes, I know this is the wrong way to go... But implementing it like this was simpler :). That is very old code... I probably still have it somewhere, but I have to search for it. If someone is interested, I can try to search (the story of the user-space daemon for adaptive reservations is similar: I released it as open-source years ago... If anyone is interested I can search for this code too) Luca I'm glad that you reply this email. yes, I'm so interesting about your solution. In fact , there are scenarios in our product. Could you send me a link if you have? I can test your solution in our scene if you like. Ok, so I found my old code for the CBS scheduler with GRUB modifications. You can get it from here: http://disi.unitn.it/~abeni/old-cbs-scheduler.tgz Please note that: 1) This is old code (for 2.6.x kernels), written before SCHED_DEADLINE development was started 2) The scheduler architecture is completely different respect to the current one, but the basic scheduling algorithm implemented by my old scheduler is the same one implemented by SCHED_DEADLINE (but I did not implement multi-processor support :) 3) You can have a look at the modifications needed to implement GRUB by simply grepping for "GRUB" in the source code. Basically, the algorithm is implemented by: 1) Implementing a state machine to keep track of the current state of a task (is it using its reserved fraction of CPU time, did it already use such a fraction of CPU time, or is it not using any CPU time?). This is done by adding a "state" field in "cbs_struct", and properly updating it in cbs.c 2) Keeping track of the total fraction of CPU time used by the active tasks. See the "U" variable in cbs.c (in a modern scheduler, it should probably become a field in the runqueue structure) 3) Modifying the rule used to update the runtime. For a "standard" CBS without CPU reclaiming (the one implemented by SCHED_DEADLINE), if a task executes for an amount of time "delta" its runtime must be decreased by delta. For GRUB, it must be decreased by "delta" mutliplied by U. See "account()" in cbs.c. The "trick" is in properly updating U (and this is done using the state machine mentioned above) Summing up, this code is not directly usable, but it shows you what needs to be done in order to implement the GRUB mechanism for CPU reclaiming in a CBS scheduler... Thanks for giving me your solution. I will take a look at it and modify it in our scene later. Thanks Yan Luca . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizing its blacklist, it fails and reports many errors
as below.
Failed to find blacklist 000101316830
Failed to find blacklist 0001013000f0a000
Failed to find blacklist 000101315f70a000
Failed to find blacklist 000101324c80a000
Failed to find blacklist 0001013063f0a000
Failed to find blacklist 000101327800a000
Failed to find blacklist 0001013277f0a000
Failed to find blacklist 000101315a70a000
Failed to find blacklist 0001013277e0a000
Failed to find blacklist 000101305a20a000
Failed to find blacklist 0001013277d0a000
Failed to find blacklist 00010130bdc0a000
Failed to find blacklist 00010130dc20a000
Failed to find blacklist 000101309a00a000
Failed to find blacklist 0001013277c0a000
Failed to find blacklist 0001013277b0a000
Failed to find blacklist 0001013277a0a000
Failed to find blacklist 000101327790a000
Failed to find blacklist 000101303140a000
Failed to find blacklist 0001013a3280a000
To fix this bug, this introduces function_entry() macro to
retrieve the entry address from the given function pointer,
and uses for kallsyms_lookup_size_offset() while initializing
blacklist.
Changes in v4:
- Add kernel_text_address() check for verifying the address.
- Moved on the latest linus tree.
Changes in v3:
- Fix a bug to get blacklist address based on function entry
instead of function descriptor. (Suzuki's work, Thanks!)
Changes in V2:
- Use function_entry() macro when lookin up symbols instead
of storing it.
- Update for the latest -next.
Signed-off-by: Masami Hiramatsu
Reported-by: Tony Luck
Tested-by: Tony Luck
Cc: Michael Ellerman
Cc: Suzuki K. Poulose
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Ananth N Mavinakayanahalli
Cc: Kevin Hao
Cc: linux-i...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
arch/ia64/include/asm/types.h|2 ++
arch/powerpc/include/asm/types.h | 11 +++
include/linux/types.h|4
kernel/kprobes.c | 15 ++-
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
index 4c351b1..95279dd 100644
--- a/arch/ia64/include/asm/types.h
+++ b/arch/ia64/include/asm/types.h
@@ -27,5 +27,7 @@ struct fnptr {
unsigned long gp;
};
+#define function_entry(fn) (((struct fnptr *)(fn))->ip)
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_IA64_TYPES_H */
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index bfb6ded..8b89d65 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -25,6 +25,17 @@ typedef struct {
unsigned long env;
} func_descr_t;
+#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
+#define function_entry(fn) (((func_descr_t *)(fn))->entry)
+#else
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/linux/types.h b/include/linux/types.h
index a0bb704..3b95369 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -213,5 +213,9 @@ struct callback_head {
};
#define rcu_head callback_head
+#ifndef function_entry
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_TYPES_H */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 3214289..7412535 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
* added function-return probes.
*/
#include
+#include
#include
#include
#include
@@ -2037,19 +2038,23 @@ static int __init populate_kprobe_blacklist(unsigned
long *start,
{
unsigned long *iter;
struct kprobe_blacklist_entry *ent;
- unsigned long offset = 0, size = 0;
+ unsigned long entry, offset = 0, size = 0;
for (iter = start; iter < end; iter++) {
- if (!kallsyms_lookup_size_offset(*iter, , )) {
- pr_err("Failed to find blacklist %p\n", (void *)*iter);
+ entry = function_entry(*iter);
+
+ if (!kernel_text_address(entry) ||
+ !kallsyms_lookup_size_offset(entry, , )) {
+ pr_err("Failed to find blacklist at %p\n",
+ (void *)entry);
continue;
}
ent = kmalloc(sizeof(*ent), GFP_KERNEL);
if (!ent)
[PATCH] x86: numa: setup_node_data(): drop dead code and rename function
The setup_node_data() function allocates a pg_data_t object, inserts it into the node_data[] array and initializes the following fields: node_id, node_start_pfn and node_spanned_pages. However, a few function calls later during the kernel boot, free_area_init_node() re-initializes those fields, possibly with different values. This means that the initialization done by setup_node_data() is not used. This causes a small glitch when running Linux as a hyperv numa guest: [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0 [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0 [0.00] SRAT: PXM 1 -> APIC 0x02 -> Node 1 [0.00] SRAT: PXM 1 -> APIC 0x03 -> Node 1 [0.00] SRAT: Node 0 PXM 0 [mem 0x-0x7fff] [0.00] SRAT: Node 1 PXM 1 [mem 0x8020-0xf7ff] [0.00] SRAT: Node 1 PXM 1 [mem 0x1-0x1081f] [0.00] NUMA: Node 1 [mem 0x8020-0xf7ff] + [mem 0x1-0x1081f] -> [mem 0x8020-0x1081f] [0.00] Initmem setup node 0 [mem 0x-0x7fff] [0.00] NODE_DATA [mem 0x7ffec000-0x7ffe] [0.00] Initmem setup node 1 [mem 0x8080-0x1081f] [0.00] NODE_DATA [mem 0x1081fa000-0x1081fdfff] [0.00] crashkernel: memory value expected [0.00] [ea00-ea0001ff] PMD -> [88007de0-88007fdf] on node 0 [0.00] [ea000200-ea00043f] PMD -> [88010560-8801077f] on node 1 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x1081f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0x7ffe] [0.00] node 1: [mem 0x8020-0xf7ff] [0.00] node 1: [mem 0x1-0x1081f] [0.00] On node 0 totalpages: 524174 [0.00] DMA zone: 64 pages used for memmap [0.00] DMA zone: 21 pages reserved [0.00] DMA zone: 3998 pages, LIFO batch:0 [0.00] DMA32 zone: 8128 pages used for memmap [0.00] DMA32 zone: 520176 pages, LIFO batch:31 [0.00] On node 1 totalpages: 524288 [0.00] DMA32 zone: 7672 pages used for memmap [0.00] DMA32 zone: 491008 pages, LIFO batch:31 [0.00] Normal zone: 520 pages used for memmap [0.00] Normal zone: 33280 pages, LIFO batch:7 In this dmesg, the SRAT table reports that the memory range for node 1 starts at 0x8020. However, the line starting with "Initmem" reports that node 1 memory range starts at 0x8080. The "Initmem" line is reported by setup_node_data() and is wrong, because the kernel ends up using the range as reported in the SRAT table. This commit drops all that dead code from setup_node_data(), renames it to alloc_node_data() and adds a printk() to free_area_init_node() so that we report a node's memory range accurately. Here's the same dmesg section with this patch applied: [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0 [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0 [0.00] SRAT: PXM 1 -> APIC 0x02 -> Node 1 [0.00] SRAT: PXM 1 -> APIC 0x03 -> Node 1 [0.00] SRAT: Node 0 PXM 0 [mem 0x-0x7fff] [0.00] SRAT: Node 1 PXM 1 [mem 0x8020-0xf7ff] [0.00] SRAT: Node 1 PXM 1 [mem 0x1-0x1081f] [0.00] NUMA: Node 1 [mem 0x8020-0xf7ff] + [mem 0x1-0x1081f] -> [mem 0x8020-0x1081f] [0.00] NODE_DATA(0) allocated [mem 0x7ffec000-0x7ffe] [0.00] NODE_DATA(1) allocated [mem 0x1081fa000-0x1081fdfff] [0.00] crashkernel: memory value expected [0.00] [ea00-ea0001ff] PMD -> [88007de0-88007fdf] on node 0 [0.00] [ea000200-ea00043f] PMD -> [88010560-8801077f] on node 1 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x1081f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0x7ffe] [0.00] node 1: [mem 0x8020-0xf7ff] [0.00] node 1: [mem 0x1-0x1081f] [0.00] Node 0 memory range 0x1000-0x7ffe [0.00] On node 0 totalpages: 524174 [0.00] DMA zone: 64 pages used for memmap [0.00] DMA zone: 21 pages reserved [0.00] DMA zone: 3998 pages, LIFO batch:0 [0.00] DMA32 zone: 8128 pages used for memmap [0.00] DMA32 zone: 520176 pages, LIFO batch:31 [0.00] Node 1 memory range 0x8020-0x1081f [0.00] On node 1
Re: [PATCH -tip v2 3/3] kprobes: Set IPMODIFY flag only if the probe can change regs->ip
(2014/06/19 21:34), Namhyung Kim wrote:
> Hi Masami,
>
> 2014-06-17 (화), 11:04 +, Masami Hiramatsu:
>> +static int __ftrace_add_filter_ip(struct ftrace_ops *ops, unsigned long ip,
>> + int *ref)
>> +{
>> +int ret;
>> +
>> +/* Try to set given ip to filter */
>> +ret = ftrace_set_filter_ip(ops, ip, 0, 0);
>> +if (ret >= 0) {
>
> Hmm.. this doesn't look comfortable. What not using usual pattern?
>
> if (ret < 0)
> return ret;
>
> This way we can reduce a indent level.
OK, I'll do so :)
>
>
>> +(*ref)++;
>> +if (*ref == 1) {
>> +ret = register_ftrace_function(ops);
>> +if (ret < 0) {
>> +/* Rollback refcounter and filter */
>> +(*ref)--;
>> +ftrace_set_filter_ip(ops, ip, 1, 0);
>> +}
>> +}
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +static int __ftrace_remove_filter_ip(struct ftrace_ops *ops, unsigned long
>> ip,
>> + int *ref)
>> +{
>> +int ret = 0;
>> +
>> +(*ref)--;
>> +if (*ref == 0)
>> +ret = unregister_ftrace_function(ops);
>> +if (ret >= 0)
>> +/* Try to remove given ip to filter */
>> +ret = ftrace_set_filter_ip(ops, ip, 1, 0);
>
> I think any failure at this time can be problematic. Since we already
> unregistered the ops but the refcount will get increased again, future
> attemp to register won't enable the ops anymore IMHO.
Agreed.
> I think it'd better just ignoring faiure of filter removal here. We'll
> miss a filter entry but it'll be usable anyway.
>
> What about this?
OK, I'll use your v2 code :)
Thank you for review!
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH -tip v2 1/3] ftrace: Simplify ftrace_hash_disable/enable path in ftrace_hash_move
(2014/06/20 11:08), Steven Rostedt wrote: > On Tue, 17 Jun 2014 11:04:42 + > Masami Hiramatsu wrote: > >> Simplify ftrace_hash_disable/enable path in ftrace_hash_move >> for hardening the process if the memory allocation failed. >> > > Regardless of what we do with IPMODIFY, I pulled this into my 3.17 > queue. You don't need to resend it with any new versions of the patches. OK, thanks Steve! -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(2014/06/20 9:37), Michael Ellerman wrote:
> On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote:
>> (2014/06/19 20:01), Masami Hiramatsu wrote:
>>
>>> Ah, those messages should be shown in dmesg when booting if it doesn't
>>> work,
>>> because the messages are printed by initialization process of kprobe
>>> blacklist.
>>> So, reproducing it is just enabling CONFIG_KPROBES and boot it.
>> Well, we don't get those messages on Power, since the kallsyms has the
>> entries for ".function_name". The correct way to verify is, either :
>
> Hmm, that seems another issue on powerpc. Is that expected(and designed)
> behavior?
AFAIK, yes, it is.
To be more precise :
we have 'foo' and '.foo' for a function foo(), where 'foo' points to the
function_entry and '.foo' points to the actual function.
>>>
>>> Ah, I see. So if we run
>>>
>>> func_ptr p = foo;
>>> return p == kallsyms_lookup_name(".foo");
>>>
>>> it returns true.
>>
>> One more thing I should know, is the address of ".function_name" within the
>> kernel text? In other words, does kernel_text_address() return true for that
>> address? If not, it's easy to verify the address.
>
> Yes. That is the text address, kernel_text_address() should definitely return
> true.
>
> On 64-bit, ABIv1, "foo" points to the function descriptor, in the ".opd"
> section.
>
> ".foo" points to the actual text of the function, in ".text".
Hmm, I misunderstood that. Anyway, we can verify it by kernel_text_address().
>
> On 64-bit, ABIv2, "foo" points to the text in ".text". There are no dot
> symbols.
OK, in that case, kernel_text_address() check is still available. :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] initramfs: Support initrd that is bigger then 2G.
When initrd (compressed or not) is used, kernel report data corrupted
with /dev/ram0.
The root cause:
During initramfs checking, if it is initrd, it will be transferred to
/initrd.image with sys_write.
sys_write only support 2G-4K write, so if the initrd ram is more than
that, /initrd.image will not complete at all.
Add local sys_write_large to loop calling sys_write to workaround the
problem.
Also need to use that in write_buffer path for cpio that have file is
more than file.
At the same time, we don't need to worry about sys_read/sys_write in
do_mounts_rd.c::crd_load. As decompressor will have fill/flush that
means it will allocate buffer and buffer is smaller than 2G.
Test with uncompressed initrd, and compressed with gz, bz2, lzma,xz,
lzop.
Signed-off-by: Yinghai Lu
---
init/initramfs.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
Index: linux-2.6/init/initramfs.c
===
--- linux-2.6.orig/init/initramfs.c
+++ linux-2.6/init/initramfs.c
@@ -19,6 +19,26 @@
#include
#include
+static long __init sys_write_large(unsigned int fd, char *p,
+ size_t count)
+{
+ ssize_t left = count;
+ long written;
+
+ /* sys_write only can write MAX_RW_COUNT aka 2G-4K bytes at most */
+ while (left > 0) {
+ written = sys_write(fd, p, left);
+
+ if (written <= 0)
+ break;
+
+ left -= written;
+ p += written;
+ }
+
+ return (written < 0) ? written : count;
+}
+
static __initdata char *message;
static void __init error(char *x)
{
@@ -346,7 +366,7 @@ static int __init do_name(void)
static int __init do_copy(void)
{
if (count >= body_len) {
- sys_write(wfd, victim, body_len);
+ sys_write_large(wfd, victim, body_len);
sys_close(wfd);
do_utime(vcollected, mtime);
kfree(vcollected);
@@ -354,7 +374,7 @@ static int __init do_copy(void)
state = SkipIt;
return 0;
} else {
- sys_write(wfd, victim, count);
+ sys_write_large(wfd, victim, count);
body_len -= count;
eat(count);
return 1;
@@ -604,8 +624,13 @@ static int __init populate_rootfs(void)
fd = sys_open("/initrd.image",
O_WRONLY|O_CREAT, 0700);
if (fd >= 0) {
- sys_write(fd, (char *)initrd_start,
- initrd_end - initrd_start);
+ long written = sys_write_large(fd, (char *)initrd_start,
+ initrd_end - initrd_start);
+
+ if (written != initrd_end - initrd_start)
+ pr_err("/initrd.image: incomplete write (%ld !=
%ld)\n",
+ written, initrd_end - initrd_start);
+
sys_close(fd);
free_initrd();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: rtl8192 Check for Null return from dev_skb_alloc
If anyone able to check this patch it would be great.
Thanks Nick
On Thu, Jun 19, 2014 at 5:18 PM, Nicholas Krause wrote:
> Checks for Null return from dev_skb_alloc if it returns Null,
> fw_download returns false. Otherwise it returns true.Also
> removed rt_status due to returning true of false directly.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..affa89a 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -36,7 +36,6 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
> u32 buffer_len)
> {
> struct r8192_priv *priv = rtllib_priv(dev);
> - boolrt_status = true;
> u16 frag_threshold;
> u16 frag_length, frag_offset = 0;
> int i;
> @@ -59,7 +58,9 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
> bLastIniPkt = 1;
>
> }
>skb = dev_alloc_skb(frag_length + 4);
> + if (!skb)
> + return false;
> memcpy((unsigned char *)(skb->cb), , sizeof(dev));
> tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
> @@ -99,7 +100,7 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
>
> write_nic_byte(dev, TPPoll, TPPoll_CQ);
>
> - return rt_status;
> + return true;
> }
>
> static bool CPUcheck_maincodeok_turnonCPU(struct net_device *dev)
> --
> 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 -tip v2 1/3] ftrace: Simplify ftrace_hash_disable/enable path in ftrace_hash_move
On Tue, 17 Jun 2014 11:04:42 +
Masami Hiramatsu wrote:
> Simplify ftrace_hash_disable/enable path in ftrace_hash_move
> for hardening the process if the memory allocation failed.
>
Regardless of what we do with IPMODIFY, I pulled this into my 3.17
queue. You don't need to resend it with any new versions of the patches.
-- Steve
> Signed-off-by: Masami Hiramatsu
> Cc: Steven Rostedt
> Cc: Josh Poimboeuf
> Cc: Namhyung Kim
> ---
> kernel/trace/ftrace.c | 33 +++--
> 1 file changed, 11 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 5b372e3..d65719d 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1304,25 +1304,15 @@ ftrace_hash_move(struct ftrace_ops *ops, int enable,
> struct ftrace_hash *new_hash;
> int size = src->count;
> int bits = 0;
> - int ret;
> int i;
>
> /*
> - * Remove the current set, update the hash and add
> - * them back.
> - */
> - ftrace_hash_rec_disable(ops, enable);
> -
> - /*
>* If the new source is empty, just free dst and assign it
>* the empty_hash.
>*/
> if (!src->count) {
> - free_ftrace_hash_rcu(*dst);
> - rcu_assign_pointer(*dst, EMPTY_HASH);
> - /* still need to update the function records */
> - ret = 0;
> - goto out;
> + new_hash = EMPTY_HASH;
> + goto update;
> }
>
> /*
> @@ -1335,10 +1325,9 @@ ftrace_hash_move(struct ftrace_ops *ops, int enable,
> if (bits > FTRACE_HASH_MAX_BITS)
> bits = FTRACE_HASH_MAX_BITS;
>
> - ret = -ENOMEM;
> new_hash = alloc_ftrace_hash(bits);
> if (!new_hash)
> - goto out;
> + return -ENOMEM;
>
> size = 1 << src->size_bits;
> for (i = 0; i < size; i++) {
> @@ -1349,20 +1338,20 @@ ftrace_hash_move(struct ftrace_ops *ops, int enable,
> }
> }
>
> +update:
> + /*
> + * Remove the current set, update the hash and add
> + * them back.
> + */
> + ftrace_hash_rec_disable(ops, enable);
> +
> old_hash = *dst;
> rcu_assign_pointer(*dst, new_hash);
> free_ftrace_hash_rcu(old_hash);
>
> - ret = 0;
> - out:
> - /*
> - * Enable regardless of ret:
> - * On success, we enable the new hash.
> - * On failure, we re-enable the original hash.
> - */
> ftrace_hash_rec_enable(ops, enable);
>
> - return ret;
> + return 0;
> }
>
> /*
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: Remove unnecessary OOM messages
On 06/18/2014 02:30 PM, Jingoo Han wrote: > The site-specific OOM messages are unnecessary, because they > duplicate the MM subsystem generic OOM message. The following > checkpatch warning is also removed. > > WARNING: Possible unnecessary 'out of memory' message > > Signed-off-by: Jingoo Han > --- > drivers/extcon/extcon-arizona.c |4 +--- > drivers/extcon/extcon-max14577.c |5 ++--- > drivers/extcon/extcon-max77693.c |5 ++--- > drivers/extcon/extcon-max8997.c |4 +--- > 4 files changed, 6 insertions(+), 12 deletions(-) Applied it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: palmas: Make of_device_id array const
Hi Jingoo,
On 06/18/2014 02:27 PM, Jingoo Han wrote:
> Make of_device_id array const, because all OF functions handle
> it as const.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/extcon/extcon-palmas.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 7417ce8..5efa96c 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -278,7 +278,7 @@ static int palmas_usb_resume(struct device *dev)
>
> static SIMPLE_DEV_PM_OPS(palmas_pm_ops, palmas_usb_suspend,
> palmas_usb_resume);
>
> -static struct of_device_id of_palmas_match_tbl[] = {
> +static const struct of_device_id of_palmas_match_tbl[] = {
> { .compatible = "ti,palmas-usb", },
> { .compatible = "ti,palmas-usb-vid", },
> { .compatible = "ti,twl6035-usb", },
>
The same patch was applied by Krzysztof Kozlowski on extcon-next branch.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf timechart: implement IO mode
Hi Stanislav,
On Thu, 19 Jun 2014 16:23:01 +0400, Stanislav Fomichev wrote:
> In IO mode timechart shows any disk/network activity.
> + for (i = 0; i < disk_events_nr; i++) {
> + if (!is_valid_tracepoint(disk_events[i])) {
> + rec_argc--;
It (and others below) should be 'rec_argc -= 4' - i.e. I still see the
segfault. :)
> + continue;
> + }
> +
> + *p++ = "-e";
> + *p++ = strdup(disk_events[i]);
> + *p++ = "--filter";
> + *p++ = filter;
> + }
[SNIP]
> +void svg_ubox(int Yslot, u64 start, u64 end, double height, const char
> *type, int fd, int err, int merges)
> +{
> + double w = time2pixels(end) - time2pixels(start);
> + height = normalize_height(height);
> +
> + if (!svgfile)
> + return;
> +
> + fprintf(svgfile, "\n");
> + fprintf(svgfile, "fd=%d error=%d merges=%d\n", fd, err,
> merges);
> + fprintf(svgfile, " height=\"%.1f\" class=\"%s\"/>\n",
Looks like this change should be applied to the exsting (for cpu and
power events) boxes too. Care to send it as a separate fix?
> + time2pixels(start),
> + w,
> + Yslot * SLOT_MULT,
> + SLOT_HALF * height,
> + type);
> + fprintf(svgfile, "\n");
> +}
[SNIP]
> @@ -579,8 +669,10 @@ void svg_time_grid(void)
> color = 128;
> }
>
> - fprintf(svgfile, " y2=\"%" PRIu64 "\" style=\"stroke:rgb(%i,%i,%i);stroke-width:%1.3f\"/>\n",
> - time2pixels(i), SLOT_MULT/2, time2pixels(i),
> total_height, color, color, color, thickness);
> + if (thickness >= min_thickness)
> + fprintf(svgfile, " x2=\"%4.8f\" y2=\"%" PRIu64 "\"
> style=\"stroke:rgb(%i,%i,%i);stroke-width:%1.3f\"/>\n",
It seems you missed the change above (s/4.8f/.8f/g). :)
Thanks,
Namhyung
> + time2pixels(i), SLOT_MULT/2, time2pixels(i),
> + total_height, color, color, color, thickness);
>
> i += 1000;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On Thu, 2014-06-19 at 20:20 +0900, Masami Hiramatsu wrote:
> (2014/06/19 20:01), Masami Hiramatsu wrote:
>
> > Ah, those messages should be shown in dmesg when booting if it doesn't
> > work,
> > because the messages are printed by initialization process of kprobe
> > blacklist.
> > So, reproducing it is just enabling CONFIG_KPROBES and boot it.
> Well, we don't get those messages on Power, since the kallsyms has the
> entries for ".function_name". The correct way to verify is, either :
> >>>
> >>> Hmm, that seems another issue on powerpc. Is that expected(and designed)
> >>> behavior?
> >> AFAIK, yes, it is.
> >> To be more precise :
> >>
> >> we have 'foo' and '.foo' for a function foo(), where 'foo' points to the
> >> function_entry and '.foo' points to the actual function.
> >
> > Ah, I see. So if we run
> >
> > func_ptr p = foo;
> > return p == kallsyms_lookup_name(".foo");
> >
> > it returns true.
>
> One more thing I should know, is the address of ".function_name" within the
> kernel text? In other words, does kernel_text_address() return true for that
> address? If not, it's easy to verify the address.
Yes. That is the text address, kernel_text_address() should definitely return
true.
On 64-bit, ABIv1, "foo" points to the function descriptor, in the ".opd"
section.
".foo" points to the actual text of the function, in ".text".
On 64-bit, ABIv2, "foo" points to the text in ".text". There are no dot
symbols.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
The RNDIS_STATUS_NETWORK_CHANGE event is received after the Hyper-V host
sleep or hibernation. We refresh network at this time.
MS-TFS: 135162
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/hyperv_net.h |3 ++-
drivers/net/hyperv/netvsc_drv.c | 30 ++
drivers/net/hyperv/rndis_filter.c | 21 +
include/linux/rndis.h |1 +
4 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 6cc37c1..24441ae 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -170,6 +170,7 @@ struct rndis_device {
enum rndis_device_state state;
bool link_state;
+ bool link_change;
atomic_t new_req_id;
spinlock_t request_lock;
@@ -185,7 +186,7 @@ int netvsc_device_remove(struct hv_device *device);
int netvsc_send(struct hv_device *device,
struct hv_netvsc_packet *packet);
void netvsc_linkstatus_callback(struct hv_device *device_obj,
- unsigned int status);
+ struct rndis_message *resp);
int netvsc_recv_callback(struct hv_device *device_obj,
struct hv_netvsc_packet *packet,
struct ndis_tcp_ip_checksum_info *csum_info);
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4fd71b7..9b27ca8 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -579,8 +579,9 @@ drop:
* netvsc_linkstatus_callback - Link up/down notification
*/
void netvsc_linkstatus_callback(struct hv_device *device_obj,
- unsigned int status)
+ struct rndis_message *resp)
{
+ struct rndis_indicate_status *indicate = >msg.indicate_status;
struct net_device *net;
struct net_device_context *ndev_ctx;
struct netvsc_device *net_device;
@@ -589,7 +590,19 @@ void netvsc_linkstatus_callback(struct hv_device
*device_obj,
net_device = hv_get_drvdata(device_obj);
rdev = net_device->extension;
- rdev->link_state = status != 1;
+ switch (indicate->status) {
+ case RNDIS_STATUS_MEDIA_CONNECT:
+ rdev->link_state = false;
+ break;
+ case RNDIS_STATUS_MEDIA_DISCONNECT:
+ rdev->link_state = true;
+ break;
+ case RNDIS_STATUS_NETWORK_CHANGE:
+ rdev->link_change = true;
+ break;
+ default:
+ return;
+ }
net = net_device->ndev;
@@ -597,7 +610,7 @@ void netvsc_linkstatus_callback(struct hv_device
*device_obj,
return;
ndev_ctx = netdev_priv(net);
- if (status == 1) {
+ if (!rdev->link_state) {
schedule_delayed_work(_ctx->dwork, 0);
schedule_delayed_work(_ctx->dwork, msecs_to_jiffies(20));
} else {
@@ -767,7 +780,9 @@ static void netvsc_link_change(struct work_struct *w)
struct net_device *net;
struct netvsc_device *net_device;
struct rndis_device *rdev;
- bool notify;
+ bool notify, refresh = false;
+ char *argv[] = { "/etc/init.d/network", "restart", NULL };
+ char *envp[] = { "HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
rtnl_lock();
@@ -782,10 +797,17 @@ static void netvsc_link_change(struct work_struct *w)
} else {
netif_carrier_on(net);
notify = true;
+ if (rdev->link_change) {
+ rdev->link_change = false;
+ refresh = true;
+ }
}
rtnl_unlock();
+ if (refresh)
+ call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
+
if (notify)
netdev_notify_peers(net);
}
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 99c527a..2b86f0b 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -320,25 +320,6 @@ static void rndis_filter_receive_response(struct
rndis_device *dev,
}
}
-static void rndis_filter_receive_indicate_status(struct rndis_device *dev,
-struct rndis_message *resp)
-{
- struct rndis_indicate_status *indicate =
- >msg.indicate_status;
-
- if (indicate->status == RNDIS_STATUS_MEDIA_CONNECT) {
- netvsc_linkstatus_callback(
- dev->net_dev->dev, 1);
- } else if (indicate->status == RNDIS_STATUS_MEDIA_DISCONNECT) {
- netvsc_linkstatus_callback(
- dev->net_dev->dev, 0);
- } else {
- /*
-* TODO:
-*/
- }
-}
-
/*
* Get the Per-Packet-Info with the specified
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 20.06.2014 02:28, Chanwoo Choi wrote:
> On 06/20/2014 09:24 AM, Tomasz Figa wrote:
>> On 20.06.2014 02:22, Chanwoo Choi wrote:
>>> Hi Tomasz,
>>>
>>> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
Hi Chanwoo,
On 18.06.2014 04:20, Chanwoo Choi wrote:
> This patch control special clock for ADC in Exynos series's FSYS block.
> If special clock of ADC is registerd on clock list of common clk
> framework,
> Exynos ADC drvier have to control this clock.
>
> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
> - 'adc' clock: bus clock for ADC
>
> Exynos3250 has additional 'sclk_adc' clock as following:
> - 'sclk_adc' clock: special clock for ADC which provide clock to internal
> ADC
>
> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc'
> clock
> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
> 'sclk_adc'
> clock in FSYS_BLK.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> drivers/iio/adc/exynos_adc.c | 93
> ++--
> 1 file changed, 81 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index c30def6..6b026ac 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -41,7 +41,8 @@
>
> enum adc_version {
> ADC_V1,
> - ADC_V2
> + ADC_V2,
> + ADC_V2_EXYNOS3250,
> };
>
> /* EXYNOS4412/5250 ADC_V1 registers definitions */
> @@ -85,9 +86,11 @@ enum adc_version {
> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>
> struct exynos_adc {
> + struct device *dev;
> void __iomem*regs;
> void __iomem*enable_reg;
> struct clk *clk;
> + struct clk *sclk;
> unsigned intirq;
> struct regulator*vdd;
> struct exynos_adc_ops *ops;
> @@ -96,6 +99,7 @@ struct exynos_adc {
>
> u32 value;
> unsigned intversion;
> + boolneeds_sclk;
This should be rather a part of the variant struct. See my comments to
patch 1/4.
>>>
>>> OK, I'll include 'needs_sclk' in "variant" structure.
>>>
> };
>
> struct exynos_adc_ops {
> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
> void (*clear_irq)(struct exynos_adc *info);
> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> void (*stop_conv)(struct exynos_adc *info);
> + void (*disable_clk)(struct exynos_adc *info);
> + int (*enable_clk)(struct exynos_adc *info);
> };
>
> static const struct of_device_id exynos_adc_match[] = {
> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
> + {
> + .compatible = "samsung,exynos-adc-v1",
> + .data = (void *)ADC_V1,
> + }, {
> + .compatible = "samsung,exynos-adc-v2",
> + .data = (void *)ADC_V2,
> + }, {
> + .compatible = "samsung,exynos3250-adc-v2",
> + .data = (void *)ADC_V2_EXYNOS3250,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, exynos_adc_match);
> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
> exynos_adc *info)
> writel(con, ADC_V1_CON(info->regs));
> }
>
> +static void exynos_adc_disable_clk(struct exynos_adc *info)
> +{
> + if (info->needs_sclk)
> + clk_disable_unprepare(info->sclk);
> + clk_disable_unprepare(info->clk);
> +}
> +
> +static int exynos_adc_enable_clk(struct exynos_adc *info)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(info->clk);
> + if (ret) {
> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (info->needs_sclk) {
> + ret = clk_prepare_enable(info->sclk);
> + if (ret) {
> + clk_disable_unprepare(info->clk);
> + dev_err(info->dev,
> + "failed enabling sclk_tsadc clock: %d\n", ret);
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct exynos_adc_ops exynos_adc_v1_ops = {
> .init_hw= exynos_adc_v1_init_hw,
> .clear_irq = exynos_adc_v1_clear_irq,
> .start_conv = exynos_adc_v1_start_conv,
> .stop_conv = exynos_adc_v1_stop_conv,
> + .disable_clk= exynos_adc_disable_clk,
> + .enable_clk = exynos_adc_enable_clk,
> };
>
> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
>
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 06/20/2014 09:24 AM, Tomasz Figa wrote:
> On 20.06.2014 02:22, Chanwoo Choi wrote:
>> Hi Tomasz,
>>
>> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
>>> Hi Chanwoo,
>>>
>>> On 18.06.2014 04:20, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal
ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
'sclk_adc'
clock in FSYS_BLK.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/iio/adc/exynos_adc.c | 93
++--
1 file changed, 81 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c30def6..6b026ac 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -41,7 +41,8 @@
enum adc_version {
ADC_V1,
- ADC_V2
+ ADC_V2,
+ ADC_V2_EXYNOS3250,
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -85,9 +86,11 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT(msecs_to_jiffies(100))
struct exynos_adc {
+ struct device *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
struct exynos_adc_ops *ops;
@@ -96,6 +99,7 @@ struct exynos_adc {
u32 value;
unsigned intversion;
+ boolneeds_sclk;
>>>
>>> This should be rather a part of the variant struct. See my comments to
>>> patch 1/4.
>>
>> OK, I'll include 'needs_sclk' in "variant" structure.
>>
>>>
};
struct exynos_adc_ops {
@@ -103,11 +107,21 @@ struct exynos_adc_ops {
void (*clear_irq)(struct exynos_adc *info);
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
void (*stop_conv)(struct exynos_adc *info);
+ void (*disable_clk)(struct exynos_adc *info);
+ int (*enable_clk)(struct exynos_adc *info);
};
static const struct of_device_id exynos_adc_match[] = {
- { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
- { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
+ {
+ .compatible = "samsung,exynos-adc-v1",
+ .data = (void *)ADC_V1,
+ }, {
+ .compatible = "samsung,exynos-adc-v2",
+ .data = (void *)ADC_V2,
+ }, {
+ .compatible = "samsung,exynos3250-adc-v2",
+ .data = (void *)ADC_V2_EXYNOS3250,
+ },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct
exynos_adc *info)
writel(con, ADC_V1_CON(info->regs));
}
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+ if (info->needs_sclk)
+ clk_disable_unprepare(info->sclk);
+ clk_disable_unprepare(info->clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret) {
+ dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+ return ret;
+ }
+
+ if (info->needs_sclk) {
+ ret = clk_prepare_enable(info->sclk);
+ if (ret) {
+ clk_disable_unprepare(info->clk);
+ dev_err(info->dev,
+ "failed enabling sclk_tsadc clock: %d\n", ret);
+ }
+ }
+
+ return 0;
+}
+
static struct exynos_adc_ops exynos_adc_v1_ops = {
.init_hw= exynos_adc_v1_init_hw,
.clear_irq = exynos_adc_v1_clear_irq,
.start_conv = exynos_adc_v1_start_conv,
.stop_conv = exynos_adc_v1_stop_conv,
+ .disable_clk= exynos_adc_disable_clk,
+ .enable_clk = exynos_adc_enable_clk,
};
static void exynos_adc_v2_init_hw(struct exynos_adc *info)
@@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
.start_conv = exynos_adc_v2_start_conv,
.clear_irq = exynos_adc_v2_clear_irq,
.stop_conv = exynos_adc_v2_stop_conv,
Re: [PATCH v2 2/2] staging: alarm-dev: Support to Compile as Module
On Fri, Jun 13, 2014 at 11:49:43AM +0530, pramod.gurav@gmail.com wrote: > From: Pramod Gurav > > Currently this alarm-dev can be compiles only as built in > driver. This adds support to compile it as module as well which is in > planned activity (See drivers/staging/android/TODO) > > > CC: Greg Kroah-Hartman > CC: Brian Swetland > Signed-off-by: Pramod Gurav > --- > drivers/staging/android/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig > index 99e484f..c359317 100644 > --- a/drivers/staging/android/Kconfig > +++ b/drivers/staging/android/Kconfig > @@ -76,7 +76,7 @@ config ANDROID_LOW_MEMORY_KILLER > Registers processes to be killed when memory is low > > config ANDROID_INTF_ALARM_DEV > - bool "Android alarm driver" > + tristate "Android alarm driver" > depends on RTC_CLASS > default n > ---help--- With this change you will get a warning about a missing MODULE_LICENSE(), can you please send a follow-on patch to fix that? 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: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
On 20.06.2014 02:20, Chanwoo Choi wrote:
> Hi Tomasz,
>
> On 06/18/2014 04:55 PM, Tomasz Figa wrote:
>> Hi Chanwoo,
>>
>> On 18.06.2014 04:20, Chanwoo Choi wrote:
>>> This patchset add 'exynos_adc_ops' structure which includes some functions
>>> to control ADC operation according to ADC version (v1 or v2).
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> drivers/iio/adc/exynos_adc.c | 174
>>> +--
>>> 1 file changed, 120 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>> index 010578f..c30def6 100644
>>> --- a/drivers/iio/adc/exynos_adc.c
>>> +++ b/drivers/iio/adc/exynos_adc.c
>>> @@ -90,6 +90,7 @@ struct exynos_adc {
>>> struct clk *clk;
>>> unsigned intirq;
>>> struct regulator*vdd;
>>> + struct exynos_adc_ops *ops;
>>>
>>> struct completion completion;
>>>
>>> @@ -97,6 +98,13 @@ struct exynos_adc {
>>> unsigned intversion;
>>> };
>>>
>>> +struct exynos_adc_ops {
>>> + void (*init_hw)(struct exynos_adc *info);
>>> + void (*clear_irq)(struct exynos_adc *info);
>>> + void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>>> + void (*stop_conv)(struct exynos_adc *info);
>>> +};
>>> +
>>> static const struct of_device_id exynos_adc_match[] = {
>>> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>>> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>>> @@ -112,30 +120,98 @@ static inline unsigned int
>>> exynos_adc_get_version(struct platform_device *pdev)
>>> return (unsigned int)match->data;
>>> }
>>>
>>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>>> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
>>> +{
>>> + u32 con1;
>>> +
>>> + /* set default prescaler values and Enable prescaler */
>>> + con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>>> +
>>> + /* Enable 12-bit ADC resolution */
>>> + con1 |= ADC_V1_CON_RES;
>>> + writel(con1, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned
>>> long addr)
>>> +{
>>> + u32 con1;
>>> +
>>> + writel(addr, ADC_V1_MUX(info->regs));
>>> +
>>> + con1 = readl(ADC_V1_CON(info->regs));
>>> + writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
>>> +{
>>> + writel(1, ADC_V1_INTCLR(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
>>> +{
>>> + u32 con;
>>> +
>>> + con = readl(ADC_V1_CON(info->regs));
>>> + con |= ADC_V1_CON_STANDBY;
>>> + writel(con, ADC_V1_CON(info->regs));
>>> +}
>>> +
>>> +static struct exynos_adc_ops exynos_adc_v1_ops = {
>>> + .init_hw= exynos_adc_v1_init_hw,
>>> + .clear_irq = exynos_adc_v1_clear_irq,
>>> + .start_conv = exynos_adc_v1_start_conv,
>>> + .stop_conv = exynos_adc_v1_stop_conv,
>>> +};
>>> +
>>> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>>> {
>>> u32 con1, con2;
>>>
>>> - if (info->version == ADC_V2) {
>>> - con1 = ADC_V2_CON1_SOFT_RESET;
>>> - writel(con1, ADC_V2_CON1(info->regs));
>>> + con1 = ADC_V2_CON1_SOFT_RESET;
>>> + writel(con1, ADC_V2_CON1(info->regs));
>>>
>>> - con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>>> - ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>>> - writel(con2, ADC_V2_CON2(info->regs));
>>> + con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>>> + ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>>> + writel(con2, ADC_V2_CON2(info->regs));
>>>
>>> - /* Enable interrupts */
>>> - writel(1, ADC_V2_INT_EN(info->regs));
>>> - } else {
>>> - /* set default prescaler values and Enable prescaler */
>>> - con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>>> + /* Enable interrupts */
>>> + writel(1, ADC_V2_INT_EN(info->regs));
>>> +}
>>>
>>> - /* Enable 12-bit ADC resolution */
>>> - con1 |= ADC_V1_CON_RES;
>>> - writel(con1, ADC_V1_CON(info->regs));
>>> - }
>>> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned
>>> long addr)
>>> +{
>>> + u32 con1, con2;
>>> +
>>> + con2 = readl(ADC_V2_CON2(info->regs));
>>> + con2 &= ~ADC_V2_CON2_ACH_MASK;
>>> + con2 |= ADC_V2_CON2_ACH_SEL(addr);
>>> + writel(con2, ADC_V2_CON2(info->regs));
>>> +
>>> + con1 = readl(ADC_V2_CON1(info->regs));
>>> + writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
>>> +{
>>> + writel(1, ADC_V2_INT_ST(info->regs));
>>> +}
>>> +
>>> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
>>> +{
>>> + u32 con;
>>> +
>>> + con = readl(ADC_V2_CON1(info->regs));
>>> + con &= ~ADC_CON_EN_START;
>>>
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On 20.06.2014 02:22, Chanwoo Choi wrote:
> Hi Tomasz,
>
> On 06/18/2014 04:58 PM, Tomasz Figa wrote:
>> Hi Chanwoo,
>>
>> On 18.06.2014 04:20, Chanwoo Choi wrote:
>>> This patch control special clock for ADC in Exynos series's FSYS block.
>>> If special clock of ADC is registerd on clock list of common clk framework,
>>> Exynos ADC drvier have to control this clock.
>>>
>>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>>> - 'adc' clock: bus clock for ADC
>>>
>>> Exynos3250 has additional 'sclk_adc' clock as following:
>>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal
>>> ADC
>>>
>>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>>> clock in FSYS_BLK.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> drivers/iio/adc/exynos_adc.c | 93
>>> ++--
>>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>> index c30def6..6b026ac 100644
>>> --- a/drivers/iio/adc/exynos_adc.c
>>> +++ b/drivers/iio/adc/exynos_adc.c
>>> @@ -41,7 +41,8 @@
>>>
>>> enum adc_version {
>>> ADC_V1,
>>> - ADC_V2
>>> + ADC_V2,
>>> + ADC_V2_EXYNOS3250,
>>> };
>>>
>>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>>> @@ -85,9 +86,11 @@ enum adc_version {
>>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>>
>>> struct exynos_adc {
>>> + struct device *dev;
>>> void __iomem*regs;
>>> void __iomem*enable_reg;
>>> struct clk *clk;
>>> + struct clk *sclk;
>>> unsigned intirq;
>>> struct regulator*vdd;
>>> struct exynos_adc_ops *ops;
>>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>>
>>> u32 value;
>>> unsigned intversion;
>>> + boolneeds_sclk;
>>
>> This should be rather a part of the variant struct. See my comments to
>> patch 1/4.
>
> OK, I'll include 'needs_sclk' in "variant" structure.
>
>>
>>> };
>>>
>>> struct exynos_adc_ops {
>>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>>> void (*clear_irq)(struct exynos_adc *info);
>>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>>> void (*stop_conv)(struct exynos_adc *info);
>>> + void (*disable_clk)(struct exynos_adc *info);
>>> + int (*enable_clk)(struct exynos_adc *info);
>>> };
>>>
>>> static const struct of_device_id exynos_adc_match[] = {
>>> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>>> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>>> + {
>>> + .compatible = "samsung,exynos-adc-v1",
>>> + .data = (void *)ADC_V1,
>>> + }, {
>>> + .compatible = "samsung,exynos-adc-v2",
>>> + .data = (void *)ADC_V2,
>>> + }, {
>>> + .compatible = "samsung,exynos3250-adc-v2",
>>> + .data = (void *)ADC_V2_EXYNOS3250,
>>> + },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct exynos_adc
>>> *info)
>>> writel(con, ADC_V1_CON(info->regs));
>>> }
>>>
>>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>>> +{
>>> + if (info->needs_sclk)
>>> + clk_disable_unprepare(info->sclk);
>>> + clk_disable_unprepare(info->clk);
>>> +}
>>> +
>>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>>> +{
>>> + int ret;
>>> +
>>> + ret = clk_prepare_enable(info->clk);
>>> + if (ret) {
>>> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + if (info->needs_sclk) {
>>> + ret = clk_prepare_enable(info->sclk);
>>> + if (ret) {
>>> + clk_disable_unprepare(info->clk);
>>> + dev_err(info->dev,
>>> + "failed enabling sclk_tsadc clock: %d\n", ret);
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>>> .init_hw= exynos_adc_v1_init_hw,
>>> .clear_irq = exynos_adc_v1_clear_irq,
>>> .start_conv = exynos_adc_v1_start_conv,
>>> .stop_conv = exynos_adc_v1_stop_conv,
>>> + .disable_clk= exynos_adc_disable_clk,
>>> + .enable_clk = exynos_adc_enable_clk,
>>> };
>>>
>>> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>>> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
>>> .start_conv = exynos_adc_v2_start_conv,
>>> .clear_irq = exynos_adc_v2_clear_irq,
>>> .stop_conv = exynos_adc_v2_stop_conv,
>>> + .disable_clk= exynos_adc_disable_clk,
>>> + .enable_clk = exynos_adc_enable_clk,
>>
>> Based on the fact that all
Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Tomasz,
On 06/18/2014 04:58 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>> clock in FSYS_BLK.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 93
>> ++--
>> 1 file changed, 81 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index c30def6..6b026ac 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -41,7 +41,8 @@
>>
>> enum adc_version {
>> ADC_V1,
>> -ADC_V2
>> +ADC_V2,
>> +ADC_V2_EXYNOS3250,
>> };
>>
>> /* EXYNOS4412/5250 ADC_V1 registers definitions */
>> @@ -85,9 +86,11 @@ enum adc_version {
>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>>
>> struct exynos_adc {
>> +struct device *dev;
>> void __iomem*regs;
>> void __iomem*enable_reg;
>> struct clk *clk;
>> +struct clk *sclk;
>> unsigned intirq;
>> struct regulator*vdd;
>> struct exynos_adc_ops *ops;
>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>
>> u32 value;
>> unsigned intversion;
>> +boolneeds_sclk;
>
> This should be rather a part of the variant struct. See my comments to
> patch 1/4.
OK, I'll include 'needs_sclk' in "variant" structure.
>
>> };
>>
>> struct exynos_adc_ops {
>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>> void (*clear_irq)(struct exynos_adc *info);
>> void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> void (*stop_conv)(struct exynos_adc *info);
>> +void (*disable_clk)(struct exynos_adc *info);
>> +int (*enable_clk)(struct exynos_adc *info);
>> };
>>
>> static const struct of_device_id exynos_adc_match[] = {
>> -{ .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> -{ .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> +{
>> +.compatible = "samsung,exynos-adc-v1",
>> +.data = (void *)ADC_V1,
>> +}, {
>> +.compatible = "samsung,exynos-adc-v2",
>> +.data = (void *)ADC_V2,
>> +}, {
>> +.compatible = "samsung,exynos3250-adc-v2",
>> +.data = (void *)ADC_V2_EXYNOS3250,
>> +},
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct exynos_adc
>> *info)
>> writel(con, ADC_V1_CON(info->regs));
>> }
>>
>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>> +{
>> +if (info->needs_sclk)
>> +clk_disable_unprepare(info->sclk);
>> +clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>> +{
>> +int ret;
>> +
>> +ret = clk_prepare_enable(info->clk);
>> +if (ret) {
>> +dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +if (info->needs_sclk) {
>> +ret = clk_prepare_enable(info->sclk);
>> +if (ret) {
>> +clk_disable_unprepare(info->clk);
>> +dev_err(info->dev,
>> +"failed enabling sclk_tsadc clock: %d\n", ret);
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static struct exynos_adc_ops exynos_adc_v1_ops = {
>> .init_hw= exynos_adc_v1_init_hw,
>> .clear_irq = exynos_adc_v1_clear_irq,
>> .start_conv = exynos_adc_v1_start_conv,
>> .stop_conv = exynos_adc_v1_stop_conv,
>> +.disable_clk= exynos_adc_disable_clk,
>> +.enable_clk = exynos_adc_enable_clk,
>> };
>>
>> static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>> @@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
>> .start_conv = exynos_adc_v2_start_conv,
>> .clear_irq = exynos_adc_v2_clear_irq,
>> .stop_conv = exynos_adc_v2_stop_conv,
>> +.disable_clk= exynos_adc_disable_clk,
>> +.enable_clk = exynos_adc_enable_clk,
>
> Based on the fact that all variants use the same function, I don't think
> there is a reason to add .{disable,enable}_clk in the ops struct. If
> they diverge
Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
Hi Tomasz,
On 06/18/2014 04:55 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patchset add 'exynos_adc_ops' structure which includes some functions
>> to control ADC operation according to ADC version (v1 or v2).
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 174
>> +--
>> 1 file changed, 120 insertions(+), 54 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index 010578f..c30def6 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -90,6 +90,7 @@ struct exynos_adc {
>> struct clk *clk;
>> unsigned intirq;
>> struct regulator*vdd;
>> +struct exynos_adc_ops *ops;
>>
>> struct completion completion;
>>
>> @@ -97,6 +98,13 @@ struct exynos_adc {
>> unsigned intversion;
>> };
>>
>> +struct exynos_adc_ops {
>> +void (*init_hw)(struct exynos_adc *info);
>> +void (*clear_irq)(struct exynos_adc *info);
>> +void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>> +void (*stop_conv)(struct exynos_adc *info);
>> +};
>> +
>> static const struct of_device_id exynos_adc_match[] = {
>> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> @@ -112,30 +120,98 @@ static inline unsigned int
>> exynos_adc_get_version(struct platform_device *pdev)
>> return (unsigned int)match->data;
>> }
>>
>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
>> +{
>> +u32 con1;
>> +
>> +/* set default prescaler values and Enable prescaler */
>> +con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +
>> +/* Enable 12-bit ADC resolution */
>> +con1 |= ADC_V1_CON_RES;
>> +writel(con1, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long
>> addr)
>> +{
>> +u32 con1;
>> +
>> +writel(addr, ADC_V1_MUX(info->regs));
>> +
>> +con1 = readl(ADC_V1_CON(info->regs));
>> +writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
>> +{
>> +writel(1, ADC_V1_INTCLR(info->regs));
>> +}
>> +
>> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
>> +{
>> +u32 con;
>> +
>> +con = readl(ADC_V1_CON(info->regs));
>> +con |= ADC_V1_CON_STANDBY;
>> +writel(con, ADC_V1_CON(info->regs));
>> +}
>> +
>> +static struct exynos_adc_ops exynos_adc_v1_ops = {
>> +.init_hw= exynos_adc_v1_init_hw,
>> +.clear_irq = exynos_adc_v1_clear_irq,
>> +.start_conv = exynos_adc_v1_start_conv,
>> +.stop_conv = exynos_adc_v1_stop_conv,
>> +};
>> +
>> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>> {
>> u32 con1, con2;
>>
>> -if (info->version == ADC_V2) {
>> -con1 = ADC_V2_CON1_SOFT_RESET;
>> -writel(con1, ADC_V2_CON1(info->regs));
>> +con1 = ADC_V2_CON1_SOFT_RESET;
>> +writel(con1, ADC_V2_CON1(info->regs));
>>
>> -con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> -ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> -writel(con2, ADC_V2_CON2(info->regs));
>> +con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> +ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> +writel(con2, ADC_V2_CON2(info->regs));
>>
>> -/* Enable interrupts */
>> -writel(1, ADC_V2_INT_EN(info->regs));
>> -} else {
>> -/* set default prescaler values and Enable prescaler */
>> -con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +/* Enable interrupts */
>> +writel(1, ADC_V2_INT_EN(info->regs));
>> +}
>>
>> -/* Enable 12-bit ADC resolution */
>> -con1 |= ADC_V1_CON_RES;
>> -writel(con1, ADC_V1_CON(info->regs));
>> -}
>> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long
>> addr)
>> +{
>> +u32 con1, con2;
>> +
>> +con2 = readl(ADC_V2_CON2(info->regs));
>> +con2 &= ~ADC_V2_CON2_ACH_MASK;
>> +con2 |= ADC_V2_CON2_ACH_SEL(addr);
>> +writel(con2, ADC_V2_CON2(info->regs));
>> +
>> +con1 = readl(ADC_V2_CON1(info->regs));
>> +writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>> +}
>> +
>> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
>> +{
>> +writel(1, ADC_V2_INT_ST(info->regs));
>> +}
>> +
>> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
>> +{
>> +u32 con;
>> +
>> +con = readl(ADC_V2_CON1(info->regs));
>> +con &= ~ADC_CON_EN_START;
>> +writel(con, ADC_V2_CON1(info->regs));
>> }
>>
>> +static struct exynos_adc_ops exynos_adc_v2_ops = {
>> +
Re: [PATCH 1/3] staging: lustre: ldlm: ldlm_resource.c removed unecessary braces
On Fri, Jun 20, 2014 at 02:01:46AM +1000, Anil Belur wrote:
> From: Anil Belur
>
> - this fixed the "WARNING: braces {} are not necessary for
> single statement blocks"
>
> Signed-off-by: Anil Belur
> ---
> drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Doesn't apply :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] staging: r8192ee: Adapt flush function prototype
On Sat, Jun 07, 2014 at 07:39:19PM +0200, Vincent Stehlé wrote: > Commit 77be2c54c5bd 'mac80211: add vif to flush call' modifies the flush > operation prototype. Update r8192ee function accordingly. > > This fixes the following compilation warnings: > > drivers/staging/rtl8192ee/core.c: At top level: > drivers/staging/rtl8192ee/core.c:1599:2: warning: initialization from > incompatible pointer type [enabled by default] > .flush = rtl_op_flush, > ^ > drivers/staging/rtl8192ee/core.c:1599:2: warning: (near initialization for > ‘rtl92e_ops.flush’) [enabled by default] > > Signed-off-by: Vincent Stehlé > Cc: Greg Kroah-Hartman > Cc: Larry Finger > --- > > Hi, > > Linux next gives a "heads up" that the flush function of staging driver > r8192ee > needs to be adapted soon. > > This can be seen with e.g. linux next-20140606 and x86 allmodconfig. > > Also, r8192ee would benefit from the following patch: > http://www.spinics.net/lists/linux-driver-devel/msg47690.html This doesn't apply as I think it's already done part of a merge... 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: [RFC PATCH] use snprintf instead of sprintf in rcu_torture_printk
On 06/19/2014 07:49 PM, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 07:24:48PM -0400, Pranith Kumar wrote:
>> (dropping some CCs)
>>
>> On 06/19/2014 05:00 PM, Paul E. McKenney wrote:
>>> On Wed, Jun 18, 2014 at 12:49:42PM -0700, Joe Perches wrote:
I believe the function doesn't work well.
static void
rcu_torture_stats_print(void)
{
int size = nr_cpu_ids * 200 + 8192;
char *buf;
buf = kmalloc(size, GFP_KERNEL);
if (!buf) {
pr_err("rcu-torture: Out of memory, need: %d\n", size);
return;
}
rcu_torture_printk(buf);
pr_alert("%s", buf);
kfree(buf);
}
rcu_torture_printk simply fills buf
btw: I believe the arguments should pass size and
rcu_torture_printk should use snprintf/size
but all printks are limited to a maximum of 1024
bytes so the large allocation is senseless and
would even if it worked, would likely need to be
vmalloc/vfree
>>>
>>> Fair point!
>>>
>>> Pranith, Romanov, if you would like part of RCU that is less touchy
>>> about random hacking, this would be a good place to start. Scripts in
>>> tools/testing/selftests/rcutorture/bin do care about some of the format,
>>> but the variable-length portion generated by cur_ops->stats() is as far
>>> as I know only parsed by human eyes.
>>>
>>
>> Here is a first run of the change. Please let me know if I am totally off.
>> RFC. :)
>
> Thank you for taking this on!
You are most welcome :)
>
>> Three things on Todo list:
>>
>> * We need to check that we are using less than the allocated size of the
>> buffer (used > size). (we are allocating a big buffer, so not sure if
>> necessary)
>> * Need to check with the scripts if they are working.
>> * I used a loop for pr_alert(). I am not sure this is right, there should be
>> a better way for printing large buffers
>>
>> If the overall structure is ok I will go ahead and check how the scripts are
>> handling these changes.
>
> One other thing... Convince this function (and a few others that it
> calls) that the system really has 4096 CPUs, run this code, and see what
> actually happens both before and after. Just to get a bit of practice
> mixed in with the theory. ;-)
>
OK. I think to do this I need to use 4096 instead of nr_cpu_ids. I will try
this and see how it goes :)
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] use snprintf instead of sprintf in rcu_torture_printk
On 06/19/2014 07:33 PM, Joe Perches wrote:
>>
>> Here is a first run of the change. Please let me know if I am totally off.
>> RFC. :)
>>
>> Three things on Todo list:
>>
>> * We need to check that we are using less than the allocated size of the
>> buffer (used > size). (we are allocating a big buffer, so not sure if
>> necessary)
>> * Need to check with the scripts if they are working.
>> * I used a loop for pr_alert(). I am not sure this is right, there should be
>> a better way for printing large buffers
>>
>> If the overall structure is ok I will go ahead and check how the scripts are
>> handling these changes.
> []
>> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> []
>> @@ -1130,17 +1134,23 @@ rcu_torture_printk(char *page)
>> static void
>> rcu_torture_stats_print(void)
>> {
> []
>> +/* printk can print only print LOG_LINE_MAX chars at a time */
>> +while (used > 0) {
>> +size_pr = pr_alert("%s", buf);
>> +used -= size_pr;
>> +buf += size_pr;
>> +}
>> +vfree(buf);
>> }
>
> You can't increment buf then vfree it.
>
> Try a char *tmpbuf = buf, and increment it.
>
> I suggest you check by strcspn(tmpbuf, "\n")
> save the byte after, replace it with 0,
> print, replace the 0 with saved byte, and
> loop until end of buffer.
>
Please find v2 which I changed according to your comments:
v2:
* use tmpbuf to increment
* print each line (search for "\n" as suggested and mark with '\0')
* minor fix while calling cur_ops->stats
Signed-off-by: Pranith Kumar
---
include/linux/torture.h | 2 +-
kernel/rcu/rcutorture.c | 86 ++---
kernel/torture.c| 7 ++--
3 files changed, 57 insertions(+), 38 deletions(-)
diff --git a/include/linux/torture.h b/include/linux/torture.h
index 5ca58fc..1e47ec7 100644
--- a/include/linux/torture.h
+++ b/include/linux/torture.h
@@ -51,7 +51,7 @@
/* Definitions for online/offline exerciser. */
int torture_onoff_init(long ooholdoff, long oointerval);
-char *torture_onoff_stats(char *page);
+int torture_onoff_stats(char *page, int size);
bool torture_onoff_failures(void);
/* Low-rider random number generator. */
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7fa34f8..b149c5f 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -242,7 +242,7 @@ struct rcu_torture_ops {
void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
void (*cb_barrier)(void);
void (*fqs)(void);
- void (*stats)(char *page);
+ int (*stats)(char *page, int size);
int irq_capable;
int can_boost;
const char *name;
@@ -525,21 +525,22 @@ static void srcu_torture_barrier(void)
srcu_barrier(_ctl);
}
-static void srcu_torture_stats(char *page)
+static int srcu_torture_stats(char *page, int size)
{
- int cpu;
+ int cpu, used = 0;
int idx = srcu_ctl.completed & 0x1;
- page += sprintf(page, "%s%s per-CPU(idx=%d):",
+ used = snprintf(page, size, "%s%s per-CPU(idx=%d):",
torture_type, TORTURE_FLAG, idx);
for_each_possible_cpu(cpu) {
long c0, c1;
c0 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx];
c1 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx];
- page += sprintf(page, " %d(%ld,%ld)", cpu, c0, c1);
+ used += snprintf(page + used, size - used, " %d(%ld,%ld)", cpu,
c0, c1);
}
- sprintf(page, "\n");
+ used += snprintf(page + used, size - used, "\n");
+ return used;
}
static void srcu_torture_synchronize_expedited(void)
@@ -1033,10 +1034,10 @@ rcu_torture_reader(void *arg)
/*
* Create an RCU-torture statistics message in the specified buffer.
*/
-static void
-rcu_torture_printk(char *page)
+static int
+rcu_torture_printk(char *page, int size)
{
- int cpu;
+ int cpu, used = 0;
int i;
long pipesummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
long batchsummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
@@ -1052,8 +1053,8 @@ rcu_torture_printk(char *page)
if (pipesummary[i] != 0)
break;
}
- page += sprintf(page, "%s%s ", torture_type, TORTURE_FLAG);
- page += sprintf(page,
+ used += snprintf(page + used, size - used, "%s%s ", torture_type,
TORTURE_FLAG);
+ used += snprintf(page + used, size - used,
"rtc: %p ver: %lu tfle: %d rta: %d rtaf: %d rtf: %d ",
rcu_torture_current,
rcu_torture_current_version,
@@ -1061,46 +1062,47 @@ rcu_torture_printk(char *page)
atomic_read(_rcu_torture_alloc),
atomic_read(_rcu_torture_alloc_fail),
atomic_read(_rcu_torture_free));
- page += sprintf(page, "rtmbe: %d rtbke: %ld rtbre: %ld ",
+ used +=
Re: [PATCH] staging: rtl8172u: Make ieee80211_crypto_init static
On Thu, Jun 12, 2014 at 07:40:49PM +0200, L. Alberto Giménez wrote:
> Fix sparse warning.
>
> Signed-off-by: L. Alberto Giménez
> ---
> drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> index 5533221..3be690d 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> @@ -200,7 +200,7 @@ static struct ieee80211_crypto_ops ieee80211_crypt_null =
> {
> .owner = THIS_MODULE,
> };
>
> -int __init ieee80211_crypto_init(void)
> +static int __init ieee80211_crypto_init(void)
> {
> int ret = -ENOMEM;
You obviously did not compile this change :(
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] IBM Akebono: Remove obsolete config select
Hi Ben, It looks like we may have missed this trivial fix? Can you please apply it to your tree? Regards, Alistair On Fri, 13 Jun 2014 13:56:32 Paul Bolle wrote: > On Fri, 2014-05-02 at 18:06 +1000, Alistair Popple wrote: > > The original implementation of MMC support for Akebono introduced a > > new configuration symbol (MMC_SDHCI_OF_476GTR). This symbol has been > > dropped in favour of using the generic platform driver however the > > select for this symbol was mistakenly left in the platform > > configuration. > > > > This patch removes the obsolete symbol selection. > > > > Signed-off-by: Alistair Popple > > This patch hasn't yet entered linux-next nor Linus' tree. Is it queued > somewhere? If not, would a > Acked-by: Paul Bolle > > help to get this trivial patch queued for either of those trees? > > > Paul Bolle > > > --- > > > > arch/powerpc/platforms/44x/Kconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/powerpc/platforms/44x/Kconfig > > b/arch/powerpc/platforms/44x/Kconfig index 8beec7d..908bf11 100644 > > --- a/arch/powerpc/platforms/44x/Kconfig > > +++ b/arch/powerpc/platforms/44x/Kconfig > > @@ -220,7 +220,6 @@ config AKEBONO > > > > select USB_EHCI_HCD_PLATFORM > > select MMC_SDHCI > > select MMC_SDHCI_PLTFM > > > > - select MMC_SDHCI_OF_476GTR > > > > select ATA > > select SATA_AHCI_PLATFORM > > help -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -tip v2 3/3] kprobes: Set IPMODIFY flag only if the probe can change regs->ip
On Thu, 19 Jun 2014 21:34:31 +0900, Namhyung Kim wrote:
> What about this?
>
> static int __ftrace_remove_filter_ip(...)
> {
> if (*ref == 1) {
> int ret = unregister_ftrace_function(ops);
> if (ret < 0)
> return ret;
>
> ftrace_set_filter_ip(ops, ip, 1, 0);
> }
>
> (*ref)--;
> return 0;
> }
Hmm.. I missed removing in *ref > 1 case. Here's a v2. :)
static int __ftrace_remove_filter_ip(...)
{
int ret;
if (*ref == 1) {
ret = unregister_ftrace_function(ops);
if (ret < 0)
return ret;
/* ignore failure here */
ftrace_set_filter_ip(ops, ip, 1, 0);
} else
ret = ftrace_set_filter_ip(ops, ip, 1, 0);
if (ret < 0)
return ret;
}
(*ref)--;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: bcm: Queue.h: fix checkpatch errors
On Wed, Jun 18, 2014 at 04:10:06PM +0200, Christian Bay wrote: > This patch fixes all checkpatch errors and warnings in Queue.h: > Whitespaces, brackets and comments according to the coding guideline Same as the previous one, 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 1/2] Staging: bcm: Prototypes.h: fix checkpatch errors
On Wed, Jun 18, 2014 at 04:10:05PM +0200, Christian Bay wrote: > This patch fixes all errors, excluding > 80 character warnings, shown by the > checkpatch > script. In detail whitespace changes according to the coding guideline are > meant. > Additionally there is exactly one newline after every declaration of methods > now. Please break this up into a "do one thing at a time" set of patches. 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 5/5] x86,vdso: Create .build-id links for unstripped vdso files
On Thu, Jun 19, 2014 at 3:46 PM, H. Peter Anvin wrote: > On 06/18/2014 03:59 PM, Andy Lutomirski wrote: >> >> This may break make vdso_install with binutils before 2.17.50.0.17. >> On the other hand, make vdso_install was probably never useful with >> earlier binutils, since the installed files are AFAIK completely >> useless without build-id. >> > > How does it fail? If --build-id=none on modern binutils accurately replicates old binutils, it fails by silently creating a broken symlink called .debug. If you want this patch for 3.16, I can send a better version that just doesn't create the links on old binutils. > > -hpa > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
On Fri, 4 Apr 2014 17:22:01 +0800
Daniel Kurtz wrote:
> Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> kernel mapping (kvaddr, stored in info->screen_base).
>
> User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
> These functions also only use screen_base/screen_size().
>
> Therefore, it is not necessary to set fix->smem_{start,len} or
> fix->mmio_{start,len} fields.
>
> This avoids leaking kernel, physical and dma mapped addresses to user
> space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.
>
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 5fa342e..2dcc589 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -123,14 +123,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
> *helper,
>
> dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
> fbi->screen_base = buffer->kvaddr + offset;
> - if (is_drm_iommu_supported(dev))
> - fbi->fix.smem_start = (unsigned long)
> - (page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
> - else
> - fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
> -
> fbi->screen_size = size;
> - fbi->fix.smem_len = size;
Can we keep proper initialization of 'smem_len'? Some userland
applications use it for calculating the size for mmap:
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>
> return 0;
> }
Basically, this patch breaks the xf86-video-fbdev ddx and some users
are already unhappy.
--
Best regards,
Siarhei Siamashka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] staging: ft1000: ft1000-usb: ft1000_debug.c: Misc. fixes.
On Fri, Jun 06, 2014 at 08:02:18PM -0700, Thomas Wood wrote: > Remove initialization of static value. > Invert the empty if statement's test to replace the else statement. > Remove parentheses from a return statement. > Fix some code indentation. > > Signed-off-by: Thomas Wood > --- > > I'm pretty sure that the indentation was caused by a mistake by me earlier on > in the patch set, so I'm fixing it now. As Dan says, please fix this in the original patch. Can you please fix this up and resend the whole series? 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 1/9] perf bench: Add --repeat option
Hi Davidlohr, On Thu, Jun 19, 2014 at 11:45 AM, Davidlohr Bueso wrote: > Hi Namhyung, > > On Thu, 2014-06-19 at 15:14 +0900, Namhyung Kim wrote: >> By adding a top-level option, I think it should be applied to all >> benchmaks - but I guess it only supports sched messaging and futex, >> right? > > Yes, for now only those. While there is opportunity for others to use it > as well (perhaps shed-pipe & memcpy/memset), I don't think *all* > benchmarks need multiple runs, ie: numa. Hmm.. but it'd make users confusing if one runs the numa benchmark with -r 5 option but it only do a single run.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] use snprintf instead of sprintf in rcu_torture_printk
On Thu, Jun 19, 2014 at 07:24:48PM -0400, Pranith Kumar wrote:
> (dropping some CCs)
>
> On 06/19/2014 05:00 PM, Paul E. McKenney wrote:
> > On Wed, Jun 18, 2014 at 12:49:42PM -0700, Joe Perches wrote:
> >>
> >> I believe the function doesn't work well.
> >>
> >> static void
> >> rcu_torture_stats_print(void)
> >> {
> >>int size = nr_cpu_ids * 200 + 8192;
> >>char *buf;
> >>
> >>buf = kmalloc(size, GFP_KERNEL);
> >>if (!buf) {
> >>pr_err("rcu-torture: Out of memory, need: %d\n", size);
> >>return;
> >>}
> >>rcu_torture_printk(buf);
> >>pr_alert("%s", buf);
> >>kfree(buf);
> >> }
> >>
> >> rcu_torture_printk simply fills buf
> >>
> >> btw: I believe the arguments should pass size and
> >> rcu_torture_printk should use snprintf/size
> >>
> >> but all printks are limited to a maximum of 1024
> >> bytes so the large allocation is senseless and
> >> would even if it worked, would likely need to be
> >> vmalloc/vfree
> >
> > Fair point!
> >
> > Pranith, Romanov, if you would like part of RCU that is less touchy
> > about random hacking, this would be a good place to start. Scripts in
> > tools/testing/selftests/rcutorture/bin do care about some of the format,
> > but the variable-length portion generated by cur_ops->stats() is as far
> > as I know only parsed by human eyes.
> >
>
> Here is a first run of the change. Please let me know if I am totally off.
> RFC. :)
Thank you for taking this on!
> Three things on Todo list:
>
> * We need to check that we are using less than the allocated size of the
> buffer (used > size). (we are allocating a big buffer, so not sure if
> necessary)
> * Need to check with the scripts if they are working.
> * I used a loop for pr_alert(). I am not sure this is right, there should be
> a better way for printing large buffers
>
> If the overall structure is ok I will go ahead and check how the scripts are
> handling these changes.
One other thing... Convince this function (and a few others that it
calls) that the system really has 4096 CPUs, run this code, and see what
actually happens both before and after. Just to get a bit of practice
mixed in with the theory. ;-)
Thanx, Paul
> >From 0d52fdcd941b0eaaacb6732f59f609595ac14d11 Mon Sep 17 00:00:00 2001
> From: Pranith Kumar
> Date: Thu, 19 Jun 2014 19:00:46 -0400
> Subject: [PATCH 1/1] use snprintf instead of sprintf in
> rcu_torture_print_stats
>
> Signed-off-by: Pranith Kumar
> ---
> include/linux/torture.h | 2 +-
> kernel/rcu/rcutorture.c | 76
> -
> kernel/torture.c| 7 +++--
> 3 files changed, 48 insertions(+), 37 deletions(-)
>
> diff --git a/include/linux/torture.h b/include/linux/torture.h
> index 5ca58fc..1e47ec7 100644
> --- a/include/linux/torture.h
> +++ b/include/linux/torture.h
> @@ -51,7 +51,7 @@
>
> /* Definitions for online/offline exerciser. */
> int torture_onoff_init(long ooholdoff, long oointerval);
> -char *torture_onoff_stats(char *page);
> +int torture_onoff_stats(char *page, int size);
> bool torture_onoff_failures(void);
>
> /* Low-rider random number generator. */
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 7fa34f8..f708db4 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -242,7 +242,7 @@ struct rcu_torture_ops {
> void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
> void (*cb_barrier)(void);
> void (*fqs)(void);
> - void (*stats)(char *page);
> + int (*stats)(char *page, int size);
> int irq_capable;
> int can_boost;
> const char *name;
> @@ -525,21 +525,22 @@ static void srcu_torture_barrier(void)
> srcu_barrier(_ctl);
> }
>
> -static void srcu_torture_stats(char *page)
> +static int srcu_torture_stats(char *page, int size)
> {
> - int cpu;
> + int cpu, used = 0;
> int idx = srcu_ctl.completed & 0x1;
>
> - page += sprintf(page, "%s%s per-CPU(idx=%d):",
> + used = snprintf(page, size, "%s%s per-CPU(idx=%d):",
> torture_type, TORTURE_FLAG, idx);
> for_each_possible_cpu(cpu) {
> long c0, c1;
>
> c0 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx];
> c1 = (long)per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx];
> - page += sprintf(page, " %d(%ld,%ld)", cpu, c0, c1);
> + used += snprintf(page + used, size - used, " %d(%ld,%ld)", cpu,
> c0, c1);
> }
> - sprintf(page, "\n");
> + used += snprintf(page + used, size - used, "\n");
> + return used;
> }
>
> static void srcu_torture_synchronize_expedited(void)
> @@ -1033,10 +1034,10 @@ rcu_torture_reader(void *arg)
> /*
> * Create an RCU-torture statistics message in the specified buffer.
> */
> -static void
> -rcu_torture_printk(char *page)
> +static int
> +rcu_torture_printk(char
Re: [PATCH 5/5] perf tools: Add report.show-headers config file option
On Thu, 19 Jun 2014 18:58:15 +0200, Jiri Olsa wrote: > On Thu, Jun 19, 2014 at 12:28:43PM -0300, Arnaldo Carvalho de Melo wrote: >> Em Thu, Jun 19, 2014 at 09:56:44PM +0900, Namhyung Kim escreveu: >> > 2014-06-19 (목), 13:41 +0200, Jiri Olsa: >> > > Adding report.show-headers config file option to setup >> > > the appearance of the columns headers. >> > > >> > > Currently columns headers are displayed by default, following >> > > lines in ~/.perfconfig file will disable that: >> > > >> > > [report] >> > > show-headers = true >> > >> > This also applies to perf top, right? And it's TUI-specific. So how >> > about calling it something like "tui.show-headers"? >> >> Why should it be TUI specific? You either show the headers or you don't, >> in all UIs. >> >> And also in all tools, I think, so I suggest putting it in some global, >> for all tools, section in the config file, i.e. something like >> all.show-headers. > > seems like so far we have 'core.' and 'hist.' as non-command specific > config sections (note '.core' does not hold any options yet) > > I can add another 'all.' section I don't think it's a better name - it's too general. If we really want to control all UI behavior I'd rather suggest 'ui.' section name. Oh, I found that it'd somewhat clash with existing --header(-only) option in perf report. :-/ Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cannot partition 32GB disk on a 32bit machine (correct version of the patch this time)
On Fri, 2014-06-20 at 00:04 +0100, Alan Cox wrote: > > Wow that's junk issued by an Exchange server ... Alan, really ... > > Blame evolution. It apparently thinks that if you follow up to your own > email from one address it should randomly switch to another. so you @linux.intel.com is sane and you @intel.com is exchange ... > > Do you have CONFIG_LBD turned on? That's supposed to let us go up to > > about 16TB before we run out of page index bits. If you do, we might > > have a variable that's int but should be sector_t somewhere. > > LBDAF is set OK, so as Andrew said, it looks like Viro's conversion from aio to iterators has a length and offset problem on 32 bits. my suspicion is that iov_offset and count in struct iov_iter have to become loff_t quantities ... plus a lot of other size_t to loff_t conversions. Hopefully Viro will fix it as a matter of urgency. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
