Re: same ext4 file system corruption on different machines
Il giorno mer, 29/01/2014 alle 12.38 -0500, Theodore Ts'o ha scritto:
> On Wed, Jan 29, 2014 at 02:05:43PM +0100, Luca Ognibene wrote:
> > I say "same ext4 file system corruption" because e2fsck reports errors
> > on inodes around 127233 on all file systems.a I'm not sure about the
> > syslog errors because i have syslog logs for only the latest faulty
> > partition.
>
> The e2fsck output shows that all of the inodes in a tight sequential
> range around 127233 are getting corrupted. That implies that a
> specific block is getting corrupted. You can see which block by using
> the imap command in debugfs:
>
> # debugfs -R "imap <12345>" /dev/sda3
> debugfs 1.42.9 (28-Dec-2013)
> Inode 12345 is part of block group 1
> located at block 1828, offset 0x0800
These are debugfs(1.42.9) outputs. BROKEN1/BROKEN2 are two partitions
with the problem, CORRECT1 is a system without the problem made from the
same root image.
BROKEN1
debugfs: imap <127233>
Inode 127233 is part of block group 16
located at block 524320, offset 0x
debugfs: bd 524320
*
debugfs: ex <127233>
debugfs:
debugfs: stats
Filesystem volume name:
Last mounted on: /root/dom/a
Filesystem UUID: 6ee8fc7f-9229-44c2-8173-921b9d625436
Filesystem magic number: 0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype extent flex_bg sparse_super large_file huge_file uninit_bg
dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options:user_xattr acl
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 230608
Block count: 921600
Reserved block count: 9216
Free blocks: 298621
Free inodes: 128483
First block: 0
Block size: 4096
Fragment size:4096
Reserved GDT blocks: 224
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7952
Inode blocks per group: 497
Flex block group size:16
Filesystem created: Wed May 15 12:44:06 2013
Last mount time: Tue Jan 28 17:45:16 2014
Last write time: Thu Jan 30 07:31:43 2014
Mount count: 37
Maximum mount count: -1
Last checked: Fri Dec 13 16:56:50 2013
Check interval: 15552000 (6 months)
Next check after: Wed Jun 11 17:56:50 2014
Lifetime writes: 2692 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode:8
Default directory hash: half_md4
Directory Hash Seed: 43472f4b-ba7f-4204-97d8-9addd838f9a6
Journal backup: inode blocks
FS Error count: 13
First error time: Wed Jan 15 08:46:12 2014
First error function: ext4_iget
First error line #: 3888
First error inode #: 127233
First error block #: 0
Last error time: Tue Jan 28 17:46:07 2014
Last error function: ext4_iget
Last error line #:3888
Last error inode #: 127233
Last error block #: 0
Directories: 11616
Group 0: block bitmap at 226, inode bitmap at 242, inode table at 258
17418 free blocks, 0 free inodes, 1013 used directories, 0
unused inodes
[Checksum 0x2793]
Group 1: block bitmap at 227, inode bitmap at 243, inode table at 755
1 free block, 0 free inodes, 741 used directories, 0 unused
inodes
[Checksum 0xb365]
Group 2: block bitmap at 228, inode bitmap at 244, inode table at 1252
114 free blocks, 0 free inodes, 1175 used directories, 0
unused inodes
[Checksum 0xed5f]
Group 3: block bitmap at 229, inode bitmap at 245, inode table at 1749
10815 free blocks, 0 free inodes, 868 used directories, 0
unused inodes
[Checksum 0x3127]
Group 4: block bitmap at 230, inode bitmap at 246, inode table at 2246
0 free blocks, 0 free inodes, 861 used directories, 0 unused
inodes
[Checksum 0xfd99]
Group 5: block bitmap at 231, inode bitmap at 247, inode table at 2743
0 free blocks, 1 free inode, 741 used directories, 0 unused
inodes
[Checksum 0x1b9e]
Group 6: block bitmap at 232, inode bitmap at 248, inode table at 3240
0 free blocks, 364 free inodes, 487 used directories, 0
unused inodes
[Checksum 0x0b53]
Group 7: block bitmap at 233, inode bitmap at 249, inode table at 3737
78 free blocks, 3977 free inodes, 348 used directories, 3874
unused inodes
[Checksum 0x8ffb]
Group 8: block bitmap at 234, inode bitmap at 250, inode table at 4234
0 free blocks, 7922 free inodes, 30 used directories, 7695
unused inodes
[Che
Re: [PATCH v2] ceph: fix posix ACL hooks
On Wed, Jan 29, 2014 at 11:09:18AM -0800, Linus Torvalds wrote: > So attached is the incremental diff of the patch by Sage and Ilya, and > I'll apply it (delayed a bit to see if I can get the sign-off from > Ilya), but I also think we should fix the (non-cached) ACL functions > that call down to the filesystem layer to also get the dentry. For ->set_acl that's fairly easily doable and I actually had a version doing that to be able to convert 9p. But for ->get_acl the path walking caller didn't seem easily feasible. ->get_acl actually is an invention of yours, so if you got a good idea to get the dentry to it I'd love to be able to pass it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
On 01/30/2014 06:42 AM, Amit Grover wrote:
> This patch adds Controls to set Horizontal and Vertical search range
> for Motion Estimation block for Samsung MFC video Encoders.
>
> Signed-off-by: Swami Nathan
> Signed-off-by: Amit Grover
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24
> +++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
> 4 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> index 2398cdf..8d0b686 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> @@ -229,6 +229,7 @@
> #define S5P_FIMV_E_PADDING_CTRL_V6 0xf7a4
> #define S5P_FIMV_E_MV_HOR_RANGE_V6 0xf7ac
> #define S5P_FIMV_E_MV_VER_RANGE_V6 0xf7b0
> +#define S5P_FIMV_E_MV_RANGE_V6_MASK 0x3fff
>
> #define S5P_FIMV_E_VBV_BUFFER_SIZE_V60xf84c
> #define S5P_FIMV_E_VBV_INIT_DELAY_V6 0xf850
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 6920b54..b90ee34 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
> struct s5p_mfc_enc_params {
> u16 width;
> u16 height;
> + u32 mv_h_range;
> + u32 mv_v_range;
>
> u16 gop_size;
> enum v4l2_mpeg_video_multi_slice_mode slice_mode;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 4ff3b6c..704f30c1 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
> .default_value = 0,
> },
> {
> + .id = V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Horizontal MV Search Range",
Don't set the name here if the control is also defined in v4l2-ctrls.
That way the string from v4l2-ctrls is the leading definition.
Regards,
Hans
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Vertical MV Search Range",
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> .id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
> .type = V4L2_CTRL_TYPE_INTEGER,
> .minimum = 0,
> @@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
> p->vbv_size = ctrl->val;
> break;
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
> + p->mv_h_range = ctrl->val;
> + break;
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> + p->mv_v_range = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
> p->codec.h264.cpb_size = ctrl->val;
> break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 461358c..3c10188 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx
> *ctx)
> WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
>
> /* setting for MV range [16, 256] */
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->mv_h_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
> WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
>
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->mv_v_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
> WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
>
> WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range
On 01/30/2014 06:42 AM, Amit Grover wrote:
> Adding V4L2 controls for horizontal and vertical search range in pixels
> for motion estimation module in video encoder.
>
> Signed-off-by: Swami Nathan
> Signed-off-by: Amit Grover
> ---
> Documentation/DocBook/media/v4l/controls.xml | 20
> drivers/media/v4l2-core/v4l2-ctrls.c | 14 ++
> include/uapi/linux/v4l2-controls.h |2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index 7a3b49b..be04d18 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.
> VBV buffer control.
>
>
> +
> +
> + spanname="id">V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE
> + integer
> +
> + Horizontal search range defines
> maximum horizontal search area in pixels
> +to search and match for the present Macroblock (MB) in the reference
> picture. This V4L2 control macro is used to set
> +horizontal search range for motion estimation module in video
> encoder.
> +
> +
> +
> +
> + spanname="id">V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE
> + integer
These two controls sound very mfc specific as opposed to being part of the
standard.
If so, then they should be named V4L2_CID_MPEG_MFC51_*. Also, for which codecs
are
these controls applicable?
> +
> + Vertical search range defines
> maximum vertical search area in pixels
> +to search and match for the present Macroblock (MB) in the reference
> picture. This V4L2 control macro is used to set
> +vertical search range for motion estimation module in video encoder.
> +
> +
>
>
>spanname="id">V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index fb46790..e775388 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video
> Decoder PTS";
> case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video
> Decoder Frame Count";
> case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial
> Delay for VBV Control";
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return
> "Horizontal MV Search Range";
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return
> "Vertical MV Search Range";
> case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat
> Sequence Header";
>
> /* VPX controls */
> @@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> *min = 0;
> *max = *step = 1;
> break;
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
Weird range, why not use range 1-8?
> + break;
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
> + break;
> case V4L2_CID_PAN_RESET:
> case V4L2_CID_TILT_RESET:
> case V4L2_CID_FLASH_STROBE:
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 1666aab..80e1def 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
> #define V4L2_CID_MPEG_VIDEO_DEC_FRAME
> (V4L2_CID_MPEG_BASE+224)
> #define V4L2_CID_MPEG_VIDEO_VBV_DELAY
> (V4L2_CID_MPEG_BASE+225)
> #define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER
> (V4L2_CID_MPEG_BASE+226)
> +#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE
> (V4L2_CID_MPEG_BASE+227)
> +#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE
> (V4L2_CID_MPEG_BASE+228)
>
> #define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
> #define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
>
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation cleanup, update 00-INDEX files in Documentation/
On Wed, Jan 29, 2014 at 10:24:11PM -0600, Rob Landley wrote: > [...] > However, I'm curious about this bit: > > >--- a/Documentation/00-INDEX > >+++ b/Documentation/00-INDEX > >@@ -1,11 +1,11 @@ > > > >-This is a brief list of all the files in ./linux/Documentation and what > >-they contain. If you add a documentation file, please list it here in > >-alphabetical order as well, or risk being hunted down like a rabid dog. > >-Please keep the descriptions small enough to fit on one line. > >- Thanks -- Paul G. > >+# This is a brief list of all the files in ./linux/Documentation and what > >+# they contain. If you add a documentation file, please list it here in > >+# alphabetical order as well, or risk being hunted down like a rabid dog. > >+# Please keep the descriptions small enough to fit on one line. > >+#Thanks -- Paul G. > > > >-Following translations are available on the WWW: > >+# Following translations are available on the WWW: > > Is there a reason for that? Ahem, yes, but not anymore. Leftovers from my initial index-traverse.py hack. Updated patch below. henrik >From 78882b49b0910079aa574781accc9426e215ac78 Mon Sep 17 00:00:00 2001 From: Henrik Austad Date: Thu, 31 Oct 2013 14:19:10 +0100 Subject: [PATCH] Documentation cleanup, update 00-INDEX files in Documentation/ Some of the 00-INDEX files are somewhat outdated and some folders does not contain 00-INDEX at all. Only outdated (with the notably exception of spi) indexes are touched here, the 169 folders without 00-INDEX has not been touched. This applies to Linus' tip (0e47c969). New 00-INDEX - spi/* was added in a series of commits dating back to 2006 Added files (missing in (*/)00-INDEX) - dmatest.txt was added by 851b7e16 (dmatest: run test via debugfs). - this_cpu_ops.txt was added by a1b2a555 (percpu: add documentation on this_cpu operations) - ww-mutex-design.txt was added by 040a0a37 (mutex: Add support for wound/wait style locks) - bcache.txt was added by cafe5635 (bcache: A block layer cache) - kernel-per-CPU-kthreads.txt was added by 49717cb40 (kthread: Document ways of reducing OS jitter due to per-CPU kthreads). - phy.txt was added by ff764963 (phy: add generic PHY framework) - block/null_blk was added by 12f8f4fc (null_blk: documentation) - module-signing.txt was added by 3cafea30 (Add Documentation/module-signing.txt file) - assoc_array.txt was added by 3cb98950 (Add a generic associative array implementation.) - arm/IXP4xx was part of the initial repo (1da177e4). - arm/cluster-pm-race-avoidance.txt was added by 7fe31d28 (ARM: mcpm: introduce helpers for platform coherency exit/setup). - arm/firmware.txt was added by 7366b92a (ARM: Add interface for registering and calling firmware-specific operations). - arm/kernel_mode_neon.txt was added by 2afd0a05 (ARM: 7825/1: document the use of NEON in kernel mode) - arm/tcm.txt was added by bc581770 (ARM: 5580/2: ARM TCM (Tightly-Coupled Memory) support v3) - arm/vlocks.txt was added by 9762f12d (ARM: mcpm: Add baremetal voting mutexes) - blackfin/gptimers-example.c, Makefile was added by 4b60779d (Blackfin: add an example showing how to use the gptimers API) - devicetree/usage-model.txt was added by 31134efc (dt: Linux DT usage model documentation) - fb/api.txt was added by fb21c2f4 (fbdev: Add FOURCC-based format configuration API) - fb/sm501.txt was added by e6a04980 (video, sm501: add edid and commandline support) - fb/udlfb.txt was added by 96f8d864 (fbdev: move udlfb out of staging.) - filesystems/Makefile was added by 1e0051ae (Documentation/fs/: split txt and source files) - filesystems/nfs/nfsd-admin-interfaces.txt was added by 8a4c6e19 (nfsd: document kernel interfaces for nfsd configuration) - ide/warm-plug-howto.txt was added by f74c9141 (ide: add warm-plug support for IDE devices (take 2)) - laptops/Makefile was added by d49129ac (Documentation/laptop/: split txt and source files). - leds/leds-blinkm.txt was added by b54cf35a (LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS) - leds/ledtrig-oneshot.txt was added by 5e417281c (leds: add oneshot trigger) - leds/ledtrig-transient.txt was added by 44e1e9f8 (leds: add new transient trigger for one shot timer activation) - m68k/README.buddha was part of the initial repo (1da177e4). - networking/LICENSE.(qla3xxx|qlcnic|qlge) was added by 5a4faa87, 40839129, c4e84bde. - networking/Makefile was added by 3794f3e8 (docsrc: build Documentation/ sources) - networking/i40evf.txt was added by 105bf2fe (i40evf: add driver to kernel build system) - networking/ipsec.txt was added by b3c6efbc (xfrm: Add file to document IPsec corner case) - networking/mac80211-auth-assoc-deauth.txt was added by 3cd7920a (mac80211: add auth/assoc/deauth flow diagram) - networking/netlink_mmap.txt was added by 5683264c (netlink: add documentation for memory mapped I/O) - net
Re: [PATCH v3] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Thu, Jan 30, 2014 at 11:48 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 30 January 2014 09:49 AM, Vivek Gautam wrote: >> Hi Kishon, >> >> >> On Mon, Jan 27, 2014 at 2:27 PM, Kishon Vijay Abraham I >> wrote: >>> Hi, >> >> Thanks for review. Please find my answers inline below. >> >>> >>> On Monday 20 January 2014 07:12 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Thereby, removing old phy-samsung-usb3 driver and related code used untill now which was based on usb/phy framework. Signed-off-by: Vivek Gautam --- Changes from v2: 1) Added support for multiple PHYs (UTMI+ and PIPE3) and related changes in the driver structuring. 2) Added a xlate function to get the required phy out of number of PHYs in mutiple PHY scenerio. 3) Changed the names of few structures and variables to have a clearer meaning. 4) Added 'usb3phy_config' structure to take care of mutiple phys for a SoC having 'exynos5_usb3phy_drv_data' driver data. 5) Not deleting support for old driver 'phy-samsung-usb3' until required support for generic phy is added to DWC3. .../devicetree/bindings/phy/samsung-phy.txt| 49 ++ drivers/phy/Kconfig|8 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 621 4 files changed, 679 insertions(+) create mode 100644 drivers/phy/phy-exynos5-usb3.c >> [snip] >> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 330ef2d..32f9f38 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO help Support for Display Port PHY found on Samsung EXYNOS SoCs. +config PHY_EXYNOS5_USB3 > > This shouldn't be USB3 since this driver has support for both USB2 and USB3. > maybe just PHY_EXYNOS5_USB? Ok, will change this. + tristate "Exynos5 SoC series USB 3.0 PHY driver" + depends on ARCH_EXYNOS5 + select GENERIC_PHY + select MFD_SYSCON >>> >>> add depends on 'HAS_IOMEM'. Someone reported getting >>> undefined reference to `devm_ioremap_resource' with it. >> >> Ok will add it. >> + help + Enable USB 3.0 PHY support for Exynos 5 SoC series + endmenu >> [snip] >> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..24efed0 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,621 @@ +/* + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Author: Vivek Gautam + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Exynos USB PHY registers */ +#define EXYNOS5_FSEL_9MHZ6 0x0 +#define EXYNOS5_FSEL_10MHZ 0x1 +#define EXYNOS5_FSEL_12MHZ 0x2 +#define EXYNOS5_FSEL_19MHZ2 0x3 +#define EXYNOS5_FSEL_20MHZ 0x4 +#define EXYNOS5_FSEL_24MHZ 0x5 +#define EXYNOS5_FSEL_50MHZ 0x7 + +/* EXYNOS5: USB 3.0 DRD PHY registers */ +#define EXYNOS5_DRD_LINKSYSTEM (0x04) + +#define LINKSYSTEM_FLADJ_MASK(0x3f << 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27) + +#define EXYNOS5_DRD_PHYUTMI (0x08) + +#define PHYUTMI_OTGDISABLE (0x1 << 6) +#define PHYUTMI_FORCESUSPEND (0x1 << 1) +#define PHYUTMI_FORCESLEEP (0x1 << 0) >>> >>> use BIT macro here and below? >> >> Ok. >> + +#define EXYNOS5_DRD_PHYPIPE (0x0c) + +#define EXYNOS5_DRD_PHYCLKRST(0x10) + +#define PHYCLKRST_EN_UTMISUSPEND (0x1 << 31) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) + +#define PHYCLKRST_SSC_EN
[PATCH] btrfs: Return EXDEV for cross file system snapshot
EXDEV seems an appropriate error if an operation fails bacause it
crosses file system boundaries.
Signed-off-by: Kusanagi Kouichi
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 34772cb..0176045 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1573,7 +1573,7 @@ static noinline int
btrfs_ioctl_snap_create_transid(struct file *file,
if (src_inode->i_sb != file_inode(file)->i_sb) {
btrfs_info(BTRFS_I(src_inode)->root->fs_info,
"Snapshot src from another FS");
- ret = -EINVAL;
+ ret = -EXDEV;
} else if (!inode_owner_or_capable(src_inode)) {
/*
* Subvolume creation is not restricted, but snapshots
--
1.9.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/9] perf tools: Fix symbol annotation for relocated kernel
On 29/01/14 20:57, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 29, 2014 at 04:14:36PM +0200, Adrian Hunter escreveu:
>> Kernel maps map memory addresses to file offsets.
>> For symbol annotation, objdump needs the object VMA
>> addresses. For an unrelocated kernel, that is the
>> same as the memory address.
>>
>> The addresses passed to objdump for symbol annotation
>> did not take into account kernel relocation. This
>> patch fixes that.
>
> Question: To fix the problem reported by Linus, i.e. the very minimal
> fix, we only need this patch, right?
Yes but the other fixes are needed too.
>
> Reading the other patches now.
>
> - Arnaldo
>
>> Signed-off-by: Adrian Hunter
>> ---
>> tools/perf/util/map.c| 5 +++--
>> tools/perf/util/map.h| 1 +
>> tools/perf/util/symbol-elf.c | 2 ++
>> 3 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
>> index ee1dd68..b46f527 100644
>> --- a/tools/perf/util/map.c
>> +++ b/tools/perf/util/map.c
>> @@ -39,6 +39,7 @@ void map__init(struct map *map, enum map_type type,
>> map->start= start;
>> map->end = end;
>> map->pgoff= pgoff;
>> +map->reloc= 0;
>> map->dso = dso;
>> map->map_ip = map__map_ip;
>> map->unmap_ip = map__unmap_ip;
>> @@ -288,7 +289,7 @@ u64 map__rip_2objdump(struct map *map, u64 rip)
>> if (map->dso->rel)
>> return rip - map->pgoff;
>>
>> -return map->unmap_ip(map, rip);
>> +return map->unmap_ip(map, rip) - map->reloc;
>> }
>>
>> /**
>> @@ -311,7 +312,7 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
>> if (map->dso->rel)
>> return map->unmap_ip(map, ip + map->pgoff);
>>
>> -return ip;
>> +return ip + map->reloc;
>> }
>>
>> void map_groups__init(struct map_groups *mg)
>> diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
>> index 18068c6..257e513 100644
>> --- a/tools/perf/util/map.h
>> +++ b/tools/perf/util/map.h
>> @@ -36,6 +36,7 @@ struct map {
>> boolerange_warned;
>> u32 priv;
>> u64 pgoff;
>> +u64 reloc;
>> u32 maj, min; /* only valid for MMAP2 record */
>> u64 ino; /* only valid for MMAP2 record */
>> u64 ino_generation;/* only valid for MMAP2 record */
>> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
>> index 7594567..8ce52da 100644
>> --- a/tools/perf/util/symbol-elf.c
>> +++ b/tools/perf/util/symbol-elf.c
>> @@ -751,6 +751,8 @@ int dso__load_sym(struct dso *dso, struct map *map,
>> if (strcmp(elf_name, kmap->ref_reloc_sym->name))
>> continue;
>> kmap->ref_reloc_sym->unrelocated_addr = sym.st_value;
>> +map->reloc = kmap->ref_reloc_sym->addr -
>> + kmap->ref_reloc_sym->unrelocated_addr;
>> break;
>> }
>> }
>> --
>> 1.7.11.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kmem_cache_alloc panic in 3.10+
> > On Sat, 2014-01-18 at 00:44 -0800, dormando wrote: > > > Hello again! > > > > > > We've had a rare crash that's existed between 3.10.0 and 3.10.15 at least > > > (trying newer stables now, but I can't tell if it was fixed, and it takes > > > weeks to reproduce). > > > > > > Unfortunately I can only get 8k back from pstore. The panic looks a bit > > > longer than that is caught in the log, but the bottom part is almost > > > always this same trace as this one: > > > > > > Panic#6 Part1 > > > <4>[1197485.199166] [] tcp_push+0x6c/0x90 > > > <4>[1197485.199171] [] tcp_sendmsg+0x109/0xd40 > > > <4>[1197485.199179] [] ? put_page+0x35/0x40 > > > <4>[1197485.199185] [] inet_sendmsg+0x45/0xb0 > > > <4>[1197485.199191] [] sock_aio_write+0x11e/0x130 > > > <4>[1197485.199196] [] ? inet_recvmsg+0x4f/0x80 > > > <4>[1197485.199203] [] do_sync_readv_writev+0x6d/0xa0 > > > <4>[1197485.199209] [] do_readv_writev+0xfb/0x2f0 > > > <4>[1197485.199215] [] ? __free_pages+0x35/0x40 > > > <4>[1197485.199220] [] ? free_pages+0x46/0x50 > > > <4>[1197485.199226] [] ? SyS_mincore+0x152/0x690 > > > <4>[1197485.199231] [] vfs_writev+0x48/0x60 > > > <4>[1197485.199236] [] SyS_writev+0x5f/0xd0 > > > <4>[1197485.199243] [] system_call_fastpath+0x16/0x1b > > > <4>[1197485.199247] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 > > > 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 > > > 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c > > > <1>[1197485.199290] RIP [] kmem_cache_alloc+0x5a/0x130 > > > <4>[1197485.199296] RSP > > > <4>[1197485.199299] CR2: 0001 > > > <4>[1197485.199343] ---[ end trace 90fee06aa40b7304 ]--- > > > <1>[1197485.263911] BUG: unable to handle kernel paging request at > > > 0001 > > > <1>[1197485.263923] IP: [] kmem_cache_alloc+0x5a/0x130 > > > <4>[1197485.263932] PGD 3f43e5c067 PUD 0 > > > <4>[1197485.263937] Oops: [#5] SMP > > > <4>[1197485.263941] Modules linked in: ntfs vfat msdos fat macvlan bridge > > > coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode sb_edac > > > edac_core lpc_ich mfd_core ixgbe igb i2c_algo_bit mdio ptp pps_core > > > <4>[1197485.263966] CPU: 0 PID: 233846 Comm: cache-worker Tainted: G > > > D 3.10.15 #1 > > > <4>[1197485.263972] Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 2.0a > > > 03/07/2013 > > > <4>[1197485.263976] task: 883427f9dc00 ti: 8830d4312000 task.ti: > > > 8830d4312000 > > > <4>[1197485.263982] RIP: 0010:[] [] > > > kmem_cache_alloc+0x5a/0x130 > > > <4>[1197485.263990] RSP: 0018:881fffc038c8 EFLAGS: 00010286 > > > <4>[1197485.263994] RAX: RBX: 81c8c740 RCX: > > > > > > <4>[1197485.263999] RDX: 29273024 RSI: 0020 RDI: > > > 00015680 > > > <4>[1197485.264004] RBP: 881fffc03908 R08: 881fffc15680 R09: > > > 815bdd4b > > > <4>[1197485.264009] R10: 881c65d21800 R11: R12: > > > 881fff803800 > > > <4>[1197485.264014] R13: 0001 R14: R15: > > > > > > <4>[1197485.264019] FS: 7f8d855eb700() GS:881fffc0() > > > knlGS: > > > <4>[1197485.264024] CS: 0010 DS: ES: CR0: 80050033 > > > <4>[1197485.264028] CR2: 0001 CR3: 00308f258000 CR4: > > > 000407f0 > > > <4>[1197485.264032] DR0: DR1: DR2: > > > > > > <4>[1197485.264037] DR3: DR6: 0ff0 DR7: > > > 0400 > > > <4>[1197485.264041] Stack: > > > <4>[1197485.264044] 881fffc03928 0020815d0d95 881fffc03938 > > > 81c8c740 > > > <4>[1197485.264050] 881fce21 0001 > > > > > > <4>[1197485.264056] 881fffc03958 815bdd4b 881fffc039a8 > > > > > > <4>[1197485.264063] Call Trace: > > > <4>[1197485.264066] > > > <4>[1197485.264069] [] dst_alloc+0x5b/0x190 > > > <4>[1197485.264080] [] rt_dst_alloc+0x4c/0x50 > > > <4>[1197485.264085] [] > > > __ip_route_output_key+0x270/0x880 > > > <4>[1197485.264092] [] ? try_to_wake_up+0x23e/0x2b0 > > > <4>[1197485.264097] [] ip_route_output_flow+0x27/0x60 > > > <4>[1197485.264102] [] ip_queue_xmit+0x36a/0x390 > > > <4>[1197485.264108] [] tcp_transmit_skb+0x485/0x890 > > > <4>[1197485.264113] [] tcp_send_ack+0xf1/0x130 > > > <4>[1197485.264118] [] __tcp_ack_snd_check+0x5e/0xa0 > > > <4>[1197485.264123] [] > > > tcp_rcv_state_process+0x8b2/0xb20 > > > <4>[1197485.264128] [] tcp_v4_do_rcv+0x191/0x4f0 > > > <4>[1197485.264133] [] tcp_v4_rcv+0x5fc/0x750 > > > <4>[1197485.264138] [] ? ip_rcv+0x350/0x350 > > > <4>[1197485.264143] [] ? nf_hook_slow+0x7d/0x160 > > > <4>[1197485.264147] [] ? ip_rcv+0x350/0x350 > > > <4>[1197485.264152] [] > > > ip_local_deliver_finish+0xce/0x250 > > > <4>[1197485.264156] [] ip_local_deli
Re: Do we really need curr_target in signal_struct ?
On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov wrote: > On 01/29, Rakib Mullick wrote: >> Are you thinking that , since things are not broken, then we shouldn't >> try to do anything? > > Hmm. No. > > I am thinking that, since you misunderstood the purpose of ->curr_target, > I should probably try to argue with your patch which blindly removes this > optimization ? > Since the optimization (usages of ->curr_target) isn't perfect, so there's chance of being misunderstood. This optimization is misleading too (I think), cause curr_target don't have anything to do with wants_signal() and ->curr_target is used only for this optimization and to get this optimization needs to maintain it properly, and this maintenance does have cost and if we don't get benefited too much, then it doesn't worth it (my pov). > I also think that this logic doesn't look perfect, but this is another > story. Yes, this logic seems need to improve. Thanks, Rakib -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()
On 2014-01-26 11:53, Geert Uytterhoeven wrote:
> drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
> drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used
> uninitialized in this function
>
> Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 ("ath9k:
> optimize ath9k_flush").
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Felix Fietkau
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 freeze with v3.13 on Avoton CPUs
On 01/23/2014 01:44 PM, Peter Tyser wrote: On 01/23/2014 12:50 AM, Guenter Roeck wrote: Hi folks, we are seeing an odd problem with kernel version 3.13 running on Mohan Peak with an Avoton 8-core CPU. The kernel boots to the login prompt and then freezes silently within a few seconds. The problem disappears if we revert patch 8477128fe0 (mfd: lpc_ich: Add support for Intel Avoton SoC). v3.10.27 runs fine. If we cherry-pick 8477128fe0 on top of 3.10.27 we see exactly the same problem. Any idea what might be causing this, and/or what we could do to track this down further ? I took a look at the Avoton datasheet, and it looks like its register layout is close, but not identical to the other ICH chipsets supported by the lpc_ich driver which could be part of the issue. Eg the "enable ACPI BAR" bit is in register offset 0x44 of PCI device 31, function 0 on most ICH chipsets, while it's in 0x40 on the Avoton. So on the Avoton the "enable ACPI BAR" bit isn't being set by the lpc_ich driver. If your BIOS didn't set this bit, it could cause erratic behavior since Linux assumes the ACPI region has been enabled. The driver is also writing to offset 0x44 which is RO/reserved on the Avoton. In theory this should be OK, but clearly isn't "correct". The same comment applies to the GPIO register in PCI device 31, function 0. The current lpc_ich driver enables the GPIO region in offset 0x4C while the Avoton does in 0x48. I'm not sure if the above explains the specific behavior you saw, but does indicate that the driver shouldn't be used for the Avoton as-is. I don't have an Avoton to try and reproduce, but do have access to a Bay Trail platform which appears to have the same register layout as the Avoton. I can give adding it to the lpc_ich driver a shot in the next week and see if I run into the same issues as you did. In the short term we could either revert 8477128fe0 or wait a bit until more investigation is done in hopes that we can fix it. As a follow up on this problem, it appears that the culprit may be the iTCO watchdog timer, which is enabled in our system. Looks like the iTCO registers are sufficiently similar to enable the watchdog, but different enough to cause the heartbeat ping to fail. If so, that would explain why the system freezes only after reaching the login prompt. So far this is only a theory since I don't have a Rangeley/Avoton datasheet and can not really compare registers. I'll try to dig one up and find out more. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4
On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote: > This series of patches add support for XIP to ext4. Unfortunately, > it turns out to be necessary to rewrite the existing XIP support code > first due to races that are unfixable in the current design. > > Since v4 of this patchset, I've improved the documentation, fixed a > couple of warnings that a newer version of gcc emitted, and fixed a > bug where we would read/write the wrong address for I/Os that were not > aligned to PAGE_SIZE. Looks like there's something fundamentally broken with the patch set as it stands. I get this same data corruption on both ext4 and XFS with XIP using fsx. It's as basic as it gets - the first read after a mmapped write fails to see the data written by mmap: $ sudo mkfs.xfs -f /dev/ram0 meta-data=/dev/ram0 isize=256agcount=4, agsize=256000 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 data = bsize=4096 blocks=1024000, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 $ sudo mount -o xip /dev/ram0 /mnt/scr $ sudo chmod 777 /mnt/scr $ ltp/fsx -d -N 1000 -S 0 /mnt/scr/fsx Seed set to 3774 1 mapwrite 0x3db39 thru0x3 (0x24c7 bytes) 2 mapread 0x2e947 thru0x33163 (0x481d bytes) 3 read 0x2e836 thru0x3cba1 (0xe36c bytes) 4 punch from 0x2e7 to 0x5c43, (0x595c bytes) 5 mapwrite 0xcaea thru 0x13ba9 (0x70c0 bytes) 6 punch from 0x31645 to 0x38d1d, (0x76d8 bytes) 7 fallocfrom 0x24f92 to 0x2f2b7 (0xa325 bytes) fallocating to largest ever: 0x171ac 8 fallocfrom 0xbcf1 to 0x171ac (0xb4bb bytes) 9 read 0x126f thru 0x11136 (0xfec8 bytes) READ BAD DATA: offset = 0x126f, size = 0xfec8, fname = /mnt/scr/fsx OFFSET GOODBAD RANGE 0x caea 0x05f9 0x 0x0 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caeb 0xf905 0x 0x1 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caec 0x0599 0x 0x2 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caed 0x9905 0x 0x3 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caee 0x05e8 0x 0x4 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caef 0xe805 0x 0x5 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf0 0x0580 0x 0x6 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf1 0x8005 0x 0x7 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf2 0x056c 0x 0x8 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf3 0x6c05 0x 0x9 operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf4 0x05ad 0x 0xa operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf5 0xad05 0x 0xb operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf6 0x0539 0x 0xc operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf7 0x3905 0x 0xd operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf8 0x05db 0x 0xe operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops 0x caf9 0xdb05 0x 0xf operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops LOG DUMP (9 total operations): 1( 1 mod 256): MAPWRITE 0x3db39 thru 0x3 (0x24c7 bytes) 2( 2 mod 256): MAPREAD 0x2e947 thru 0x33163 (0x481d bytes) 3( 3 mod 256): READ 0x2e836 thru 0x3cba1 (0xe36c bytes) 4( 4 mod 256): PUNCH0x2e7 thru 0x5c42 (0x595c bytes) 5( 5 mod 256): MAPWRITE 0xcaea thru 0x13ba9(0x70c0 bytes) ** 6( 6 mod 256): PUNCH0x31645 thru 0x38d1c (0x76d8 bytes) 7( 7 mod 256): FALLOC 0x24f92 thru 0x2f2b7 (0xa325 bytes) INTERIOR 8( 8 mod 256): FALLOC 0xbcf1 thru 0x171ac(0xb4bb bytes) INTERIOR ** 9( 9 mod 256): READ 0x126f thru 0x11136(0xfec8 bytes) ****** Correct content saved for comparison (maybe hexdump "/mnt/scr/fsx" vs "/mnt/scr/fsx.fsxgood") XFS gives a good indication that we aren't doing something correctly w.r.t. mapped XIP writes, as trying to fiemap the file ASSERT fails with a delayed allocation extent somewhere inside the file after a sync. I shall keep digging. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/maj
[PATCH] mm, hugetlb: gimme back my page
From: Davidlohr Bueso
While testing some changes, I noticed an issue triggered by the libhugetlbfs
test-suite. This is caused by commit 309381fe (mm: dump page when hitting a
VM_BUG_ON using VM_BUG_ON_PAGE), where an application can unexpectedly OOM due
to another program that using, or reserving, pool_size-1 pages later triggers
a VM_BUG_ON_PAGE and thus greedly leaves no memory to the rest of the hugetlb
aware tasks. For example, in libhugetlbfs 2.14:
mmap-gettest 10 32783 (2M: 64): < hit VM_BUG_ON_PAGE
mmap-cow 32782 32783 (2M: 32): FAILFailed to create shared mapping: Cannot
allocate memory
mmap-cow 32782 32783 (2M: 64): FAILFailed to create shared mapping: Cannot
allocate memory
While I have not looked into why 'mmap-gettest' keeps failing, it is of no
importance to this particular issue. This problem is similar to why we have
the hugetlb_instantiation_mutex, hugepages are quite finite.
Revert the use of VM_BUG_ON_PAGE back to just VM_BUG_ON.
Signed-off-by: Davidlohr Bueso
---
include/linux/hugetlb.h| 3 +--
include/linux/hugetlb_cgroup.h | 5 ++---
mm/hugetlb.c | 10 +-
mm/hugetlb_cgroup.c| 2 +-
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..d01cc97 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -2,7 +2,6 @@
#define _LINUX_HUGETLB_H
#include
-#include
#include
#include
#include
@@ -355,7 +354,7 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct
vm_area_struct *vma,
static inline struct hstate *page_hstate(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
+ VM_BUG_ON(!PageHuge(page));
return size_to_hstate(PAGE_SIZE << compound_order(page));
}
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index 787bba3..ce8217f 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -15,7 +15,6 @@
#ifndef _LINUX_HUGETLB_CGROUP_H
#define _LINUX_HUGETLB_CGROUP_H
-#include
#include
struct hugetlb_cgroup;
@@ -29,7 +28,7 @@ struct hugetlb_cgroup;
static inline struct hugetlb_cgroup *hugetlb_cgroup_from_page(struct page
*page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
+ VM_BUG_ON(!PageHuge(page));
if (compound_order(page) < HUGETLB_CGROUP_MIN_ORDER)
return NULL;
@@ -39,7 +38,7 @@ static inline struct hugetlb_cgroup
*hugetlb_cgroup_from_page(struct page *page)
static inline
int set_hugetlb_cgroup(struct page *page, struct hugetlb_cgroup *h_cg)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
+ VM_BUG_ON(!PageHuge(page));
if (compound_order(page) < HUGETLB_CGROUP_MIN_ORDER)
return -1;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c01cb9f..04306b9 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -584,7 +584,7 @@ static void update_and_free_page(struct hstate *h, struct
page *page)
1 << PG_active | 1 << PG_reserved |
1 << PG_private | 1 << PG_writeback);
}
- VM_BUG_ON_PAGE(hugetlb_cgroup_from_page(page), page);
+ VM_BUG_ON(hugetlb_cgroup_from_page(page));
set_compound_page_dtor(page, NULL);
set_page_refcounted(page);
arch_release_hugepage(page);
@@ -1089,7 +1089,7 @@ retry:
* no users -- drop the buddy allocator's reference.
*/
put_page_testzero(page);
- VM_BUG_ON_PAGE(page_count(page), page);
+ VM_BUG_ON(page_count(page));
enqueue_huge_page(h, page);
}
free:
@@ -3503,7 +3503,7 @@ int dequeue_hwpoisoned_huge_page(struct page *hpage)
bool isolate_huge_page(struct page *page, struct list_head *list)
{
- VM_BUG_ON_PAGE(!PageHead(page), page);
+ VM_BUG_ON(!PageHead(page));
if (!get_page_unless_zero(page))
return false;
spin_lock(&hugetlb_lock);
@@ -3514,7 +3514,7 @@ bool isolate_huge_page(struct page *page, struct
list_head *list)
void putback_active_hugepage(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHead(page), page);
+ VM_BUG_ON(!PageHead(page));
spin_lock(&hugetlb_lock);
list_move_tail(&page->lru, &(page_hstate(page))->hugepage_activelist);
spin_unlock(&hugetlb_lock);
@@ -3523,7 +3523,7 @@ void putback_active_hugepage(struct page *page)
bool is_hugepage_active(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
+ VM_BUG_ON(!PageHuge(page));
/*
* This function can be called for a tail page because the caller,
* scan_movable_pages, scans through a given pfn-range which typically
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index cb00829..d747a84 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -390,7 +390,7 @@ void hugetlb_cgroup_migrate(struct page *oldhpage, struct
page *new
[PATCH] rtl8192ce is disabling the irqs for too long
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans The observable symptoms in dmesg can be: - underruns from ALSA playback - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled): [ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100 [ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable [ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32) [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0 [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc [ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!! [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x4000, ofdm_index=0xc [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <=== [ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1 [ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore [ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505) The exact code flow that causes that is: 1. wpa_supplicant send a start_scan request to the nl80211 driver 2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE 3. rtl_ips_nic_on is called which disable local irqs 4. rtl92c_phy_set_rf_power_state() is called 5. rtl_ps_enable_nic() is called and hw_init()is executed and interrupts on the device A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled but a quick and dirty solution that has proven to work is to reenable the irqs during the function rtl92ce_hw_init(). I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed. Signed-off-by: Olivier Langlois --- drivers/net/wireless/rtlwifi/ps.c | 2 +- drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 -- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c index 0d81f76..a56e9b3 100644 --- a/drivers/net/wireless/rtlwifi/ps.c +++ b/drivers/net/wireless/rtlwifi/ps.c @@ -48,7 +48,7 @@ bool rtl_ps_enable_nic(struct ieee80211_hw *hw) /*<2> Enable Adapter */ if (rtlpriv->cfg->ops->hw_init(hw)) - return 1; + return false; RT_CLEAR_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC); /*<3> Enable Interrupt */ diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c index a82b30a..2eb0b38 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c @@ -937,14 +937,26 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw) bool is92c; int err; u8 tmp_u1b; + unsigned long flags; rtlpci->bei
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote: > On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote: > > > + > > > +Clients must use the format described in the dma.txt file, using a three > > > cell > > > +specifier for each channel. > > > + > > > +The three cells in order are: > > > + 1. A phandle pointing to the DMA controller > > > + 2. The channel number > > > + 3. Direction of the fixed unidirectional channel > > > + 0 - Memory to Device > > > + 1 - Device to Memory > > > + 2 - Device to Device > > > + > > > > Why does the direction needs to be specified in specifier? I see two > > options, either the direction per is fixed in hardware. In that case the DMA > > controller node should describe which channel is which direction. Or the > > direction is not fixed in hardware and can be changed at runtime in which > > case it should be set on a per descriptor basis. > > Normally the direction is implied by dmaengine_slave_config(). > Note that neither the dma slave API nor the generic DT binding > can actually support device-to-device transfers, since this > normally implies using two dma-request lines rather than one. > > There might be a case where the direction is required in order > to allocate a channel, because the engine has specialized channels > per direction, and might connect any of them to any dma request > line. This does not seem to be the case for "bam", because > the DMA specifier already contains a specific channel number, not > a request line or slave ID number. After some deliberation, I think the best solution is removing the direction from the DT for now. It doesn't add anything except some verification of direction. As for the device to device: As I mentioned before, each bam dma node is attached to a specific peripheral (with one exception, but lets skip over that). The peripherals allow for more than one execution environment to access the peripheral and attached bam. 2 bam channels can be connected to form a unidirectional pipe from one execution environment to another. Once the pipe is configured, the actually transfer resembles a cyclical dma transfer and continues until you explicitly stop it. That functionality will come later. -- sent by an employee of the Qualcomm Innovation Center, Inc. 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/
[tip:x86/asmlinkage] x86, asmlinkage, xen, kvm: Make {xen, kvm}_lock_spinning global and visible
Commit-ID: dd41f818e581bc8244d34d594e20331fcb835524
Gitweb: http://git.kernel.org/tip/dd41f818e581bc8244d34d594e20331fcb835524
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:58 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:18 -0800
x86, asmlinkage, xen, kvm: Make {xen,kvm}_lock_spinning global and visible
These functions are called from inline assembler stubs, thus
need to be global and visible.
Cc: Konrad Rzeszutek Wilk
Cc: Gleb Natapov
Cc: Raghavendra K T
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-7-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/kvm.c | 2 +-
arch/x86/xen/spinlock.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 6dd802c..cd1b362 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -673,7 +673,7 @@ static cpumask_t waiting_cpus;
/* Track spinlock on which a cpu is waiting */
static DEFINE_PER_CPU(struct kvm_lock_waiting, klock_waiting);
-static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+__visible void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
{
struct kvm_lock_waiting *w;
int cpu;
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 0e36cde..581521c 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -106,7 +106,7 @@ static DEFINE_PER_CPU(struct xen_lock_waiting,
lock_waiting);
static cpumask_t waiting_cpus;
static bool xen_pvspin = true;
-static void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+__visible void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
{
int irq = __this_cpu_read(lock_kicker_irq);
struct xen_lock_waiting *w = &__get_cpu_var(lock_waiting);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/asmlinkage] x86, asmlinkage, xen: Fix type of NMI
Commit-ID: 07ba06d9d293d3c0a512f1cb9189645c6e0424e2
Gitweb: http://git.kernel.org/tip/07ba06d9d293d3c0a512f1cb9189645c6e0424e2
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:59 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:18 -0800
x86, asmlinkage, xen: Fix type of NMI
LTO requires consistent types of symbols over all files.
So "nmi" cannot be declared as a char [] here, need to use the
correct function type.
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-8-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/xen/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 68c054f..518ab4a 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -34,7 +34,7 @@
extern const char xen_hypervisor_callback[];
extern const char xen_failsafe_callback[];
#ifdef CONFIG_X86_64
-extern const char nmi[];
+extern asmlinkage void nmi(void);
#endif
extern void xen_sysenter_target(void);
extern void xen_syscall_target(void);
@@ -559,7 +559,7 @@ void xen_enable_syscall(void)
void xen_enable_nmi(void)
{
#ifdef CONFIG_X86_64
- if (register_callback(CALLBACKTYPE_nmi, nmi))
+ if (register_callback(CALLBACKTYPE_nmi, (char *)nmi))
BUG();
#endif
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/asmlinkage] x86, asmlinkage, paravirt: Make paravirt thunks global
Commit-ID: a2e7f0e3a4f0f23fe4cd8cc22da547872f0170bb
Gitweb: http://git.kernel.org/tip/a2e7f0e3a4f0f23fe4cd8cc22da547872f0170bb
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:56 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:17 -0800
x86, asmlinkage, paravirt: Make paravirt thunks global
The paravirt thunks use a hack of using a static reference to a static
function to reference that function from the top level statement.
This assumes that gcc always generates static function names in a specific
format, which is not necessarily true.
Simply make these functions global and asmlinkage or __visible. This way the
static __used variables are not needed and everything works.
Functions with arguments are __visible to keep the register calling
convention on 32bit.
Changed in paravirt and in all users (Xen and vsmp)
v2: Use __visible for functions with arguments
Cc: Jeremy Fitzhardinge
Cc: Ido Yariv
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-5-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/paravirt.h | 2 +-
arch/x86/kernel/vsmp_64.c | 8
arch/x86/xen/irq.c | 8
arch/x86/xen/mmu.c | 16
4 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 401f350..cd6e161 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -781,9 +781,9 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
*/
#define PV_CALLEE_SAVE_REGS_THUNK(func)
\
extern typeof(func) __raw_callee_save_##func; \
- static void *__##func##__ __used = func;\
\
asm(".pushsection .text;" \
+ ".globl __raw_callee_save_" #func " ; " \
"__raw_callee_save_" #func ": " \
PV_SAVE_ALL_CALLER_REGS \
"call " #func ";" \
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 992f890..f6584a9 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -33,7 +33,7 @@
* and vice versa.
*/
-static unsigned long vsmp_save_fl(void)
+asmlinkage unsigned long vsmp_save_fl(void)
{
unsigned long flags = native_save_fl();
@@ -43,7 +43,7 @@ static unsigned long vsmp_save_fl(void)
}
PV_CALLEE_SAVE_REGS_THUNK(vsmp_save_fl);
-static void vsmp_restore_fl(unsigned long flags)
+__visible void vsmp_restore_fl(unsigned long flags)
{
if (flags & X86_EFLAGS_IF)
flags &= ~X86_EFLAGS_AC;
@@ -53,7 +53,7 @@ static void vsmp_restore_fl(unsigned long flags)
}
PV_CALLEE_SAVE_REGS_THUNK(vsmp_restore_fl);
-static void vsmp_irq_disable(void)
+asmlinkage void vsmp_irq_disable(void)
{
unsigned long flags = native_save_fl();
@@ -61,7 +61,7 @@ static void vsmp_irq_disable(void)
}
PV_CALLEE_SAVE_REGS_THUNK(vsmp_irq_disable);
-static void vsmp_irq_enable(void)
+asmlinkage void vsmp_irq_enable(void)
{
unsigned long flags = native_save_fl();
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 0da7f86..f56c23b 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -22,7 +22,7 @@ void xen_force_evtchn_callback(void)
(void)HYPERVISOR_xen_version(0, NULL);
}
-static unsigned long xen_save_fl(void)
+asmlinkage unsigned long xen_save_fl(void)
{
struct vcpu_info *vcpu;
unsigned long flags;
@@ -40,7 +40,7 @@ static unsigned long xen_save_fl(void)
}
PV_CALLEE_SAVE_REGS_THUNK(xen_save_fl);
-static void xen_restore_fl(unsigned long flags)
+__visible void xen_restore_fl(unsigned long flags)
{
struct vcpu_info *vcpu;
@@ -62,7 +62,7 @@ static void xen_restore_fl(unsigned long flags)
}
PV_CALLEE_SAVE_REGS_THUNK(xen_restore_fl);
-static void xen_irq_disable(void)
+asmlinkage void xen_irq_disable(void)
{
/* There's a one instruction preempt window here. We need to
make sure we're don't switch CPUs between getting the vcpu
@@ -73,7 +73,7 @@ static void xen_irq_disable(void)
}
PV_CALLEE_SAVE_REGS_THUNK(xen_irq_disable);
-static void xen_irq_enable(void)
+asmlinkage void xen_irq_enable(void)
{
struct vcpu_info *vcpu;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index ce563be..648512c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -431,7 +431,7 @@ static pteval_t iomap_pte(pteval_t val)
return val;
}
-static pteval_t xen_pte_val(pte_t pte)
+__visible pteval_t xen_pte_val(pte_t pte)
{
pteval_t pteval = pte.pte;
#if 0
@@ -448,7 +448,7 @@ static pteval_t xen_pte_val(pte_t pte)
}
PV_
[tip:x86/asmlinkage] x86, asmlinkage, paravirt: Don' t rely on local assembler labels
Commit-ID: 824a2870098fa5364d49d4cd5a1f41544d9f6c65
Gitweb: http://git.kernel.org/tip/824a2870098fa5364d49d4cd5a1f41544d9f6c65
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:55 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:17 -0800
x86, asmlinkage, paravirt: Don't rely on local assembler labels
The paravirt patching code assumes that it can reference a
local assembler label between two different top level assembler
statements. This does not work with LTO
where the assembler code may end up in different assembler files.
Replace it with extern / global /asm linkage labels.
This also removes one redundant copy of the macro.
Cc: Jeremy Fitzhardinge
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-4-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/paravirt_types.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index aab8f67..7549b8b 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -388,10 +388,11 @@ extern struct pv_lock_ops pv_lock_ops;
_paravirt_alt(insn_string, "%c[paravirt_typenum]",
"%c[paravirt_clobber]")
/* Simple instruction patching code. */
-#define DEF_NATIVE(ops, name, code)\
- extern const char start_##ops##_##name[] __visible, \
- end_##ops##_##name[] __visible; \
- asm("start_" #ops "_" #name ": " code "; end_" #ops "_" #name ":")
+#define NATIVE_LABEL(a,x,b) "\n\t.globl " a #x "_" #b "\n" a #x "_" #b ":\n\t"
+
+#define DEF_NATIVE(ops, name, code)\
+ __visible extern const char start_##ops##_##name[],
end_##ops##_##name[]; \
+ asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops,
name))
unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/asmlinkage] x86: Use inline assembler instead of global register variable to get sp
Commit-ID: dff38e3e93bbc10653a232f68077e5d031624464
Gitweb: http://git.kernel.org/tip/dff38e3e93bbc10653a232f68077e5d031624464
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:57 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:17 -0800
x86: Use inline assembler instead of global register variable to get sp
LTO in gcc 4.6/47. has trouble with global register variables. They were used
to read the stack pointer. Use a simple inline assembler statement with
a mov instead.
This also helps LLVM/clang, which does not support global register
variables.
[ hpa: Ideally this should become a builtin in both gcc and clang. ]
v2: More general asm constraint. Fix description (Jan Beulich)
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-6-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/thread_info.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 3ba3de4..e1940c0 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -163,9 +163,11 @@ struct thread_info {
*/
#ifndef __ASSEMBLY__
-
-/* how to get the current stack pointer from C */
-register unsigned long current_stack_pointer asm("esp") __used;
+#define current_stack_pointer ({ \
+ unsigned long sp; \
+ asm("mov %%esp,%0" : "=g" (sp));\
+ sp; \
+})
/* how to get the thread information struct from C */
static inline struct thread_info *current_thread_info(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asmlinkage] x86, asmlinkage, lguest: Fix C functions used by inline assembler
Commit-ID: 9549b9b3479323a1ad6ae83eae8e98aa765994f0
Gitweb: http://git.kernel.org/tip/9549b9b3479323a1ad6ae83eae8e98aa765994f0
Author: Andi Kleen
AuthorDate: Tue, 22 Oct 2013 09:07:54 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 29 Jan 2014 22:17:17 -0800
x86, asmlinkage, lguest: Fix C functions used by inline assembler
- Make the C code used by the paravirt stubs visible
- Since they have to be global now, give them a more unique
name.
Cc: Rusty Russell
Signed-off-by: Andi Kleen
Link:
http://lkml.kernel.org/r/1382458079-24450-3-git-send-email-a...@firstfloor.org
Signed-off-by: H. Peter Anvin
---
arch/x86/lguest/boot.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index bdf8532..ad1fb5f 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -233,13 +233,13 @@ static void lguest_end_context_switch(struct task_struct
*next)
* flags word contains all kind of stuff, but in practice Linux only cares
* about the interrupt flag. Our "save_flags()" just returns that.
*/
-static unsigned long save_fl(void)
+asmlinkage unsigned long lguest_save_fl(void)
{
return lguest_data.irq_enabled;
}
/* Interrupts go off... */
-static void irq_disable(void)
+asmlinkage void lguest_irq_disable(void)
{
lguest_data.irq_enabled = 0;
}
@@ -253,8 +253,8 @@ static void irq_disable(void)
* PV_CALLEE_SAVE_REGS_THUNK(), which pushes %eax onto the stack, calls the
* C function, then restores it.
*/
-PV_CALLEE_SAVE_REGS_THUNK(save_fl);
-PV_CALLEE_SAVE_REGS_THUNK(irq_disable);
+PV_CALLEE_SAVE_REGS_THUNK(lguest_save_fl);
+PV_CALLEE_SAVE_REGS_THUNK(lguest_irq_disable);
/*:*/
/* These are in i386_head.S */
@@ -1291,9 +1291,9 @@ __init void lguest_init(void)
*/
/* Interrupt-related operations */
- pv_irq_ops.save_fl = PV_CALLEE_SAVE(save_fl);
+ pv_irq_ops.save_fl = PV_CALLEE_SAVE(lguest_save_fl);
pv_irq_ops.restore_fl = __PV_IS_CALLEE_SAVE(lg_restore_fl);
- pv_irq_ops.irq_disable = PV_CALLEE_SAVE(irq_disable);
+ pv_irq_ops.irq_disable = PV_CALLEE_SAVE(lguest_irq_disable);
pv_irq_ops.irq_enable = __PV_IS_CALLEE_SAVE(lg_irq_enable);
pv_irq_ops.safe_halt = lguest_safe_halt;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Thursday 30 January 2014 09:49 AM, Vivek Gautam wrote: > Hi Kishon, > > > On Mon, Jan 27, 2014 at 2:27 PM, Kishon Vijay Abraham I wrote: >> Hi, > > Thanks for review. Please find my answers inline below. > >> >> On Monday 20 January 2014 07:12 PM, Vivek Gautam wrote: >>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. >>> The new driver uses the generic PHY framework and will interact >>> with DWC3 controller present on Exynos5 series of SoCs. >>> Thereby, removing old phy-samsung-usb3 driver and related code >>> used untill now which was based on usb/phy framework. >>> >>> Signed-off-by: Vivek Gautam >>> --- >>> >>> Changes from v2: >>> 1) Added support for multiple PHYs (UTMI+ and PIPE3) and >>>related changes in the driver structuring. >>> 2) Added a xlate function to get the required phy out of >>>number of PHYs in mutiple PHY scenerio. >>> 3) Changed the names of few structures and variables to >>>have a clearer meaning. >>> 4) Added 'usb3phy_config' structure to take care of mutiple >>>phys for a SoC having 'exynos5_usb3phy_drv_data' driver data. >>> 5) Not deleting support for old driver 'phy-samsung-usb3' until >>>required support for generic phy is added to DWC3. >>> >>> .../devicetree/bindings/phy/samsung-phy.txt| 49 ++ >>> drivers/phy/Kconfig|8 + >>> drivers/phy/Makefile |1 + >>> drivers/phy/phy-exynos5-usb3.c | 621 >>> >>> 4 files changed, 679 insertions(+) >>> create mode 100644 drivers/phy/phy-exynos5-usb3.c > [snip] > >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig >>> index 330ef2d..32f9f38 100644 >>> --- a/drivers/phy/Kconfig >>> +++ b/drivers/phy/Kconfig >>> @@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO >>> help >>> Support for Display Port PHY found on Samsung EXYNOS SoCs. >>> >>> +config PHY_EXYNOS5_USB3 This shouldn't be USB3 since this driver has support for both USB2 and USB3. maybe just PHY_EXYNOS5_USB? >>> + tristate "Exynos5 SoC series USB 3.0 PHY driver" >>> + depends on ARCH_EXYNOS5 >>> + select GENERIC_PHY >>> + select MFD_SYSCON >> >> add depends on 'HAS_IOMEM'. Someone reported getting >> undefined reference to `devm_ioremap_resource' with it. > > Ok will add it. > >>> + help >>> + Enable USB 3.0 PHY support for Exynos 5 SoC series >>> + >>> endmenu > [snip] > >>> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c >>> new file mode 100644 >>> index 000..24efed0 >>> --- /dev/null >>> +++ b/drivers/phy/phy-exynos5-usb3.c >>> @@ -0,0 +1,621 @@ >>> +/* >>> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver >>> + * >>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd. >>> + * Author: Vivek Gautam >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License version 2 as >>> + * published by the Free Software Foundation. >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* Exynos USB PHY registers */ >>> +#define EXYNOS5_FSEL_9MHZ6 0x0 >>> +#define EXYNOS5_FSEL_10MHZ 0x1 >>> +#define EXYNOS5_FSEL_12MHZ 0x2 >>> +#define EXYNOS5_FSEL_19MHZ2 0x3 >>> +#define EXYNOS5_FSEL_20MHZ 0x4 >>> +#define EXYNOS5_FSEL_24MHZ 0x5 >>> +#define EXYNOS5_FSEL_50MHZ 0x7 >>> + >>> +/* EXYNOS5: USB 3.0 DRD PHY registers */ >>> +#define EXYNOS5_DRD_LINKSYSTEM (0x04) >>> + >>> +#define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >>> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >>> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27) >>> + >>> +#define EXYNOS5_DRD_PHYUTMI (0x08) >>> + >>> +#define PHYUTMI_OTGDISABLE (0x1 << 6) >>> +#define PHYUTMI_FORCESUSPEND (0x1 << 1) >>> +#define PHYUTMI_FORCESLEEP (0x1 << 0) >> >> use BIT macro here and below? > > Ok. > >>> + >>> +#define EXYNOS5_DRD_PHYPIPE (0x0c) >>> + >>> +#define EXYNOS5_DRD_PHYCLKRST(0x10) >>> + >>> +#define PHYCLKRST_EN_UTMISUSPEND (0x1 << 31) >>> + >>> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >>> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >>> + >>> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >>> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >>> + >>> +#define PHYCLKRST_SSC_EN (0x1 << 20) >>> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19) >>> +#define PHYCLKRST_REF_CLKDIV2(0x1 << 18) >>> + >>> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >>> +#define PHYC
Re: [PATCH] kthread: ensure locality of task_struct allocations
On Wed, 2014-01-29 at 16:27 -0800, David Rientjes wrote:
> Eric, did you try this when writing 207205a2ba26 ("kthread: NUMA aware
> kthread_create_on_node()") or was it always numa_node_id() from the
> beginning?
Hmm, I think I did not try this, its absolutely possible NUMA_NO_NODE
was better here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BISECTED] OMAP: DSS: clk rate mismatch
On 2014-01-29 20:52, Ivaylo Dimitrov wrote: >> Can you try this one: >> >> From e511789f7be00be0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001 >> From: Tomi Valkeinen >> Date: Wed, 29 Jan 2014 13:28:53 +0200 >> Subject: [PATCH] clkoutx2 fix >> >> --- >> arch/arm/mach-omap2/cclock3xxx_data.c | 7 +++ >> arch/arm/mach-omap2/dpll3xxx.c| 20 >> 2 files changed, 27 insertions(+) >> > > Yep, that one fixes the problem. Thanks! Ok, good. I'll probably do some studying about clk framework and clean up the patch and post it. Btw, the clkoutx2 fix makes the DSS clocks work for you generally, but if you happen to hit clock rates that don't divide evenly, you may also need the patches for clk-divider and dss I posted earlier. > Now I only need to find why maemo is 10 times slower with linux-next > compared to 3.13-rc7, but that is another story :). I sure hope it's not DSS's doings =). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/2] drivers/media: Add controls for Horizontal and Vertical MV Search Range
Hi Amit, On 30 January 2014 11:12, Amit Grover wrote: > Based on 'master' branch of Linux-next. Kamil's tree [1] would be more current most of the times for this driver. [1] git://linuxtv.org/kdebski/media.git > This is v2 version for the patch: > s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks > (https://lkml.org/lkml/2013/12/30/83) > > Changes from v1: > 1) Splitted the patch into v4l2 and mfc driver patches. > 2) Incorporated review comments of v1 > > Amit Grover (2): > drivers/media: v4l2: Add settings for Horizontal and Vertical MV > Search Range > drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range nit: media changes use the following title format: [media] v4l2: Add settings for Horizontal and Vertical MV Search Range [media] s5p-mfc: Add Horizontal and Vertical MV Search Range -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes
On Wed, Jan 29, 2014 at 09:52:46PM -0700, Matthew Wilcox wrote: > On Fri, Jan 24, 2014 at 10:57:48AM +, Mel Gorman wrote: > > So far on the table is > > > > 1. major filesystem overhawl > > 2. major vm overhawl > > 3. use compound pages as they are today and hope it does not go > >completely to hell, reboot when it does > > Is the below paragraph an exposition of option 2, or is it an option 4, > change the VM unit of allocation? Other than the names you're using, > this is basically what I said to Kirill in an earlier thread; either > scrap the difference between PAGE_SIZE and PAGE_CACHE_SIZE, or start > making use of it. Christoph Lamater's compound page patch set scrapped PAGE_CACHE_SIZE and made it a variable that was set on the struct address_space when it was instantiated by the filesystem. In effect, it allowed filesystems to specify the unit of page cache allocation on a per-inode basis. > The fact that EVERYBODY in this thread has been using PAGE_SIZE when they > should have been using PAGE_CACHE_SIZE makes me wonder if part of the > problem is that the split in naming went the wrong way. ie use PTE_SIZE > for 'the amount of memory pointed to by a pte_t' and use PAGE_SIZE for > 'the amount of memory described by a struct page'. PAGE_CACHE_SIZE was never distributed sufficiently to be used, and if you #define it to something other than PAGE_SIZE stuff will simply break. > (we need to remove the current users of PTE_SIZE; sparc32 and powerpc32, > but that's just a detail) > > And we need to fix all the places that are currently getting the > distinction wrong. SMOP ... ;-) What would help is correct typing of > variables, possibly with sparse support to help us out. Big Job. Yes, that's what the Christoph's patchset did. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
Hi Nicolas, On 01/30/2014 10:58 AM, Nicolas Pitre wrote: > On Thu, 30 Jan 2014, Preeti U Murthy wrote: > >> Hi Nicolas, >> >> On 01/30/2014 02:01 AM, Nicolas Pitre wrote: >>> On Wed, 29 Jan 2014, Nicolas Pitre wrote: >>> In order to integrate cpuidle with the scheduler, we must have a better proximity in the core code with what cpuidle is doing and not delegate such interaction to arch code. Architectures implementing arch_cpu_idle() should simply enter a cheap idle mode in the absence of a proper cpuidle driver. Signed-off-by: Nicolas Pitre Acked-by: Daniel Lezcano >>> >>> As mentioned in my reply to Olof's comment on patch #5/6, here's a new >>> version of this patch adding the safety local_irq_enable() to the core >>> code. >>> >>> - >8 >>> >>> From: Nicolas Pitre >>> Subject: idle: move the cpuidle entry point to the generic idle loop >>> >>> In order to integrate cpuidle with the scheduler, we must have a better >>> proximity in the core code with what cpuidle is doing and not delegate >>> such interaction to arch code. >>> >>> Architectures implementing arch_cpu_idle() should simply enter >>> a cheap idle mode in the absence of a proper cpuidle driver. >>> >>> In both cases i.e. whether it is a cpuidle driver or the default >>> arch_cpu_idle(), the calling convention expects IRQs to be disabled >>> on entry and enabled on exit. There is a warning in place already but >>> let's add a forced IRQ enable here as well. This will allow for >>> removing the forced IRQ enable some implementations do locally and >> >> Why would this patch allow for removing the forced IRQ enable that are >> being done on some archs in arch_cpu_idle()? Isn't this patch expecting >> the default arch_cpu_idle() to have re-enabled the interrupts after >> exiting from the default idle state? Its supposed to only catch faulty >> cpuidle drivers that haven't enabled IRQs on exit from idle state but >> are expected to have done so, isn't it? > > Exact. However x86 currently does this: > > if (cpuidle_idle_call()) > x86_idle(); > else > local_irq_enable(); > > So whenever cpuidle_idle_call() is successful then IRQs are > unconditionally enabled whether or not the underlying cpuidle driver has > properly done it or not. And the reason is that some of the x86 cpuidle > do fail to enable IRQs before returning. > > So the idea is to get rid of this unconditional IRQ enabling and let the > core issue a warning instead (as well as enabling IRQs to allow the > system to run). Oh ok, thank you for clarifying this:) Regards Preeti U Murthy > > > Nicolas > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver
On 1/20/2014 10:03 AM, Satish Patel wrote: > Changes from v1: > * RFC(v1) comments are fixed > > ** removed "gpio_to_irq" as GPIO controller process cell from DT and > give it to DT node > ** comments on documentation > ** few other comments on null checks are resolved > > * BWT timing configuration is added to ti-usim driver > > v1 cover letter link# > https://lkml.org/lkml/2014/1/6/250 > > Satish Patel (5): > sc_phy:SmartCard(SC) PHY interface to SC controller > misc: tda8026: Add NXP TDA8026 PHY driver > char: ti-usim: Add driver for USIM module on AM43xx > ARM: dts: AM43xx: DT entries added for ti-usim > ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy > > Documentation/devicetree/bindings/misc/tda8026.txt | 19 + > .../devicetree/bindings/ti-usim/ti-usim.txt| 31 + > Documentation/sc_phy.txt | 171 ++ > arch/arm/boot/dts/am4372.dtsi | 10 + > arch/arm/boot/dts/am43x-epos-evm.dts | 43 + > drivers/char/Kconfig |7 + > drivers/char/Makefile |1 + > drivers/char/ti-usim-hw.h | 863 + > drivers/char/ti-usim.c | 1859 > > drivers/misc/Kconfig |7 + > drivers/misc/Makefile |1 + > drivers/misc/tda8026.c | 1255 + > include/linux/sc_phy.h | 132 ++ > include/linux/ti-usim.h| 98 + > 14 files changed, 4497 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt > create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt > create mode 100644 Documentation/sc_phy.txt > create mode 100644 drivers/char/ti-usim-hw.h > create mode 100644 drivers/char/ti-usim.c > create mode 100644 drivers/misc/tda8026.c > create mode 100644 include/linux/sc_phy.h > create mode 100644 include/linux/ti-usim.h Any comments on this patch series ? If not, Can you accept these patches for next merge window Thanks Satish > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL timers] Timer-wheel bandaids^Wcommits
Hi Paul, The commit id:e1d690cdc07637131ba4334: timers: Track total number of timers in list has a minor glitch in the changelog. I am referring to your git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/timers branch. "even if ->active_timers is zero, there might well be *non-deferrable* timers in the list" s/non-deferrable/deferrable. Thanks Regards Preeti U Murthy On Thu, Jan 30, 2014 at 5:09 AM, Paul E. McKenney wrote: > Hello, Ingo, > > This pull request contains latency bandaids^Woptimizations to the > timer-wheel code that are useful in conjunction with NO_HZ_FULL Kconfig > option. These optimizations reduce the jiffy-by-jiffy looping in cases > where there is either zero or one timers in the timer wheel, which is > a common case for NO_HZ_FULL "worker" CPUs that run almost entirely > in usermode for a single task. > > Each of these commits has at least two Reviewed-by, one Acked-by, and > one Tested-by tag, so they are ready for more extensive testing in -tip. > > Thanx, Paul > > The following changes since commit 00e2bcd6d35f59fce7fa0e76e24d08f74c6a8506: > > clocksource: Timer-sun5i: Switch to sched_clock_register() (2014-01-19 > 13:23:23 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > rcu/timers > > for you to fetch changes up to 6f089d0be7fef9705b3a7755b05d1092e772b910: > > timers: Make internal_add_timer() update ->next_timer if ->active_timers == > 0 (2014-01-29 15:25:16 -0800) > > > Oleg Nesterov (1): > timers: Make internal_add_timer() update ->next_timer if > ->active_timers == 0 > > Paul E. McKenney (4): > timers: Track total number of timers in list > timers: Reduce __run_timers() latency for empty list > timers: Reduce future __run_timers() latency for newly emptied list > timers: Reduce future __run_timers() latency for first add to empty list > > kernel/timer.c | 30 -- > 1 file changed, 28 insertions(+), 2 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: use ASM_NL instead of ';' for assembler new line character in the macro
On 01/28/2014 05:57 AM, Michal Marek wrote: > Dne 25.1.2014 12:07, Chen Gang napsal(a): >> On 01/21/2014 12:55 PM, Vineet Gupta wrote: >>> Hi Mike, >>> >>> On Saturday 18 January 2014 03:14 PM, Chen Gang wrote: Hello Maintainers: Please help check this patch when you have time. Thanks. >>> >>> Do you know whose tree this is goona go thru. I can take it thru ARC (but >>> maybe >>> for 3.15, however it would be better it went thru mm or some such). >>> >> >> Hello all: >> >> Is this patch OK? if need additional improvement, please let me know, >> thanks. > > I applied the patch to kbuild.git#kbuild, sorry for the delay. > That's all right (in fact, don't need sorry), most of us are really busy, so thank you very much for your work on it. And next, I will/should continue make patches for upstream kernel in my free time (at least, should provide 1-3 patches per month in this year). :-) Thanks. -- Chen Gang Open, share and attitude like air, water and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
This patch adds Controls to set Horizontal and Vertical search range
for Motion Estimation block for Samsung MFC video Encoders.
Signed-off-by: Swami Nathan
Signed-off-by: Amit Grover
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24 +++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
4 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 2398cdf..8d0b686 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -229,6 +229,7 @@
#define S5P_FIMV_E_PADDING_CTRL_V6 0xf7a4
#define S5P_FIMV_E_MV_HOR_RANGE_V6 0xf7ac
#define S5P_FIMV_E_MV_VER_RANGE_V6 0xf7b0
+#define S5P_FIMV_E_MV_RANGE_V6_MASK0x3fff
#define S5P_FIMV_E_VBV_BUFFER_SIZE_V6 0xf84c
#define S5P_FIMV_E_VBV_INIT_DELAY_V6 0xf850
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..b90ee34 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
struct s5p_mfc_enc_params {
u16 width;
u16 height;
+ u32 mv_h_range;
+ u32 mv_v_range;
u16 gop_size;
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..704f30c1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
.default_value = 0,
},
{
+ .id = V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Horizontal MV Search Range",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Vertical MV Search Range",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
.id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
.type = V4L2_CTRL_TYPE_INTEGER,
.minimum = 0,
@@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
p->vbv_size = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ p->mv_h_range = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ p->mv_v_range = ctrl->val;
+ break;
case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
p->codec.h264.cpb_size = ctrl->val;
break;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 461358c..3c10188 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
/* setting for MV range [16, 256] */
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->mv_h_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->mv_v_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] drivers/media: Add controls for Horizontal and Vertical MV Search Range
Based on 'master' branch of Linux-next. This is v2 version for the patch: s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks (https://lkml.org/lkml/2013/12/30/83) Changes from v1: 1) Splitted the patch into v4l2 and mfc driver patches. 2) Incorporated review comments of v1 Amit Grover (2): drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range Documentation/DocBook/media/v4l/controls.xml| 20 +++ drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++ drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24 +++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++-- drivers/media/v4l2-core/v4l2-ctrls.c| 14 + include/uapi/linux/v4l2-controls.h |2 ++ 7 files changed, 65 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range
Adding V4L2 controls for horizontal and vertical search range in pixels
for motion estimation module in video encoder.
Signed-off-by: Swami Nathan
Signed-off-by: Amit Grover
---
Documentation/DocBook/media/v4l/controls.xml | 20
drivers/media/v4l2-core/v4l2-ctrls.c | 14 ++
include/uapi/linux/v4l2-controls.h |2 ++
3 files changed, 36 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..be04d18 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.
VBV buffer control.
+
+
+ V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE
+ integer
+
+ Horizontal search range defines
maximum horizontal search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture.
This V4L2 control macro is used to set
+horizontal search range for motion estimation module in video encoder.
+
+
+
+
+ V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE
+ integer
+
+ Vertical search range defines
maximum vertical search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture.
This V4L2 control macro is used to set
+vertical search range for motion estimation module in video encoder.
+
+
V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index fb46790..e775388 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video
Decoder PTS";
case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video
Decoder Frame Count";
case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial
Delay for VBV Control";
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return
"Horizontal MV Search Range";
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return
"Vertical MV Search Range";
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat
Sequence Header";
/* VPX controls */
@@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
*min = 0;
*max = *step = 1;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
case V4L2_CID_FLASH_STROBE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 1666aab..80e1def 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
#define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
#define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
+#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
+#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP(V4L2_CID_MPEG_BASE+300)
#define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP(V4L2_CID_MPEG_BASE+301)
--
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: linux-next: manual merge of the arm-soc tree with Linus' tree
On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
> from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
> clock framework support") from the arm-soc tree.
Ugh. Looks like some last minute cleanup stuff went into clk-next
that didn't spend time in linux-next, and now causes conflicts with
some clk stuff we still have queued in arm-soc (ack'd by Mike.)
Now, based on the Hulk's response to Mike's pull request, if we submit
this, introducing yet more conflicts in the Makefile, it will surely
be Hulk angry, Hulk smash.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0))
On Wed, Jan 29, 2014 at 11:50:43PM -0500, Steven Rostedt wrote: > Are you running as root? If not, you found another way to get perf to start > function tracing. Good point. In this case, I was trying some new experimental trinity code that starts as root, generates fd's, then drops privs before doing syscalls. So the "generate fds" part did some perf_event_open's as root, yeah. While that's less scary from a security pov than it was last time, it's still something that aparently needs fixing. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
On Thu, 30 Jan 2014, Preeti U Murthy wrote: > Hi Nicolas, > > On 01/30/2014 02:01 AM, Nicolas Pitre wrote: > > On Wed, 29 Jan 2014, Nicolas Pitre wrote: > > > >> In order to integrate cpuidle with the scheduler, we must have a better > >> proximity in the core code with what cpuidle is doing and not delegate > >> such interaction to arch code. > >> > >> Architectures implementing arch_cpu_idle() should simply enter > >> a cheap idle mode in the absence of a proper cpuidle driver. > >> > >> Signed-off-by: Nicolas Pitre > >> Acked-by: Daniel Lezcano > > > > As mentioned in my reply to Olof's comment on patch #5/6, here's a new > > version of this patch adding the safety local_irq_enable() to the core > > code. > > > > - >8 > > > > From: Nicolas Pitre > > Subject: idle: move the cpuidle entry point to the generic idle loop > > > > In order to integrate cpuidle with the scheduler, we must have a better > > proximity in the core code with what cpuidle is doing and not delegate > > such interaction to arch code. > > > > Architectures implementing arch_cpu_idle() should simply enter > > a cheap idle mode in the absence of a proper cpuidle driver. > > > > In both cases i.e. whether it is a cpuidle driver or the default > > arch_cpu_idle(), the calling convention expects IRQs to be disabled > > on entry and enabled on exit. There is a warning in place already but > > let's add a forced IRQ enable here as well. This will allow for > > removing the forced IRQ enable some implementations do locally and > > Why would this patch allow for removing the forced IRQ enable that are > being done on some archs in arch_cpu_idle()? Isn't this patch expecting > the default arch_cpu_idle() to have re-enabled the interrupts after > exiting from the default idle state? Its supposed to only catch faulty > cpuidle drivers that haven't enabled IRQs on exit from idle state but > are expected to have done so, isn't it? Exact. However x86 currently does this: if (cpuidle_idle_call()) x86_idle(); else local_irq_enable(); So whenever cpuidle_idle_call() is successful then IRQs are unconditionally enabled whether or not the underlying cpuidle driver has properly done it or not. And the reason is that some of the x86 cpuidle do fail to enable IRQs before returning. So the idea is to get rid of this unconditional IRQ enabling and let the core issue a warning instead (as well as enabling IRQs to allow the system to run). Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0))
Are you running as root? If not, you found another way to get perf to start function tracing. -- Steve Dave Jones wrote: >WARNING: CPU: 3 PID: 796 at kernel/trace/ftrace.c:1655 >__ftrace_hash_rec_update.part.38+0x20a/0x240() >CPU: 3 PID: 796 Comm: trinity-main Not tainted 3.13.0+ #100 > 0009 3628f1c9 8802395dfc48 b1737a8a > 8802395dfc80 b106d28d > 0001 880221165000 8801db17c9d8 >Call Trace: > [] dump_stack+0x4e/0x7a > [] warn_slowpath_common+0x7d/0xa0 > [] warn_slowpath_null+0x1a/0x20 > [] __ftrace_hash_rec_update.part.38+0x20a/0x240 > [] ftrace_shutdown+0x1ff/0x330 > [] unregister_ftrace_function+0x20/0x40 > [] perf_ftrace_event_register+0x87/0x130 > [] perf_trace_destroy+0x2c/0x50 > [] tp_perf_event_destroy+0x9/0x10 > [] __free_event+0x25/0xb0 > [] free_event+0x77/0x100 > [] perf_event_release_kernel+0x64/0x90 > [] put_event+0xdf/0x130 > [] ? put_event+0x30/0x130 > [] perf_release+0x10/0x20 > [] __fput+0xea/0x2c0 > [] fput+0xe/0x10 > [] task_work_run+0xb4/0xe0 > [] do_exit+0x2e5/0xb40 > [] ? ftrace_call+0x5/0x2f > [] do_group_exit+0x4c/0xc0 > [] SyS_exit_group+0x14/0x20 > [] tracesys+0xdd/0xe2 >---[ end trace f3c5dcf3f350edcc ]--- > > >1655 if (FTRACE_WARN_ON((rec->flags & >~FTRACE_FL_MASK) == 0)) >1656 return; > > >This old friend came back. I first reported this back in July, and we >aparently never >got to the bottom of it. > > Dave -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm next tree
On Wed, Jan 29, 2014 at 6:49 PM, Dave Airlie wrote: > > For some reason the request-pull and the merge into your tree look different, > since some of the changes in this have already gone in via the arm-soc tree > and dma stuff, all for tegra. Hopefully nobody rebased when they shouldn't. Looks more like it's just a few cross-merges, which then ends up meaning that there are multiple merge-bases and not just one common ancestor commit. In that case, a simple "git diff" can't do a great job, and the actual merge diff will usually end up different. 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: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes
On Fri, Jan 24, 2014 at 10:57:48AM +, Mel Gorman wrote: > So far on the table is > > 1. major filesystem overhawl > 2. major vm overhawl > 3. use compound pages as they are today and hope it does not go >completely to hell, reboot when it does Is the below paragraph an exposition of option 2, or is it an option 4, change the VM unit of allocation? Other than the names you're using, this is basically what I said to Kirill in an earlier thread; either scrap the difference between PAGE_SIZE and PAGE_CACHE_SIZE, or start making use of it. The fact that EVERYBODY in this thread has been using PAGE_SIZE when they should have been using PAGE_CACHE_SIZE makes me wonder if part of the problem is that the split in naming went the wrong way. ie use PTE_SIZE for 'the amount of memory pointed to by a pte_t' and use PAGE_SIZE for 'the amount of memory described by a struct page'. (we need to remove the current users of PTE_SIZE; sparc32 and powerpc32, but that's just a detail) And we need to fix all the places that are currently getting the distinction wrong. SMOP ... ;-) What would help is correct typing of variables, possibly with sparse support to help us out. Big Job. > That's why I suggested that it may be necessary to change the basic unit of > allocation the kernel uses to be larger than the MMU page size and restrict > how the sub pages are used. The requirement is to preserve the property that > "with the exception of slab reclaim that any reclaim action will result > in K-sized allocation succeeding" where K is the largest blocksize used by > any underlying storage device. From an FS perspective then certain things > would look similar to what they do today. Block data would be on physically > contiguous pages, buffer_heads would still manage the case where block_size > <= PAGEALLOC_PAGE_SIZE (as opposed to MMU_PAGE_SIZE), particularly for > dirty tracking and so on. The VM perspective is different because now it > has to handle MMU_PAGE_SIZE in a very different way, page reclaim of a page > becomes multiple unmap events and so on. There would also be anomalies such > as mlock of a range smaller than PAGEALLOC_PAGE_SIZE becomes difficult if > not impossible to sensibly manage because mlock of a 4K page effectively > pins the rest and it's not obvious how we would deal with the VMAs in that > case. It would get more than just the storage gains though. Some of the > scalability problems that deal with massive amount of struct pages may > magically go away if the base unit of allocation and management changes. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] memblock: Add limit checking to memblock_virt_alloc
On 29 January 2014 03:34, Yinghai Lu wrote: > In original bootmem wrapper for memblock, we have limit checking. > > Add it to memblock_virt_alloc, to address arm and x86 booting crash. > > Signed-off-by: Yinghai Lu > > --- Confirmed that this patch fixes the boot crash issue on Exynos (ARM based) boards. Tested-by: Sachin Kamat -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation cleanup, update 00-INDEX files in Documentation/
On 01/29/14 18:27, Henrik Austad wrote: Some of the 00-INDEX files are somewhat outdated and some folders does not contain 00-INDEX at all. Only outdated (with the notably exception of spi) indexes are touched here, the 169 folders without 00-INDEX has not been touched. This applies to Linus' tip (0e47c969). Looks like an improvement. Acked-by: Rob Landley (My own scripts to find this stuff are based on maintaining http://kernel.org/doc and the kernel developers are no longer capable of providing rsync access to that, despite repeated requests. Most recently https://bugzilla.kernel.org/show_bug.cgi?id=52721 ) However, I'm curious about this bit: --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -1,11 +1,11 @@ -This is a brief list of all the files in ./linux/Documentation and what -they contain. If you add a documentation file, please list it here in -alphabetical order as well, or risk being hunted down like a rabid dog. -Please keep the descriptions small enough to fit on one line. -Thanks -- Paul G. +# This is a brief list of all the files in ./linux/Documentation and what +# they contain. If you add a documentation file, please list it here in +# alphabetical order as well, or risk being hunted down like a rabid dog. +# Please keep the descriptions small enough to fit on one line. +# Thanks -- Paul G. -Following translations are available on the WWW: +# Following translations are available on the WWW: Is there a reason for that? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, On Mon, Jan 27, 2014 at 2:27 PM, Kishon Vijay Abraham I wrote: > Hi, Thanks for review. Please find my answers inline below. > > On Monday 20 January 2014 07:12 PM, Vivek Gautam wrote: >> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. >> The new driver uses the generic PHY framework and will interact >> with DWC3 controller present on Exynos5 series of SoCs. >> Thereby, removing old phy-samsung-usb3 driver and related code >> used untill now which was based on usb/phy framework. >> >> Signed-off-by: Vivek Gautam >> --- >> >> Changes from v2: >> 1) Added support for multiple PHYs (UTMI+ and PIPE3) and >>related changes in the driver structuring. >> 2) Added a xlate function to get the required phy out of >>number of PHYs in mutiple PHY scenerio. >> 3) Changed the names of few structures and variables to >>have a clearer meaning. >> 4) Added 'usb3phy_config' structure to take care of mutiple >>phys for a SoC having 'exynos5_usb3phy_drv_data' driver data. >> 5) Not deleting support for old driver 'phy-samsung-usb3' until >>required support for generic phy is added to DWC3. >> >> .../devicetree/bindings/phy/samsung-phy.txt| 49 ++ >> drivers/phy/Kconfig|8 + >> drivers/phy/Makefile |1 + >> drivers/phy/phy-exynos5-usb3.c | 621 >> >> 4 files changed, 679 insertions(+) >> create mode 100644 drivers/phy/phy-exynos5-usb3.c [snip] >> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig >> index 330ef2d..32f9f38 100644 >> --- a/drivers/phy/Kconfig >> +++ b/drivers/phy/Kconfig >> @@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO >> help >> Support for Display Port PHY found on Samsung EXYNOS SoCs. >> >> +config PHY_EXYNOS5_USB3 >> + tristate "Exynos5 SoC series USB 3.0 PHY driver" >> + depends on ARCH_EXYNOS5 >> + select GENERIC_PHY >> + select MFD_SYSCON > > add depends on 'HAS_IOMEM'. Someone reported getting > undefined reference to `devm_ioremap_resource' with it. Ok will add it. >> + help >> + Enable USB 3.0 PHY support for Exynos 5 SoC series >> + >> endmenu [snip] >> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c >> new file mode 100644 >> index 000..24efed0 >> --- /dev/null >> +++ b/drivers/phy/phy-exynos5-usb3.c >> @@ -0,0 +1,621 @@ >> +/* >> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver >> + * >> + * Copyright (C) 2013 Samsung Electronics Co., Ltd. >> + * Author: Vivek Gautam >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* Exynos USB PHY registers */ >> +#define EXYNOS5_FSEL_9MHZ6 0x0 >> +#define EXYNOS5_FSEL_10MHZ 0x1 >> +#define EXYNOS5_FSEL_12MHZ 0x2 >> +#define EXYNOS5_FSEL_19MHZ2 0x3 >> +#define EXYNOS5_FSEL_20MHZ 0x4 >> +#define EXYNOS5_FSEL_24MHZ 0x5 >> +#define EXYNOS5_FSEL_50MHZ 0x7 >> + >> +/* EXYNOS5: USB 3.0 DRD PHY registers */ >> +#define EXYNOS5_DRD_LINKSYSTEM (0x04) >> + >> +#define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27) >> + >> +#define EXYNOS5_DRD_PHYUTMI (0x08) >> + >> +#define PHYUTMI_OTGDISABLE (0x1 << 6) >> +#define PHYUTMI_FORCESUSPEND (0x1 << 1) >> +#define PHYUTMI_FORCESLEEP (0x1 << 0) > > use BIT macro here and below? Ok. >> + >> +#define EXYNOS5_DRD_PHYPIPE (0x0c) >> + >> +#define EXYNOS5_DRD_PHYCLKRST(0x10) >> + >> +#define PHYCLKRST_EN_UTMISUSPEND (0x1 << 31) >> + >> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >> + >> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >> + >> +#define PHYCLKRST_SSC_EN (0x1 << 20) >> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19) >> +#define PHYCLKRST_REF_CLKDIV2(0x1 << 18) >> + >> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) >> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) >> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) >> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) >> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) >> + >> +#define PHYCLKR
FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0))
WARNING: CPU: 3 PID: 796 at kernel/trace/ftrace.c:1655 __ftrace_hash_rec_update.part.38+0x20a/0x240() CPU: 3 PID: 796 Comm: trinity-main Not tainted 3.13.0+ #100 0009 3628f1c9 8802395dfc48 b1737a8a 8802395dfc80 b106d28d 0001 880221165000 8801db17c9d8 Call Trace: [] dump_stack+0x4e/0x7a [] warn_slowpath_common+0x7d/0xa0 [] warn_slowpath_null+0x1a/0x20 [] __ftrace_hash_rec_update.part.38+0x20a/0x240 [] ftrace_shutdown+0x1ff/0x330 [] unregister_ftrace_function+0x20/0x40 [] perf_ftrace_event_register+0x87/0x130 [] perf_trace_destroy+0x2c/0x50 [] tp_perf_event_destroy+0x9/0x10 [] __free_event+0x25/0xb0 [] free_event+0x77/0x100 [] perf_event_release_kernel+0x64/0x90 [] put_event+0xdf/0x130 [] ? put_event+0x30/0x130 [] perf_release+0x10/0x20 [] __fput+0xea/0x2c0 [] fput+0xe/0x10 [] task_work_run+0xb4/0xe0 [] do_exit+0x2e5/0xb40 [] ? ftrace_call+0x5/0x2f [] do_group_exit+0x4c/0xc0 [] SyS_exit_group+0x14/0x20 [] tracesys+0xdd/0xe2 ---[ end trace f3c5dcf3f350edcc ]--- 1655 if (FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0)) 1656 return; This old friend came back. I first reported this back in July, and we aparently never got to the bottom of it. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jan 30
Hi all, Please do *not* add material destined for v3.15 to your linux-next included trees until after v3.14-rc1 is released. This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140130: Linus' tree lost its build failure. The arm-soc tree gained a conflict against Linus' tree. The powerpc tree still had its build failure. The tip tree gained a conflict against Linus' tree. The clk tree lost its build failure. The init tree gained a conflict against the kvm tree and lost a few of its patches. Non-merge commits (relative to Linus' tree): 2706 3339 files changed, 210172 insertions(+), 61366 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 208 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (0e47c969c65e Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (d326b65c57d6 ARM: fix building with gcc 4.6.4) Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more reliably) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap) Merging sparc/master (a54983ae64b1 sparc: Hook up sched_setattr and sched_getattr syscalls.) Merging net/master (c044dc2132d1 qeth: fix build of s390 allmodconfig) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (cd262518a3ae ALSA: hda - Add parameter for dumping processing coefficients) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (7d0d46da750a Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging driver-core.current/driver-core-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging staging.current/staging-linus (77d143de7581 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml) Merging char-misc.current/char-misc-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging input-current/for-linus (55df811f2066 Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (79ba451d66ca crypto: aesni - fix build on x86 (32bit)) Merging ide/master (61eae5bb0649 drivers: ide: Include appropriate header file in ide-pio-blacklist.c) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL dereference in unflatten_a
linux-next: build failure after merge of the final tree
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
arch/powerpc/kvm/44x.c: In function 'kvmppc_44x_exit':
arch/powerpc/kvm/44x.c:231:2: error: implicit declaration of function
'kvmppc_booke_exit' [-Werror=implicit-function-declaration]
Caused by my conflict fixup in the init tree. I just reverted the rest
of commit f9315b9d2680 ("powerpc: kvm e500/44x is not modular, so don't
use module_init") from the init tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp1BWJJXj463.pgp
Description: PGP signature
[btrfs/i_size] xfstests generic/299 TFAIL
Hi Steven, We noticed xfstests generic/299 TFAIL on btrfs since commit 9fe55eea7e4b444bafc42facc2d1d2847275 Author: Steven Whitehouse AuthorDate: Fri Jan 24 14:42:22 2014 + Commit: Al Viro CommitDate: Sun Jan 26 08:26:42 2014 -0500 Fix race when checking i_size on direct i/o read More changes that might help debugging: 2796e4cec525a2b 9fe55eea7e4b444bafc42fa00 --- - 0 +Inf% 1 ~ 0% xfstests.generic.299.fail 6601 ~11% +55547.3%3673721 ~18% slabinfo.btrfs_extent_map.active_objs 49 ~ 6% +6181.0% 3115 ~19% slabinfo.btrfs_extent_buffer.num_slabs 85 ~18%+776.4%750 ~14% slabinfo.buffer_head.num_slabs 30584 ~ 0% +1105.5% 368688 ~ 0% time.maximum_resident_set_size 85 ~18%+776.4%750 ~14% slabinfo.buffer_head.active_slabs 3367 ~18%+769.2% 29268 ~14% slabinfo.buffer_head.num_objs 3304 ~19%+783.1% 29180 ~14% slabinfo.buffer_head.active_objs 49 ~ 6% +6181.0% 3115 ~19% slabinfo.btrfs_extent_buffer.active_slabs 1249 ~ 6% +6134.8% 77897 ~19% slabinfo.btrfs_extent_buffer.num_objs 1102 ~ 3% +6957.3% 1 ~19% slabinfo.btrfs_extent_buffer.active_objs 255 ~11% +55224.5% 141298 ~18% slabinfo.btrfs_extent_map.num_slabs 255 ~11% +55224.5% 141298 ~18% slabinfo.btrfs_extent_map.active_slabs 6645 ~10% +55181.5%3673784 ~18% slabinfo.btrfs_extent_map.num_objs 2850 ~ 7%+434.8% 15242 ~ 9% slabinfo.ext4_extent_status.num_objs 2841 ~ 8%+429.5% 15047 ~10% slabinfo.ext4_extent_status.active_objs 44659 ~ 2% +1329.9% 638573 ~17% meminfo.SReclaimable 61541 ~ 2%+964.6% 655186 ~17% meminfo.Slab 27 ~ 8%+447.8%149 ~ 9% slabinfo.ext4_extent_status.num_slabs 9188 ~ 3%+666.4% 70420 ~ 9% interrupts.TLB 2642 ~ 5%+425.0% 13874 ~14% slabinfo.ext3_xattr.active_objs 2662 ~ 5%+424.9% 13973 ~14% slabinfo.ext3_xattr.num_objs 57 ~ 5%+428.2%303 ~14% slabinfo.ext3_xattr.num_slabs 57 ~ 5%+428.2%303 ~14% slabinfo.ext3_xattr.active_slabs 27 ~ 8%+447.8%149 ~ 9% slabinfo.ext4_extent_status.active_slabs 0 ~ 0% +Inf% 138193 ~ 0% proc-vmstat.unevictable_pgs_culled 379 ~13% +45684.1% 173705 ~ 0% proc-vmstat.pgdeactivate 8107 ~16% +3196.9% 267299 ~ 0% proc-vmstat.pgactivate 11160 ~ 2% +1329.0% 159479 ~17% proc-vmstat.nr_slab_reclaimable 6577 ~ 3%+387.4% 32059 ~24% proc-vmstat.nr_tlb_remote_flush 6684 ~ 3%+380.8% 32142 ~24% proc-vmstat.nr_tlb_remote_flush_received 15707 ~31%+282.3% 60043 ~17% meminfo.Dirty 6380554 ~ 0%+259.8% 22954274 ~ 7% proc-vmstat.pgfault 22901 ~ 3%+290.9% 89514 ~18% proc-vmstat.nr_active_file 4067 ~29%+268.0% 14966 ~17% proc-vmstat.nr_dirty 91655 ~ 3%+291.3% 358640 ~18% meminfo.Active(file) 3088362 ~ 0%+211.5%9618749 ~ 6% proc-vmstat.pgalloc_dma32 3090040 ~ 0%+211.3%9619232 ~ 6% proc-vmstat.pgfree 3046221 ~ 0%+211.2%9479249 ~ 6% proc-vmstat.numa_local 3046221 ~ 0%+211.2%9479249 ~ 6% proc-vmstat.numa_hit 23371 ~ 3%+218.6% 74472 ~29% softirqs.TIMER 51894 ~ 2%+202.5% 156994 ~23% interrupts.LOC 207400 ~ 2%+142.2% 502386 ~10% meminfo.Active 101124 ~ 1%+151.8% 254632 ~17% proc-vmstat.nr_tlb_local_flush_all 30294 ~ 8% -50.7% 14930 ~17% slabinfo.btrfs_extent_state.active_objs 725 ~ 7% -49.5%366 ~15% slabinfo.btrfs_extent_state.num_slabs 725 ~ 7% -49.5%366 ~15% slabinfo.btrfs_extent_state.active_slabs 30490 ~ 7% -49.5% 15409 ~15% slabinfo.btrfs_extent_state.num_objs 63861 ~11% +90.7% 121757 ~ 9% softirqs.RCU 849659 ~ 1%+105.7%1747978 ~15% proc-vmstat.nr_tlb_local_flush_one 1034500 ~ 0% +94.1%2007885 ~ 3% proc-vmstat.pgpgin 232831 ~14% +90.8% 444281 ~13% interrupts.RES 169 ~ 3% +91.2%323 ~15% uptime.boot 7332 ~ 8%+104.1% 14968 ~36% softirqs.SCHED 59342 ~17% +60.4% 95197 ~23% interrupts.43:PCI-MSI-edge.virtio1-requests 555 ~ 8% +70.4%946 ~13% slabinfo.blkdev_requests.num_objs 526 ~ 7% +65.0%867 ~18% slabinfo.kmalloc-2048.active_objs 525 ~ 8% +66.0%872 ~15% slabinfo.blkdev_requests.active_objs 648109 ~ 1% -36.8% 409436 ~ 9% proc-vmstat.nr_free_pages 2594146 ~ 1% -36.9%1635776 ~ 9% meminfo.MemFree 603 ~ 8% +60.5%968 ~16% slabinfo.kmalloc-2048.num_objs 2587973 ~ 1% -36.7
Re: [PATCH v4 1/2] mm: add kstrimdup function
On Wed, 2014-01-29 at 19:41 -0800, Sebastian Capella wrote:
> Quoting Joe Perches (2014-01-29 17:24:28)
> > Why not minimize the malloc length too?
> >
> I figured it would be mostly for small trimming, but it seems like
> it could be and advantage and used more generally this way.
>
> I have a couple of small changes to return NULL in empty string/all ws
> cases and fix a buffer underrun.
>
> How does this look?
[]
> char *kstrimdup(const char *s, gfp_t gfp)
> {
>
> char *buf;
>
> const char *begin = skip_spaces(s);
>
> size_t len = strlen(begin);
>
removing begin and just using s would work
> if (len == 0)
>
> return NULL;
>
>
>
> while (len > 1 && isspace(begin[len - 1]))
>
> len--;
>
>
>
> buf = kmalloc_track_caller(len + 1, gfp);
>
> if (!buf)
>
> return NULL;
>
>
>
> memcpy(buf, begin, len);
>
> buf[len] = '\0';
>
>
>
> return buf;
>
> }
What should the return be to this string?
" "
Should it be "" or " " or NULL?
I don't think it should be NULL.
I don't think it should be " ".
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
Hi Nicolas,
On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>
>> In order to integrate cpuidle with the scheduler, we must have a better
>> proximity in the core code with what cpuidle is doing and not delegate
>> such interaction to arch code.
>>
>> Architectures implementing arch_cpu_idle() should simply enter
>> a cheap idle mode in the absence of a proper cpuidle driver.
>>
>> Signed-off-by: Nicolas Pitre
>> Acked-by: Daniel Lezcano
>
> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> version of this patch adding the safety local_irq_enable() to the core
> code.
>
> - >8
>
> From: Nicolas Pitre
> Subject: idle: move the cpuidle entry point to the generic idle loop
>
> In order to integrate cpuidle with the scheduler, we must have a better
> proximity in the core code with what cpuidle is doing and not delegate
> such interaction to arch code.
>
> Architectures implementing arch_cpu_idle() should simply enter
> a cheap idle mode in the absence of a proper cpuidle driver.
>
> In both cases i.e. whether it is a cpuidle driver or the default
> arch_cpu_idle(), the calling convention expects IRQs to be disabled
> on entry and enabled on exit. There is a warning in place already but
> let's add a forced IRQ enable here as well. This will allow for
> removing the forced IRQ enable some implementations do locally and
Why would this patch allow for removing the forced IRQ enable that are
being done on some archs in arch_cpu_idle()? Isn't this patch expecting
the default arch_cpu_idle() to have re-enabled the interrupts after
exiting from the default idle state? Its supposed to only catch faulty
cpuidle drivers that haven't enabled IRQs on exit from idle state but
are expected to have done so, isn't it?
Thanks
Regards
Preeti U Murthy
> allowing for the warning to trig.
>
> Signed-off-by: Nicolas Pitre
>
> diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
> index 988573a9a3..14ca43430a 100644
> --- a/kernel/cpu/idle.c
> +++ b/kernel/cpu/idle.c
> @@ -3,6 +3,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -95,8 +96,10 @@ static void cpu_idle_loop(void)
> if (!current_clr_polling_and_test()) {
> stop_critical_timings();
> rcu_idle_enter();
> - arch_cpu_idle();
> - WARN_ON_ONCE(irqs_disabled());
> + if (cpuidle_idle_call())
> + arch_cpu_idle();
> + if (WARN_ON_ONCE(irqs_disabled()))
> + local_irq_enable();
> rcu_idle_exit();
> start_critical_timings();
> } else {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 1/2] mm: add kstrimdup function
Quoting Joe Perches (2014-01-29 17:24:28)
> Why not minimize the malloc length too?
>
> maybe something like:
>
> char *kstrimdup(const char *s, gfp_t gfp)
> {
> char *buf;
> const char *begin = skip_spaces(s);
> size_t len = strlen(begin);
>
> while (len && isspace(begin[len - 1]))
> len--;
>
> buf = kmalloc_track_caller(len + 1, gfp);
> if (!buf)
> return NULL;
>
> memcpy(buf, begin, len);
> buf[len] = 0;
>
> return buf;
> }
I figured it would be mostly for small trimming, but it seems like
it could be and advantage and used more generally this way.
I have a couple of small changes to return NULL in empty string/all ws
cases and fix a buffer underrun.
How does this look?
Thanks,
Sebastian
char *kstrimdup(const char *s, gfp_t gfp)
{
char *buf;
const char *begin = skip_spaces(s);
size_t len = strlen(begin);
if (len == 0)
return NULL;
while (len > 1 && isspace(begin[len - 1]))
len--;
buf = kmalloc_track_caller(len + 1, gfp);
if (!buf)
return NULL;
memcpy(buf, begin, len);
buf[len] = '\0';
return buf;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the init tree with the kvm/kvm-ppc trees
On Wed, Jan 29, 2014 at 10:27 PM, Stephen Rothwell
wrote:
> Hi Paul,
>
> Today's linux-next merge of the init tree got conflicts in
> arch/powerpc/kvm/44x.c, arch/powerpc/kvm/e500.c,
> arch/powerpc/kvm/e500mc.c between commit 398a76c677a2 ("KVM: PPC: Add
> devname:kvm aliases for modules") from the kvm/kvm-ppc trees and commit
> "powerpc: kvm e500/44x is not modular, so don't use module_init" from the
> init tree.
>
> It sounds like there may be some intent to allow these to be built as
> modules in the future, so for now I have just reverted the init tree
> patch to these files and can carry the fix as necessary (no action is
> required).
Thanks, I'll check it out tomorrow morning (EDT) once you've published
the latest linux-next and update accordingly,
Paul.
--
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the init tree with the kvm/kvm-ppc trees
Hi Paul,
Today's linux-next merge of the init tree got conflicts in
arch/powerpc/kvm/44x.c, arch/powerpc/kvm/e500.c,
arch/powerpc/kvm/e500mc.c between commit 398a76c677a2 ("KVM: PPC: Add
devname:kvm aliases for modules") from the kvm/kvm-ppc trees and commit
"powerpc: kvm e500/44x is not modular, so don't use module_init" from the
init tree.
It sounds like there may be some intent to allow these to be built as
modules in the future, so for now I have just reverted the init tree
patch to these files and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpRgvW6D9CIY.pgp
Description: PGP signature
[ANNOUNCE]: SCST iSER target driver is available for testing
I'm glad to announce that SCST iSER target driver is available for testing from the SCST SVN iser branch. You can download it either by command: $ svn checkout svn://svn.code.sf.net/p/scst/svn/branches/iser iser-scst-branch or by clicking on "Download Snapshot" button on http://sourceforge.net/p/scst/svn/HEAD/tree/branches/iser page. Big thanks to Yan Burman and Mellanox Technologies who developed it! SCST is SCSI target mode stack for Linux. SCST allows creation of sophisticated storage devices, which provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. More info about SCST and its modules you can find on: http://scst.sourceforge.net Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] net: ethoc: implement ethtool operations
On Thu, Jan 30, 2014 at 5:59 AM, Ben Hutchings wrote:
> On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
>> The following methods are implemented:
>> - get/set settings;
>> - get registers length/registers;
>> - get link state (standard implementation);
>> - get/set ring parameters;
>> - get timestamping info (standard implementation).
> [...]
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> [...]
>> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd
>> *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_gset(phydev, cmd);
>> +}
>> +
>> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd
>> *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_sset(phydev, cmd);
>> +}
>
> I think these should return -EOPNOTSUPP in the PHY-less case, just as if
> the set_settings pointer was not set.
Ok
> [...]
>> +static void ethoc_get_ringparam(struct net_device *dev,
>> + struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + ring->rx_max_pending = priv->num_bd;
>> + ring->rx_mini_max_pending = 0;
>> + ring->rx_jumbo_max_pending = 0;
>> + ring->tx_max_pending = priv->num_bd;
>> +
>> + ring->rx_pending = priv->num_rx;
>> + ring->rx_mini_pending = 0;
>> + ring->rx_jumbo_pending = 0;
>> + ring->tx_pending = priv->num_tx;
>> +}
>> +
>> +static int ethoc_set_ringparam(struct net_device *dev,
>> +struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + if (netif_running(dev))
>> + return -EBUSY;
>
> This is unhelpful. Most implementations of this operation will restart
> the interface if it's running.
Ok
>> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
>
> Range check?
May there be requested more than ring->tx_max_pending that we
indicated in the get_ringparam?
>> + priv->num_rx = priv->num_bd - priv->num_tx;
>> + if (priv->num_rx > ring->rx_pending)
>> + priv->num_rx = ring->rx_pending;
>
> So the RX ring may only ever be shrunk?! Did you mean to compare with
> priv->num_bd instead?
First all non-TX descriptors are made RX, and if that's more than user
requested I trim it.
>> + return 0;
>> +}
>> +
>> +const struct ethtool_ops ethoc_ethtool_ops = {
>
> static
Ok
--
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git next branch
Hi Linus ! Here are a few more powerpc bits for this merge window. The bulk is made of two pull requests from Scott and Anatolij that I had missed previously (they arrived while I was away). Since both their branches are in -next independently, and the content has been around for a little while, they can still go in. The rest is mostly bug and regression fixes, a small series of cleanups to our pseries cpuidle code (including moving it to the right place), and one new cpuidle bakend for the powernv platform. I also wired up the new sched_attr syscalls. Cheers, Ben. The following changes since commit d891ea23d5203e5c47439b2a174f86a00b356a6c: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client (2014-01-28 11:02:23 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to f878f84373aefda7f041a74b24a83b8b7dec1cf0: powerpc: Wire up sched_setattr and sched_getattr syscalls (2014-01-29 17:13:05 +1100) Alistair Popple (1): powerpc/iommu: Fix initialisation of DART iommu table Andreas Schwab (1): powerpc: Fix hw breakpoints on !HAVE_HW_BREAKPOINT configurations Benjamin Herrenschmidt (3): Merge remote-tracking branch 'agust/next' into next Merge remote-tracking branch 'scott/next' into next powerpc: Wire up sched_setattr and sched_getattr syscalls Deepthi Dharwar (6): powerpc/pseries/cpuidle: Move processor_idle.c to drivers/cpuidle. powerpc/pseries/cpuidle: Use cpuidle_register() for initialisation. powerpc/pseries/cpuidle: Make cpuidle-pseries backend driver a non-module. powerpc/pseries/cpuidle: Remove MAX_IDLE_STATE macro. powerpc/pseries/cpuidle: smt-snooze-delay cleanup. powerpc/powernv/cpuidle: Back-end cpuidle driver for powernv platform. Gerhard Sittig (20): dts: mpc512x: introduce dt-bindings/clock/ header dts: mpc512x: add clock related device tree specs clk: mpc512x: introduce COMMON_CLK for MPC512x (disabled) clk: mpc512x: add backwards compat to the CCF code dts: mpc512x: add clock specs for client lookups clk: mpc5xxx: switch to COMMON_CLK, retire PPC_CLOCK spi: mpc512x: adjust to OF based clock lookup serial: mpc512x: adjust for OF based clock lookup serial: mpc512x: setup the PSC FIFO clock as well USB: fsl-mph-dr-of: adjust for OF based clock lookup mtd: mpc5121_nfc: adjust for OF based clock lookup fsl-viu: adjust for OF based clock lookup net: can: mscan: adjust to common clock support for mpc512x net: can: mscan: remove non-CCF code for MPC512x powerpc/mpc512x: improve DIU related clock setup clk: mpc512x: remove migration support workarounds powerpc/512x: clk: minor comment updates powerpc/512x: clk: enforce even SDHC divider values powerpc/512x: clk: support MPC5121/5123/5125 SoC variants powerpc/512x: dts: add MPC5125 clock specs Joe Perches (1): powerpc/numa: Fix decimal permissions Li Zhong (1): powerpc/mm: Fix compile error of pgtable-ppc64.h Paul Mackerras (2): powerpc: Fix 32-bit frames for signals delivered when transactional powerpc: Make sure "cache" directory is removed when offlining cpu Scott Wood (1): powerpc/booke64: Guard e6500 tlb handler with CONFIG_PPC_FSL_BOOK3E Tang Yuantian (1): clk: corenet: Adds the clock binding Tiejun Chen (1): powerpc/hugetlb: Replace __get_cpu_var with get_cpu_var jmarc...@redhat.com (1): powerpc/mm: Fix mmap errno when MAP_FIXED is set and mapping exceeds the allowed address space .../devicetree/bindings/clock/corenet-clock.txt| 134 +++ arch/powerpc/Kconfig |6 +- arch/powerpc/boot/dts/ac14xx.dts |7 + arch/powerpc/boot/dts/mpc5121.dtsi | 113 +- arch/powerpc/boot/dts/mpc5125twr.dts | 53 +- arch/powerpc/include/asm/clk_interface.h | 20 - arch/powerpc/include/asm/mpc5121.h |7 +- arch/powerpc/include/asm/pgtable-ppc64.h |6 +- arch/powerpc/include/asm/processor.h |7 - arch/powerpc/include/asm/systbl.h |2 + arch/powerpc/include/asm/unistd.h |2 +- arch/powerpc/include/uapi/asm/unistd.h |3 +- arch/powerpc/kernel/Makefile |1 - arch/powerpc/kernel/cacheinfo.c|3 + arch/powerpc/kernel/clock.c| 82 -- arch/powerpc/kernel/process.c |2 +- arch/powerpc/kernel/signal_32.c| 19 +- arch/powerpc/kernel/sysfs.c|2 - arch/powerpc/mm/hugetlbpage.c |4 +- arch/powerpc/mm/numa.c |2 +- arch/p
From: Joseph
Greetings I am a US Army officer currently on military assignment in Iraq, I humbly ask of your assistance secure and invest some money for me in your country. As a matter of fact, I have the sum of US$5 Million which I would like you to help me to invest. I will appreciate it if you can assist me urgently in securing and investing the money in your country pending when I will disengage from my military assignment. I promise to compensate you with 10% of the funds for your assistance while hoping that you assist me as soon as possible. I await your urgent response. Best Regards, Joseph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Documentation cleanup, update 00-INDEX files in Documentation/
On Thu, Jan 30, 2014 at 01:27:55AM +0100, Henrik Austad wrote: > Some of the 00-INDEX files are somewhat outdated and some folders does not > contain 00-INDEX at all. Only outdated (with the notably exception of > spi) indexes are touched here, the 169 folders without 00-INDEX has not > been touched. > > This applies to Linus' tip (0e47c969). RCU parts: Reviewed-by: Paul E. McKenney > New 00-INDEX > - spi/* was added in a series of commits dating back to 2006 > > Added files (missing in (*/)00-INDEX) > - dmatest.txt was added by 851b7e16 (dmatest: run test via > debugfs). > - this_cpu_ops.txt was added by a1b2a555 (percpu: add documentation on > this_cpu operations) > - ww-mutex-design.txt was added by 040a0a37 (mutex: Add support for > wound/wait style locks) > - bcache.txt was added by cafe5635 (bcache: A block layer cache) > - kernel-per-CPU-kthreads.txt was added by 49717cb40 (kthread: Document > ways of reducing OS jitter due to per-CPU kthreads). > - phy.txt was added by ff764963 (phy: add generic PHY framework) > - block/null_blk was added by 12f8f4fc (null_blk: documentation) > - module-signing.txt was added by 3cafea30 (Add > Documentation/module-signing.txt file) > - assoc_array.txt was added by 3cb98950 (Add a generic associative array > implementation.) > - arm/IXP4xx was part of the initial repo (1da177e4). > - arm/cluster-pm-race-avoidance.txt was added by 7fe31d28 (ARM: mcpm: > introduce helpers for platform coherency exit/setup). > - arm/firmware.txt was added by 7366b92a (ARM: Add interface for > registering and calling firmware-specific operations). > - arm/kernel_mode_neon.txt was added by 2afd0a05 (ARM: 7825/1: document > the use of NEON in kernel mode) > - arm/tcm.txt was added by bc581770 (ARM: 5580/2: ARM TCM > (Tightly-Coupled Memory) support v3) > - arm/vlocks.txt was added by 9762f12d (ARM: mcpm: Add baremetal voting > mutexes) > - blackfin/gptimers-example.c, Makefile was added by 4b60779d (Blackfin: > add an example showing how to use the gptimers API) > - devicetree/usage-model.txt was added by 31134efc (dt: Linux DT usage > model documentation) > - fb/api.txt was added by fb21c2f4 (fbdev: Add FOURCC-based format > configuration API) > - fb/sm501.txt was added by e6a04980 (video, sm501: add edid and > commandline support) > - fb/udlfb.txt was added by 96f8d864 (fbdev: move udlfb out of staging.) > - filesystems/Makefile was added by 1e0051ae (Documentation/fs/: split > txt and source files) > - filesystems/nfs/nfsd-admin-interfaces.txt was added by 8a4c6e19 (nfsd: > document kernel interfaces for nfsd configuration) > - ide/warm-plug-howto.txt was added by f74c9141 (ide: add warm-plug > support for IDE devices (take 2)) > - laptops/Makefile was added by d49129ac (Documentation/laptop/: split > txt and source files). > - leds/leds-blinkm.txt was added by b54cf35a (LEDS: add BlinkM RGB LED > driver, documentation and update MAINTAINERS) > - leds/ledtrig-oneshot.txt was added by 5e417281c (leds: add oneshot > trigger) > - leds/ledtrig-transient.txt was added by 44e1e9f8 (leds: add new > transient trigger for one shot timer activation) > - m68k/README.buddha was part of the initial repo (1da177e4). > - networking/LICENSE.(qla3xxx|qlcnic|qlge) was added by 5a4faa87, > 40839129, c4e84bde. > - networking/Makefile was added by 3794f3e8 (docsrc: build > Documentation/ sources) > - networking/i40evf.txt was added by 105bf2fe (i40evf: add driver to > kernel build system) > - networking/ipsec.txt was added by b3c6efbc (xfrm: Add file to document > IPsec corner case) > - networking/mac80211-auth-assoc-deauth.txt was added by 3cd7920a > (mac80211: add auth/assoc/deauth flow diagram) > - networking/netlink_mmap.txt was added by 5683264c (netlink: add > documentation for memory mapped I/O) > - networking/nf_conntrack-sysctl.txt was added by c9f9e0e1 (netfilter: > doc: add nf_conntrack sysctl api documentation) > lan) > - networking/team.txt was added by 3d249d4c (net: introduce ethernet > teaming device) > - networking/vxlan.txt was added by d342894c (vxlan: virtual extensible > - power/runtime_pm.txt was added by 5e928f77 (PM: Introduce core > framework for run-time PM of I/O devices (rev. 17)) > - power/charger-manager.txt was added by 3bb3dbbd (power_supply: Add > initial Charger-Manager driver) > - RCU/lockdep-splat.txt was added by d7bd2d68 (rcu: Document > terpretation of RCU-lockdep splats) > - s390/kvm.txt was added by 5ecee4b (KVM: s390: API documentation) > - s390/qeth.txt was added by b4d72c08 (qeth: bridgeport support - basic > control) > - scheduler/sched-bwc.txt was added by 88ebc08e (sched: Add > documentation for bandwidth control) > - scsi/advansys.txt was added by 4bd6d7f3 ([SCSI] advansys: Move > documentation to Documentation/scsi) > - scsi/bfa.txt was added by 1ec90174 ([SCSI] bfa: add readme file) > - scsi/bnx2fc.txt was added by 12b8fc10 ([SCSI] bnx2fc: Add driver > documentation) > - scsi/c
[GIT PULL] update Michael Krufky's email address
Mauro, My mailer seems to have mangled my patch. :-/ Please just pull my email address update patch from my tree. I am no longer available at the kernellabs.com or m1k.net email addresses. Update each instance of my email to my linuxtv.org account. The following changes since commit 0e47c969c65e213421450c31043353ebe3c67e0c: Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd (2014-01-28 18:56:37 -0800) are available in the git repository at: git://linuxtv.org/mkrufky/dvb krufky for you to fetch changes up to cb0ceb4bc7a297246dd26e55c3fb7a5fc42561f6: update Michael Krufky's email address (2014-01-29 21:10:11 -0500) Michael Krufky (1): update Michael Krufky's email address Documentation/dvb/contributors.txt| 2 +- drivers/media/dvb-frontends/nxt200x.c | 2 +- drivers/media/pci/bt8xx/bttv-cards.c | 2 +- drivers/media/pci/saa7134/saa7134-cards.c | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c | 4 ++-- drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-phy.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-reg.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c | 4 ++-- drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 4 ++-- drivers/media/usb/dvb-usb-v2/mxl111sf.h | 2 +- 17 files changed, 20 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mm, oom: base root bonus on current usage
On Wed, Jan 29, 2014 at 12:28:13PM -0800, Andrew Morton wrote:
> On Sat, 25 Jan 2014 19:48:32 -0800 (PST) David Rientjes
> wrote:
>
> > A 3% of system memory bonus is sometimes too excessive in comparison to
> > other processes and can yield poor results when all processes on the
> > system are root and none of them use over 3% of memory.
> >
> > Replace the 3% of system memory bonus with a 3% of current memory usage
> > bonus.
>
> This changelog has deteriorated :( We should provide sufficient info so
> that people will be able to determine whether this patch will fix a
> problem they or their customers are observing. And so that people who
> maintain -stable and its derivatives can decide whether to backport it.
>
> I went back and stole some text from the v1 patch. Please review the
> result. The changelog would be even better if it were to describe the
> new behaviour under the problematic workloads.
Looks good to me, thanks. How about the below?
> We don't think -stable needs this?
That's actually a good idea, we're putting it into RHEL too.
> From: David Rientjes
> Subject: mm, oom: base root bonus on current usage
>
> A 3% of system memory bonus is sometimes too excessive in comparison to
> other processes.
>
> With a63d83f427fb ("oom: badness heuristic rewrite"), the OOM killer tries
> to avoid killing privileged tasks by subtracting 3% of overall memory
> (system or cgroup) from their per-task consumption. But as a result, all
> root tasks that consume less than 3% of overall memory are considered
> equal, and so it only takes 33+ privileged tasks pushing the system out of
> memory for the OOM killer to do something stupid and kill sshd or
> dhclient. For example, on a 32G machine it can't tell the difference
> between the 1M agetty and the 10G fork bomb member.
>
> The changelog describes this 3% boost as the equivalent to the global
> overcommit limit being 3% higher for privileged tasks, but this is not the
> same as discounting 3% of overall memory from _every privileged task
> individually_ during OOM selection.
>
> Replace the 3% of system memory bonus with a 3% of current memory usage
> bonus.
By giving root tasks a bonus that is proportional to their actual
size, they remain comparable even when relatively small. In the
example above, the OOM killer will discount the 1M agetty's 256
badness points down to 179, and the 10G fork bomb's 262144 points down
to 183500 points and make the right choice, instead of discounting
both to 0 and killing agetty because it's first in the task list.
> Signed-off-by: David Rientjes
> Reported-by: Johannes Weiner
> Acked-by: Johannes Weiner
> Signed-off-by: Andrew Morton
Cc:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Contact Me Please
Guten Tag, Mein Name ist Mr.SUN Zhijun, ich mit der Bank of China zu arbeiten. Ich brauche Ihre Unterstützung in Durchführung einer Transaktion bei $ 18,5 Millionen Dollar geschätzt, möchte ich Ihnen 30% der gesamten Mittel als Ausgleich für Ihre Unterstützung in dieser Transaktion. Ich werde Sie über die vollständige Transaktion benachrichtigt nach Eingang Ihrer Antwort, wenn interessiert, bitte senden Sie mir Ihren vollständigen detials als unten, um meine E-Mail aufgeführt: sun.zhi...@yahoo.com.hk 1. Vollständiger Name 2.Private Telefonnummer 3.Current Wohnadresse Mit freundlichen Grüßen, Mr.SUN Zhijun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with Linus' tree
On Thu, Jan 30, 2014 at 12:58:35PM +1100, Stephen Rothwell wrote:
> Hi Andi,
>
> On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen wrote:
> >
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> >
> > I don't think the fix is correct, both sysctls need to be kept. They
> > do different things.
>
> The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
> p->numa_migrate_deferred") explicitly removed the
> numa_balancing_migrate_deferred sysctl.
Okay, sorry for the noise then.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] update Michael Krufky's email address
I am no longer available at the kernellabs.com or m1k.net email
addresses. Update each instance of my email to my linuxtv.org
account.
Signed-off-by: Michael Krufky
diff --git a/Documentation/dvb/contributors.txt
b/Documentation/dvb/contributors.txt index 47c3009..731a009 100644
--- a/Documentation/dvb/contributors.txt
+++ b/Documentation/dvb/contributors.txt
@@ -78,7 +78,7 @@ Peter Beutner
Wilson Michaels
for the lgdt330x frontend driver, and various bugfixes
-Michael Krufky
+Michael Krufky
for maintaining v4l/dvb inter-tree dependencies
Taylor Jacob
diff --git a/drivers/media/dvb-frontends/nxt200x.c
b/drivers/media/dvb-frontends/nxt200x.c index fbca985..67bdb5b 100644
--- a/drivers/media/dvb-frontends/nxt200x.c
+++ b/drivers/media/dvb-frontends/nxt200x.c
@@ -2,7 +2,7 @@
*Support for NXT2002 and NXT2004 - VSB/QAM
*
*Copyright (C) 2005 Kirk Lapray
- *Copyright (C) 2006 Michael Krufky
+ *Copyright (C) 2006-2014 Michael Krufky
*based on nxt2002 by Taylor Jacob
*and nxt2004 by Jean-Francois Thibert
*
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c
b/drivers/media/pci/bt8xx/bttv-cards.c index d85cb0a..6662b49 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -2426,7 +2426,7 @@ struct tvcard bttv_tvcards[] = {
},
/* card 0x87-- */
[BTTV_BOARD_DVICO_FUSIONHDTV_5_LITE] = {
- /* Michael Krufky */
+ /* Michael Krufky */
.name = "DViCO FusionHDTV 5 Lite",
.tuner_type = TUNER_LG_TDVS_H06XF, /* TDVS-H064F */
.tuner_addr = ADDR_UNSET,
diff --git a/drivers/media/pci/saa7134/saa7134-cards.c
b/drivers/media/pci/saa7134/saa7134-cards.c index d45e7f6..c9b2350
100644 --- a/drivers/media/pci/saa7134/saa7134-cards.c
+++ b/drivers/media/pci/saa7134/saa7134-cards.c
@@ -2590,7 +2590,7 @@ struct saa7134_board saa7134_boards[] = {
}},
},
[SAA7134_BOARD_AVERMEDIA_AVERTVHD_A180] = {
- /* Michael Krufky
+ /* Michael Krufky
* Uses Alps Electric TDHU2, containing NXT2004 ATSC
Decoder
* AFAIK, there is no analog demod, thus,
* no support for analog television.
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c index d83df4b..0a98d04
100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
@@ -1,7 +1,7 @@
/*
* mxl111sf-demod.c - driver for the MaxLinear MXL111SF DVB-T
demodulator *
- * Copyright (C) 2010 Michael Krufky
+ * Copyright (C) 2010-2014 Michael Krufky
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License as published
by @@ -601,7 +601,7 @@ struct dvb_frontend
*mxl111sf_demod_attach(struct mxl111sf_state *mxl_state,
EXPORT_SYMBOL_GPL(mxl111sf_demod_attach);
MODULE_DESCRIPTION("MaxLinear MxL111SF DVB-T demodulator driver");
-MODULE_AUTHOR("Michael Krufky ");
+MODULE_AUTHOR("Michael Krufky ");
MODULE_LICENSE("GPL");
MODULE_VERSION("0.1");
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h index 3f3f8bf..2d4530f
100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
@@ -1,7 +1,7 @@
/*
* mxl111sf-demod.h - driver for the MaxLinear MXL111SF DVB-T
demodulator *
- * Copyright (C) 2010 Michael Krufky
+ * Copyright (C) 2010-2014 Michael Krufky
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License as published
by diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c index e4121cb..a619410
100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.c
@@ -1,7 +1,7 @@
/*
* mxl111sf-gpio.c - driver for the MaxLinear MXL111SF
*
- * Copyright (C) 2010 Michael Krufky
+ * Copyright (C) 2010-2014 Michael Krufky
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License as published
by diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h
b/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h index 0220f54..b85a577
100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-gpio.h
@@ -1,7 +1,7 @@
/*
* mxl111sf-gpio.h - driver for the MaxLinear MXL111SF
*
- * Copyright (C) 2010 Michael Krufky
+ * Copyright (C) 2010-2014 Michael Krufky
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License as published
by diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
b
Re: [git pull] vfs pile 1
2014-01-29 Jan Kara : > On Tue 28-01-14 19:26:08, Linus Torvalds wrote: >> On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote: >> > Assorted stuff; the biggest pile here is Christoph's ACL series. >> > Plus assorted cleanups and fixes all over the place... There will be >> > another pile later this week. >> >> The posix_acl_chmod() code looks wrong. >> >> Not that it looked right before either, but whatever. The code >> basically looks like some variation of this in most setattr() >> implementations: >> >> if (ia_valid & ATTR_MODE) >> rc = posix_acl_chmod(inode, inode->i_mode); >> >> but the mode we're changing to (and what ATTR_MODE guards) is actually >> attr->ia_mode, not inode->i_mode. > Yes, but posix_acl_chmod() is called after setattr_copy() was done so > inode->i_mode should be the same as attr->ia_mode. Whether i_mode or > ia_mode is mode logical depends on whether you view posix_acl_chmod() as > "sync current i_mode into acls" or "reflect this i_mode change in acls". > I agree the function name suggests more the latter semantics. > >> And quite frankly, passing in inode->i_mode looks stupid, since we're >> already passing in the inode pointer, so that's just redundant and >> pointless information. > Yes, it looks stupid. We could almost drop that argument, except that f2fs > tries to play some tricks with i_mode and stores i_mode in a different > place when acls are enabled. Huh? Jaegeuk, can you explain why are you > doing that? As described to Christoph before, the reason is for acl consistency between on-disk xattr->mode and on-disk inode->mode. Previously, there are three i_modes managed by: inode->mode on-disk xattr->mode on-disk->i_mode f2fs_setattr[x] y y [update_inode] xy [x] [checkpoint]x [y] x __f2fs_setxattrx [x] x In this flow, f2fs is able to break the consistency between on-disk xattr->mode and on-disk->i_mode after checkpoint followed by sudden-power-off. So, fi->i_mode was introduced to address the problem. The new f2fs_setattr triggers: inode->mode fi->i_mode on-disk xattr->mode on-disk->i_mode f2fs_setattr y[x] y y [update_inode] y x y y [checkpoint]y x y y __f2fs_setxattr [x]x [x] [x] Finally, __f2fs_setxattr synchronizes inode->mode, on-disk xattr->mode, and on-disk inode->i_mode all together. Am I missing something? Thanks, > > Honza > -- > Jan Kara > SUSE Labs, CR > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
> The following methods are implemented:
> - get/set settings;
> - get registers length/registers;
> - get link state (standard implementation);
> - get/set ring parameters;
> - get timestamping info (standard implementation).
[...]
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> [...]
> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd
> *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_gset(phydev, cmd);
> +}
> +
> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd
> *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_sset(phydev, cmd);
> +}
I think these should return -EOPNOTSUPP in the PHY-less case, just as if
the set_settings pointer was not set.
[...]
> +static void ethoc_get_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + ring->rx_max_pending = priv->num_bd;
> + ring->rx_mini_max_pending = 0;
> + ring->rx_jumbo_max_pending = 0;
> + ring->tx_max_pending = priv->num_bd;
> +
> + ring->rx_pending = priv->num_rx;
> + ring->rx_mini_pending = 0;
> + ring->rx_jumbo_pending = 0;
> + ring->tx_pending = priv->num_tx;
> +}
> +
> +static int ethoc_set_ringparam(struct net_device *dev,
> +struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + return -EBUSY;
This is unhelpful. Most implementations of this operation will restart
the interface if it's running.
> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
Range check?
> + priv->num_rx = priv->num_bd - priv->num_tx;
> + if (priv->num_rx > ring->rx_pending)
> + priv->num_rx = ring->rx_pending;
So the RX ring may only ever be shrunk?! Did you mean to compare with
priv->num_bd instead?
> + return 0;
> +}
> +
> +const struct ethtool_ops ethoc_ethtool_ops = {
static
> + .get_settings = ethoc_get_settings,
> + .set_settings = ethoc_set_settings,
> + .get_regs_len = ethoc_get_regs_len,
> + .get_regs = ethoc_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_ringparam = ethoc_get_ringparam,
> + .set_ringparam = ethoc_set_ringparam,
> + .get_ts_info = ethtool_op_get_ts_info,
> +};
[...]
--
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein
signature.asc
Description: This is a digitally signed message part
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Andi,
On Wed, 29 Jan 2014 17:49:14 -0800 Andi Kleen wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> I don't think the fix is correct, both sysctls need to be kept. They
> do different things.
The tip tree commit 52bf84aa206c ("sched/numa,mm: Remove
p->numa_migrate_deferred") explicitly removed the
numa_balancing_migrate_deferred sysctl.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpOpqDm_OUlR.pgp
Description: PGP signature
Re: linux-next: manual merge of the tip tree with Linus' tree
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
I don't think the fix is correct, both sysctls need to be kept. They
do different things.
-Andi
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc kernel/sysctl.c
> index 096db7452cbd,2a4a4fc89cd1..
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@@ -383,22 -386,6 +385,15 @@@ static struct ctl_table kern_table[] =
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> +{
> - .procname = "numa_balancing_migrate_deferred",
> - .data = &sysctl_numa_balancing_migrate_deferred,
> - .maxlen = sizeof(unsigned int),
> - .mode = 0644,
> - .proc_handler = proc_dointvec,
> - },
> - {
> +.procname = "numa_balancing",
> +.data = NULL, /* filled in by handler */
> +.maxlen = sizeof(unsigned int),
> +.mode = 0644,
> +.proc_handler = sysctl_numa_balancing,
> +.extra1 = &zero,
> +.extra2 = &one,
> +},
> #endif /* CONFIG_NUMA_BALANCING */
> #endif /* CONFIG_SCHED_DEBUG */
> {
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with Linus' tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/sysctl.c between commit 54a43d54988a ("numa: add a sysctl for
numa_balancing") from Linus' tree and commit 52bf84aa206c ("sched/numa,
mm: Remove p->numa_migrate_deferred") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/sysctl.c
index 096db7452cbd,2a4a4fc89cd1..
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -383,22 -386,6 +385,15 @@@ static struct ctl_table kern_table[] =
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
- .procname = "numa_balancing_migrate_deferred",
- .data = &sysctl_numa_balancing_migrate_deferred,
- .maxlen = sizeof(unsigned int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
+ .procname = "numa_balancing",
+ .data = NULL, /* filled in by handler */
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = sysctl_numa_balancing,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
#endif /* CONFIG_NUMA_BALANCING */
#endif /* CONFIG_SCHED_DEBUG */
{
pgpr9mIN2YDgh.pgp
Description: PGP signature
Re: [PATCH v4 1/2] mm: add kstrimdup function
On Wed, 2014-01-29 at 19:58 -0500, Mikulas Patocka wrote:
> On Wed, 29 Jan 2014, Sebastian Capella wrote:
> > kstrimdup will duplicate and trim spaces from the passed in
> > null terminated string. This is useful for strings coming from
> > sysfs that often include trailing whitespace due to user input.
[]
> > diff --git a/mm/util.c b/mm/util.c
[]
> > /**
> > + * kstrimdup - Trim and copy a %NUL terminated string.
> > + * @s: the string to trim and duplicate
> > + * @gfp: the GFP mask used in the kmalloc() call when allocating memory
> > + *
> > + * Returns an address, which the caller must kfree, containing
> > + * a duplicate of the passed string with leading and/or trailing
> > + * whitespace (as defined by isspace) removed.
>
> It doesn't remove leading whitespace. To remove them, you need to do
>
> char *p = strim(ret);
> memmove(ret, p, strlen(p) + 1);
[]
> > + */
> > +char *kstrimdup(const char *s, gfp_t gfp)
> > +{
> > + char *ret = kstrdup(skip_spaces(s), gfp);
> > +
> > + if (ret)
> > + strim(ret);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(kstrimdup);
Why not minimize the malloc length too?
maybe something like:
char *kstrimdup(const char *s, gfp_t gfp)
{
char *buf;
const char *begin = skip_spaces(s);
size_t len = strlen(begin);
while (len && isspace(begin[len - 1]))
len--;
buf = kmalloc_track_caller(len + 1, gfp);
if (!buf)
return NULL;
memcpy(buf, begin, len);
buf[len] = 0;
return buf;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/1] Drivers: hv: vmbus: Extract the mmio information from DSDT
On Gen2 firmware, Hyper-V does not emulate the PCI bus. However, the MMIO
information is packaged up in DSDT. Extract this information and export it
for use by the synthetic framebuffer driver. This is the only driver that
needs this currently.
In this version of the patch mmio, I have updated the hyperv header file
(linux/hyperv.h) with mmio definitions.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/vmbus_drv.c | 45 -
include/linux/hyperv.h |3 +++
2 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 077bb1b..b37c91b 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -43,6 +43,10 @@ static struct acpi_device *hv_acpi_dev;
static struct tasklet_struct msg_dpc;
static struct completion probe_event;
static int irq;
+u64 hyperv_mmio_start;
+EXPORT_SYMBOL_GPL(hyperv_mmio_start);
+u64 hyperv_mmio_size;
+EXPORT_SYMBOL_GPL(hyperv_mmio_size);
static int vmbus_exists(void)
{
@@ -886,18 +890,19 @@ void vmbus_device_unregister(struct hv_device *device_obj)
/*
- * VMBUS is an acpi enumerated device. Get the the IRQ information
- * from DSDT.
+ * VMBUS is an acpi enumerated device. Get the the information we
+ * need from DSDT.
*/
-static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *irq)
+static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
{
+ switch (res->type) {
+ case ACPI_RESOURCE_TYPE_IRQ:
+ irq = res->data.irq.interrupts[0];
- if (res->type == ACPI_RESOURCE_TYPE_IRQ) {
- struct acpi_resource_irq *irqp;
- irqp = &res->data.irq;
-
- *((unsigned int *)irq) = irqp->interrupts[0];
+ case ACPI_RESOURCE_TYPE_ADDRESS64:
+ hyperv_mmio_start = res->data.address64.minimum;
+ hyperv_mmio_size = res->data.address64.address_length;
}
return AE_OK;
@@ -906,18 +911,32 @@ static acpi_status vmbus_walk_resources(struct
acpi_resource *res, void *irq)
static int vmbus_acpi_add(struct acpi_device *device)
{
acpi_status result;
+ int ret_val = -ENODEV;
hv_acpi_dev = device;
result = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
- vmbus_walk_resources, &irq);
+ vmbus_walk_resources, NULL);
- if (ACPI_FAILURE(result)) {
- complete(&probe_event);
- return -ENODEV;
+ if (ACPI_FAILURE(result))
+ goto acpi_walk_err;
+ /*
+* The parent of the vmbus acpi device (Gen2 firmware) is the VMOD that
+* has the mmio ranges. Get that.
+*/
+ if (device->parent) {
+ result = acpi_walk_resources(device->parent->handle,
+ METHOD_NAME__CRS,
+ vmbus_walk_resources, NULL);
+
+ if (ACPI_FAILURE(result))
+ goto acpi_walk_err;
}
+ ret_val = 0;
+
+acpi_walk_err:
complete(&probe_event);
- return 0;
+ return ret_val;
}
static const struct acpi_device_id vmbus_acpi_device_ids[] = {
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 344883d..be3028f 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1459,6 +1459,9 @@ int hv_vss_init(struct hv_util_service *);
void hv_vss_deinit(void);
void hv_vss_onchannelcallback(void *);
+extern u64 hyperv_mmio_start;
+extern u64 hyperv_mmio_size;
+
/*
* Negotiated version with the Host.
*/
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
Hi Maxime,
El 29/01/14 08:10, Maxime Ripard escribió:
The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
SoCs.
It supports DMA, but the driver only does PIO for now, and DMA will be
supported eventually.
Signed-off-by: Maxime Ripard
---
(snip)
+ struct sun6i_spi *sspi = spi_master_get_devdata(master);
+ int ret;
+
+ ret = clk_prepare_enable(sspi->hclk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
+ goto out;
+ }
+
+ ret = clk_prepare_enable(sspi->mclk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
A different message would be nice :)
Cheers,
Emilio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 1/2] mm: add kstrimdup function
On Wed, 29 Jan 2014, Mikulas Patocka wrote:
>
>
> On Wed, 29 Jan 2014, Sebastian Capella wrote:
>
> > kstrimdup will duplicate and trim spaces from the passed in
> > null terminated string. This is useful for strings coming from
> > sysfs that often include trailing whitespace due to user input.
> >
> > Signed-off-by: Sebastian Capella
> > Cc: Andrew Morton
> > Cc: Rik van Riel (commit_signer:5/10=50%)
> > Cc: Michel Lespinasse
> > Cc: Shaohua Li
> > Cc: Jerome Marchand
> > Cc: Mikulas Patocka
> > Cc: Joonsoo Kim
> > ---
> > include/linux/string.h |1 +
> > mm/util.c | 19 +++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/include/linux/string.h b/include/linux/string.h
> > index ac889c5..f29f9a0 100644
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -114,6 +114,7 @@ void *memchr_inv(const void *s, int c, size_t n);
> >
> > extern char *kstrdup(const char *s, gfp_t gfp);
> > extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
> > +extern char *kstrimdup(const char *s, gfp_t gfp);
> > extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
> >
> > extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
> > diff --git a/mm/util.c b/mm/util.c
> > index a24aa22..da17de5 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -63,6 +63,25 @@ char *kstrndup(const char *s, size_t max, gfp_t gfp)
> > EXPORT_SYMBOL(kstrndup);
> >
> > /**
> > + * kstrimdup - Trim and copy a %NUL terminated string.
> > + * @s: the string to trim and duplicate
> > + * @gfp: the GFP mask used in the kmalloc() call when allocating memory
> > + *
> > + * Returns an address, which the caller must kfree, containing
> > + * a duplicate of the passed string with leading and/or trailing
> > + * whitespace (as defined by isspace) removed.
>
> It doesn't remove leading whitespace. To remove them, you need to do
I was wrong - I forgot about that skip_spaces in kstrdup.
Mikulas
> > + */
> > +char *kstrimdup(const char *s, gfp_t gfp)
> > +{
> > + char *ret = kstrdup(skip_spaces(s), gfp);
> > +
> > + if (ret)
> > + strim(ret);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(kstrimdup);
> > +
> > +/**
> > * kmemdup - duplicate region of memory
> > *
> > * @src: memory region to duplicate
> > --
> > 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 v4 1/2] mm: add kstrimdup function
On Wed, 29 Jan 2014, Sebastian Capella wrote:
> kstrimdup will duplicate and trim spaces from the passed in
> null terminated string. This is useful for strings coming from
> sysfs that often include trailing whitespace due to user input.
>
> Signed-off-by: Sebastian Capella
> Cc: Andrew Morton
> Cc: Rik van Riel (commit_signer:5/10=50%)
> Cc: Michel Lespinasse
> Cc: Shaohua Li
> Cc: Jerome Marchand
> Cc: Mikulas Patocka
> Cc: Joonsoo Kim
> ---
> include/linux/string.h |1 +
> mm/util.c | 19 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index ac889c5..f29f9a0 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -114,6 +114,7 @@ void *memchr_inv(const void *s, int c, size_t n);
>
> extern char *kstrdup(const char *s, gfp_t gfp);
> extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
> +extern char *kstrimdup(const char *s, gfp_t gfp);
> extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
>
> extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
> diff --git a/mm/util.c b/mm/util.c
> index a24aa22..da17de5 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -63,6 +63,25 @@ char *kstrndup(const char *s, size_t max, gfp_t gfp)
> EXPORT_SYMBOL(kstrndup);
>
> /**
> + * kstrimdup - Trim and copy a %NUL terminated string.
> + * @s: the string to trim and duplicate
> + * @gfp: the GFP mask used in the kmalloc() call when allocating memory
> + *
> + * Returns an address, which the caller must kfree, containing
> + * a duplicate of the passed string with leading and/or trailing
> + * whitespace (as defined by isspace) removed.
It doesn't remove leading whitespace. To remove them, you need to do
char *p = strim(ret);
memmove(ret, p, strlen(p) + 1);
Mikulas
> + */
> +char *kstrimdup(const char *s, gfp_t gfp)
> +{
> + char *ret = kstrdup(skip_spaces(s), gfp);
> +
> + if (ret)
> + strim(ret);
> + return ret;
> +}
> +EXPORT_SYMBOL(kstrimdup);
> +
> +/**
> * kmemdup - duplicate region of memory
> *
> * @src: memory region to duplicate
> --
> 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] memblock: Add limit checking to memblock_virt_alloc
On Wed, Jan 29, 2014 at 4:34 PM, Andrew Morton wrote: > It applies for me. MIME getting you down? Perhaps - Gmail's web client showed me a downward pointing arrow when I moused over the attachment icon in Yinghai's e-mail. So I clicked it ... and it looked like it downloaded a patch-like looking file. So I ran "patch -p1 < file" and whoops - that wasn't so great after all :-( Your plain text e-mail version applied just fine. GUI: 0 CLI: 1 Patch works - my ia64 boots again. Thanks. Tested-by: Tony Luck -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V3 0/4] APM X-Gene PCIe controller
On Wed, Jan 29, 2014 at 4:18 PM, Bjorn Helgaas wrote: > On Sat, Jan 25, 2014 at 9:09 AM, Dann Frazier > wrote: >> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar wrote: >>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The >>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint >>> cards. >>> >>> X-Gene PCIe controller driver has depedency on the pcie arch support for >>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel >>> and approach for arch support is under discussion with arm64 maintainers. >>> The reference patch can be found here --> >>> https://lkml.org/lkml/2013/10/23/244 >> >> The reference patch looks corrupted (pcibios.c has no includes, etc), >> would you mind reposting? > > When you repost, please make sure you fix whatever problem is > preventing your email from appearing on the vger mailing lists. I > won't apply things that haven't appeared on the linux-pci list, > because that list is the opportunity for other people to review them. > You are absolutely right. If the patches are not reaching mailing list, they should not appear on archive list as well. However I am seeing my patches recorded on archives. So I am not sure if they are actually getting dropped on linux-pci or any other mailing list. http://www.spinics.net/lists/linux-pci/msg28198.html http://article.gmane.org/gmane.linux.kernel.pci/28442/match=tanmay+inamdar > 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/
[PATCH] Documentation cleanup, update 00-INDEX files in Documentation/
Some of the 00-INDEX files are somewhat outdated and some folders does not contain 00-INDEX at all. Only outdated (with the notably exception of spi) indexes are touched here, the 169 folders without 00-INDEX has not been touched. This applies to Linus' tip (0e47c969). New 00-INDEX - spi/* was added in a series of commits dating back to 2006 Added files (missing in (*/)00-INDEX) - dmatest.txt was added by 851b7e16 (dmatest: run test via debugfs). - this_cpu_ops.txt was added by a1b2a555 (percpu: add documentation on this_cpu operations) - ww-mutex-design.txt was added by 040a0a37 (mutex: Add support for wound/wait style locks) - bcache.txt was added by cafe5635 (bcache: A block layer cache) - kernel-per-CPU-kthreads.txt was added by 49717cb40 (kthread: Document ways of reducing OS jitter due to per-CPU kthreads). - phy.txt was added by ff764963 (phy: add generic PHY framework) - block/null_blk was added by 12f8f4fc (null_blk: documentation) - module-signing.txt was added by 3cafea30 (Add Documentation/module-signing.txt file) - assoc_array.txt was added by 3cb98950 (Add a generic associative array implementation.) - arm/IXP4xx was part of the initial repo (1da177e4). - arm/cluster-pm-race-avoidance.txt was added by 7fe31d28 (ARM: mcpm: introduce helpers for platform coherency exit/setup). - arm/firmware.txt was added by 7366b92a (ARM: Add interface for registering and calling firmware-specific operations). - arm/kernel_mode_neon.txt was added by 2afd0a05 (ARM: 7825/1: document the use of NEON in kernel mode) - arm/tcm.txt was added by bc581770 (ARM: 5580/2: ARM TCM (Tightly-Coupled Memory) support v3) - arm/vlocks.txt was added by 9762f12d (ARM: mcpm: Add baremetal voting mutexes) - blackfin/gptimers-example.c, Makefile was added by 4b60779d (Blackfin: add an example showing how to use the gptimers API) - devicetree/usage-model.txt was added by 31134efc (dt: Linux DT usage model documentation) - fb/api.txt was added by fb21c2f4 (fbdev: Add FOURCC-based format configuration API) - fb/sm501.txt was added by e6a04980 (video, sm501: add edid and commandline support) - fb/udlfb.txt was added by 96f8d864 (fbdev: move udlfb out of staging.) - filesystems/Makefile was added by 1e0051ae (Documentation/fs/: split txt and source files) - filesystems/nfs/nfsd-admin-interfaces.txt was added by 8a4c6e19 (nfsd: document kernel interfaces for nfsd configuration) - ide/warm-plug-howto.txt was added by f74c9141 (ide: add warm-plug support for IDE devices (take 2)) - laptops/Makefile was added by d49129ac (Documentation/laptop/: split txt and source files). - leds/leds-blinkm.txt was added by b54cf35a (LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS) - leds/ledtrig-oneshot.txt was added by 5e417281c (leds: add oneshot trigger) - leds/ledtrig-transient.txt was added by 44e1e9f8 (leds: add new transient trigger for one shot timer activation) - m68k/README.buddha was part of the initial repo (1da177e4). - networking/LICENSE.(qla3xxx|qlcnic|qlge) was added by 5a4faa87, 40839129, c4e84bde. - networking/Makefile was added by 3794f3e8 (docsrc: build Documentation/ sources) - networking/i40evf.txt was added by 105bf2fe (i40evf: add driver to kernel build system) - networking/ipsec.txt was added by b3c6efbc (xfrm: Add file to document IPsec corner case) - networking/mac80211-auth-assoc-deauth.txt was added by 3cd7920a (mac80211: add auth/assoc/deauth flow diagram) - networking/netlink_mmap.txt was added by 5683264c (netlink: add documentation for memory mapped I/O) - networking/nf_conntrack-sysctl.txt was added by c9f9e0e1 (netfilter: doc: add nf_conntrack sysctl api documentation) lan) - networking/team.txt was added by 3d249d4c (net: introduce ethernet teaming device) - networking/vxlan.txt was added by d342894c (vxlan: virtual extensible - power/runtime_pm.txt was added by 5e928f77 (PM: Introduce core framework for run-time PM of I/O devices (rev. 17)) - power/charger-manager.txt was added by 3bb3dbbd (power_supply: Add initial Charger-Manager driver) - RCU/lockdep-splat.txt was added by d7bd2d68 (rcu: Document terpretation of RCU-lockdep splats) - s390/kvm.txt was added by 5ecee4b (KVM: s390: API documentation) - s390/qeth.txt was added by b4d72c08 (qeth: bridgeport support - basic control) - scheduler/sched-bwc.txt was added by 88ebc08e (sched: Add documentation for bandwidth control) - scsi/advansys.txt was added by 4bd6d7f3 ([SCSI] advansys: Move documentation to Documentation/scsi) - scsi/bfa.txt was added by 1ec90174 ([SCSI] bfa: add readme file) - scsi/bnx2fc.txt was added by 12b8fc10 ([SCSI] bnx2fc: Add driver documentation) - scsi/cxgb3i.txt was added by c3673464 ([SCSI] cxgb3i: Add cxgb3i iSCSI driver.) - scsi/hpsa.txt was added by 992ebcf1 ([SCSI] hpsa: Add hpsa.txt to Documentation/scsi) - scsi/link_power_management_policy.txt was added by ca77329f ([libata] Link power management infrastructure) - scsi/osd.txt was a
Re: [patch] mm, oom: base root bonus on current usage
On Wed, 29 Jan 2014, Andrew Morton wrote: > This changelog has deteriorated :( We should provide sufficient info so > that people will be able to determine whether this patch will fix a > problem they or their customers are observing. And so that people who > maintain -stable and its derivatives can decide whether to backport it. > > I went back and stole some text from the v1 patch. Please review the > result. The changelog would be even better if it were to describe the > new behaviour under the problematic workloads. > The new changelog looks fine with the exception of the mention of sshd which typically sets itself to be disabled from oom killing altogether. > We don't think -stable needs this? > Nobody has reported it in over three years as causing an issue, probably because people typically have enough memory that oom kills don't come from a ton of small processes allocating memory that can't be reclaimed, there's usually at least one large process to kill. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] memblock: Add limit checking to memblock_virt_alloc
On Wed, 29 Jan 2014 16:12:13 -0800 Tony Luck wrote:
> Applying on top of Linus' tree (commit =
> dda68a8c1707b4011dc3c656fa1b2c6de6f7f304) I just get:
>
> patching file include/linux/bootmem.h
> Hunk #1 FAILED at 264.
> Hunk #2 FAILED at 272.
> 2 out of 2 hunks FAILED -- saving rejects to file include/linux/bootmem.h.rej
>
> - not a promising start :-(
>
It applies for me. MIME getting you down?
From: Yinghai Lu
Subject: memblock, bootmem: restore goal for alloc_low
Now we have memblock_virt_alloc_low to replace original bootmem api
in swiotlb.
But we should not use BOOTMEM_LOW_LIMIT for arch that does not support
CONFIG_NOBOOTMEM, as old api take 0.
| #define alloc_bootmem_low(x) \
|__alloc_bootmem_low(x, SMP_CACHE_BYTES, 0)
|#define alloc_bootmem_low_pages_nopanic(x) \
|__alloc_bootmem_low_nopanic(x, PAGE_SIZE, 0)
and we have
#define BOOTMEM_LOW_LIMIT __pa(MAX_DMA_ADDRESS)
for CONFIG_NOBOOTMEM.
Restore goal to 0 to fix ia64 crash, that Tony found.
Signed-off-by: Yinghai Lu
Reported-by: Tony Luck
Signed-off-by: Andrew Morton
---
include/linux/bootmem.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN include/linux/bootmem.h~memblock-bootmem-restore-goal-for-alloc_low
include/linux/bootmem.h
--- a/include/linux/bootmem.h~memblock-bootmem-restore-goal-for-alloc_low
+++ a/include/linux/bootmem.h
@@ -264,7 +264,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low(size, align, 0);
}
static inline void * __init memblock_virt_alloc_low_nopanic(
@@ -272,7 +272,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low_nopanic(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low_nopanic(size, align, 0);
}
static inline void * __init memblock_virt_alloc_from_nopanic(
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kthread: ensure locality of task_struct allocations
On Wed, 29 Jan 2014, Christoph Lameter wrote:
> > > diff --git a/kernel/kthread.c b/kernel/kthread.c
> > > index b5ae3ee..8573e4e 100644
> > > --- a/kernel/kthread.c
> > > +++ b/kernel/kthread.c
> > > @@ -217,7 +217,7 @@ int tsk_fork_get_node(struct task_struct *tsk)
> > > if (tsk == kthreadd_task)
> > > return tsk->pref_node_fork;
> > > #endif
> > > - return numa_node_id();
> > > + return numa_mem_id();
> >
> > I'm wondering why return NUMA_NO_NODE wouldn't have the same effect and
> > prefer the local node?
> >
>
> The idea here seems to be that the allocation may occur from a cpu that is
> different from where the process will run later on.
>
Yeah, that makes sense for kthreadd, but I'm wondering why we have to
return numa_mem_id() rather than just NUMA_NO_NODE. Sorry for not being
specific about doing s/numa_mem_id/NUMA_NO_NODE/ here.
That should just turn kmem_cache_alloc_node() into kmem_cache_alloc() and
alloc_pages_node() into alloc_pages() for the allocators that use this
return value, task_struct and thread_info. If that's not allocating local
memory, if possible, and numa_mem_id() magically does, then there's a
problem.
Eric, did you try this when writing 207205a2ba26 ("kthread: NUMA aware
kthread_create_on_node()") or was it always numa_node_id() from the
beginning?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with Linus' tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
clock framework support") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clk/Makefile
index a367a9831717,7c7f40e9ba05..
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -9,44 -9,44 +9,45 @@@ obj-$(CONFIG_COMMON_CLK) += clk-gate.
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
-# SoCs specific
-obj-$(CONFIG_ARCH_BCM2835)+= clk-bcm2835.o
-obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
-obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
-obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
-obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
-obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
-obj-$(CONFIG_ARCH_MXS)+= mxs/
-obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/
-obj-$(CONFIG_PLAT_SPEAR) += spear/
-obj-$(CONFIG_ARCH_U300) += clk-u300.o
-obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
-obj-$(CONFIG_ARCH_SIRF) += clk-prima2.o
-obj-$(CONFIG_PLAT_ORION) += mvebu/
+# hardware specific clock types
+# please keep this section sorted lexicographically by file/directory path
name
++obj-$(CONFIG_ARCH_BCM)+= bcm/
+obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
+obj-$(CONFIG_ARCH_BCM2835)+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
+obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
+obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
+obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+obj-$(CONFIG_COMMON_CLK_SI570)+= clk-si570.o
+obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
+obj-$(CONFIG_ARCH_U300) += clk-u300.o
+obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
+obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
+obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
+obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
+obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
ifeq ($(CONFIG_COMMON_CLK), y)
-obj-$(CONFIG_ARCH_MMP)+= mmp/
+obj-$(CONFIG_ARCH_MMP)+= mmp/
endif
-obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
-obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
-obj-$(CONFIG_ARCH_SUNXI) += sunxi/
-obj-$(CONFIG_ARCH_U8500) += ux500/
-obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
-obj-$(CONFIG_ARCH_ZYNQ) += zynq/
-obj-$(CONFIG_ARCH_TEGRA) += tegra/
-obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
-obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
-obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
-obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+obj-$(CONFIG_PLAT_ORION) += mvebu/
+obj-$(CONFIG_ARCH_MXS)+= mxs/
+obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
+obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
-
-obj-$(CONFIG_X86) += x86/
-obj-$(CONFIG_ARCH_BCM)+= bcm/
-
-# Chip specific
-obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
-obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
-obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
-obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
-obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
-obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_ARCH_SIRF) += sirf/
+obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/
+obj-$(CONFIG_PLAT_SPEAR) += spear/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
+obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_ARCH_OMAP2PLUS) += ti/
+obj-$(CONFIG_ARCH_U8500) += ux500/
+obj-$(CONFIG_COMMON_CLK_VERSATILE)+= versatile/
+obj-$(CONFIG_X86) += x86/
+obj-$(CONFIG_ARCH_ZYNQ) += zynq/
pgpGvhMwrUeW_.pgp
Description: PGP signature
Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller
On Sat, Jan 25, 2014 at 9:09 AM, Dann Frazier wrote: > On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar wrote: >> This patch adds support for AppliedMicro X-Gene PCIe host controller. The >> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint >> cards. >> >> X-Gene PCIe controller driver has depedency on the pcie arch support for >> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel >> and approach for arch support is under discussion with arm64 maintainers. >> The reference patch can be found here --> >> https://lkml.org/lkml/2013/10/23/244 > > The reference patch looks corrupted (pcibios.c has no includes, etc), > would you mind reposting? When you repost, please make sure you fix whatever problem is preventing your email from appearing on the vger mailing lists. I won't apply things that haven't appeared on the linux-pci list, because that list is the opportunity for other people to review them. 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/
[PATCH] pvh: set cr4 flags for APs
We need to set cr4 flags for APs that are already set for BSP. Signed-off-by: Mukesh Rathor --- arch/x86/xen/enlighten.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a4d7b64..201d09a 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1473,6 +1473,18 @@ static void xen_pvh_set_cr_flags(int cpu) * X86_CR0_TS, X86_CR0_PE, X86_CR0_ET are set by Xen for HVM guests * (which PVH shared codepaths), while X86_CR0_PG is for PVH. */ write_cr0(read_cr0() | X86_CR0_MP | X86_CR0_NE | X86_CR0_WP | X86_CR0_AM); + + if (!cpu) + return; + /* +* For BSP, PSE PGE are set in probe_page_size_mask(), for APs +* set them here. For all, OSFXSR OSXMMEXCPT are set in fpu_init. + */ + if (cpu_has_pse) + set_in_cr4(X86_CR4_PSE); + + if (cpu_has_pge) + set_in_cr4(X86_CR4_PGE); } /* -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V0] linux PVH: Set CR4 flags
Konrad, The CR4 settings were dropped from my earlier patch because you didn't wanna enable them. But since you do now, we need to set them in the APs also. If you decide not too again, please apply my prev patch "pvh: disable pse feature for now". thanks Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] net: ethoc: set up MII management bus clock
On Wed, Jan 29, 2014 at 11:01 AM, Florian Fainelli wrote:
> Le 28/01/2014 22:00, Max Filippov a écrit :
>
>> MII management bus clock is derived from the MAC clock by dividing it by
>> MIIMODER register CLKDIV field value. This value may need to be set up
>> in case it is undefined or its default value is too high (and
>> communication with PHY is too slow) or too low (and communication with
>> PHY is impossible). The value of CLKDIV is not specified directly, but
>> is derived from the MAC clock for the default MII management bus frequency
>> of 2.5MHz. The MAC clock may be specified in the platform data, or as
>> either 'clock-frequency' or 'clocks' device tree attribute.
>>
>> Signed-off-by: Max Filippov
>> ---
>> Changes v1->v2:
>> - drop MDIO bus frequency configurability, always configure for standard
>>2.5MHz;
>> - allow using common clock framework to provide ethoc clock.
>>
>> drivers/net/ethernet/ethoc.c | 37 +++--
>> include/net/ethoc.h | 1 +
>> 2 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>> index 5643b2d..5854d41 100644
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> @@ -13,6 +13,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -216,6 +217,7 @@ struct ethoc {
>>
>> struct phy_device *phy;
>> struct mii_bus *mdio;
>> + struct clk *clk;
>> s8 phy_id;
>> };
>>
>> @@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
>> int num_bd;
>> int ret = 0;
>> bool random_mac = false;
>> + u32 eth_clkfreq = 0;
>> + struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
>>
>> /* allocate networking device */
>> netdev = alloc_etherdev(sizeof(struct ethoc));
>> @@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
>> }
>>
>> /* Allow the platform setup code to pass in a MAC address. */
>> - if (dev_get_platdata(&pdev->dev)) {
>> - struct ethoc_platform_data *pdata =
>> dev_get_platdata(&pdev->dev);
>> + if (pdata) {
>> memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
>> priv->phy_id = pdata->phy_id;
>> } else {
>> @@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device
>> *pdev)
>> if (random_mac)
>> netdev->addr_assign_type = NET_ADDR_RANDOM;
>>
>> + /* Allow the platform setup code to adjust MII management bus
>> clock. */
>> + if (pdata)
>> + eth_clkfreq = pdata->eth_clkfreq;
>
> Since this is a new member, why not make it a struct clk pointer directly so
> you could simplify the code path?
Basically this is to provide flexibility for the user: it may be more
appropriate to
specify frequency if it's known and fixed, otherwise clk_get below
would find the
clock registered for this device/generic clock.
>> + else
>> + of_property_read_u32(pdev->dev.of_node,
>> +"clock-frequency", ð_clkfreq);
>> + if (!eth_clkfreq) {
>> + struct clk *clk = clk_get(&pdev->dev, NULL);
This should have been devm_clk_get.
>> +
>> + if (!IS_ERR(clk)) {
>> + priv->clk = clk;
>> + clk_prepare_enable(clk);
>> + eth_clkfreq = clk_get_rate(clk);
>> + }
>> + }
>> + if (eth_clkfreq) {
>> + u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 250 + 1);
>> +
>> + if (!clkdiv)
>> + clkdiv = 2;
>> + dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
>> + ethoc_write(priv, MIIMODER,
>> + (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE)
>> |
>> + clkdiv);
>> + }
>
>
> This does look a bit convoluted, and it looks like the clk_get() or getting
> the clock-frequency property should boil down to being the same thing with
> of_clk_get() as it should resolve all clocks phandles and fetch their
> frequencies appropriately.
I can drop clock-frequency property checking to encourage usage of common
clock framework. I don't quite understand the rest of the objection, could you
please rephrase it? clk_get calls of_clk_get internally.
>> +
>> /* register MII bus */
>> priv->mdio = mdiobus_alloc();
>> if (!priv->mdio) {
>> @@ -1141,6 +1170,8 @@ free_mdio:
>> kfree(priv->mdio->irq);
>> mdiobus_free(priv->mdio);
>> free:
>> + if (priv->clk)
>> + clk_disable_unprepare(priv->clk);
>
>
> This should probbaly be if (!IS_ERR(priv-clk)).
No, I haven't changed priv->clk when get_clk returned error.
>> free_netdev(netdev);
>> out:
>> return ret;
>> @@ -1165,6 +1196,8 @@
Re: [PATCH] memblock: Add limit checking to memblock_virt_alloc
Applying on top of Linus' tree (commit = dda68a8c1707b4011dc3c656fa1b2c6de6f7f304) I just get: patching file include/linux/bootmem.h Hunk #1 FAILED at 264. Hunk #2 FAILED at 272. 2 out of 2 hunks FAILED -- saving rejects to file include/linux/bootmem.h.rej - not a promising start :-( -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs: udf: parse_options: blocksize check
On Wed 29-01-14 17:13:16, Fabian Frederick wrote:
> Both affs and isofs check for blocksize integrity during
> parse_options.Do the same thing for udf.
>
> Valid values : 512, 1024, 2048 or 4096 bytes.
Thanks. Merged into my tree.
Honza
>
> Signed-off-by: Fabian Frederick
> ---
> fs/udf/super.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 3306b9f..ac76538 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -505,6 +505,7 @@ static int udf_parse_options(char *options, struct
> udf_options *uopt,
> while ((p = strsep(&options, ",")) != NULL) {
> substring_t args[MAX_OPT_ARGS];
> int token;
> + unsigned n;
> if (!*p)
> continue;
>
> @@ -516,7 +517,10 @@ static int udf_parse_options(char *options, struct
> udf_options *uopt,
> case Opt_bs:
> if (match_int(&args[0], &option))
> return 0;
> - uopt->blocksize = option;
> + n = option;
> + if (n != 512 && n != 1024 && n != 2048 && n != 4096)
> + return 0;
> + uopt->blocksize = n;
> uopt->flags |= (1 << UDF_FLAG_BLOCKSIZE_SET);
> break;
> case Opt_unhide:
> --
> 1.8.1.4
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
Add documentation for generic SYSCON reboot driver.
Signed-off-by: Feng Kan
---
.../bindings/power/reset/syscon-reboot.txt | 23
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
new file mode 100644
index 000..963f3c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
@@ -0,0 +1,23 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset
+with the mask defined in the reboot node.
+
+Required properties:
+- compatible: should contain "syscon-reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+- mask: the reset value written to the reboot register (32 bit access)
+
+Default will be little endian mode, 32 bit access only.
+
+Examples:
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <®mapnode>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
--
1.7.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: In "pci_fixup_video" check if this is or should be the primary video devi
On Wed, Jan 15, 2014 at 11:25:28PM +0100, Sander Eikelenboom wrote:
> Date: Sun, 12 Jan 2014 04:49:44 +0100
> Subject: [PATCH] In "pci_fixup_video" check if this is or should be the
> primary video device to prevent setting the
> IORESOURCE_ROM_SHADOW flag on a secondary VGA card
> To: Dave Airlie ,
> Eiichiro Oiwa ,
> Greg Kroah-Hartman
> Cc: Konrad Rzeszutek Wilk ,
> linux-kernel@vger.kernel.org
>
> Setting the IORESOURCE_ROM_SHADOW flag on a secondary VGA card prevents if
> from
> reading it's own rom. It will get the content of the shadowrom at C000
> instead,
> which is of the primary VGA card and the driver of the secondary card will
> bail
> out.
>
> Fix this by checking if this is or should be the primary video device before
> applying the fix and let the comment reflect this.
>
> Signed-off-by: Sander Eikelenboom
> ---
> arch/x86/pci/fixup.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index b046e07..525e49a 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -314,9 +314,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_MCH_PC1,pcie_r
> * IORESOURCE_ROM_SHADOW is used to associate the boot video
> * card with this copy. On laptops this copy has to be used since
> * the main ROM may be compressed or combined with another image.
> - * See pci_map_rom() for use of this flag. IORESOURCE_ROM_SHADOW
> - * is marked here since the boot video device will be the only enabled
> - * video device at this point.
> + * See pci_map_rom() for use of this flag. Before we mark the device
> + * with IORESOURCE_ROM_SHADOW we have to check if this is or should become
> + * the primary video card, since this quirk is ran for all video devices.
> */
>
> static void pci_fixup_video(struct pci_dev *pdev)
> @@ -347,12 +347,13 @@ static void pci_fixup_video(struct pci_dev *pdev)
> }
> bus = bus->parent;
> }
> - pci_read_config_word(pdev, PCI_COMMAND, &config);
> - if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
> - pdev->resource[PCI_ROM_RESOURCE].flags |=
> IORESOURCE_ROM_SHADOW;
> - dev_printk(KERN_DEBUG, &pdev->dev, "Boot video device\n");
> - if (!vga_default_device())
> + if (!vga_default_device() || pdev == vga_default_device()) {
> + pci_read_config_word(pdev, PCI_COMMAND, &config);
> + if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
> + pdev->resource[PCI_ROM_RESOURCE].flags |=
> IORESOURCE_ROM_SHADOW;
> + dev_printk(KERN_DEBUG, &pdev->dev, "Boot video
> device\n");
> vga_set_default_device(pdev);
> + }
ia64 also has a pci_fixup_video() that is essentially the same. Can you
fix that one as well, unless there is a reason why the fix applies only to
x86 and not to ia64?
> }
> }
> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
> --
> 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: About gpio-regulator setting on DT
Hi Mark
> The combination of the enable-active-high and enable-at-boot properties
> ought be able to cause the driver to do the right thing, the flags do
> this:
>
> if (config->enabled_at_boot) {
> if (config->enable_high)
> cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
> else
> cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
> } else {
> if (config->enable_high)
> cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
> else
> cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
> }
>
> of_get_named_gpio() just looks up the GPIO number, it doesn't request
> the GPIO.
Hmm...
I'm not sure detail,
but, I need config->gpios[ptr].flags instead of cfg.ena_gpio_flags.
Because it is used for drvdata->state.
static int gpio_regulator_probe(struct platform_device *pdev)
{
if (np) {
config = of_get_gpio_regulator_config(&pdev->dev, np);
if (IS_ERR(config))
return PTR_ERR(config);
}
...
/* build initial state from gpio init data. */
state = 0;
for (ptr = 0; ptr < drvdata->nr_gpios; ptr++) {
if (config->gpios[ptr].flags & GPIOF_OUT_INIT_HIGH) <== we need this
state |= (1 << ptr);
}
drvdata->state = state;
...
cfg.ena_gpio_invert = !config->enable_high;
if (config->enabled_at_boot) {
if (config->enable_high)
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
else
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
} else {
if (config->enable_high)
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
else
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
}
)
Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V5 2/5] power: reset: Remove X-Gene reboot driver
Remove X-Gene reboot driver.
Signed-off-by: Feng Kan
---
drivers/power/reset/Kconfig|7 ---
drivers/power/reset/Makefile |1 -
drivers/power/reset/xgene-reboot.c | 103
3 files changed, 0 insertions(+), 111 deletions(-)
delete mode 100644 drivers/power/reset/xgene-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4501c02..13a5191 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -45,13 +45,6 @@ config POWER_RESET_VEXPRESS
Power off and reset support for the ARM Ltd. Versatile
Express boards.
-config POWER_RESET_XGENE
- bool "APM SoC X-Gene reset driver"
- depends on ARM64
- depends on POWER_RESET
- help
- Reboot support for the APM SoC X-Gene Eval boards.
-
config POWER_RESET_SYSCON
bool "Generic SYSCON regmap reset driver"
depends on MFD_SYSCON
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index f2c0327..a3137ff 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -3,5 +3,4 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
-obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c
b/drivers/power/reset/xgene-reboot.c
deleted file mode 100644
index ecd55f8..000
--- a/drivers/power/reset/xgene-reboot.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * AppliedMicro X-Gene SoC Reboot Driver
- *
- * Copyright (c) 2013, Applied Micro Circuits Corporation
- * Author: Feng Kan
- * Author: Loc Ho
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * This driver provides system reboot functionality for APM X-Gene SoC.
- * For system shutdown, this is board specify. If a board designer
- * implements GPIO shutdown, use the gpio-poweroff.c driver.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct xgene_reboot_context {
- struct platform_device *pdev;
- void *csr;
- u32 mask;
-};
-
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(char str, const char *cmd)
-{
- struct xgene_reboot_context *ctx = xgene_restart_ctx;
- unsigned long timeout;
-
- /* Issue the reboot */
- if (ctx)
- writel(ctx->mask, ctx->csr);
-
- timeout = jiffies + HZ;
- while (time_before(jiffies, timeout))
- cpu_relax();
-
- dev_emerg(&ctx->pdev->dev, "Unable to restart system\n");
-}
-
-static int xgene_reboot_probe(struct platform_device *pdev)
-{
- struct xgene_reboot_context *ctx;
-
- ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
- if (!ctx) {
- dev_err(&pdev->dev, "out of memory for context\n");
- return -ENODEV;
- }
-
- ctx->csr = of_iomap(pdev->dev.of_node, 0);
- if (!ctx->csr) {
- devm_kfree(&pdev->dev, ctx);
- dev_err(&pdev->dev, "can not map resource\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
- ctx->mask = 0x;
-
- ctx->pdev = pdev;
- arm_pm_restart = xgene_restart;
- xgene_restart_ctx = ctx;
-
- return 0;
-}
-
-static struct of_device_id xgene_reboot_of_match[] = {
- { .compatible = "apm,xgene-reboot" },
- {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
- .probe = xgene_reboot_probe,
- .driver = {
- .name = "xgene-reboot",
- .of_match_table = xgene_reboot_of_match,
- },
-};
-
-static int __init xgene_reboot_init(void)
-{
- return platform_driver_register(&xgene_reboot_driver);
-}
-device_initcall(xgene_reboot_init);
--
1.7.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 4/5] arm64: Select reboot driver for X-Gene platform
Select reboot driver for X-Gene platform. Signed-off-by: Feng Kan --- arch/arm64/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index dd4327f..f43820f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -123,6 +123,8 @@ config ARCH_VEXPRESS config ARCH_XGENE bool "AppliedMicro X-Gene SOC Family" + select MFD_SYSCON + select POWER_RESET_SYSCON help This enables support for AppliedMicro X-Gene SOC Family -- 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 3/5] arm64: dts: Add X-Gene reboot driver dts node
Add X-Gene platform reboot driver dts node.
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..4ef9d26 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
+ scu: system-clk-controller@1700 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x1700 0x0 0x400>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -187,5 +192,13 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ reboot@1714 {
+ compatible = "syscon-reboot";
+ regmap = <&scu>;
+ offset = <0x14>;
+ mask = <0x1>;
+ };
+
};
};
--
1.7.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 1/5] power: reset: Add generic SYSCON register mapped reset
Add a generic SYSCON register mapped reset mechanism.
Signed-off-by: Feng Kan
---
drivers/power/reset/Kconfig |7 +++
drivers/power/reset/Makefile|1 +
drivers/power/reset/syscon-reboot.c | 100 +++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/reset/syscon-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9b3ea53..4501c02 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -51,3 +51,10 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_SYSCON
+ bool "Generic SYSCON regmap reset driver"
+ depends on MFD_SYSCON
+ depends on POWER_RESET
+ help
+ Reboot support for generic SYSCON mapped register reset.
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 3e6ed88..f2c0327 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c
b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 000..29ed908
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,100 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct syscon_reboot_context {
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static void syscon_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ struct syscon_reboot_context *ctx = syscon_reboot_ctx;
+ unsigned long timeout;
+
+ /* Issue the reboot */
+ if (ctx->map)
+ regmap_write(ctx->map, ctx->offset, ctx->mask);
+
+ timeout = jiffies + HZ;
+ while (time_before(jiffies, timeout))
+ cpu_relax();
+
+ pr_emerg("Unable to restart system\n");
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+ struct syscon_reboot_context *ctx;
+ struct device *dev = &pdev->dev;
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx) {
+ dev_err(&pdev->dev, "out of memory for context\n");
+ return -ENOMEM;
+ }
+
+ ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+ if (IS_ERR(ctx->map))
+ return PTR_ERR(ctx->map);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &ctx->offset))
+ return -EINVAL;
+
+ if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
+ return -EINVAL;
+
+ arm_pm_restart = syscon_restart;
+ syscon_reboot_ctx = ctx;
+
+ return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+ { .compatible = "syscon-reboot" },
+ {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+ .probe = syscon_reboot_probe,
+ .driver = {
+ .name = "syscon-reboot",
+ .of_match_table = syscon_reboot_of_match,
+ },
+};
+module_platform_driver(syscon_reboot_driver);
--
1.7.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 0/5] Add X-Gene platform reboot mechanism
Enable reboot driver for the X-Gene platform. Add generic syscon reboot driver. V5 Change: - Documentation update, endian and access size. V4 Change: - Remove old X-Gene reboot driver - Add generic syscon reboot driver - Add DTS and Kconfig for X-Gene reboot using syscon method V3 Change: - Remove the reboot driver's use of acpi resource patch. - Change the reboot driver to use syscon to parse out system clock register. Remove the old method of getting register from the reboot driver directly. - Remove documentation since its now simple. V2 Change: - Add support for using ACPI resource. Feng Kan (5): power: reset: Add generic SYSCON register mapped reset power: reset: Remove X-Gene reboot driver arm64: dts: Add X-Gene reboot driver dts node arm64: Select reboot driver for X-Gene platform Documentation: power: reset: Add documentation for generic SYSCON reboot driver .../bindings/power/reset/syscon-reboot.txt | 23 + arch/arm64/Kconfig |2 + arch/arm64/boot/dts/apm-storm.dtsi | 13 +++ drivers/power/reset/Kconfig|8 +- drivers/power/reset/Makefile |2 +- drivers/power/reset/syscon-reboot.c| 100 +++ drivers/power/reset/xgene-reboot.c | 103 7 files changed, 143 insertions(+), 108 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt create mode 100644 drivers/power/reset/syscon-reboot.c delete mode 100644 drivers/power/reset/xgene-reboot.c -- 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memblock: Add limit checking to memblock_virt_alloc
On Wed, Jan 29, 2014 at 3:39 PM, Yinghai Lu wrote:
> On Wed, Jan 29, 2014 at 3:07 PM, Tony Luck wrote:
>> Hmmph. ia64 is broken too. git bisect says:
>>
>> commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c
>> Author: Yinghai Lu
>> Date: Mon Jan 27 17:06:49 2014 -0800
>>
>> memblock, nobootmem: add memblock_virt_alloc_low()
>>
>> is to blame. But this patch doesn't fix it. Still dies with:
>>
>> PID hash table entries: 4096 (order: -1, 32768 bytes)
>> Sorting __ex_table...
>> kernel BUG at mm/bootmem.c:504!
>
> that's another path with memblock_virt wrapper for bootmem.
Please check attached patch.
Thanks
Yinghai
Subject: [PATCH] memblock, bootmem: Restore goal for alloc_low
Now we have memblock_virt_alloc_low to replace original bootmem api
in swiotlb.
But we should not use BOOTMEM_LOW_LIMIT for arch that does not support
CONFIG_NOBOOTMEM, as old api take 0.
| #define alloc_bootmem_low(x) \
|__alloc_bootmem_low(x, SMP_CACHE_BYTES, 0)
|#define alloc_bootmem_low_pages_nopanic(x) \
|__alloc_bootmem_low_nopanic(x, PAGE_SIZE, 0)
and we have
#define BOOTMEM_LOW_LIMIT __pa(MAX_DMA_ADDRESS)
for CONFIG_NOBOOTMEM.
Restore goal to 0 to fix ia64 crash, that Tony found.
Reported-by: Tony Luck
Signed-off-by: Yinghai Lu
---
include/linux/bootmem.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/include/linux/bootmem.h
===
--- linux-2.6.orig/include/linux/bootmem.h
+++ linux-2.6/include/linux/bootmem.h
@@ -264,7 +264,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low(size, align, 0);
}
static inline void * __init memblock_virt_alloc_low_nopanic(
@@ -272,7 +272,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low_nopanic(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low_nopanic(size, align, 0);
}
static inline void * __init memblock_virt_alloc_from_nopanic(
Re: latest git usb3.0 ports not working
On 01/29/2014 11:11 PM, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 02:17:06PM -0800, Sarah Sharp wrote: On Tue, Jan 21, 2014 at 07:47:22PM +0100, Branimir Maksimovic wrote: asus maximus v gene motherboard, this is from dmesg: [ 75.576160] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 88.991634] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead [ 88.991748] xhci_hcd :03:00.0: Abort command ring failed [ 88.991845] xhci_hcd :03:00.0: HC died; cleaning up [ 93.985489] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 93.985494] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. [ 98.982586] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 98.982591] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. [ 103.979696] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 103.979702] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. By latest git, do you mean linus/master, or 3.13.0? If it's linus/master, please provide the commit ID. Which kernel version worked for you? Try reverting commit 7dd09a1af2c7150269350aaa567a11b06e831003 "xhci: replace xhci_write_64() with writeq()" and let me know if it worked for you. I would like to help you, but I can't if you don't respond. Sarah Sharp Everything is fine after revert. Thanks! usb3.0 is working now. It is latest repository from linus/master. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/2] PM / Hibernate: use name_to_dev_t to parse resume
Use the name_to_dev_t call to parse the device name echo'd to
to /sys/power/resume. This imitates the method used in hibernate.c
in software_resume, and allows the resume partition to be specified
using other equivalent device formats as well. By allowing
/sys/debug/resume to accept the same syntax as the resume=device
parameter, we can parse the resume=device in the init script and
use the resume device directly from the kernel command line.
Signed-off-by: Sebastian Capella
Cc: Pavel Machek
Cc: Len Brown
Cc: "Rafael J. Wysocki"
---
kernel/power/hibernate.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 37170d4..b4a3e0b 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -973,26 +973,27 @@ static ssize_t resume_show(struct kobject *kobj, struct
kobj_attribute *attr,
static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t n)
{
- unsigned int maj, min;
dev_t res;
- int ret = -EINVAL;
+ char *name = kstrimdup(buf, GFP_KERNEL);
- if (sscanf(buf, "%u:%u", &maj, &min) != 2)
- goto out;
+ if (name == NULL)
+ return -ENOMEM;
- res = MKDEV(maj,min);
- if (maj != MAJOR(res) || min != MINOR(res))
- goto out;
+ res = name_to_dev_t(name);
- lock_system_sleep();
- swsusp_resume_device = res;
- unlock_system_sleep();
- printk(KERN_INFO "PM: Starting manual resume from disk\n");
- noresume = 0;
- software_resume();
- ret = n;
- out:
- return ret;
+ if (res != 0) {
+ lock_system_sleep();
+ swsusp_resume_device = res;
+ unlock_system_sleep();
+ printk(KERN_INFO "PM: Starting manual resume from disk\n");
+ noresume = 0;
+ software_resume();
+ } else {
+ n = -EINVAL;
+ }
+
+ kfree(name);
+ return n;
}
power_attr(resume);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] mm: add kstrimdup function
kstrimdup will duplicate and trim spaces from the passed in
null terminated string. This is useful for strings coming from
sysfs that often include trailing whitespace due to user input.
Signed-off-by: Sebastian Capella
Cc: Andrew Morton
Cc: Rik van Riel (commit_signer:5/10=50%)
Cc: Michel Lespinasse
Cc: Shaohua Li
Cc: Jerome Marchand
Cc: Mikulas Patocka
Cc: Joonsoo Kim
---
include/linux/string.h |1 +
mm/util.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index ac889c5..f29f9a0 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -114,6 +114,7 @@ void *memchr_inv(const void *s, int c, size_t n);
extern char *kstrdup(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
+extern char *kstrimdup(const char *s, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
diff --git a/mm/util.c b/mm/util.c
index a24aa22..da17de5 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -63,6 +63,25 @@ char *kstrndup(const char *s, size_t max, gfp_t gfp)
EXPORT_SYMBOL(kstrndup);
/**
+ * kstrimdup - Trim and copy a %NUL terminated string.
+ * @s: the string to trim and duplicate
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Returns an address, which the caller must kfree, containing
+ * a duplicate of the passed string with leading and/or trailing
+ * whitespace (as defined by isspace) removed.
+ */
+char *kstrimdup(const char *s, gfp_t gfp)
+{
+ char *ret = kstrdup(skip_spaces(s), gfp);
+
+ if (ret)
+ strim(ret);
+ return ret;
+}
+EXPORT_SYMBOL(kstrimdup);
+
+/**
* kmemdup - duplicate region of memory
*
* @src: memory region to duplicate
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] PM / Hibernate: sysfs resume
Patchset related to hibernation resume: - enhancement to make the use of an existing resume file more general - add kstrimdup function which trims and duplicates a string Both patches are based on the 3.13 tag. This was tested on a Beaglebone black with partial hibernation support, and compiled for x86_64. [PATCH v4 1/2] mm: add kstrimdup function include/linux/string.h |1 + mm/util.c | 19 +++ 2 files changed, 20 insertions(+) Adds the kstrimdup function to duplicate and trim whitespace from a string. This is useful for working with user input to sysfs. [PATCH v4 2/2] PM / Hibernate: use name_to_dev_t to parse resume kernel/power/hibernate.c | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) Use name_to_dev_t to parse the /sys/power/resume file making the syntax more flexible. It supports the previous use syntax and additionally can support other formats such as /dev/devicenode and UUID= formats. By changing /sys/debug/resume to accept the same syntax as the resume=device parameter, we can parse the resume=device in the initrd init script and use the resume device directly from the kernel command line. Changes in v4: -- * Dropped name_to_dev_t rework in favor of adding kstrimdup * adjusted resume_store Changes in v3: -- * Dropped documentation patch as it went in through trivial * Added patch for name_to_dev_t to support directly parsing userspace buffer Changes in v2: -- * Added check for null return of kstrndup in hibernate.c Thanks, Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ARM: dts: OMAP5: Add device nodes for ABB
From: "Andrii.Tseglytskyi"
Add ABB device nodes for OMAP5 family of devices. Data is based on
OMAP543x Technical Reference Manual revision U (April 2013).
NOTE: clock node has been disabled in this patch due to the lack of
OMAP5 clock data.
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon
Signed-off-by: Andrii.Tseglytskyi
---
arch/arm/boot/dts/omap5.dtsi | 63 ++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..6159f20 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -801,6 +801,69 @@
#thermal-sensor-cells = <1>;
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07cdc 0x8>, <0x4ae06014 0x4>,
+ <0x4a0021ac 0x18>, <0x4ae0C318 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address", "ldo-address";
+ ti,tranxdone-status-mask = <0x80>;
+ /* LDOVBBMPU_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMPU_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info = <
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 88 0 0x4 0 0x2000 0x1F00
+ 106 0 0x8 0 0x2000 0x1F00
+ 125 0 0x100 0x2000 0x1F00
+ 126 1 0x140 0x2000 0x1F00
+ >;
+ };
+
+ abb_mm: regulator-abb-mm {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mm";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
+ <0x4a002194 0x14>, <0x4ae0C314 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address", "ldo-address";
+ ti,tranxdone-status-mask = <0x8000>;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+ ti,abb_info = <
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 88 0 0x4 0 0x2000 0x1F00
+ 1025000 0 0x8 0 0x2000 0x1F00
+ 112 1 0x100 0x2000 0x1F00
+ >;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: dts: OMAP4: Add device nodes for ABB
From: "Andrii.Tseglytskyi"
Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April 2013).
ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon
Signed-off-by: Andrii.Tseglytskyi
---
arch/arm/boot/dts/omap4.dtsi| 26 ++
arch/arm/boot/dts/omap443x.dtsi | 26 ++
arch/arm/boot/dts/omap4460.dtsi | 37 +
3 files changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..72e6bd7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -757,6 +757,32 @@
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ ti,tranxdone-status-mask = <0x80>;
+ clocks = <&sys_clkin_ck>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ status = "disabled";
+ };
+
+ abb_iva: regulator-abb-iva {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_iva";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ ti,tranxdone-status-mask = <0x8000>;
+ clocks = <&sys_clkin_ck>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 8c1cfad..0adfa1d 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -43,6 +43,32 @@
#thermal-sensor-cells = <0>;
};
};
+
+ ocp {
+ abb_mpu: regulator-abb-mpu {
+ status = "okay";
+
+ reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>;
+ reg-names = "base-address", "int-address";
+
+ ti,abb_info = <
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 120 0 0 0 0 0
+ 1313000 0 0 0 0 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ >;
+ };
+
+ /* Default unused, just provide register info for record */
+ abb_iva: regulator-abb-iva {
+ reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>;
+ reg-names = "base-address", "int-address";
+ };
+
+ };
+
};
/include/ "omap443x-clocks.dtsi"
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 6b32f52..194f9ef 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -50,7 +50,44 @@
#thermal-sensor-cells = <0>;
};
+
+ abb_mpu: regulator-abb-mpu {
+ status = "okay";
+
+ reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>,
+ <0x4A002268 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address";
+
+ ti,abb_info = <
+ /*uVABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 120 0 0 0 0 0
+ 1313000 0 0 0x10 0x4 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ >;
+ };
+
+ abb_iva: regulator-abb-iva {
+ status = "okay";
+
+ reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>,
+ <0x4A002268 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address";
+
+ ti,abb_i
