[RFC/PATCH 5/5] mtd: ubi: Add sysfs entry to force all pebs' scan
A given eraseblock can be read many times or not at all. We do not have the account of such eraseblocks that have not been accessed since a pre-defined threshold interval. By means of scanning the entire flash device it is possible to identify all such eraseblocks. Add a sysfs entry to force scan on all the PEBs on demand basis. The sysfs entry would be available under /sys/class/ubi/ubiX/peb_scan - echo 1 to this entry would trigger the scan, ignored if in progress - On reading returns the scan status (1 = Scan executing, 0 = Scan not executing) Signed-off-by: Pratibhasagar V Signed-off-by: Tatyana Brokhman --- drivers/mtd/ubi/build.c | 32 +-- drivers/mtd/ubi/ubi.h | 3 + drivers/mtd/ubi/wl.c| 143 +++- 3 files changed, 171 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 34fe23a..a7464f8 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -154,6 +154,9 @@ static struct device_attribute dev_dt_threshold = static struct device_attribute dev_rd_threshold = __ATTR(rd_threshold, (S_IWUSR | S_IRUGO), dev_attribute_show, dev_attribute_store); +static struct device_attribute dev_mtd_trigger_scan = + __ATTR(peb_scan, (S_IWUSR | S_IRUGO), + dev_attribute_show, dev_attribute_store); /** * ubi_volume_notify - send a volume change notification. @@ -395,6 +398,8 @@ static ssize_t dev_attribute_show(struct device *dev, ret = sprintf(buf, "%d\n", ubi->dt_threshold); else if (attr == &dev_rd_threshold) ret = sprintf(buf, "%d\n", ubi->rd_threshold); + else if (attr == &dev_mtd_trigger_scan) + ret = sprintf(buf, "%d\n", ubi->scan_in_progress); else ret = -EINVAL; @@ -406,7 +411,7 @@ static ssize_t dev_attribute_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { - int value; + int value, ret; struct ubi_device *ubi; ubi = container_of(dev, struct ubi_device, dev); @@ -414,8 +419,11 @@ static ssize_t dev_attribute_store(struct device *dev, if (!ubi) return -ENODEV; - if (kstrtos32(buf, 10, &value)) - return -EINVAL; + ret = count; + if (kstrtos32(buf, 10, &value)) { + ret = -EINVAL; + goto out; + } /* Consider triggering full scan if threshods change */ else if (attr == &dev_dt_threshold) { if (value < UBI_MAX_DT_THRESHOLD) @@ -429,9 +437,21 @@ static ssize_t dev_attribute_store(struct device *dev, else pr_err("Max supported threshold value is %d", UBI_MAX_READCOUNTER); + } else if (attr == &dev_mtd_trigger_scan) { + if (value != 1) { + pr_err("Invalid input. Echo 1 to start trigger"); + goto out; + } + if (!ubi->lookuptbl) { + pr_err("lookuptbl is null"); + goto out; + } + ret = ubi_wl_scan_all(ubi); } - return count; +out: + ubi_put_device(ubi); + return ret; } static void dev_release(struct device *dev) @@ -500,6 +520,9 @@ static int ubi_sysfs_init(struct ubi_device *ubi, int *ref) if (err) return err; err = device_create_file(&ubi->dev, &dev_rd_threshold); + if (err) + return err; + err = device_create_file(&ubi->dev, &dev_mtd_trigger_scan); return err; } @@ -509,6 +532,7 @@ static int ubi_sysfs_init(struct ubi_device *ubi, int *ref) */ static void ubi_sysfs_close(struct ubi_device *ubi) { + device_remove_file(&ubi->dev, &dev_mtd_trigger_scan); device_remove_file(&ubi->dev, &dev_mtd_num); device_remove_file(&ubi->dev, &dev_dt_threshold); device_remove_file(&ubi->dev, &dev_rd_threshold); diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index ed04de2..1079517 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -491,6 +491,7 @@ struct ubi_debug_info { * for more info * @dt_threshold: data retention threshold. See UBI_DT_THRESHOLD * for more info + * @scan_in_progress: true if scanning of device PEBs is in progress * * @flash_size: underlying MTD device size (in bytes) * @peb_count: count of physical eraseblocks on the MTD device @@ -595,6 +596,7 @@ struct ubi_device { char bgt_name[sizeof(UBI_BGT_NAME_PATTERN)+2]; int rd_threshold; int dt_threshold; + bool scan_in_progress; /* I/O sub-system's stuff */ @@ -873,6 +875,7 @@ int ubi_is_erase_work(struct ubi_work *wrk); void ubi_refill_pools(struct ubi_device
[RFC/PATCH 4/5] mtd: ubi: Read threshold verification
From: Tatyana Brokhman One of the criteria to scrub an eraseblock due to read disturb issue is if that eraseblock was read from more times then a pre-defined threshold. This is verified at each LEB read according to the read counter parameter of the read PEB. An eraseblock that is found needs scrubbing is added to the ubi->scrub list. Signed-off-by: Tanya Brokhman --- drivers/mtd/ubi/eba.c | 7 ++- drivers/mtd/ubi/wl.c | 56 +-- 2 files changed, 56 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 0e11671d..1c7b5f9 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -1,5 +1,8 @@ /* * Copyright (c) International Business Machines Corp., 2006 + * Copyright (c) 2014, Linux Foundation. All rights reserved. + * Linux Foundation chooses to take subject only to the GPLv2 + * license terms, and distributes only under these terms. * * 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 @@ -466,8 +469,10 @@ retry: goto out_unlock; } } + if (ubi->lookuptbl[pnum]->rc >= ubi->rd_threshold) + scrub = 1; - if (scrub) + if (scrub && !ubi_in_wl_tree(ubi->lookuptbl[pnum], &ubi->scrub)) err = ubi_wl_scrub_peb(ubi, pnum); leb_read_unlock(ubi, vol_id, lnum); diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c index 64c7dfd..a5d754f 100644 --- a/drivers/mtd/ubi/wl.c +++ b/drivers/mtd/ubi/wl.c @@ -449,7 +449,7 @@ static struct ubi_wl_entry *find_anchor_wl_entry(struct rb_root *root) return victim; } -static int anchor_pebs_avalible(struct rb_root *root) +static int anchor_pebs_avalible(struct rb_root *root, int rd_threshold) { struct rb_node *p; struct ubi_wl_entry *e; @@ -560,6 +560,12 @@ static void return_unused_pool_pebs(struct ubi_device *ubi, for (i = pool->used; i < pool->size; i++) { e = ubi->lookuptbl[pool->pebs[i]]; + /* If given PEB pending to be scrubbed - remove it */ + if (ubi_in_wl_tree(e, &ubi->scrub)) { + ubi_err("PEB %d was pending scrubb", e->pnum); + self_check_in_wl_tree(ubi, e, &ubi->scrub); + rb_erase(&e->u.rb, &ubi->scrub); + } wl_tree_add(e, &ubi->free); ubi->free_count++; } @@ -919,6 +925,13 @@ static int schedule_erase(struct ubi_device *ubi, struct ubi_wl_entry *e, wl_wrk->lnum = lnum; wl_wrk->torture = torture; + /* If given PEB pending to be scrubbed - remove it */ + if (ubi_in_wl_tree(e, &ubi->scrub)) { + self_check_in_wl_tree(ubi, e, &ubi->scrub); + rb_erase(&e->u.rb, &ubi->scrub); + ubi_msg("PEB %d was pending scrubb", + e->pnum); + } schedule_ubi_work(ubi, wl_wrk); return 0; } @@ -948,6 +961,14 @@ static int do_sync_erase(struct ubi_device *ubi, struct ubi_wl_entry *e, wl_wrk->lnum = lnum; wl_wrk->torture = torture; + /* If given PEB pending to be scrubbed - remove it */ + if (ubi_in_wl_tree(e, &ubi->scrub)) { + self_check_in_wl_tree(ubi, e, &ubi->scrub); + rb_erase(&e->u.rb, &ubi->scrub); + ubi_msg("PEB %d was pending scrubb", + e->pnum); + } + return erase_worker(ubi, wl_wrk, 0); } @@ -1052,7 +1073,7 @@ static int wear_leveling_worker(struct ubi_device *ubi, struct ubi_work *wrk, #ifdef CONFIG_MTD_UBI_FASTMAP /* Check whether we need to produce an anchor PEB */ if (!anchor) - anchor = !anchor_pebs_avalible(&ubi->free); + anchor = !anchor_pebs_avalible(&ubi->free, ubi->rd_threshold); if (anchor) { e1 = find_anchor_wl_entry(&ubi->used); @@ -1613,6 +1634,8 @@ retry: } else if (ubi_in_wl_tree(e, &ubi->scrub)) { self_check_in_wl_tree(ubi, e, &ubi->scrub); rb_erase(&e->u.rb, &ubi->scrub); + ubi_msg("PEB %d was pending scrubb", + e->pnum); } else if (ubi_in_wl_tree(e, &ubi->erroneous)) { self_check_in_wl_tree(ubi, e, &ubi->erroneous); rb_erase(&e->u.rb, &ubi->erroneous); @@ -1656,8 +1679,6 @@ int ubi_wl_scrub_peb(struct ubi_device *ubi, int pnum) { struct ubi_wl_entry *e; - ubi_msg("schedule PEB %d for scrubbing", pnum); - retry: spin_lock(&ubi->wl_lock); e = ubi->lookuptbl[pnum]; @@ -1695,6 +1716,7 @@ retry: } } + ubi_msg("schedule PEB %d for scrubbing", pnum); wl_tree_add(e, &ubi->scrub); spin_unlock(&ubi->w
[RFC/PATCH 2/5] mtd: ubi: Fill read disturb statistics
From: Tatyana Brokhman Fill in eraseblock statistics needed for read disturb decision making: 1. read counter: incremented at each read operation reset at each erase operation Saved only as part of the meta data in RAM On attach: if fastmap data is missing a default value is assigned 2. last erase time stamp: updated at each erase operation. Saved as part of PEB OOB info on flash On attach: if fastmap data is missing retrieved from PEB EC Header on NAND. If fastmap data is corrupted a default value is assigned. The above parameters are saved as part of the fastmap data. Signed-off-by: Tatyana Brokhman Signed-off-by: Dolev Raviv --- drivers/mtd/ubi/attach.c | 137 +++--- drivers/mtd/ubi/debug.c | 11 drivers/mtd/ubi/fastmap.c | 118 ++- drivers/mtd/ubi/io.c | 28 ++ drivers/mtd/ubi/ubi.h | 24 +++- drivers/mtd/ubi/vtbl.c| 6 +- drivers/mtd/ubi/wl.c | 47 7 files changed, 322 insertions(+), 49 deletions(-) diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c index 6f27d9a..e102cac 100644 --- a/drivers/mtd/ubi/attach.c +++ b/drivers/mtd/ubi/attach.c @@ -1,5 +1,8 @@ /* * Copyright (c) International Business Machines Corp., 2006 + * Copyright (c) 2014, Linux Foundation. All rights reserved. + * Linux Foundation chooses to take subject only to the GPLv2 + * license terms, and distributes only under these terms. * * 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 @@ -87,8 +90,21 @@ #include #include #include +#include #include "ubi.h" +#define set_aeb_default_values(aeb, ai)\ + do {\ + if (aeb->ec == UBI_UNKNOWN) { \ + aeb->ec = ai->mean_ec; \ + if (ai->mean_last_erase_time) \ + aeb->last_erase_time = \ + ai->mean_last_erase_time; \ + else \ + aeb->last_erase_time = UBI_DT_THRESHOLD / 2; \ + } \ + } while (0) + static int self_check_ai(struct ubi_device *ubi, struct ubi_attach_info *ai); /* Temporary variables used during scanning */ @@ -102,6 +118,9 @@ static struct ubi_vid_hdr *vidh; * @vol_id: the last used volume id for the PEB * @lnum: the last used LEB number for the PEB * @ec: erase counter of the physical eraseblock + * @last_erase_time: last erase time stamp (%UBI_UNKNOWN if it + * is unknown) + * @rc: read counter (%UBI_UNKNOWN if it is unknown) * @to_head: if not zero, add to the head of the list * @list: the list to add to * @@ -117,7 +136,8 @@ static struct ubi_vid_hdr *vidh; * failure. */ static int add_to_list(struct ubi_attach_info *ai, int pnum, int vol_id, - int lnum, int ec, int to_head, struct list_head *list) + int lnum, int ec, long last_erase_time, long rc, + int to_head, struct list_head *list) { struct ubi_ainf_peb *aeb; @@ -139,6 +159,9 @@ static int add_to_list(struct ubi_attach_info *ai, int pnum, int vol_id, aeb->vol_id = vol_id; aeb->lnum = lnum; aeb->ec = ec; + aeb->rc = rc; + aeb->last_erase_time = last_erase_time; + if (to_head) list_add(&aeb->u.list, list); else @@ -151,13 +174,17 @@ static int add_to_list(struct ubi_attach_info *ai, int pnum, int vol_id, * @ai: attaching information * @pnum: physical eraseblock number to add * @ec: erase counter of the physical eraseblock + * @last_erase_time: last erase time stamp (%UBI_UNKNOWN if it + *is unknown) + * @rc: read counter (%UBI_UNKNOWN if it is unknown) * * This function allocates a 'struct ubi_ainf_peb' object for a corrupted * physical eraseblock @pnum and adds it to the 'corr' list. The corruption * was presumably not caused by a power cut. Returns zero in case of success * and a negative error code in case of failure. */ -static int add_corrupted(struct ubi_attach_info *ai, int pnum, int ec) +static int add_corrupted(struct ubi_attach_info *ai, int pnum, +int ec, long rc, long last_erase_time) { struct ubi_ainf_peb *aeb; @@ -170,6 +197,8 @@ static int add_corrupted(struct ubi_attach_info *ai, int pnum, int ec) ai->corr_peb_count += 1; aeb->pnum = pnum; aeb->ec = ec; + aeb->rc = rc; + aeb->last_erase_time = last_erase_time; list_add(&aeb->u.list, &ai->corr); return 0; } @@ -434,6 +463,9 @@ out_free_vidh: * @ai: attaching information * @pnum: the physical eraseblock number * @ec: erase counter + * @last_erase_time: last erase time stamp
[RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure
The need for performing read disturb is determined according to new statistics collected per eraseblock: - read counter: incremented at each read operation reset at each erase - last erase time stamp: updated at each erase This patch adds the infrastructure for the above statistics Signed-off-by: Tanya Brokhman --- drivers/mtd/ubi/build.c | 57 + drivers/mtd/ubi/fastmap.c | 14 +++ drivers/mtd/ubi/ubi-media.h | 32 ++--- drivers/mtd/ubi/ubi.h | 34 +++ drivers/mtd/ubi/wl.c| 6 + 5 files changed, 135 insertions(+), 8 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 6e30a3c..34fe23a 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1,6 +1,9 @@ /* * Copyright (c) International Business Machines Corp., 2006 * Copyright (c) Nokia Corporation, 2007 + * Copyright (c) 2014, Linux Foundation. All rights reserved. + * Linux Foundation chooses to take subject only to the GPLv2 + * license terms, and distributes only under these terms. * * 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 @@ -118,6 +121,10 @@ static struct class_attribute ubi_version = static ssize_t dev_attribute_show(struct device *dev, struct device_attribute *attr, char *buf); +static ssize_t dev_attribute_store(struct device *dev, + struct device_attribute *attr, const char *buf, + size_t count); + /* UBI device attributes (correspond to files in '//class/ubi/ubiX') */ static struct device_attribute dev_eraseblock_size = __ATTR(eraseblock_size, S_IRUGO, dev_attribute_show, NULL); @@ -141,6 +148,12 @@ static struct device_attribute dev_bgt_enabled = __ATTR(bgt_enabled, S_IRUGO, dev_attribute_show, NULL); static struct device_attribute dev_mtd_num = __ATTR(mtd_num, S_IRUGO, dev_attribute_show, NULL); +static struct device_attribute dev_dt_threshold = + __ATTR(dt_threshold, (S_IWUSR | S_IRUGO), dev_attribute_show, + dev_attribute_store); +static struct device_attribute dev_rd_threshold = + __ATTR(rd_threshold, (S_IWUSR | S_IRUGO), dev_attribute_show, + dev_attribute_store); /** * ubi_volume_notify - send a volume change notification. @@ -378,6 +391,10 @@ static ssize_t dev_attribute_show(struct device *dev, ret = sprintf(buf, "%d\n", ubi->thread_enabled); else if (attr == &dev_mtd_num) ret = sprintf(buf, "%d\n", ubi->mtd->index); + else if (attr == &dev_dt_threshold) + ret = sprintf(buf, "%d\n", ubi->dt_threshold); + else if (attr == &dev_rd_threshold) + ret = sprintf(buf, "%d\n", ubi->rd_threshold); else ret = -EINVAL; @@ -385,6 +402,38 @@ static ssize_t dev_attribute_show(struct device *dev, return ret; } +static ssize_t dev_attribute_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + int value; + struct ubi_device *ubi; + + ubi = container_of(dev, struct ubi_device, dev); + ubi = ubi_get_device(ubi->ubi_num); + if (!ubi) + return -ENODEV; + + if (kstrtos32(buf, 10, &value)) + return -EINVAL; + /* Consider triggering full scan if threshods change */ + else if (attr == &dev_dt_threshold) { + if (value < UBI_MAX_DT_THRESHOLD) + ubi->dt_threshold = value; + else + pr_err("Max supported threshold value is %d", + UBI_MAX_DT_THRESHOLD); + } else if (attr == &dev_rd_threshold) { + if (value < UBI_MAX_READCOUNTER) + ubi->rd_threshold = value; + else + pr_err("Max supported threshold value is %d", + UBI_MAX_READCOUNTER); + } + + return count; +} + static void dev_release(struct device *dev) { struct ubi_device *ubi = container_of(dev, struct ubi_device, dev); @@ -445,6 +494,12 @@ static int ubi_sysfs_init(struct ubi_device *ubi, int *ref) if (err) return err; err = device_create_file(&ubi->dev, &dev_mtd_num); + if (err) + return err; + err = device_create_file(&ubi->dev, &dev_dt_threshold); + if (err) + return err; + err = device_create_file(&ubi->dev, &dev_rd_threshold); return err; } @@ -455,6 +510,8 @@ static int ubi_sysfs_init(struct ubi_device *ubi, int *ref) static void ubi_sysfs_close(struct ubi_device *ubi) { device_remove_file(&ubi->dev, &dev_mtd_num); + device_remove_file(&ubi->dev,
[RFC/PATCH 3/5] mtd: ubi: Make in_wl_tree function public
From: Tatyana Brokhman Make the in_wl_tree function public to be used outside of wl.c. Rename it to ubi_in_wl_tree. Signed-off-by: Tanya Brokhman --- drivers/mtd/ubi/ubi.h | 1 + drivers/mtd/ubi/wl.c | 18 +- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index e4c97ad..ed04de2 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -872,6 +872,7 @@ int ubi_wl_put_fm_peb(struct ubi_device *ubi, struct ubi_wl_entry *used_e, int ubi_is_erase_work(struct ubi_work *wrk); void ubi_refill_pools(struct ubi_device *ubi); int ubi_ensure_anchor_pebs(struct ubi_device *ubi); +int ubi_in_wl_tree(struct ubi_wl_entry *e, struct rb_root *root); /* io.c */ int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset, diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c index 2b4e6fe..64c7dfd 100644 --- a/drivers/mtd/ubi/wl.c +++ b/drivers/mtd/ubi/wl.c @@ -291,14 +291,14 @@ static int produce_free_peb(struct ubi_device *ubi) } /** - * in_wl_tree - check if wear-leveling entry is present in a WL RB-tree. + * ubi_in_wl_tree - check if wear-leveling entry is present in a WL RB-tree. * @e: the wear-leveling entry to check * @root: the root of the tree * * This function returns non-zero if @e is in the @root RB-tree and zero if it * is not. */ -static int in_wl_tree(struct ubi_wl_entry *e, struct rb_root *root) +int ubi_in_wl_tree(struct ubi_wl_entry *e, struct rb_root *root) { struct rb_node *p; @@ -1607,13 +1607,13 @@ retry: spin_unlock(&ubi->wl_lock); return 0; } else { - if (in_wl_tree(e, &ubi->used)) { + if (ubi_in_wl_tree(e, &ubi->used)) { self_check_in_wl_tree(ubi, e, &ubi->used); rb_erase(&e->u.rb, &ubi->used); - } else if (in_wl_tree(e, &ubi->scrub)) { + } else if (ubi_in_wl_tree(e, &ubi->scrub)) { self_check_in_wl_tree(ubi, e, &ubi->scrub); rb_erase(&e->u.rb, &ubi->scrub); - } else if (in_wl_tree(e, &ubi->erroneous)) { + } else if (ubi_in_wl_tree(e, &ubi->erroneous)) { self_check_in_wl_tree(ubi, e, &ubi->erroneous); rb_erase(&e->u.rb, &ubi->erroneous); ubi->erroneous_peb_count -= 1; @@ -1661,8 +1661,8 @@ int ubi_wl_scrub_peb(struct ubi_device *ubi, int pnum) retry: spin_lock(&ubi->wl_lock); e = ubi->lookuptbl[pnum]; - if (e == ubi->move_from || in_wl_tree(e, &ubi->scrub) || - in_wl_tree(e, &ubi->erroneous)) { + if (e == ubi->move_from || ubi_in_wl_tree(e, &ubi->scrub) || + ubi_in_wl_tree(e, &ubi->erroneous)) { spin_unlock(&ubi->wl_lock); return 0; } @@ -1680,7 +1680,7 @@ retry: goto retry; } - if (in_wl_tree(e, &ubi->used)) { + if (ubi_in_wl_tree(e, &ubi->used)) { self_check_in_wl_tree(ubi, e, &ubi->used); rb_erase(&e->u.rb, &ubi->used); } else { @@ -2150,7 +2150,7 @@ static int self_check_in_wl_tree(const struct ubi_device *ubi, if (!ubi_dbg_chk_gen(ubi)) return 0; - if (in_wl_tree(e, root)) + if (ubi_in_wl_tree(e, root)) return 0; ubi_err("self-check failed for PEB %d, EC %d, RB-tree %p ", -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: ubi: Extend UBI layer debug/messaging capabilities
If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Signed-off-by: Tanya Brokhman --- drivers/mtd/ubi/attach.c | 138 drivers/mtd/ubi/build.c | 130 -- drivers/mtd/ubi/cdev.c| 37 +- drivers/mtd/ubi/debug.c | 9 +-- drivers/mtd/ubi/eba.c | 54 +++--- drivers/mtd/ubi/fastmap.c | 108 drivers/mtd/ubi/io.c | 177 +++--- drivers/mtd/ubi/kapi.c| 6 +- drivers/mtd/ubi/misc.c| 6 +- drivers/mtd/ubi/ubi.h | 13 ++-- drivers/mtd/ubi/vmt.c | 76 +++- drivers/mtd/ubi/vtbl.c| 54 -- drivers/mtd/ubi/wl.c | 87 +++ 13 files changed, 521 insertions(+), 374 deletions(-) diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c index 6f27d9a..3f11561 100644 --- a/drivers/mtd/ubi/attach.c +++ b/drivers/mtd/ubi/attach.c @@ -176,6 +176,7 @@ static int add_corrupted(struct ubi_attach_info *ai, int pnum, int ec) /** * validate_vid_hdr - check volume identifier header. + * @ubi: UBI device description object * @vid_hdr: the volume identifier header to check * @av: information about the volume this logical eraseblock belongs to * @pnum: physical eraseblock number the VID header came from @@ -188,7 +189,8 @@ static int add_corrupted(struct ubi_attach_info *ai, int pnum, int ec) * information in the VID header is consistent to the information in other VID * headers of the same volume. */ -static int validate_vid_hdr(const struct ubi_vid_hdr *vid_hdr, +static int validate_vid_hdr(const struct ubi_device *ubi, + const struct ubi_vid_hdr *vid_hdr, const struct ubi_ainf_volume *av, int pnum) { int vol_type = vid_hdr->vol_type; @@ -206,7 +208,7 @@ static int validate_vid_hdr(const struct ubi_vid_hdr *vid_hdr, */ if (vol_id != av->vol_id) { - ubi_err("inconsistent vol_id"); + ubi_err(ubi->ubi_num, "inconsistent vol_id"); goto bad; } @@ -216,17 +218,17 @@ static int validate_vid_hdr(const struct ubi_vid_hdr *vid_hdr, av_vol_type = UBI_VID_DYNAMIC; if (vol_type != av_vol_type) { - ubi_err("inconsistent vol_type"); + ubi_err(ubi->ubi_num, "inconsistent vol_type"); goto bad; } if (used_ebs != av->used_ebs) { - ubi_err("inconsistent used_ebs"); + ubi_err(ubi->ubi_num, "inconsistent used_ebs"); goto bad; } if (data_pad != av->data_pad) { - ubi_err("inconsistent data_pad"); + ubi_err(ubi->ubi_num, "inconsistent data_pad"); goto bad; } } @@ -234,7 +236,7 @@ static int validate_vid_hdr(const struct ubi_vid_hdr *vid_hdr, return 0; bad: - ubi_err("inconsistent VID header at PEB %d", pnum); + ubi_err(ubi->ubi_num, "inconsistent VID header at PEB %d", pnum); ubi_dump_vid_hdr(vid_hdr); ubi_dump_av(av); return -EINVAL; @@ -336,7 +338,7 @@ int ubi_compare_lebs(struct ubi_device *ubi, const struct ubi_ainf_peb *aeb, * support these images anymore. Well, those images still work, * but only if no unclean reboots happened. */ - ubi_err("unsupported on-flash UBI format"); + ubi_err(ubi->ubi_num, "unsupported on-flash UBI format"); return -EINVAL; } @@ -377,7 +379,7 @@ int ubi_compare_lebs(struct ubi_device *ubi, const struct ubi_ainf_peb *aeb, if (err == UBI_IO_BITFLIPS) bitflips = 1; else { - ubi_err("VID of PEB %d header is bad, but it was OK earlier, err %d", + ubi_err(ubi->ubi_num, "VID of PEB %d header is bad, but it was OK earlier, err %d", pnum, err); if (err > 0) err = -EIO; @@ -507,7 +509,7 @@ int ubi_add_to_av(struct ubi_device *ubi, struct ubi_attach_info *ai, int pnum, * logical eraseblocks because there was an unclean reboot. */ if (aeb->sqnum == sqnum && sqnum != 0) { - ubi_err("two LEBs with same sequence number %llu", + ubi_err(ubi->ubi_num, "two LEBs with same sequence number %llu", sqnum);
Re: SKB Documentation Ideas and How to Write Docs for Kernel
On Sat, 2014-09-27 at 22:21 -0400, nick wrote: > Hello to the maintainers of the file,skb.c , > I am wondering about making it easier for new developers including myself by > writing a file in the docs on networking > related to skb_buff and it's various methods of use to developing in the > kernel's various networking subsystems. If one of the maintainers would like > to help give me feedback on my writing of these docs this would be helpful > and make it > easier for everyone as from my experience skb_buff is one of the most asked > about things in the networking lists and > would allow people more thing for other work, including the maintainers of > lots of the networking code. I understand > you guys are very busy so feel free to respond whenever you get free time > during the next few weeks. Observation #2, this time public: despite having been told repeatedly that this is not the way to help, step #1 in your work flow continues to be to pester people to help YOU. This repeated pattern of attempts by you to TAP the community to help YOU really needs to stop. If you want to work on the linux kernel, get off your butt and get to work, but whatever you do, STOP trying to engage developers to become your private tutors. This list is NOT about developing Nick Krause. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] [PATCH 1/3] mm/slab: use percpu allocator for cpu cache
On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote: > Because of chicken and egg problem, initializaion of SLAB is really > complicated. We need to allocate cpu cache through SLAB to make > the kmem_cache works, but, before initialization of kmem_cache, > allocation through SLAB is impossible. > > On the other hand, SLUB does initialization with more simple way. It > uses percpu allocator to allocate cpu cache so there is no chicken and > egg problem. > > So, this patch try to use percpu allocator in SLAB. This simplify > initialization step in SLAB so that we could maintain SLAB code more > easily. > > From my testing, there is no performance difference. > > Signed-off-by: Joonsoo Kim > --- > include/linux/slab_def.h | 20 +--- > mm/slab.c| 237 > +++--- > mm/slab.h|1 - > 3 files changed, 81 insertions(+), 177 deletions(-) > > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h > index 8235dfb..b869d16 100644 > --- a/include/linux/slab_def.h > +++ b/include/linux/slab_def.h > @@ -8,6 +8,8 @@ > */ > > struct kmem_cache { > + struct array_cache __percpu *cpu_cache; > + > /* 1) Cache tunables. Protected by slab_mutex */ > unsigned int batchcount; > unsigned int limit; > @@ -71,23 +73,7 @@ struct kmem_cache { > struct memcg_cache_params *memcg_params; > #endif > > -/* 6) per-cpu/per-node data, touched during every alloc/free */ > - /* > - * We put array[] at the end of kmem_cache, because we want to size > - * this array to nr_cpu_ids slots instead of NR_CPUS > - * (see kmem_cache_init()) > - * We still use [NR_CPUS] and not [1] or [0] because cache_cache > - * is statically defined, so we reserve the max number of cpus. > - * > - * We also need to guarantee that the list is able to accomodate a > - * pointer for each node since "nodelists" uses the remainder of > - * available pointers. > - */ > - struct kmem_cache_node **node; > - struct array_cache *array[NR_CPUS + MAX_NUMNODES]; > - /* > - * Do not add fields after array[] > - */ > + struct kmem_cache_node *node[MAX_NUMNODES]; > }; > > #endif /* _LINUX_SLAB_DEF_H */ > diff --git a/mm/slab.c b/mm/slab.c > index 5927a17..09b060e 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -237,11 +237,10 @@ struct arraycache_init { > /* > * Need this for bootstrapping a per node allocator. > */ > -#define NUM_INIT_LISTS (3 * MAX_NUMNODES) > +#define NUM_INIT_LISTS (2 * MAX_NUMNODES) > static struct kmem_cache_node __initdata > init_kmem_cache_node[NUM_INIT_LISTS]; > #define CACHE_CACHE 0 > -#define SIZE_AC MAX_NUMNODES > -#define SIZE_NODE (2 * MAX_NUMNODES) > +#define SIZE_NODE (MAX_NUMNODES) > > static int drain_freelist(struct kmem_cache *cache, > struct kmem_cache_node *n, int tofree); > @@ -253,7 +252,6 @@ static void cache_reap(struct work_struct *unused); > > static int slab_early_init = 1; > > -#define INDEX_AC kmalloc_index(sizeof(struct arraycache_init)) > #define INDEX_NODE kmalloc_index(sizeof(struct kmem_cache_node)) > > static void kmem_cache_node_init(struct kmem_cache_node *parent) > @@ -458,9 +456,6 @@ static inline unsigned int obj_to_index(const struct > kmem_cache *cache, > return reciprocal_divide(offset, cache->reciprocal_buffer_size); > } > > -static struct arraycache_init initarray_generic = > -{ {0, BOOT_CPUCACHE_ENTRIES, 1, 0} }; > - > /* internal cache of cache description objs */ > static struct kmem_cache kmem_cache_boot = { > .batchcount = 1, > @@ -476,7 +471,7 @@ static DEFINE_PER_CPU(struct delayed_work, > slab_reap_work); > > static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep) > { > - return cachep->array[smp_processor_id()]; > + return this_cpu_ptr(cachep->cpu_cache); > } > > static size_t calculate_freelist_size(int nr_objs, size_t align) > @@ -1096,9 +1091,6 @@ static void cpuup_canceled(long cpu) > struct alien_cache **alien; > LIST_HEAD(list); > > - /* cpu is dead; no one can alloc from it. */ > - nc = cachep->array[cpu]; > - cachep->array[cpu] = NULL; > n = get_node(cachep, node); > > if (!n) > @@ -1108,6 +1100,9 @@ static void cpuup_canceled(long cpu) > > /* Free limit for this kmem_cache_node */ > n->free_limit -= cachep->batchcount; > + > + /* cpu is dead; no one can alloc from it. */ > + nc = per_cpu_ptr(cachep->cpu_cache, cpu); > if (nc) > free_block(cachep, nc->entry, nc->avail, node, &list); > > @@ -1135,7 +1130,6 @@ static void cpuup_canceled(long cpu) > } > free_array_cache: > slabs_destroy(cachep, &list); > - kfree(nc); > } > /* >
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On 2014/9/28 10:32, Yijing Wang wrote: > On 2014/9/26 17:05, Thierry Reding wrote: >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote: >> [...] >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus() >>> directly (patch attached). >> >> Really attached this time. >> >> Thierry >> > > It looks good to me, so I will update the arm pci hostbridge driver to assign > pci root bus the msi chip instead of current pcibios_add_bus(). But for other > platforms which only have a one msi chip, I will kept the arch_find_msi_chip() > temporarily for more comments, especially from Bjorn. Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply assign msi chip to root bus in all host drivers's scan functions. > > Thanks! > Yijing. > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ata: Disabling the async PM for JMicron chips
On 09/24/2014 03:22 PM, Chuansheng Liu wrote: > Like the commit e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip > 363/361"), > Barto found the similar issue for JMicron chip 368, that 363/368 has no > parent-children relationship, but they have the power dependency. > > So here we can exclude the JMicron chips out of pm_async method directly, > to avoid further similar issues. > > Details in: > https://bugzilla.kernel.org/show_bug.cgi?id=84861 I think we can disable the async PM for JMicron chips in PCI subsystem: pci_pm_init, check if it is JMicron chip and then enable_async accordingly. The problem doesn't have much to do with ATA, so move them to PCI may be more appropriate. Thanks, Aaron > > Reported-and-tested-by: Barto > Signed-off-by: Chuansheng Liu > --- > drivers/ata/ahci.c | 11 +-- > drivers/ata/pata_jmicron.c | 11 +-- > 2 files changed, 10 insertions(+), 12 deletions(-) > > diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c > index a0cc0ed..85aa6ec 100644 > --- a/drivers/ata/ahci.c > +++ b/drivers/ata/ahci.c > @@ -1340,15 +1340,14 @@ static int ahci_init_one(struct pci_dev *pdev, const > struct pci_device_id *ent) > ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS; > > /* > - * The JMicron chip 361/363 contains one SATA controller and one > + * The JMicron chip 361/363/368 contains one SATA controller and one >* PATA controller,for powering on these both controllers, we must >* follow the sequence one by one, otherwise one of them can not be > - * powered on successfully, so here we disable the async suspend > - * method for these chips. > + * powered on successfully. > + * Here we can exclude the Jmicron family directly out of pm_async > + * method to follow the power-on sequence. >*/ > - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && > - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || > - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) > + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) > device_disable_async_suspend(&pdev->dev); > > /* acquire resources */ > diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c > index 47e418b..1d685b6 100644 > --- a/drivers/ata/pata_jmicron.c > +++ b/drivers/ata/pata_jmicron.c > @@ -144,15 +144,14 @@ static int jmicron_init_one (struct pci_dev *pdev, > const struct pci_device_id *i > const struct ata_port_info *ppi[] = { &info, NULL }; > > /* > - * The JMicron chip 361/363 contains one SATA controller and one > + * The JMicron chip 361/363/368 contains one SATA controller and one >* PATA controller,for powering on these both controllers, we must >* follow the sequence one by one, otherwise one of them can not be > - * powered on successfully, so here we disable the async suspend > - * method for these chips. > + * powered on successfully. > + * Here we can exclude the Jmicron family directly out of pm_async > + * method to follow the power-on sequence. >*/ > - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && > - (pdev->device == PCI_DEVICE_ID_JMICRON_JMB363 || > - pdev->device == PCI_DEVICE_ID_JMICRON_JMB361)) > + if (pdev->vendor == PCI_VENDOR_ID_JMICRON) > device_disable_async_suspend(&pdev->dev); > > return ata_pci_bmdma_init_one(pdev, ppi, &jmicron_sht, NULL, 0); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus GIT - 3.17.0-rc6+ - BUG: unable to handle kernel NULL pointer dereference - IP: [] thermal_get_trip_type+0x17/0x84 [thermal]
On Sun, 2014-09-28 at 01:24 -0400, Miles Lane wrote: > This occurs during the boot process. It is not triggered by userspace > as far as I can tell. There are other OOPS messages. I can send the > full list if it will help. > yes, please do. is this 100% reproducible for every boot? what is the latest kernel version you've tried that does not have this problem? does the problem still exist if you blacklist the acpi thermal driver, aka, thermal.ko? what do you get in dmesg if you blacklist the thermal driver and modprobe it manually AFTER boot? thanks, rui > > [2.364611] BUG: unable to handle kernel NULL pointer dereference > at 0039 > [2.364615] IP: [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364616] PGD 374d6067 PUD 374d7067 PMD 0 > [2.364618] Oops: [#1] PREEMPT SMP > [2.364621] Modules linked in: thermal(+) mmc_core > [2.364623] CPU: 0 PID: 971 Comm: systemd-udevd Not tainted 3.17.0-rc6+ #6 > [2.364624] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 > 11/14/2013 > [2.364625] task: 8802155f8cf0 ti: 8800374f4000 task.ti: > 8800374f4000 > [2.364628] RIP: 0010:[] [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364629] RSP: 0018:8800374f7b50 EFLAGS: 00010202 > [2.364629] RAX: 0001 RBX: 0001 RCX: > > [2.364630] RDX: 8800374f7b7c RSI: RDI: > 880216a67800 > [2.364631] RBP: 8800374f7b50 R08: R09: > 0700 > [2.364631] R10: 8802156c7300 R11: 0001 R12: > > [2.364632] R13: R14: R15: > 880216a67800 > [2.364633] FS: 7f85e4b55880() GS:88021fa0() > knlGS: > [2.364634] CS: 0010 DS: ES: CR0: 80050033 > [2.364635] CR2: 0039 CR3: 374d5000 CR4: > 001407f0 > [2.364635] Stack: > [2.364637] 8800374f7ba8 813cd140 > 880216a67804 > [2.364638] 880216a67818 8800374f7bb8 880216a67000 > 8802168721e0 > [2.364639] 88021630e860 88021630e890 88021630e830 > 8800374f7c10 > [2.364640] Call Trace: > [2.364645] [] thermal_zone_device_register+0x479/0x75a > [2.364649] [] acpi_thermal_add+0x24d/0x427 [thermal] > [2.364653] [] acpi_device_probe+0x4a/0xf0 > [2.364655] [] driver_probe_device+0xb2/0x1e8 > [2.364657] [] __driver_attach+0x58/0x7a > [2.364659] [] ? __device_attach+0x38/0x38 > [2.364662] [] bus_for_each_dev+0x68/0x80 > [2.364663] [] driver_attach+0x19/0x1b > [2.364664] [] bus_add_driver+0x103/0x1c2 > [2.364666] [] driver_register+0x89/0xc5 > [2.364669] [] acpi_bus_register_driver+0x38/0x3a > [2.364671] [] acpi_thermal_init+0x67/0x81 [thermal] > [2.364673] [] ? 0xc0159000 > [2.364675] [] do_one_initcall+0x183/0x198 > [2.364678] [] ? __vunmap+0xa4/0xac > [2.364681] [] load_module+0x16d3/0x1c4e > [2.364683] [] SyS_finit_module+0x59/0x66 > [2.364685] [] ? SyS_finit_module+0x59/0x66 > [2.364688] [] tracesys+0xdd/0xe2 > [2.364705] Code: 74 10 31 c0 83 ba 48 05 00 00 00 0f 95 c0 89 06 > 31 c0 5d c3 89 f1 55 48 8b 87 e8 02 00 00 c1 e9 1f 48 89 e5 75 6b 48 > 85 c0 74 66 40 38 01 74 0e 85 f6 75 08 c7 02 03 00 00 00 eb 50 ff > ce f6 > [2.364708] RIP [] > thermal_get_trip_type+0x17/0x84 [thermal] > [2.364708] RSP > [2.364709] CR2: 0039 > > [2.393720] BUG: unable to handle kernel NULL pointer dereference > at 0030 > [2.394613] IP: [] add_disk+0x88/0x3ff > [2.395490] PGD 375b1067 PUD 375b2067 PMD 0 > [2.396371] Oops: [#2] PREEMPT SMP > [2.397150] Modules linked in: sr_mod(+) atkbd cdrom mii thermal(+) > mmc_core > [2.397935] CPU: 0 PID: 974 Comm: systemd-udevd Tainted: G D > 3.17.0-rc6+ #6 > [2.398738] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 > 11/14/2013 > [2.399547] task: 8802155fcda0 ti: 88003749 task.ti: > 88003749 > [2.400336] RIP: 0010:[] [] > add_disk+0x88/0x3ff > [2.401142] RSP: 0018:880037493b60 EFLAGS: 00010202 > [2.401987] RAX: RBX: 8800376ee800 RCX: > 0009 > [2.402793] RDX: 000b RSI: 880037493b64 RDI: > 8800376ee848 > [2.403591] RBP: 880037493ba8 R08: R09: > > [2.40] R10: 880037493b78 R11: 81672240 R12: > 8800376ee800 > [2.405248] R13: 8800376ee80c R14: R15: > 88021629237c > [2.406049] FS: 7f85e4b55880() GS:88021fa0() > knlGS: > [2.406909] CS: 0010 DS: ES: CR0: 80050033 > [2.407726] CR2: 0030 CR3: 375b CR4: > 001407f0 > [2.408558] Stack: > [2.409458] 00b081
Linus GIT - 3.17.0-rc6+ - BUG: unable to handle kernel NULL pointer dereference - IP: [] thermal_get_trip_type+0x17/0x84 [thermal]
This occurs during the boot process. It is not triggered by userspace as far as I can tell. There are other OOPS messages. I can send the full list if it will help. [2.364611] BUG: unable to handle kernel NULL pointer dereference at 0039 [2.364615] IP: [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364616] PGD 374d6067 PUD 374d7067 PMD 0 [2.364618] Oops: [#1] PREEMPT SMP [2.364621] Modules linked in: thermal(+) mmc_core [2.364623] CPU: 0 PID: 971 Comm: systemd-udevd Not tainted 3.17.0-rc6+ #6 [2.364624] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [2.364625] task: 8802155f8cf0 ti: 8800374f4000 task.ti: 8800374f4000 [2.364628] RIP: 0010:[] [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364629] RSP: 0018:8800374f7b50 EFLAGS: 00010202 [2.364629] RAX: 0001 RBX: 0001 RCX: [2.364630] RDX: 8800374f7b7c RSI: RDI: 880216a67800 [2.364631] RBP: 8800374f7b50 R08: R09: 0700 [2.364631] R10: 8802156c7300 R11: 0001 R12: [2.364632] R13: R14: R15: 880216a67800 [2.364633] FS: 7f85e4b55880() GS:88021fa0() knlGS: [2.364634] CS: 0010 DS: ES: CR0: 80050033 [2.364635] CR2: 0039 CR3: 374d5000 CR4: 001407f0 [2.364635] Stack: [2.364637] 8800374f7ba8 813cd140 880216a67804 [2.364638] 880216a67818 8800374f7bb8 880216a67000 8802168721e0 [2.364639] 88021630e860 88021630e890 88021630e830 8800374f7c10 [2.364640] Call Trace: [2.364645] [] thermal_zone_device_register+0x479/0x75a [2.364649] [] acpi_thermal_add+0x24d/0x427 [thermal] [2.364653] [] acpi_device_probe+0x4a/0xf0 [2.364655] [] driver_probe_device+0xb2/0x1e8 [2.364657] [] __driver_attach+0x58/0x7a [2.364659] [] ? __device_attach+0x38/0x38 [2.364662] [] bus_for_each_dev+0x68/0x80 [2.364663] [] driver_attach+0x19/0x1b [2.364664] [] bus_add_driver+0x103/0x1c2 [2.364666] [] driver_register+0x89/0xc5 [2.364669] [] acpi_bus_register_driver+0x38/0x3a [2.364671] [] acpi_thermal_init+0x67/0x81 [thermal] [2.364673] [] ? 0xc0159000 [2.364675] [] do_one_initcall+0x183/0x198 [2.364678] [] ? __vunmap+0xa4/0xac [2.364681] [] load_module+0x16d3/0x1c4e [2.364683] [] SyS_finit_module+0x59/0x66 [2.364685] [] ? SyS_finit_module+0x59/0x66 [2.364688] [] tracesys+0xdd/0xe2 [2.364705] Code: 74 10 31 c0 83 ba 48 05 00 00 00 0f 95 c0 89 06 31 c0 5d c3 89 f1 55 48 8b 87 e8 02 00 00 c1 e9 1f 48 89 e5 75 6b 48 85 c0 74 66 40 38 01 74 0e 85 f6 75 08 c7 02 03 00 00 00 eb 50 ff ce f6 [2.364708] RIP [] thermal_get_trip_type+0x17/0x84 [thermal] [2.364708] RSP [2.364709] CR2: 0039 [2.393720] BUG: unable to handle kernel NULL pointer dereference at 0030 [2.394613] IP: [] add_disk+0x88/0x3ff [2.395490] PGD 375b1067 PUD 375b2067 PMD 0 [2.396371] Oops: [#2] PREEMPT SMP [2.397150] Modules linked in: sr_mod(+) atkbd cdrom mii thermal(+) mmc_core [2.397935] CPU: 0 PID: 974 Comm: systemd-udevd Tainted: G D 3.17.0-rc6+ #6 [2.398738] Hardware name: Dell Inc. Inspiron 5437/0DM6M9, BIOS A07 11/14/2013 [2.399547] task: 8802155fcda0 ti: 88003749 task.ti: 88003749 [2.400336] RIP: 0010:[] [] add_disk+0x88/0x3ff [2.401142] RSP: 0018:880037493b60 EFLAGS: 00010202 [2.401987] RAX: RBX: 8800376ee800 RCX: 0009 [2.402793] RDX: 000b RSI: 880037493b64 RDI: 8800376ee848 [2.403591] RBP: 880037493ba8 R08: R09: [2.40] R10: 880037493b78 R11: 81672240 R12: 8800376ee800 [2.405248] R13: 8800376ee80c R14: R15: 88021629237c [2.406049] FS: 7f85e4b55880() GS:88021fa0() knlGS: [2.406909] CS: 0010 DS: ES: CR0: 80050033 [2.407726] CR2: 0030 CR3: 375b CR4: 001407f0 [2.408558] Stack: [2.409458] 00b0814e22e5 880037493b90 81352deb 88021552 [2.410372] 880216292300 8800376ee800 880216b00968 [2.411297] 88021629237c 880037493c30 c01a1d40 8808200e [2.412205] Call Trace: [2.413057] [] ? __pm_runtime_use_autosuspend+0x5e/0x65 [2.413935] [] sr_probe+0x480/0x4d2 [sr_mod] [2.414853] [] driver_probe_device+0xb2/0x1e8 [2.415732] [] __driver_attach+0x58/0x7a [2.416657] [] ? __device_attach+0x38/0x38 [2.417539] [] bus_for_each_dev+0x68/0x80 [2.418421] [] driver_attach+0x19/0x1b [2.419341] []
Re: [PATCH v5 RESEND 1/3] ARM: EXYNOS: Move code from hotplug.c to platsmp.c
On 09/27/14 17:39, Krzysztof Kozlowski wrote: W dniu 26.09.2014 o 23:13, Arnd Bergmann pisze: On Friday 05 September 2014, Krzysztof Kozlowski wrote: The commit only moves code around with one additional observable change: the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These CFLAGS are not necessary any more. This turns out to be wrong, and your change broke 'allmodconfig' builds in linux-next. Please apply this patch on top. Arnd, Krzysztof commented its fix has been submitted and landed in my -test tree not -next because it should be handled in rmk's tree I think. I sent the patch to RMK patch tracking system just now and it should be fine in there. BTW, I just applied the fix in my -next until its ladning in RMK tree but as you know it will be not be sent to arm-soc via samsung tree... One more, Arnd please pull my pull-request 2nd round and 3rd round for samsung stuff for 3.18. My patch definitely needed more testing. I posted a fix here: https://lkml.org/lkml/2014/9/24/163 However it seems that it wasn't picked up by anyone yet. Russell, could you pick up the patch (with acks from Nicolas and Kukjin)? I believe Russell will take the patch in his tree. Thanks, Kukjin 8<-- From 4ba6bf8806caec386e35930314dbad071284c837 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Fri, 26 Sep 2014 23:09:38 +0200 Subject: [PATCH] ARM: EXYNOS: fix build error in platsmp.c /tmp/ccYeWL3V.s: Assembler messages: /tmp/ccYeWL3V.s:659: Error: selected processor does not support ARM mode `isb ' /tmp/ccYeWL3V.s:664: Error: selected processor does not support ARM mode `isb ' /tmp/ccYeWL3V.s:665: Error: selected processor does not support ARM mode `dsb ' make[3]: *** [arch/arm/mach-exynos/platsmp.o] Error 1 Signed-off-by: Arnd Bergmann Fixes: 17342534e1d932 ("ARM: EXYNOS: Move code from hotplug.c to platsmp.c") diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 4e49d4efb264..64324bf5edb4 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_PM_SLEEP) += suspend.o obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o +CFLAGS_platsmp.o := -march=armv7-a plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: perf: perf_fuzzer triggers instant reboot
On 09/25/2014 12:38 PM, Cong Wang wrote: > On Wed, Sep 24, 2014 at 9:59 PM, Vince Weaver > wrote: >> > >> > So I noticed Cong Wang's patch (3577af70a2ce4853d58e57d832e687d739281479) >> > perf: Fix a race condition in perf_remove_from_context() >> > >> > and that sounds a lot like the weird fork()/memory-corruption bug that the >> > fuzzer has been triggering. >> > >> > So I applied that patch alone on top of the 3.17-rc4 kernel that I could >> > reproducibly reboot... and with the patch I can't trigger the problem >> > anymore. >> > >> > Now that just might mean the patch pushed the code around enough so my >> > test doesn't trigger, but there is hope that maybe this fixes things. > I read this as it fixes your crash as well? Cong, I *suspect* that that commit also triggers the following lockdep warning. I haven't confirmed that, but hopefully it'll help: [ 690.800861] == [ 690.800864] [ INFO: possible circular locking dependency detected ] [ 690.800877] 3.17.0-rc6-next-20140926-sasha-00051-g9253dff-dirty #1242 Not tainted [ 690.800881] --- [ 690.800887] trinity-c95/17888 is trying to acquire lock: [ 690.800925] (&(&pool->lock)->rlock){..-.-.}, at: __queue_work (kernel/workqueue.c:1325) [ 690.800929] [ 690.800929] but task is already holding lock: [ 690.800955] (&ctx->lock){-.-...}, at: perf_lock_task_context (kernel/events/core.c:988) [ 690.800958] [ 690.800958] which lock already depends on the new lock. [ 690.800958] [ 690.800960] [ 690.800960] the existing dependency chain (in reverse order) is: [ 690.800971] [ 690.800971] -> #3 (&ctx->lock){-.-...}: [ 690.800990] lock_acquire (kernel/locking/lockdep.c:3610) [ 690.801006] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151) [ 690.801023] __perf_event_task_sched_out (kernel/events/core.c:2419 kernel/events/core.c:2445) [ 690.801040] perf_event_task_sched_out (include/linux/perf_event.h:714) [ 690.801051] __schedule (kernel/sched/core.c:2178 kernel/sched/core.c:2216 kernel/sched/core.c:2336 kernel/sched/core.c:2858) [ 690.801061] preempt_schedule_irq (./arch/x86/include/asm/paravirt.h:814 kernel/sched/core.c:2975) [ 690.801075] retint_kernel (arch/x86/kernel/entry_64.S:920) [ 690.801086] perf_swevent_init (kernel/events/core.c:5963 kernel/events/core.c:5983 kernel/events/core.c:6043) [ 690.801100] perf_init_event (kernel/events/core.c:6841) [ 690.801110] perf_event_alloc (kernel/events/core.c:6996) [ 690.801124] SYSC_perf_event_open (kernel/events/core.c:7291) [ 690.801136] SyS_perf_event_open (kernel/events/core.c:7210) [ 690.801149] tracesys_phase2 (arch/x86/kernel/entry_64.S:529) [ 690.801163] [ 690.801163] -> #2 (&rq->lock){-.-.-.}: [ 690.801185] lock_acquire (kernel/locking/lockdep.c:3610) [ 690.801194] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151) [ 690.801206] wake_up_new_task (include/linux/sched.h:2932 kernel/sched/core.c:320 kernel/sched/core.c:2128) [ 690.801220] do_fork (kernel/fork.c:1690) [ 690.801233] kernel_thread (kernel/fork.c:1712) [ 690.801250] rest_init (init/main.c:404) [ 690.801265] start_kernel (init/main.c:682) [ 690.801280] x86_64_start_reservations (arch/x86/kernel/head64.c:199) [ 690.801297] x86_64_start_kernel (arch/x86/kernel/head64.c:188) [ 690.801315] [ 690.801315] -> #1 (&p->pi_lock){-.-.-.}: [ 690.801326] lock_acquire (kernel/locking/lockdep.c:3610) [ 690.801340] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:117 kernel/locking/spinlock.c:159) [ 690.801350] try_to_wake_up (kernel/sched/core.c:1692) [ 690.801364] wake_up_process (kernel/sched/core.c:1787 (discriminator 3)) [ 690.801377] create_worker (include/linux/spinlock.h:359 kernel/workqueue.c:1713) [ 690.801401] init_workqueues (kernel/workqueue.c:4861) [ 690.801415] do_one_initcall (init/main.c:792) [ 690.801427] kernel_init_freeable (init/main.c:893 init/main.c:999) [ 690.801436] kernel_init (init/main.c:937) [ 690.801457] ret_from_fork (arch/x86/kernel/entry_64.S:348) [ 690.801474] [ 690.801474] -> #0 (&(&pool->lock)->rlock){..-.-.}: [ 690.801488] __lock_acquire (kernel/locking/lockdep.c:1842 kernel/locking/lockdep.c:1947 kernel/locking/lockdep.c:2133 kernel/locking/lockdep.c:3184) [ 690.801499] lock_acquire (kernel/locking/lockdep.c:3610) [ 690.801507] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151) [ 690.801517] __queue_work (kernel/workqueue.c:1325) [ 690.801525] queue_work_on (kernel/workqueue.c:1403) [ 690.801542] free_object (lib/debugobjects.c:209) [ 690.801552] __debug_check_no_obj_freed (lib/debugobjects.c:718) [ 690.801561] debug_check_no_obj_freed (lib/debugobjects.c:727) [ 690.801574] kmem_cache_free (mm/slub.c:2687 mm/slub.c:2715) [ 690.801583] free_task (kernel/fork.c:221) [ 690.801594] __put_task_struct (kernel/fork.c:251) [ 690.801609] put_
Re: [PATCH] arm: Remove read of issue in sa1111.c in sa1111_resume
On 14-09-27 11:31 PM, Randy Dunlap wrote: > On 09/27/14 19:50, Nicholas Krause wrote: >> This removes the FIXME message and issue with reading in this driver before >> resuming >> in the function, sa_resume. > > You need to explain why this makes any sense. > Hint: it doesn't. > >> Signed-off-by: Nicholas Krause >> --- >> arch/arm/common/sa.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c >> index e57d7e5..0c4b9a9 100644 >> --- a/arch/arm/common/sa.c >> +++ b/arch/arm/common/sa.c >> @@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev) >> >> /* >> * Ensure that the SA is still here. >> - * FIXME: shouldn't do this here. >> */ >> -id = sa_readl(sachip->base + SA_SKID); >> if ((id & SKID_ID_MASK) != SKID_SA_ID) { >> __sa_remove(sachip); >> platform_set_drvdata(dev, NULL); >> > > Thanks for the reply Randy. I was wondering if was what the FIX ME meant if it meant something else please let me known. Sorry, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: vf610: Add SNVS node
On Fri, Sep 26, 2014 at 06:44:00PM +0530, Sanchayan Maity wrote: > This adds a devicetree node for RTC support > for the VF610 platform. > > Signed-off-by: Sanchayan Maity > --- > arch/arm/boot/dts/vf610.dtsi | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi > index 4d2ec32..3c0c757 100644 > --- a/arch/arm/boot/dts/vf610.dtsi > +++ b/arch/arm/boot/dts/vf610.dtsi > @@ -381,6 +381,21 @@ > <&clks VF610_CLK_DMAMUX3>; > }; > > + snvs0: snvs@400a7000 { > + compatible = "fsl,sec-v4.0-mon", "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x400a7000 0x2000>; > + > + snvs-rtc-lp@34 { > + compatible = "fsl,sec-v4.0-mon-rtc-lp"; > + reg = <0x34 0x58>; > + interrupts = <0 100 > IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&clks VF610_CLK_SNVS>; > + clock-names = "snvs"; The name should describe the clock usage inside the block, so "snvs" is not a good description. Shawn > + }; > + }; > + > uart4: serial@400a9000 { > compatible = "fsl,vf610-lpuart"; > reg = <0x400a9000 0x1000>; > -- > 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 3/3] drivers/rtc/rtc-snvs: Add clock support
On Fri, Sep 26, 2014 at 06:44:01PM +0530, Sanchayan Maity wrote: > This patch adds clock enable and disable support > for the SNVS peripheral which is required by the > SNVS RTC. > > Signed-off-by: Sanchayan Maity > --- > drivers/rtc/rtc-snvs.c | 48 > +++- > 1 file changed, 39 insertions(+), 9 deletions(-) > > diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c > index fa384fe..f3e8f05 100644 > --- a/drivers/rtc/rtc-snvs.c > +++ b/drivers/rtc/rtc-snvs.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > > /* These register offsets are relative to LP (Low Power) range */ > #define SNVS_LPCR0x04 > @@ -39,6 +40,7 @@ struct snvs_rtc_data { > void __iomem *ioaddr; > int irq; > spinlock_t lock; > + struct clk *clk; > }; > > static u32 rtc_read_lp_counter(void __iomem *ioaddr) > @@ -260,8 +262,31 @@ static int snvs_rtc_probe(struct platform_device *pdev) > if (data->irq < 0) > return data->irq; > > + ret = devm_request_irq(&pdev->dev, data->irq, snvs_rtc_irq_handler, > +IRQF_SHARED, "rtc alarm", &pdev->dev); > + if (ret) { > + dev_err(&pdev->dev, "failed to request irq %d: %d\n", > + data->irq, ret); > + return ret; > + } > + > + data->clk = devm_clk_get(&pdev->dev, "snvs"); > + if (IS_ERR(data->clk)) { > + dev_err(&pdev->dev, "failed getting clock, err = %ld\n", > + PTR_ERR(data->clk)); > + ret = PTR_ERR(data->clk); > + return ret; > + } No. This will break all i.MX6 devices running a DTB without clock definition. Shawn > + > platform_set_drvdata(pdev, data); > > + ret = clk_prepare_enable(data->clk); > + if (ret) { > + dev_err(&pdev->dev, > + "Could not prepare or enable the snvs clock\n"); > + return ret; > + } > + > spin_lock_init(&data->lock); > > /* Initialize glitch detect */ > @@ -275,23 +300,20 @@ static int snvs_rtc_probe(struct platform_device *pdev) > > device_init_wakeup(&pdev->dev, true); > > - ret = devm_request_irq(&pdev->dev, data->irq, snvs_rtc_irq_handler, > -IRQF_SHARED, "rtc alarm", &pdev->dev); > - if (ret) { > - dev_err(&pdev->dev, "failed to request irq %d: %d\n", > - data->irq, ret); > - return ret; > - } > - > data->rtc = devm_rtc_device_register(&pdev->dev, pdev->name, > &snvs_rtc_ops, THIS_MODULE); > if (IS_ERR(data->rtc)) { > ret = PTR_ERR(data->rtc); > dev_err(&pdev->dev, "failed to register rtc: %d\n", ret); > - return ret; > + goto error_rtc_device_register; > } > > return 0; > + > +error_rtc_device_register: > + clk_disable_unprepare(data->clk); > + > + return ret; > } > > #ifdef CONFIG_PM_SLEEP > @@ -302,16 +324,24 @@ static int snvs_rtc_suspend(struct device *dev) > if (device_may_wakeup(dev)) > enable_irq_wake(data->irq); > > + clk_disable_unprepare(data->clk); > + > return 0; > } > > static int snvs_rtc_resume(struct device *dev) > { > + int ret; > + > struct snvs_rtc_data *data = dev_get_drvdata(dev); > > if (device_may_wakeup(dev)) > disable_irq_wake(data->irq); > > + ret = clk_prepare_enable(data->clk); > + if (ret) > + return ret; > + > return 0; > } > #endif > -- > 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] i2c designware add support of I2C standard mode
On Sat, 20 Sep 2014, Wolfram Sang wrote: > On Wed, Aug 20, 2014 at 04:29:08PM +0200, Romain Baeriswyl wrote: > > From: Romain Baeriswyl > > > > Some legacy devices support ony I2C standard mode at 100kHz. > > This patch allows to select the standard mode through the DTS > > with the use of the existing clock-frequency parameter. > > > > When clock-frequency parameter is not set, the fast mode is selected. > > Only when the parameter is set at 10, the standard mode is selected. > > > > Signed-off-by: Romain Baeriswyl > > Reviewed-by: Christian Ruppert > > Applied to for-next, thanks to all involved! > > I don't see this in git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git Is this in i2c/i2c/for-next? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, MCE: support raising machine check poll for software MCE injection in IRQ context
On Tue, 2014-08-12 at 20:45 +0800, Chen Yucong wrote: > At present MCJ_NMI_BROADCAST(same for raise_local) supports both > raise_exception() > and raise_poll(), but MCJ_IRQ_BROADCAST only supports raise_exception(). The > goal > of this patch is that MCJ_IRQ_BROADCAST can support raising machine check > poll. > > Signed-off-by: Chen Yucong > --- > arch/x86/kernel/cpu/mcheck/mce-inject.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/cpu/mcheck/mce-inject.c > b/arch/x86/kernel/cpu/mcheck/mce-inject.c > index 5ac2d1f..97e4f7a 100644 > --- a/arch/x86/kernel/cpu/mcheck/mce-inject.c > +++ b/arch/x86/kernel/cpu/mcheck/mce-inject.c > @@ -99,11 +99,13 @@ static void mce_irq_ipi(void *info) > int cpu = smp_processor_id(); > struct mce *m = &__get_cpu_var(injectm); > > - if (cpumask_test_cpu(cpu, mce_inject_cpumask) && > - m->inject_flags & MCJ_EXCEPTION) { > - cpumask_clear_cpu(cpu, mce_inject_cpumask); > + if (!cpumask_test_cpu(cpu, mce_inject_cpumask)) > + return; > + cpumask_clear_cpu(cpu, mce_inject_cpumask); > + if (m->inject_flags & MCJ_EXCEPTION) > raise_exception(m, NULL); > - } > + else if (m->status) > + raise_poll(m); > } > > /* Inject mce on current CPU */ Hi Chen Gong, Can you review the above patch? thx! cyc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regmap: debugfs: fix possbile NULL pointer dereference
If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer dereference. So before dev_name(), we need to have check of the map->dev pionter. We also should make sure that the 'name' pointer shouldn't be NULL for debugfs_create_dir(). So here using one default "dummy" debugfs name when the 'name' pointer and 'map->dev' are both NULL. Signed-off-by: Xiubo Li --- drivers/base/regmap/regmap-debugfs.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c index 0c94b66..5799a0b 100644 --- a/drivers/base/regmap/regmap-debugfs.c +++ b/drivers/base/regmap/regmap-debugfs.c @@ -473,6 +473,7 @@ void regmap_debugfs_init(struct regmap *map, const char *name) { struct rb_node *next; struct regmap_range_node *range_node; + const char *devname = "dummy"; /* If we don't have the debugfs root yet, postpone init */ if (!regmap_debugfs_root) { @@ -491,12 +492,15 @@ void regmap_debugfs_init(struct regmap *map, const char *name) INIT_LIST_HEAD(&map->debugfs_off_cache); mutex_init(&map->cache_lock); + if (map->dev) + devname = dev_name(map->dev); + if (name) { map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s", - dev_name(map->dev), name); + devname, name); name = map->debugfs_name; } else { - name = dev_name(map->dev); + name = devname; } map->debugfs = debugfs_create_dir(name, regmap_debugfs_root); -- 2.1.0.27.g96db324 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: Remove read of issue in sa1111.c in sa1111_resume
On 09/27/14 19:50, Nicholas Krause wrote: > This removes the FIXME message and issue with reading in this driver before > resuming > in the function, sa_resume. You need to explain why this makes any sense. Hint: it doesn't. > Signed-off-by: Nicholas Krause > --- > arch/arm/common/sa.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c > index e57d7e5..0c4b9a9 100644 > --- a/arch/arm/common/sa.c > +++ b/arch/arm/common/sa.c > @@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev) > > /* >* Ensure that the SA is still here. > - * FIXME: shouldn't do this here. >*/ > - id = sa_readl(sachip->base + SA_SKID); > if ((id & SKID_ID_MASK) != SKID_SA_ID) { > __sa_remove(sachip); > platform_set_drvdata(dev, NULL); > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] SPI: spi-pxa2xx: SPI support for Intel Quark X1000
> > > > > > +/* see Quark SPI data sheet for implementation rationale */ static > > > +u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) { > > > > Please document this in the driver - I don't know if this datasheet is > > public but even if it is it may not stay that way. > > Datasheet is public. > I'm just wondering if we can use just a formula instead of table. > As I said before, there are two formulas, but for the given rate, from the formulas, we can get a lot of pairs, and we also need to select them according to the guidelines which is not formula. The table the datasheet given should be the best one to meet the jitter and duty cycles as the datasheet documented.
Re: [PATCH 0/9] ARM: vf610: Suspend/resume support
On Mon, Sep 22, 2014 at 07:09:21PM +0200, Stefan Agner wrote: > This patchset provides suspend/resume support for Freescale Vybrid > SoC (vf610). The code is generally aligned to the implementation > for i.MX6. The subsystems SRC and GPC need some changes to support > the Vybrid specific implementation. > > This patchset relies on GPIO driver to be present (in order to > provide a wakeup source) as well as using the ARM Global Timer > clock source (the Vybrid specifc PIT clock source, vf_pit_timer.c > does not support shutdown). > > The implemented sleep states (LP-RUN and STOP), are not the most > power saving functions available on Vybrid. Especially for > suspend-to-memory one of the LPSTOP modes looks more appropriate. > However, the complexity is somewhat higher (we would need to move > execution path to SRAM and store IOMUX and DDRMC configuration). > Currently, I have not the resources to look into that so I hope > that this initial code qualifies as power saving functions to be > applied. So you have quite a lot of unnecessary code which is only needed by suspend from SRAM (store IOMUX and DDRMC configuration). Not happy with that. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] SPI: spi-pxa2xx: SPI support for Intel Quark X1000
> > > +static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data > > +*drv_data) { > > + if (!is_quark_x1000_ssp(drv_data)) > > + return SSCR1_CHANGE_MASK; > > + > > + return QUARK_X1000_SSCR1_CHANGE_MASK; } > > These functions would be much better written as switch statements - think > how they're going to look when we've got another controller which needs > custom values. It might also be helpful for review to have two patches, one > splitting things out into the functions and another adding the Quark support. > OK. Let me use switch. BTW, for two patches, actually, using helpers is due to we support quark. Do you mean the first patch just introduce helpers, maybe it only support one type, then another patch to add quark supporting. Am I right? > > +/* see Quark SPI data sheet for implementation rationale */ static > > +u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) { > > Please document this in the driver - I don't know if this datasheet is public > but > even if it is it may not stay that way. OK. I will document it. > > > @@ -613,6 +759,8 @@ static void pump_transfers(unsigned long data) > > u32 cr1; > > u32 dma_thresh = drv_data->cur_chip->dma_threshold; > > u32 dma_burst = drv_data->cur_chip->dma_burst_size; > > + u32 change_mask = pxa2xx_spi_get_ssrc1_change_mask(drv_data); > > + > > > > Extra blank line being added here. > I will remove it. > > @@ -145,6 +147,9 @@ static inline int pxa25x_ssp_comp(struct driver_data > *drv_data) > > return 1; > > if (drv_data->ssp_type == CE4100_SSP) > > return 1; > > + if (drv_data->ssp_type == QUARK_X1000_SSP) > > + return 1; > > + > > return 0; > > } > > Things like this should also be refactored into switch statements - in general > anything that's deciding what to do based on ssp_type probably ought to be > using switch statements. OK. I will use switch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
Thanks for your review. :) > -Original Message- > From: Kumar Gala [mailto:ga...@codeaurora.org] > Sent: Friday, September 26, 2014 10:04 PM > To: Wang Dongsheng-B40534 > Cc: Santosh Shilimkar; Sandeep Nair; Olof Johansson; shawn@linaro.org; > Greg > KH; Paul Walmsley; Arnd Bergmann; linux-kernel@vger.kernel.org; Guo > Shawn-R65073 > Subject: Re: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform > > > On Sep 26, 2014, at 1:48 AM, Dongsheng Wang > wrote: > > > From: Wang Dongsheng > > > > Only Ftm0 can be used when system going to deep sleep. So this driver > > to support ftm0 as a wakeup source. > > > > Signed-off-by: Wang Dongsheng > > How does this differ from drivers/clocksource/fsl_ftm_timer.c Fsl_ftm_timer.c is only for system to provide a clock driver. FTM ip-block can be used by other functions such as PWM. I think we should not put all of functions into a .c file. So ftm0 alarm function as a specific block driver in SOC dir. > > Why not extend that with the alarm functionality you need? The framework of clocksource not provide sys interface to set alarm. And codes of ftm0-alarm not touch on clocksource framework. > > Also, where is the DT binding spec for this (if you plan on having a separate > driver)? Yes, now only a driver. My DT depend on LS1 device tree patches, now LS1 DT is upstreaming but not apply. After LS1 DT apply, I will add ftm alarm device node. Regards, -Dongsheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crude Oil Exploration
Good day, I have an oil exportation proposition contract for you.If you don't mind, reply my email for full details of contract proposal. Sincerely, Adel Salman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm: Remove read of issue in sa1111.c in sa1111_resume
This removes the FIXME message and issue with reading in this driver before resuming in the function, sa_resume. Signed-off-by: Nicholas Krause --- arch/arm/common/sa.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c index e57d7e5..0c4b9a9 100644 --- a/arch/arm/common/sa.c +++ b/arch/arm/common/sa.c @@ -950,9 +950,7 @@ static int sa_resume(struct platform_device *dev) /* * Ensure that the SA is still here. -* FIXME: shouldn't do this here. */ - id = sa_readl(sachip->base + SA_SKID); if ((id & SKID_ID_MASK) != SKID_SA_ID) { __sa_remove(sachip); platform_set_drvdata(dev, NULL); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Legacy Code in gpmc-onenand.c
On Sat, Sep 27, 2014 at 10:37:02PM -0400, nick wrote: > Greetings Kevin and others, > I am wondering if the below code is legacy I can remove it as stated it the > fix me. > Cheers Nick Nick, could you take that to more appropriate forum? alt.sex.fetish.FIXME would probably be a good starting point... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clocksource: Add BE APIs support for clocksource counter reading.
Hi, > Subject: Re: [PATCH v2] clocksource: Add BE APIs support for clocksource > counter reading. > > On Fri, 26 Sep 2014, Xiubo Li wrote: > > For now I just added _be() support using ioread{16,32}be. > > And i have a check of the clocksource drivers, didn't find anyone > > using LE mode on one BE SoC, so _le() APIs is not needed. > > Nonsense. The existing clocksource_mmio accessor function are > providing LE access independent of the CPU endianess. So we don't need > an _le() API simply because we have it already. > > > cycle_t clocksource_mmio_readl_up(struct clocksource *c) > > { > > - return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg); > > + return (cycle_t)ioread32(to_mmio_clksrc(c)->reg); > > And how exactly is this change related to adding BE support? > Actually not very much, since the _be() APIs are using ioread{16,32}be(), so I think using ioread{16,32}() will be less odd to having two different accessors here. Wouldn't this be more unified somehow ? Thanks very much, BRs Xiubo > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Legacy Code in gpmc-onenand.c
Greetings Kevin and others, I am wondering if the below code is legacy I can remove it as stated it the fix me. Cheers Nick else { /* * FIX ME: Appears to be legacy code from initial ONENAND commit. * Unclear what boards this is for and if this can be removed. */ if (!cpu_is_omap34xx()) onenand_sync.wait_on_read = true; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map, >> compose MSI msg ..., in different platform, many arch specific MSI irq >> details in it. >> It's difficult to extract the common data and code. >> >> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, >> currently, >> HPET, DMAR and PCI have their own irq_chip and MSI related functions, >> write_msi_msg(), >> mask_msi_irq(), etc... I want to extract the common data set for that, so we >> can >> remove lots of unnecessary MSI code. > > That makes sense. Can you please make sure that this does not conflict > with the ongoing work Jiang is doing in the x86 irq area with > hierarchical irqdomains to distangle layered levels like MSI from the > underlying vector/irqremap mechanics. Yes, I'm reviewing Jiang hierarchical irqdomains series, I'm interested in that changes. Thanks! Yijing. > > Thanks, > > tglx > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
> -Original Message- > From: Linuxppc-dev > [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On > Behalf Of Mike Turquette > Sent: Saturday, September 27, 2014 7:29 AM > To: Wood Scott-B07421 > Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083 > Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add > CLK_OF_DECLARE support > > Quoting Scott Wood (2014-09-25 15:56:20) > > On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote: > > > Quoting Scott Wood (2014-09-25 13:08:00) > > > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made > > > > to work on PPC rather than have the driver carry around two > > > > binding methods. > > > > > > I guess that is an existing problem, and not related directly to > > > this patch? This patch is essentially just renames (though the > > > V1.0/V2.0 stuff seems weird). > > > > This patch is adding CLK_OF_DECLARE. > > I'm fine taking this patch but your comments are still unresolved. What do you > think needs to be done to fix the problems that you see? > CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch. Regarding V1.0 and V2.0, it is not wired just same for now. But we are not sure if it is same for v3.0 in the future. Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I am not comfortable with: This patch uses " fixed-clock" as sysclk's compatible string, while on PPC we treated it as " fsl,qoriq-sysclk-[1-2].0". That's inconsistent on both ARM and PPC platforms, neither did on bindings. Thanks, Yuantian > Regards, > Mike > > > > > -Scott > > > > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On 2014/9/26 17:05, Thierry Reding wrote: > On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote: > [...] >> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus() >> directly (patch attached). > > Really attached this time. > > Thierry > It looks good to me, so I will update the arm pci hostbridge driver to assign pci root bus the msi chip instead of current pcibios_add_bus(). But for other platforms which only have a one msi chip, I will kept the arch_find_msi_chip() temporarily for more comments, especially from Bjorn. Thanks! Yijing. -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] block: Add support for Sony SxS cards
On 2014-09-27 17:43, Kieran Kunhya wrote: +static void sxs_memcpy_read(struct sxs_device *dev, unsigned long sector, + unsigned long nsect, char *buffer) +{ + struct pci_dev *pdev = dev->pci_dev; + u32 status; + u32 data[4]; + u16 *tmp; + u32 *tmp2; + + void *dma2; + dma_addr_t dma2_handle; + void *dma3; + dma_addr_t dma3_handle; + + sector >>= dev->sector_shift; + nsect >>= dev->sector_shift; + + /* Read */ + dma2 = pci_alloc_consistent(pdev, 8192, &dma2_handle); + dma3 = pci_alloc_consistent(pdev, 8192, &dma3_handle); + + tmp = dma2; + tmp2 = dma3; + tmp2[0] = dma2_handle; + tmp2[2] = dma3_handle; + + dev_dbg_ratelimited(&pdev->dev, "CALL %lu %lu\n", + sector & 0x, nsect & 0x); + + reinit_completion(&dev->irq_response); + status = readl(dev->mmio+SXS_STATUS_REG); + data[0] = cpu_to_le32(0x00010028); + data[1] = cpu_to_le32(sector & 0x); + data[2] = 0x0; + data[3] = cpu_to_le32(nsect & 0x); + memcpy_toio(dev->mmio, data, sizeof(data)); + writel(0xa0, dev->mmio+SXS_ENABLE_REG); + writel(0x80, dev->mmio+SXS_CONTROL_REG); + + if (!wait_for_completion_timeout(&dev->irq_response, +msecs_to_jiffies(5000))) { + dev_dbg(&pdev->dev, "No IRQ\n"); + } + + reinit_completion(&dev->irq_response); + writel(dma3_handle, dev->mmio+SXS_MASTER_LINK_REG_L); + writel(0x0, dev->mmio+SXS_MASTER_LINK_REG_H); + writel(0x20, dev->mmio+SXS_CONTROL_REG); + + if (!wait_for_completion_timeout(&dev->irq_response, +msecs_to_jiffies(5000))) { + dev_dbg(&pdev->dev, "No IRQ\n"); + } + + /* FIXME: Use DMA properly */ + memcpy(buffer, dma2, dev->sector_size * nsect); + + dev_dbg_ratelimited(&pdev->dev, "boot-signature %x\n", + tmp[255]); + + writel(0, dev->mmio+SXS_ENABLE_REG); + + pci_free_consistent(pdev, 8192, dma3, dma3_handle); + pci_free_consistent(pdev, 8192, dma2, dma2_handle); +} + +static void sxs_request(struct request_queue *q, struct bio *bio) +{ + struct bvec_iter iter; + struct bio_vec bvec; + char *buffer; + unsigned long flags; + struct sxs_device *dev = q->queuedata; + struct pci_dev *pdev = dev->pci_dev; + sector_t sector = bio->bi_iter.bi_sector; + + bio_for_each_segment(bvec, bio, iter) { + dev_dbg_ratelimited(&pdev->dev, "REQUEST %i %i %i\n", + bio_cur_bytes(bio), bio->bi_vcnt, + bvec.bv_len); + buffer = bvec_kmap_irq(&bvec, &flags); + sxs_memcpy_read(dev, sector, bio_cur_bytes(bio) >> 9, + buffer); + sector += bio_cur_bytes(bio) >> 9; + bvec_kunmap_irq(buffer, &flags); + } + + bio_endio(bio, 0); So a few questions here... This device only does reads? And it seems to be assuming that only reads end up in the request handler? How so? Second question. IO never fails? There's no status checking and IO is always ended successfully. This too seems odd. Third, this wong work as-is, at least not of HIGHMEM is used. After the bvec_kmap_irq(), irqs will be disabled. But your sxs_memcpy_read() invokes schedule through the completion waits, that will instantly go bad. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/2] regulator: get voltage & duty table from dts for pwm-regulator
get voltage & duty table from device tree might be better, other platforms can also use this driver without any modify. Tested on a rk3288 sdk board as logic voltage regulator. Changes in v7: Adviced by Mark Brown - re-edit changelog - re-edit changelog Changes in v6: Adviced by Mark Rutland - fix a spelling error Changes in v4: Adviced by Doug Anderson - improve kconfig - add const for desc structure Adviced by Doug Anderson - remove regulator-always-on and regulator-boot-on from the Example Changes in v3: Adviced by Doug Anderson - Make Kconfig & Makefile alphabetical - remove pwm_reg_period from pwm_regulator_data - modify the calculation in pwm_regulator_set_voltage_sel - add length validity check Adviced by Doug Anderson - update the Example Changes in v2: Adviced by Lee Jones - rename the file - remove all the prefix st_ - add depend on PWM in Kconfig Adviced by Lee Jones - rename the documentation Adviced by Doug Anderson - update the example Adviced by Mark Rutland - remove pwm-reg-period Chris Zhong (2): regulator: pwm-regulator: get voltage and duty table from dts dt-bindings: add devicetree bindings for pwm regulator .../bindings/regulator/pwm-regulator.txt | 27 drivers/regulator/Kconfig | 13 +- drivers/regulator/Makefile |2 +- drivers/regulator/{st-pwm.c => pwm-regulator.c}| 147 ++-- 4 files changed, 112 insertions(+), 77 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/pwm-regulator.txt rename drivers/regulator/{st-pwm.c => pwm-regulator.c} (44%) -- 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 v7 2/2] dt-bindings: add devicetree bindings for pwm regulator
Document the pwm regulator Signed-off-by: Chris Zhong Reviewed-by: Doug Anderson --- Changes in v7: - re-edit changelog Changes in v6: Adviced by Mark Rutland - fix a spelling error Changes in v4: Adviced by Doug Anderson - remove regulator-always-on and regulator-boot-on from the Example Changes in v3: Adviced by Doug Anderson - update the Example Changes in v2: Adviced by Lee Jones - rename the documentation Adviced by Doug Anderson - update the example Adviced by Mark Rutland - remove pwm-reg-period .../bindings/regulator/pwm-regulator.txt | 27 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/pwm-regulator.txt diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt new file mode 100644 index 000..ce91f61 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt @@ -0,0 +1,27 @@ +pwm regulator bindings + +Required properties: +- compatible: Should be "pwm-regulator" +- pwms: OF device-tree PWM specification (see PWM binding pwm.txt) +- voltage-table: voltage and duty table, include 2 members in each set of + brackets, first one is voltage(unit: uv), the next is duty(unit: percent) + +Any property defined as part of the core regulator binding defined in +regulator.txt can also be used. + +Example: + pwm_regulator { + compatible = "pwm-regulator; + pwms = <&pwm1 0 8448 0>; + + voltage-table = <1114000 0>, + <1095000 10>, + <1076000 20>, + <1056000 30>, + <1036000 40>, + <1016000 50>; + + regulator-min-microvolt = <1016000>; + regulator-max-microvolt = <1114000>; + regulator-name = "vdd_logic"; + }; -- 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 v7 1/2] regulator: pwm-regulator: get voltage and duty table from dts
rename st-pwm to pwm-regulator. And support getting voltage & duty table from device tree, other platforms can also use this driver without any modify. Signed-off-by: Chris Zhong Reviewed-by: Doug Anderson Tested-by: Doug Anderson --- Changes in v7: Adviced by Mark Brown - re-edit changelog Changes in v6: None Changes in v4: Adviced by Doug Anderson - improve kconfig - add const for desc structure Changes in v3: Adviced by Doug Anderson - Make Kconfig & Makefile alphabetical - remove pwm_reg_period from pwm_regulator_data - modify the calculation in pwm_regulator_set_voltage_sel - add length validity check Changes in v2: Adviced by Lee Jones - rename the file - remove all the prefix st_ - add depend on PWM in Kconfig drivers/regulator/Kconfig | 13 +- drivers/regulator/Makefile |2 +- drivers/regulator/{st-pwm.c => pwm-regulator.c} | 147 --- 3 files changed, 85 insertions(+), 77 deletions(-) rename drivers/regulator/{st-pwm.c => pwm-regulator.c} (44%) diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index fb32bab..b927cab 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -449,6 +449,13 @@ config REGULATOR_PFUZE100 Say y here to support the regulators found on the Freescale PFUZE100/PFUZE200 PMIC. +config REGULATOR_PWM + tristate "PWM voltage regulator" + depends on PWM + help + This driver supports PWM controlled voltage regulators. PWM + duty cycle can increase or decrease the voltage. + config REGULATOR_RC5T583 tristate "RICOH RC5T583 Power regulators" depends on MFD_RC5T583 @@ -493,12 +500,6 @@ config REGULATOR_S5M8767 via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and supports DVS mode with 8bits of output voltage control. -config REGULATOR_ST_PWM - tristate "STMicroelectronics PWM voltage regulator" - depends on ARCH_STI - help -This driver supports ST's PWM controlled voltage regulators. - config REGULATOR_TI_ABB tristate "TI Adaptive Body Bias on-chip LDO" depends on ARCH_OMAP diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 236fdbb..f3cf5a5 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -57,6 +57,7 @@ obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o +obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o @@ -66,7 +67,6 @@ obj-$(CONFIG_REGULATOR_RK808) += rk808-regulator.o obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o -obj-$(CONFIG_REGULATOR_ST_PWM) += st-pwm.o obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o diff --git a/drivers/regulator/st-pwm.c b/drivers/regulator/pwm-regulator.c similarity index 44% rename from drivers/regulator/st-pwm.c rename to drivers/regulator/pwm-regulator.c index 5ea78df..d3f55ea 100644 --- a/drivers/regulator/st-pwm.c +++ b/drivers/regulator/pwm-regulator.c @@ -1,5 +1,5 @@ /* - * Regulator driver for ST's PWM Regulators + * Regulator driver for PWM Regulators * * Copyright (C) 2014 - STMicroelectronics Inc. * @@ -20,43 +20,40 @@ #include #include -#define ST_PWM_REG_PERIOD 8448 - -struct st_pwm_regulator_pdata { - const struct regulator_desc *desc; - struct st_pwm_voltages *duty_cycle_table; -}; - -struct st_pwm_regulator_data { - const struct st_pwm_regulator_pdata *pdata; +struct pwm_regulator_data { + struct regulator_desc desc; + struct pwm_voltages *duty_cycle_table; struct pwm_device *pwm; bool enabled; int state; }; -struct st_pwm_voltages { +struct pwm_voltages { unsigned int uV; unsigned int dutycycle; }; -static int st_pwm_regulator_get_voltage_sel(struct regulator_dev *dev) +static int pwm_regulator_get_voltage_sel(struct regulator_dev *dev) { - struct st_pwm_regulator_data *drvdata = rdev_get_drvdata(dev); + struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev); return drvdata->state; } -static int st_pwm_regulator_set_voltage_sel(struct regulator_dev *dev, - unsigned selector) +static int pwm_regulator_set_voltage_sel(struct regulator_dev *dev, +unsigned selector) { - struct st_pwm_regulator_data *drvdata = rdev_get_drvdata(dev); + struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev)
SKB Documentation Ideas and How to Write Docs for Kernel
Hello to the maintainers of the file,skb.c , I am wondering about making it easier for new developers including myself by writing a file in the docs on networking related to skb_buff and it's various methods of use to developing in the kernel's various networking subsystems. If one of the maintainers would like to help give me feedback on my writing of these docs this would be helpful and make it easier for everyone as from my experience skb_buff is one of the most asked about things in the networking lists and would allow people more thing for other work, including the maintainers of lots of the networking code. I understand you guys are very busy so feel free to respond whenever you get free time during the next few weeks. Thanks Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
What I would like to see is a way of creating the pci_host_bridge structure outside the pci_create_root_bus(). That would then allow us to pass this sort of platform details like associated msi_chip into the host bridge and the child busses will have an easy way of finding the information needed by finding the root bus and then the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly) everyone and the drivers can remove their kludges that try to work around the current limitations. >> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate. > > Except that arch sysdata at the moment is an opaque pointer. I am all in > favour in > changing the type of sysdata from void* into pci_host_bridge* and arches can > wrap their old > sysdata around the pci_host_bridge*. I inspected every arch and found there are almost no common stuff, and generic data struct should be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more, almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn. Thanks! Yijing. > > Best regards, > Liviu > >> >>> >>> I think both issues are orthogonal. Last time I checked a lot of work >>> was still necessary to unify host bridges enough so that it could be >>> shared across architectures. But perhaps some of that work has >>> happened in the meantime. >>> >>> But like I said, when you create the root bus, you can easily attach the >>> MSI chip to it. >>> >>> Thierry >>> >> >> >> -- >> Thanks! >> Yijing >> >> > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] ARM: imx: clk-gate2: allow custom gate configuration
On Mon, Sep 22, 2014 at 07:09:29PM +0200, Stefan Agner wrote: > The 2-bit gates found i.MX and Vybrid SoC support different clock > configuration: > > 0b00: clk disabled > 0b01: clk enabled in RUN mode but disabled in WAIT and STOP mode > 0b10: clk enabled in RUN, WAIT and STOP mode (only Vybrid) > 0b11: clk enabled in RUN and WAIT mode > > For some clocks, we might want to configure different behaviour, > e.g. a memory clock should be on even in STOP mode. Add a new > function imx_clk_gate2_cgr which allow to configure specific > gate values through the cgr_val parameter. > > Signed-off-by: Stefan Agner > --- > arch/arm/mach-imx/clk-gate2.c | 7 +-- > arch/arm/mach-imx/clk-vf610.c | 3 +++ > arch/arm/mach-imx/clk.h | 13 ++--- > include/dt-bindings/clock/vf610-clock.h | 3 ++- The patch should be split into two, one for clk-gate2 and the other for clk-vf610 driver change. Other than that, the patch looks good to me. Shawn > 4 files changed, 20 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-imx/clk-gate2.c b/arch/arm/mach-imx/clk-gate2.c > index 84acdfd..8c22a84 100644 > --- a/arch/arm/mach-imx/clk-gate2.c > +++ b/arch/arm/mach-imx/clk-gate2.c > @@ -31,6 +31,7 @@ struct clk_gate2 { > struct clk_hw hw; > void __iomem*reg; > u8 bit_idx; > + u8 cgr_val; > u8 flags; > spinlock_t *lock; > unsigned int*share_count; > @@ -50,7 +51,8 @@ static int clk_gate2_enable(struct clk_hw *hw) > goto out; > > reg = readl(gate->reg); > - reg |= 3 << gate->bit_idx; > + reg &= ~(3 << gate->bit_idx); > + reg |= gate->cgr_val << gate->bit_idx; > writel(reg, gate->reg); > > out: > @@ -110,7 +112,7 @@ static struct clk_ops clk_gate2_ops = { > > struct clk *clk_register_gate2(struct device *dev, const char *name, > const char *parent_name, unsigned long flags, > - void __iomem *reg, u8 bit_idx, > + void __iomem *reg, u8 bit_idx, u8 cgr_val, > u8 clk_gate2_flags, spinlock_t *lock, > unsigned int *share_count) > { > @@ -125,6 +127,7 @@ struct clk *clk_register_gate2(struct device *dev, const > char *name, > /* struct clk_gate2 assignments */ > gate->reg = reg; > gate->bit_idx = bit_idx; > + gate->cgr_val = cgr_val; > gate->flags = clk_gate2_flags; > gate->lock = lock; > > diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c > index a178184..1034e78 100644 > --- a/arch/arm/mach-imx/clk-vf610.c > +++ b/arch/arm/mach-imx/clk-vf610.c > @@ -103,6 +103,7 @@ static struct clk_onecell_data clk_data; > static unsigned int const clks_init_on[] __initconst = { > VF610_CLK_SYS_BUS, > VF610_CLK_DDR_SEL, > + VF610_CLK_DDRMC, > }; > > static void __init vf610_clocks_init(struct device_node *ccm_node) > @@ -171,6 +172,8 @@ static void __init vf610_clocks_init(struct device_node > *ccm_node) > clk[VF610_CLK_PLL4_MAIN_DIV] = clk_register_divider_table(NULL, > "pll4_main_div", "pll4_main", 0, CCM_CACRR, 6, 3, 0, pll4_main_div_table, > &imx_ccm_lock); > clk[VF610_CLK_PLL6_MAIN_DIV] = imx_clk_divider("pll6_main_div", > "pll6_main", CCM_CACRR, 21, 1); > > + clk[VF610_CLK_DDRMC] = imx_clk_gate2_cgr("ddrmc", "ddr_sel", CCM_CCGR6, > CCM_CCGRx_CGn(14), 0x2); > + > clk[VF610_CLK_USBPHY0] = imx_clk_gate("usbphy0", "pll3_main", > PLL3_CTRL, 6); > clk[VF610_CLK_USBPHY1] = imx_clk_gate("usbphy1", "pll7_main", > PLL7_CTRL, 6); > > diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h > index 4cdf8b6..d22e339 100644 > --- a/arch/arm/mach-imx/clk.h > +++ b/arch/arm/mach-imx/clk.h > @@ -29,7 +29,7 @@ struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const > char *name, > > struct clk *clk_register_gate2(struct device *dev, const char *name, > const char *parent_name, unsigned long flags, > - void __iomem *reg, u8 bit_idx, > + void __iomem *reg, u8 bit_idx, u8 cgr_val, > u8 clk_gate_flags, spinlock_t *lock, > unsigned int *share_count); > > @@ -43,7 +43,7 @@ static inline struct clk *imx_clk_gate2(const char *name, > const char *parent, > void __iomem *reg, u8 shift) > { > return clk_register_gate2(NULL, name, parent, CLK_SET_RATE_PARENT, reg, > - shift, 0, &imx_ccm_lock, NULL); > + shift, 0x3, 0, &imx_ccm_lock, NULL); > } > > static inline struct clk *imx_clk_gate2_shared(const char *name, > @@ -51,7 +51,14 @@ static inline struct clk *imx_clk_gate2_shared(const char > *name, > unsigned int *share_count) > { > return clk_register_gate2(NULL, name, parent, CLK_SET_RATE_PARENT, reg, > - shift, 0, &imx_ccm_lock, share_count); > + shift, 0x3, 0, &imx_ccm_lock, share_count);
[PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable Quad spi transfer by clear EVCR(Enhanced Volatile Configuration Register) Quad I/O protocol bit. Signed-off-by: bean huo --- v1-v2:modified to that capture wait_till_ready() return value,if error,directly return its the value. drivers/mtd/spi-nor/spi-nor.c | 46 + include/linux/mtd/spi-nor.h |6 ++ 2 files changed, 52 insertions(+) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index b5ad6be..0c3b4fd 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor) return 0; } +static int micron_quad_enable(struct spi_nor *nor) +{ + int ret, val; + + ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1); + if (ret < 0) { + dev_err(nor->dev, "error %d reading EVCR\n", ret); + return -EINVAL; + } + + write_enable(nor); + + /* set EVCR ,enable quad I/O */ + nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON; + ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0); + if (ret < 0) { + dev_err(nor->dev, + "error while writing EVCR register\n"); + return -EINVAL; + } + + ret = wait_till_ready(nor); + if (ret) + return ret; + + /* read EVCR and check it */ + ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1); + if (ret < 0) { + dev_err(nor->dev, "error %d reading EVCR\n", ret); + return -EINVAL; + } + if (val & EVCR_QUAD_EN_MICRON) { + dev_err(nor->dev, "Micron EVCR Quad bit not clear\n"); + return -EINVAL; + } + + return 0; +} + static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) { int status; @@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) return -EINVAL; } return status; + case CFI_MFR_ST: + status = micron_quad_enable(nor); + if (status) { + dev_err(nor->dev, "Micron quad-read not enabled\n"); + return -EINVAL; + } + return status; default: status = spansion_quad_enable(nor); if (status) { diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 9e6294f..d71b659 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -56,6 +56,10 @@ /* Used for Spansion flashes only. */ #define SPINOR_OP_BRWR 0x17/* Bank register write */ +/* Used for Micron flashes only. */ +#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */ +#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */ + /* Status Register bits. */ #define SR_WIP 1 /* Write in progress */ #define SR_WEL 2 /* Write enable latch */ @@ -67,6 +71,8 @@ #define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */ +#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */ + /* Flag Status Register bits */ #define FSR_READY 0x80 -- 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 1/2] MAINTAINERS: add atmel ssc driver maintainer entry
Signed-off-by: Bo Shen --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3705430..c004e6f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1703,6 +1703,13 @@ M: Nicolas Ferre S: Supported F: drivers/spi/spi-atmel.* +ATMEL SSC DRIVER +M: Bo Shen +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Supported +F: drivers/misc/atmel-ssc.c +F: include/linux/atmel-ssc.h + ATMEL Timer Counter (TC) AND CLOCKSOURCE DRIVERS M: Nicolas Ferre L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: add atmel audio alsa driver maintainer entry
Signed-off-by: Bo Shen --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c004e6f..30f92cf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1665,6 +1665,12 @@ M: Nicolas Ferre S: Supported F: drivers/tty/serial/atmel_serial.c +ATMEL Audio ALSA driver +M: Bo Shen +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +S: Supported +F: sound/soc/atmel + ATMEL DMA DRIVER M: Nicolas Ferre L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] unicore32: Remove unneeded Kconfig entry NO_IOPORT_MAP
Sorry for late reply. I checked this config, and it's only used for HAS_IOPORT_MAP in lib/Kconfig Sure, removing it means no different for .config file. I think a better way is reserving it or moving it into arch/Kconfig Cc: linux-a...@vger.kernel.org Xuetao Guan - Paul Bolle 写道: > Architectures only need a Kconfig entry for NO_IOPORT_MAP if it is > possible that its value will be 'y'. For unicore32 its value will always > be 'n', making it pointless. Remove it. > > Signed-off-by: Paul Bolle > --- > Tested by playing with arch/unicore32/configs/unicore32_defconfig. This > patch made no difference whatsoever to the generated .config file. > Please note that it has > CONFIG_HAS_IOPORT_MAP=y > > set after invoking "make oldconfig" both before and after this patch. > > arch/unicore32/Kconfig | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig > index 928237a7b9ca..2322cc87e7cb 100644 > --- a/arch/unicore32/Kconfig > +++ b/arch/unicore32/Kconfig > @@ -27,9 +27,6 @@ config UNICORE32 > config GENERIC_CSUM > def_bool y > > -config NO_IOPORT_MAP > - bool > - > config STACKTRACE_SUPPORT > def_bool y > > -- > 1.9.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/
RE: [PATCH resend] arm:extend the reserved memory for initrd to be page aligned
> -Original Message- > On Thu, Sep 25, 2014 at 03:31:42PM +0100, Russell King - ARM Linux wrote: > > On Fri, Sep 19, 2014 at 11:00:02AM +0100, Catalin Marinas wrote: > > > On Fri, Sep 19, 2014 at 08:09:47AM +0100, Wang, Yalin wrote: > > > > this patch extend the start and end address of initrd to be page > > > > aligned, so that we can free all memory including the un-page > > > > aligned head or tail page of initrd, if the start or end address > > > > of initrd are not page aligned, the page can't be freed by > free_initrd_mem() function. > > > > > > > > Signed-off-by: Yalin Wang > > > > > > Acked-by: Catalin Marinas > > > > > > (as I said, if Russell doesn't have any objections please send the > > > patch to his patch system) > > > > I now have an objection. The patches in the emails were properly > formatted. > > They were so close ;) > > I can see three patches but none of them exactly right: > > 8157/1 - wrong diff format > 8159/1 - correct format, does not have my ack (you can take this one if >you want) > 8162/1 - got my ack this time but with the wrong diff format again > > Maybe a pull request is a better idea. > I have resend the 2 patches: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8167/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8168/1 please have a look. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ASoC: rockchip-max98090: add documentation for rockchip-max98090 driver
在 09/12/2014 09:44 PM, Mark Brown 写道: > On Fri, Sep 12, 2014 at 03:30:36PM +0800, Jianqun wrote: >> Add documentation for rockchip-max98090 driver, which is need by rockchip >> board using a max98090. > > Can this use simple-card (perhaps after a bit of extension)? I haven't ever try simple-card, is there any sample usage for me from other vendor ? > >> +- rockchip,audio-codec : The phandle of the MAX98090 audio codec. > > Is the driver really specific to this CODEC? I think yes, we need to add two gpio for mic and hp detect, but simple-card driver hasn't them > >> + >> +Optional properties: >> +- rockchip,hp-det-gpios : The GPIO that detect headphones are plugged in >> +- rockchip,mic-det-gpios : The GPIO that detect micphones are plugged in >> + >> +Example: >> + >> +sound { >> +compatible = "rockchip,rockchip-audio-max98090"; >> +rockchip,model = "ROCKCHIP-I2S"; >> +rockchip,i2s-controller = <&i2s>; >> +rockchip,audio-codec = <&max98090>; >> +rockchip,hp-det-gpios = <&gpio6 5 GPIO_ACTIVE_HIGH>; >> +rockchip,mic-det-gpios = <&gpio6 11 GPIO_ACTIVE_HIGH>; >> +}; >> -- >> 1.9.1 >> >> >> -- Jianqun Xu *IMPORTANT NOTICE:*This email is from Fuzhou Rockchip Electronics Co., Ltd .The contents of this email and any attachments may contain information that is privileged, confidential and/or exempt from disclosure under applicable law and relevant NDA. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information is STRICTLY PROHIBITED. Please immediately contact the sender as soon as possible and destroy the material in its entirety in any format. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: fsl_ifc_nand: use devm_ functions consistently
+ linux-mtd FYI, I addressed a similar patch over here: http://lists.infradead.org/pipermail/linux-mtd/2014-September/055563.html I'm pretty sure this patch is wrong, and the semantic match is incorrect (or at least, it has false positives). Just because devm_* is used in some part of the driver doesn't mean that all allocations should be. Admittedly, this driver is not the best written (this patch drew my attention to at least one bug), but I just wanted to let y'all know. Regards, Brian On Sun, Aug 3, 2014 at 3:17 AM, Himangi Saraogi wrote: > Use devm_kzalloc for all calls to kzalloc and not just the first. Use > devm functions for other allocations as well. The calls to free the > allocated memory in the remove function are done away with. > > The semantic match that finds the inconsistency is as follows: > > // > @@ > @@ > > *devm_kzalloc(...) > ... > *kzalloc(...) > // > > Signed-off-by: Himangi Saraogi > Acked-by: Julia Lawall > --- > Not compile tested. > drivers/mtd/nand/fsl_ifc_nand.c | 17 ++--- > 1 file changed, 6 insertions(+), 11 deletions(-) > > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c > index 2338124..b403a77 100644 > --- a/drivers/mtd/nand/fsl_ifc_nand.c > +++ b/drivers/mtd/nand/fsl_ifc_nand.c > @@ -995,11 +995,6 @@ static int fsl_ifc_chip_remove(struct fsl_ifc_mtd *priv) > { > nand_release(&priv->mtd); > > - kfree(priv->mtd.name); > - > - if (priv->vbase) > - iounmap(priv->vbase); > - > ifc_nand_ctrl->chips[priv->bank] = NULL; > > return 0; > @@ -1062,7 +1057,8 @@ static int fsl_ifc_nand_probe(struct platform_device > *dev) > > mutex_lock(&fsl_ifc_nand_mutex); > if (!fsl_ifc_ctrl_dev->nand) { > - ifc_nand_ctrl = kzalloc(sizeof(*ifc_nand_ctrl), GFP_KERNEL); > + ifc_nand_ctrl = devm_kzalloc(&dev->dev, > sizeof(*ifc_nand_ctrl), > +GFP_KERNEL); > if (!ifc_nand_ctrl) { > mutex_unlock(&fsl_ifc_nand_mutex); > return -ENOMEM; > @@ -1085,7 +1081,7 @@ static int fsl_ifc_nand_probe(struct platform_device > *dev) > priv->ctrl = fsl_ifc_ctrl_dev; > priv->dev = &dev->dev; > > - priv->vbase = ioremap(res.start, resource_size(&res)); > + priv->vbase = devm_ioremap(&dev->dev, res.start, resource_size(&res)); > if (!priv->vbase) { > dev_err(priv->dev, "%s: failed to map chip region\n", > __func__); > ret = -ENOMEM; > @@ -1104,7 +1100,8 @@ static int fsl_ifc_nand_probe(struct platform_device > *dev) > IFC_NAND_EVTER_INTR_FTOERIR_EN | > IFC_NAND_EVTER_INTR_WPERIR_EN, > &ifc->ifc_nand.nand_evter_intr_en); > - priv->mtd.name = kasprintf(GFP_KERNEL, "%llx.flash", (u64)res.start); > + priv->mtd.name = devm_kasprintf(&dev->dev, GFP_KERNEL, "%llx.flash", > + (u64)res.start); > if (!priv->mtd.name) { > ret = -ENOMEM; > goto err; > @@ -1148,10 +1145,8 @@ static int fsl_ifc_nand_remove(struct platform_device > *dev) > > mutex_lock(&fsl_ifc_nand_mutex); > ifc_nand_ctrl->counter--; > - if (!ifc_nand_ctrl->counter) { > + if (!ifc_nand_ctrl->counter) > fsl_ifc_ctrl_dev->nand = NULL; > - kfree(ifc_nand_ctrl); > - } > mutex_unlock(&fsl_ifc_nand_mutex); > > return 0; > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove GFP_DMA and GFP_DMA32 from flags before passing it into kmalloc.
On Sat, Sep 27, 2014 at 11:13 PM, Catalin Marinas wrote: > On 27 Sep 2014, at 16:09, Miles MH Chen wrote: >> Signed-off-by: Min-Hua Chen >> --- >> arch/arm64/mm/dma-mapping.c |3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c >> index 4164c5a..273cf6d 100644 >> --- a/arch/arm64/mm/dma-mapping.c >> +++ b/arch/arm64/mm/dma-mapping.c >> @@ -103,7 +103,8 @@ static void *__dma_alloc_noncoherent(struct device *dev, >> size_t size, >> ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs); >> if (!ptr) >> goto no_mem; >> -map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA); >> +map = kmalloc(sizeof(struct page *) << order, >> +flags & ~(GFP_DMA | GFP_DMA32)); > > Do you have an explanation on why this is needed (and such explanation > should also be included in the commit log)? We don’t use ZONE_DMA32 on > arm64 (we did initially but it was for the wrong reasons). If GFP_DMA32 is passed to dma_alloc_coherent, the flag will go to kmalloc and trigger a BUG_ON check in slab allocator: __dma_alloc_noncoherent kmalloc new_slab BUG_ON(flags & GFP_SLAB_BUG_MASK); It can be avoided this by removing GFP_DMA32 before passing it to kmalloc or we should block GFP_DMA32 flag earlier in arch/arm64/dma-mapping.c if GFP_DMA32 is not allowed in arch/arm64/dma-mapping.c. Thanks, MH > > Thanks, > > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Thu, Sep 25, 2014 at 07:37:50PM -0500, Felipe Balbi wrote: > HI, > > On Fri, Sep 26, 2014 at 07:39:34AM +0800, Peter Chen wrote: > > On Thu, Sep 25, 2014 at 09:15:53AM -0500, Felipe Balbi wrote: > > > On Wed, Sep 24, 2014 at 02:23:38PM +0200, Arnd Bergmann wrote: > > > > On Wednesday 24 September 2014 19:29:05 Peter Chen wrote: > > > > > > > > > > So, it is IP CORE LIB (you suggest) vs IP CORE Platform Driver > > > > > (dwc3, musb, chipidea) you are talking about, right? Except for > > > > > creating another platform driver as well as related DT node > > > > > (optional), > > > > > are there any advantages compared to current IP core driver structure? > > > > > > > > Having a library module usually requires less code, and is more > > > > consistent with other drivers, which helps new developers understand > > > > what the driver is doing. > > > > > > I beg to differ. You end-up having to pass function pointers through > > > platform_data to handle differences which could be handled by the core > > > IP. > > > > > > > The most important aspect though is the DT binding: once the structure > > > > with separate kernel drivers leaks out into the DT format, you can't > > > > easily change the driver any more, e.g. to make a property that was > > > > introduced for one glue driver more general so it can get handled by > > > > the common part. Having a single node lets us convert to the library > > > > model later, so that would be a strong reason to keep the DT binding > > > > simple, without child nodes. > > > > > > > > Following that logic, it turns into another reason for using the library > > > > model to start with, because otherwise the child device does not have > > > > any DT properties itself and has to rely on the parent device > > > > properties, > > > > which somewhat complicates the driver structure. > > > > > > this is bullcrap. Take a look at > > > Documentation/devicetree/bindings/usb/dwc3.txt: > > > > > > synopsys DWC3 CORE > > > > > > DWC3- USB3 CONTROLLER > > > > > > Required properties: > > > - compatible: must be "snps,dwc3" > > > - reg : Address and length of the register set for the device > > > - interrupts: Interrupts used by the dwc3 controller. > > > > > > Optional properties: > > > - usb-phy : array of phandle for the PHY device. The first element > > >in the array is expected to be a handle to the USB2/HS PHY and > > >the second element is expected to be a handle to the USB3/SS PHY > > > - phys: from the *Generic PHY* bindings > > > - phy-names: from the *Generic PHY* bindings > > > - tx-fifo-resize: determines if the FIFO *has* to be reallocated. > > > > > > This is usually a subnode to DWC3 glue to which it is connected. > > > > > > dwc3@4a03 { > > > compatible = "snps,dwc3"; > > > reg = <0x4a03 0xcfff>; > > > interrupts = <0 92 4> > > > usb-phy = <&usb2_phy>, <&usb3,phy>; > > > tx-fifo-resize; > > > }; > > > > > > This contains all the attributes it needs to work. In fact, this could > > > be used without any glue. > > > > > > > If you want to add "vbus-supply" core node to support ID switch, what's > > the plan for that? > > send a patch ? Just make sure it's optional because not everybody needs > a vbus-supply. Also, DRD will still take a few merge windows to become a > reality. I don't want to merge something before considering it carefuly, > otherwise we will having which is broken and doesn't work for everybody > ;-) > > > Is it possible that the glue layer needs to access core register > > (eg, portsc.phcd during suspend)? The wrapper IP may wait some signals > > at core IP to change. > > why would a glue layer need to access registers from the core ? That > sounds very odd. I haven't seen that and will, definitely, NACK such a > patch :-) > > can you further describe why you think a glue layer might need to access > core IP's registers ? > My mistake, we can just wait core layer for finishing before doing PHY and wrapper operation. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] enhance DMA CMA on x86
2014-09-27 23:30 GMT+09:00 Peter Hurley : > On 04/15/2014 09:08 AM, Akinobu Mita wrote: >> This patch set enhances the DMA Contiguous Memory Allocator on x86. >> >> Currently the DMA CMA is only supported with pci-nommu dma_map_ops >> and furthermore it can't be enabled on x86_64. But I would like to >> allocate big contiguous memory with dma_alloc_coherent() and tell it >> to the device that requires it, regardless of which dma mapping >> implementation is actually used in the system. >> >> So this makes it work with swiotlb and intel-iommu dma_map_ops, too. >> And this also extends "cma=" kernel parameter to specify placement >> constraint by the physical address range of memory allocations. For >> example, CMA allocates memory below 4GB by "cma=64M@0-4G", it is >> required for the devices only supporting 32-bit addressing on 64-bit >> systems without iommu. >> >> * Changes from v2 >> - Rebased on current Linus tree >> - Add Acked-by line >> - Fix gfp flags check for __GFP_ATOMIC, reported by Marek Szyprowski >> - Avoid CMA area on highmem with cma= option, reported by Marek Szyprowski >> >> * Changes from v1 >> - fix dma_alloc_coherent() with __GFP_ZERO >> - add placement specifier for "cma=" kernel parameter >> >> Akinobu Mita (5): >> x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled >> x86: enable DMA CMA with swiotlb >> intel-iommu: integrate DMA CMA >> memblock: introduce memblock_alloc_range() >> cma: add placement specifier for "cma=" kernel parameter > > This patchset breaks every x86 iommu configuration when CONFIG_DMA_CMA is > on, which is the base configuration for Ubuntu x86 and amd64 distro kernels. > > Granted, the patchset leveraged existing code from the nommu configuration, > but that base (ie., calling dma_alloc_from_contiguous() in > dma_generic_alloc_config()) was an ill-conceived test configuration designed > to allow ARM developers to validate the CMA allocator on x86 boxen and > KVM guests, not as a general-purpose replacement for the existing page > allocator. The test code should have had a separate CONFIG_ knob. > > What this patchset does is restrict all iommu configurations which can > map all of system memory to one _very_ small physical region, thus disabling > the whole point of an iommu. > > Now I know why my GPU is causing paging to disk! And why my RAID controller > stalls for ages when I do a git log at the same time as a kernel build! The solution I have for this is that instead of trying to dma_alloc_from_contiguous() firstly, call alloc_pages() in dma_alloc_coherent(). dma_alloc_from_contiguous() should be called only when alloc_pages() is failed or DMA_ATTR_FORCE_CONTIGUOUS is specified in dma_attr. > And the apparent goal of this patchset is to enable DMA allocation below > 4GB, which is already supported in the existing page allocator with the > GFP_DMA32 flag?! The goal of this patchset is to enable huge DMA allocation which alloc_pages() can't (> MAX_ORDER) for the devices that require it. Thanks for the notification. I'll prepare a patch described above. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ktest doc: Automated test of linux kernel by using ktest v1.1.3
Hi, I revised ktest documentation. v1.1.2->v1.1.3: Support not only debian/jessy, but also CentOS7 as target system http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest It's not the ktest reference guild, but the quick learning guild of ktest especially focuses on some important features. After reading this document, you'll be able to do the following work automatically. - test all patches of your patchset, and - bisect to find the problematic commit I believe it saves plenty of your time. Feel free to ask me if you have any comments/questions. Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mtd: fsl_ifc_nand: Use devm_* throughout driver
Hi Aaron, Hmm, you're not the only one to send a patch like this. But I'm not sure if it's correct; this driver is written awkwardly. On Fri, Aug 15, 2014 at 07:46:44PM -0500, Aaron Sierra wrote: > For consistency, use managed resources for allocations and remaps > throughout the driver. > > Signed-off-by: Aaron Sierra > --- > drivers/mtd/nand/fsl_ifc_nand.c | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c > index 2338124..7861909 100644 > --- a/drivers/mtd/nand/fsl_ifc_nand.c > +++ b/drivers/mtd/nand/fsl_ifc_nand.c > @@ -997,9 +997,6 @@ static int fsl_ifc_chip_remove(struct fsl_ifc_mtd *priv) > > kfree(priv->mtd.name); > > - if (priv->vbase) > - iounmap(priv->vbase); > - > ifc_nand_ctrl->chips[priv->bank] = NULL; > > return 0; > @@ -1062,7 +1059,8 @@ static int fsl_ifc_nand_probe(struct platform_device > *dev) > > mutex_lock(&fsl_ifc_nand_mutex); > if (!fsl_ifc_ctrl_dev->nand) { > - ifc_nand_ctrl = kzalloc(sizeof(*ifc_nand_ctrl), GFP_KERNEL); > + ifc_nand_ctrl = devm_kzalloc(&dev->dev, > + sizeof(*ifc_nand_ctrl), GFP_KERNEL); This structure is static, and it looks like it's written with an attempt of sharing the same controller structure across potentially many instances of the device (multiple banks / chip selects?). And it has a refcount for freeing the struct, but that refcount is wrong (see below). > if (!ifc_nand_ctrl) { > mutex_unlock(&fsl_ifc_nand_mutex); > return -ENOMEM; > @@ -1085,7 +1083,7 @@ static int fsl_ifc_nand_probe(struct platform_device > *dev) > priv->ctrl = fsl_ifc_ctrl_dev; > priv->dev = &dev->dev; > > - priv->vbase = ioremap(res.start, resource_size(&res)); > + priv->vbase = devm_ioremap(priv->dev, res.start, resource_size(&res)); > if (!priv->vbase) { > dev_err(priv->dev, "%s: failed to map chip region\n", __func__); > ret = -ENOMEM; > @@ -1148,10 +1146,8 @@ static int fsl_ifc_nand_remove(struct platform_device > *dev) > > mutex_lock(&fsl_ifc_nand_mutex); > ifc_nand_ctrl->counter--; > - if (!ifc_nand_ctrl->counter) { > + if (!ifc_nand_ctrl->counter) Notice here, that there is an attempt at refcounting the ->nand structure. It is wrong (see how 'counter' is never incremented, only decremented). I don't know if anyone uses this driver in a "removed" context (e.g., rmmod or device unbinding), but this patch is potentially circumventing the (incorrect) refcounting, and instead will free the memory when it's possibly still used by another device. IMO, it's better to have a potential memory leak than a potential use-after-free, so I will not apply this patch. Feel free to provide an actual bugfix for this driver to fix the refcounting instead, though! Or work with the original authors/users to see if this driver actually needs all the global/static info that's being used here. Perhaps the driver could be refactored. > fsl_ifc_ctrl_dev->nand = NULL; > - kfree(ifc_nand_ctrl); > - } > mutex_unlock(&fsl_ifc_nand_mutex); > > return 0; BTW, I see that an earlier incarnation of this type of patch says it was based on an automated semantic patch. I'd suggest taking a hard look at the automated tools you're using, so you don't inadverently add more bugs while you're making "cleanups." Regards, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3] block: Add support for Sony SxS cards
Signed-off-by: Kieran Kunhya --- MAINTAINERS|5 + drivers/block/Kconfig |9 + drivers/block/Makefile |1 + drivers/block/sxs.c| 494 4 files changed, 509 insertions(+) create mode 100644 drivers/block/sxs.c diff --git a/MAINTAINERS b/MAINTAINERS index 3705430..f3a5231 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8539,6 +8539,11 @@ M: Maxim Levitsky S: Maintained F: drivers/memstick/core/ms_block.* +SONY SXS CARD SUPPORT +M: Kieran Kunhya +S: Maintained +F: drivers/block/sxs.c + SOUND M: Jaroslav Kysela M: Takashi Iwai diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 014a1cf..0b41ee0 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -356,6 +356,15 @@ config BLK_DEV_SX8 Use devices /dev/sx8/$N and /dev/sx8/$Np$M. +config BLK_DEV_SXS + tristate "Sony SxS card support" + depends on PCI + ---help--- + Saying Y or M here will enable support for reading + from Sony SxS cards. + + It creates a device called /dev/sxs + config BLK_DEV_RAM tristate "RAM block device support" ---help--- diff --git a/drivers/block/Makefile b/drivers/block/Makefile index 02b688d..59b9c79 100644 --- a/drivers/block/Makefile +++ b/drivers/block/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o obj-$(CONFIG_BLK_DEV_SX8) += sx8.o obj-$(CONFIG_BLK_DEV_HD) += hd.o +obj-$(CONFIG_BLK_DEV_SXS) += sxs.o obj-$(CONFIG_XEN_BLKDEV_FRONTEND) += xen-blkfront.o obj-$(CONFIG_XEN_BLKDEV_BACKEND) += xen-blkback/ diff --git a/drivers/block/sxs.c b/drivers/block/sxs.c new file mode 100644 index 000..a2da71d --- /dev/null +++ b/drivers/block/sxs.c @@ -0,0 +1,494 @@ +/* + * sxs.c: Driver for Sony SxS cards + * + * Copyright 2014 Kieran Kunhya + * + * Author/maintainer: Kieran Kunhya + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + +#define DRV_NAME "sxs" + +#define PCI_DEVICE_ID_SXS_81CE 0x81ce +#define PCI_DEVICE_ID_SXS_905C 0x905c + +#define SXS_MASTER_LINK_REG_L 0x10 +#define SXS_MASTER_LINK_REG_H 0x14 +#define SXS_MASTER_ADDR_REG_L 0x18 +#define SXS_MASTER_ADDR_REG_H 0x1c +#define SXS_MASTER_SIZE_REG 0x20 +#define SXS_ENABLE_REG 0x28 +#define SXS_CONTROL_REG 0x2c +#define SXS_STATUS_REG 0x6c +#define SXS_RESPONSE_BUF 0x40 + +#define KERNEL_SECTOR_SIZE 512 + +static struct pci_device_id ids[] = { + { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_81CE), }, + { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_905C), }, + { 0, } +}; +MODULE_DEVICE_TABLE(pci, ids); + +struct sxs_device { + struct pci_dev *pci_dev; + spinlock_t lock; + void __iomem *mmio; + + intsxs_major; + struct gendisk *disk; + intsector_size; + intnum_sectors; + intsector_shift; + struct request_queue *queue; + + struct completion irq_response; +}; + +static int sxs_getgeo(struct block_device *bdev, struct hd_geometry *geo) +{ + struct sxs_device *dev = bdev->bd_disk->private_data; + long size; + + /* Make something up here */ + size = dev->num_sectors*(dev->sector_size/KERNEL_SECTOR_SIZE); + geo->cylinders = (size & ~0x3f) >> 6; + geo->heads = 4; + geo->sectors = 16; + + return 0; +} + +static const struct block_device_operations sxs_opts = { + .owner = THIS_MODULE, + .getgeo = sxs_getgeo +}; + +static void sxs_memcpy_read(struct sxs_device *dev, unsigned long sector, + unsigned long nsect, char *buffer) +{ + struct pci_dev *pdev = dev->pci_dev; + u32 status; + u32 data[4]; + u16 *tmp; + u32 *tmp2; + + void *dma2; + dma_addr_t dma2_handle; + void *dma3; + dma_addr_t dma3_handle; + + sector >>= dev->sector_shift; + nsect >>= dev->sector_shift; + + /* Read */ + dma2 = pci_alloc_consistent(pdev, 8192, &dma2_handle); + dma3 = pci_alloc_consistent(pdev, 8192, &dma3_handle); + + tmp = dma2; + tmp2 = dma3; + tmp2[0] = dma2_handle; + tmp2[2] = dma3_handle; + + dev_dbg_ratelimited(&pdev->dev, "CALL %lu %lu\n", + sector & 0x, nsect & 0x); + + reinit_completion(&dev->irq_response); + status = readl(dev->mmio+SXS_STATUS_REG); + data[0] = cpu_to_le32(0x00010028); + data[1] = cpu_to_le32(sector & 0x); + data[2] = 0x0; + data[3] = cpu_to_le32(nsect & 0x); + memcpy_toio(dev->mmio, data, siz
[PATCH] ACPI / SBS: Fix check in acpi_ac_get_present()
From: Rafael J. Wysocki Parentheses are missing under an if () statement in acpi_ac_get_present() which makes the check work differently from what was intended (at least according to the comment right above it). Add the missing parens. The problem was found by sparse. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/sbs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/acpi/sbs.c === --- linux-pm.orig/drivers/acpi/sbs.c +++ linux-pm/drivers/acpi/sbs.c @@ -441,7 +441,7 @@ static int acpi_ac_get_present(struct ac * The spec requires that bit 4 always be 1. If it's not set, assume * that the implementation doesn't support an SBS charger */ - if (!(status >> 4) & 0x1) + if (!((status >> 4) & 0x1)) return -ENODEV; sbs->charger_present = (status >> 15) & 0x1; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/7] clk: at91: add a driver for the h32mx clock
Quoting Boris BREZILLON (2014-09-22 02:04:25) > On Fri, 19 Sep 2014 14:33:19 +0200 > Nicolas Ferre wrote: > > > On 15/09/2014 18:15, Alexandre Belloni : > > > Newer SoCs have two different AHB interconnect. The AHB 32 bits Matrix > > > interconnect (h32mx) has a clock that can be setup at the half of the > > > h64mx > > > clock (which is mck). The h32mx clock can not exceed 90 MHz. > > > > > > Signed-off-by: Alexandre Belloni > > > > Okay on my side: > > > > Acked-by: Nicolas Ferre > > > > > > > --- > > > Cc:Mike Turquette > > > > Mike, > > > > I guess that you didn't get this v3. Can you "Ack" this one of should we > > re-sent to you? > > > > I would like to take this patch with the rest of the SAMA5D4 series: is > > it okay for you? > > > Hi Mike, > > I gave my ack to this patch, so, if you don't mind letting Nicolas > take it through his tree, I think it will ease integration of the > sama5d4 support (no external dependencies on the clk tree). Acked-by: Mike Turquette > > Best Regards, > > Boris > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.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 1/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss
On 09/27/14 09:46, Felipe Balbi wrote: On Fri, Sep 26, 2014 at 06:10:52PM -0700, Behan Webster wrote: Replace the use of nested functions where a normal function will suffice. Nested functions are not liked by upstream kernel developers in general. Their use breaks the use of clang as a compiler, and doesn't make the code any better. This code now works for both gcc and clang. Signed-off-by: Behan Webster Suggested-by: Arnd Bergmann Cc: Arnd Bergmann another one that make sense :-) And probably also deserves checkpatch/coccinelle/sparse. Indeed! That would be very appreciated. The clang static analyzer already points this one out. :) Behan -- Behan Webster beh...@converseincode.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 3.12 000/142] 3.12.29-stable review
At Fri, 26 Sep 2014 08:45:36 -0700, Guenter Roeck wrote: > > On Fri, Sep 26, 2014 at 11:45:33AM +0200, Jiri Slaby wrote: > > This is the start of the stable review cycle for the 3.12.29 release. > > There are 142 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Sep 30 11:45:24 CEST 2014. > > Anything received after that time might be too late. > > > > Hi Jiri, > > Build results: > total: 135 pass: 135 fail: 0 > > Qemu test results: > total: 21 pass: 21 fail: 0 > > Both obviously look good, however my tree doesn't match your review request. > It includes 245 patches instead of just 142. > > Looks like your tree is a bit ahead of time, so I guess that is ok. > Is there a way for me to avoid this when pulling in your pending changes ? > So far I pull the changes from the stable-3.12-queue branch in your > repository at kernel.org. > > Thanks, > Guenter Plus, this kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs.git for 3.17-rc7
Assorted fixes + unifying __d_move() and __d_materialise_dentry() + minimal regression fix for d_path() of victims of overwriting rename() ported on top of that. Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (7): ufs: deal with nfsd/iget races pull rehashing and unlocking the target dentry into __d_materialise_dentry() don't open-code d_rehash() in d_materialise_unique() __d_move(): fold manipulations with ->d_child/->d_subdirs __d_materialise_dentry(): flip the order of arguments kill __d_materialise_dentry() fold unlocking the children into dentry_unlock_parents_for_move() Linus Torvalds (1): fold swapping ->d_name.hash into switch_names() Mikhail Efremov (1): vfs: Don't exchange "short" filenames unconditionally. Miklos Szeredi (2): shmem: fix nlink for rename overwrite directory fuse: honour max_read and max_write in direct_io mode Diffstat: fs/dcache.c | 112 +-- fs/direct-io.c |2 +- fs/fuse/file.c |1 + fs/ufs/ialloc.c |6 ++- fs/ufs/namei.c |4 ++ include/linux/uio.h |2 +- mm/iov_iter.c | 14 --- mm/shmem.c |4 +- 8 files changed, 60 insertions(+), 85 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/
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] please pull infiniband.git
On Wed, Sep 24, 2014 at 12:58 AM, Roland Dreier wrote: > Hi Linus, [..] > This is later and bigger than I would like, and the blame is all on > me: I got very busy with other stuff for a few weeks during the 3.17 > cycle, and didn't prepare this tree as soon as I should have. However > I don't think there's anything risky here, and no one really cares if > we break InfiniBand in 3.17 anyway... Roland, sorry, but I don't understand the joke @ the last sentence, can you elaborate? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] wireless: Remove unnessary write over of register 11 in rt2800lib.c
This removes the unnecessary overwrite of register 11 in the function, rt2800_config_channel as we are already writing a correct value to the register with rt2800_rfcsr_write(rt2x00dev,11.rfcsr). Signed-off-by: Nicholas Krause --- drivers/net/wireless/rt2x00/rt2800lib.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c index 893c9d5..fb0ae38 100644 --- a/drivers/net/wireless/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/rt2x00/rt2800lib.c @@ -2787,8 +2787,6 @@ static void rt2800_config_channel_rf55xx(struct rt2x00_dev *rt2x00dev, if (rf->channel <= 14) { rt2800_rfcsr_write(rt2x00dev, 10, 0x90); - /* FIXME: RF11 owerwrite ? */ - rt2800_rfcsr_write(rt2x00dev, 11, 0x4A); rt2800_rfcsr_write(rt2x00dev, 12, 0x52); rt2800_rfcsr_write(rt2x00dev, 13, 0x42); rt2800_rfcsr_write(rt2x00dev, 22, 0x40); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] r8169:add support for RTL8168EP
Chun-Hao Lin : > RTL8168EP is Realtek PCIe Gigabit Ethernet controller. > It is a successor chip of RTL8168DP. > > This patch add support for this chip. It does more than that. Did Hayes review it ? > Signed-off-by: Chun-Hao Lin > --- > drivers/net/ethernet/realtek/r8169.c | 611 > +-- > 1 file changed, 514 insertions(+), 97 deletions(-) > > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 1d81238..0ead9a7 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -155,6 +155,9 @@ enum mac_version { > RTL_GIGA_MAC_VER_46, > RTL_GIGA_MAC_VER_47, > RTL_GIGA_MAC_VER_48, > + RTL_GIGA_MAC_VER_49, > + RTL_GIGA_MAC_VER_50, > + RTL_GIGA_MAC_VER_51, > RTL_GIGA_MAC_NONE = 0xff, > }; > > @@ -302,6 +305,15 @@ static const struct { > [RTL_GIGA_MAC_VER_48] = > _R("RTL8107e", RTL_TD_1, FIRMWARE_8107E_2, > JUMBO_1K, false), > + [RTL_GIGA_MAC_VER_49] = > + _R("RTL8168ep/8111ep", RTL_TD_1, NULL, > + JUMBO_9K, false), > + [RTL_GIGA_MAC_VER_50] = > + _R("RTL8168ep/8111ep", RTL_TD_1, NULL, > + JUMBO_9K, false), > + [RTL_GIGA_MAC_VER_51] = > + _R("RTL8168ep/8111ep", RTL_TD_1, NULL, > + JUMBO_9K, false), > }; > #undef _R > > @@ -400,6 +412,10 @@ enum rtl_registers { > FuncEvent = 0xf0, > FuncEventMask = 0xf4, > FuncPresetState = 0xf8, > + IBCR0 = 0xf8, > + IBCR2 = 0xf9, > + IBIMR0 = 0xfa, > + IBISR0 = 0xfb, > FuncForceEvent = 0xfc, > }; > > @@ -467,6 +483,7 @@ enum rtl8168_registers { > #define ERIAR_EXGMAC (0x00 << ERIAR_TYPE_SHIFT) > #define ERIAR_MSIX (0x01 << ERIAR_TYPE_SHIFT) > #define ERIAR_ASF(0x02 << ERIAR_TYPE_SHIFT) > +#define ERIAR_OOB(0x02 << ERIAR_TYPE_SHIFT) > #define ERIAR_MASK_SHIFT 12 > #define ERIAR_MASK_0001 (0x1 << ERIAR_MASK_SHIFT) > #define ERIAR_MASK_0011 (0x3 << ERIAR_MASK_SHIFT) > @@ -935,93 +952,10 @@ static const struct rtl_cond name = { > \ > \ > static bool name ## _check(struct rtl8169_private *tp) > > -DECLARE_RTL_COND(rtl_ocpar_cond) > -{ > - void __iomem *ioaddr = tp->mmio_addr; > - > - return RTL_R32(OCPAR) & OCPAR_FLAG; > -} Feel free to move this function around but please do it in a separate patch. You are adding extra noise and thus making this stuff harder to review than it should be. > - > -static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg) > -{ > - void __iomem *ioaddr = tp->mmio_addr; > - > - RTL_W32(OCPAR, ((u32)mask & 0x0f) << 12 | (reg & 0x0fff)); > - > - return rtl_udelay_loop_wait_high(tp, &rtl_ocpar_cond, 100, 20) ? > - RTL_R32(OCPDR) : ~0; > -} (this one is modified) > - > -static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data) > -{ > - void __iomem *ioaddr = tp->mmio_addr; > - > - RTL_W32(OCPDR, data); > - RTL_W32(OCPAR, OCPAR_FLAG | ((u32)mask & 0x0f) << 12 | (reg & 0x0fff)); > - > - rtl_udelay_loop_wait_low(tp, &rtl_ocpar_cond, 100, 20); > -} (this one is modified) > - > -DECLARE_RTL_COND(rtl_eriar_cond) > -{ > - void __iomem *ioaddr = tp->mmio_addr; > - > - return RTL_R32(ERIAR) & ERIAR_FLAG; > -} Feel free to move this function around but please do it in a separate patch. > - > -static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd) > -{ > - void __iomem *ioaddr = tp->mmio_addr; > - > - RTL_W8(ERIDR, cmd); > - RTL_W32(ERIAR, 0x800010e8); > - msleep(2); > - > - if (!rtl_udelay_loop_wait_low(tp, &rtl_eriar_cond, 100, 5)) > - return; > - > - ocp_write(tp, 0x1, 0x30, 0x0001); > -} This one is modified but it is also modified for the existing 8168DP. Mantra: please do it in a separate patch. > - > #define OOB_CMD_RESET0x00 > #define OOB_CMD_DRIVER_START 0x05 > #define OOB_CMD_DRIVER_STOP 0x06 > > -static u16 rtl8168_get_ocp_reg(struct rtl8169_private *tp) > -{ > - return (tp->mac_version == RTL_GIGA_MAC_VER_31) ? 0xb8 : 0x10; > -} > - > -DECLARE_RTL_COND(rtl_ocp_read_cond) > -{ > - u16 reg; > - > - reg = rtl8168_get_ocp_reg(tp); > - > - return ocp_read(tp, 0x0f, reg) & 0x0800; > -} (this one is simply moved around) > - > -static void rtl8168_driver_start(struct rtl8169_private *tp) > -{ > - rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START); > - > - rtl_msleep_loop_wait_high(tp, &rtl_ocp_read_cond, 10, 10); > -} (this one is
Re: [PATCH v12 08/12] PCI: OF: Introduce helper function for retrieving PCI domain numbers
[+cc Yinghai] On Fri, Sep 26, 2014 at 4:47 PM, Liviu Dudau wrote: > On Fri, Sep 26, 2014 at 10:53:26PM +0100, Rob Herring wrote: >> I thought Bjorn already applied the series. Who's agreement are you >> waiting for specifically. > > Looks like he only applied about 60% of the series. I applied it all but Yinghai pointed out a problem with a patch in the middle, so I dropped that patch and everything after it because I didn't have time to work out whether the later patches depended on anything in the one I dropped. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Add PWM clock driver
Quoting Thierry Reding (2014-09-23 01:51:31) > On Wed, Sep 10, 2014 at 10:05:17PM +0200, Janusz Użycki wrote: > > Hi, > > > > http://patchwork.ozlabs.org/patch/359069/ > > https://lkml.org/lkml/2014/6/12/186 > > > > Will the patch ever included to linux-next? > > I've never seen this patch before. From a quick look it doesn't seem > like it would work as is, but the idea is certainly interesting. If > somebody decides to continue work on it, please Cc me and the linux-pwm > mailing list. I just merged a gpio-controlled clock gate and I'm fine with a PWM clock output. Janusz, how are you testing the clock driver? Regards, Mike > > > pwm_config() API could be extended to support > > not only period [ns] and duty [ns] time > > but also frequency [Hz] and duty cycle fraction [1/1000?] > > (instead of time in ns) as parameters. > > Then ns (rounded by pwm) to freq. conversion problem > > inclk_pwm_recalc_rate() usingpwm_get_period() > > could be avoided. > > To extend the API pwm_config() can support > > new flags forduty_ns and period_ns, > > eg. PWM_DUTY_PERCENT and PWM_PERIOD_HZ. > > Is that rounding really a problem? Also the PWM chips will most likely > use the concept of period and duty-cycle internally anyway, so it will > convert back from Hz/percentage to nanoseconds and fall victim to > similar rounding effects. > > Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:49 PM, Al Viro wrote: > > Fine by me. How about that s-o-b? Right now it's Sure, add my sign-off too. Not that I feel I even need the credit, so you could just have done it as yourself. But I'll take it, so.. Signed-off-by: Linus Torvalds Thanks, 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/
[GIT PULL] ARM: SoC fixes for 3.17
Hi Linus, The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd: Linux 3.17-rc4 (2014-09-07 16:09:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to fa9eb3241895d2771b87f20dd23b40de664c5e4e: drivers/soc: qcom: do not disable the iface clock in probe (2014-09-23 21:38:32 -0700) ARM: SoC fixes for 3.17 Here's our last set of fixes for 3.17. Most of these are for TI platforms, fixing some noisy Kconfig issues, runtime clock and power issues on several platforms and NAND timings on DRA7. There are also a couple of bug fixes for i.MX, one for QCOM and a small fix to avoid section mismatch noise on PXA. Diffstat looks large, partially due to some tables being updated and thus touching many lines. The qcom gsbi change also restructures clock management a bit and thus touches a bunch of lines. All in all, a bit more changes than we'd like at this point, but nothing stands out as risky either so it seems like the right thing to send it up now instead of holding it to the merge window. Arnd Bergmann (1): ARM: pxa: fix section mismatch warning for pxa_timer_nodt_init Dmitry Lifshitz (1): ARM: dts: cm-t54: fix serial console power supply. Markus Niebel (1): ARM: DT: imx53: fix lvds channel 1 port Murali Karicheri (1): ARM: keystone: dts: fix bindings for pcie and usb clock nodes Nishanth Menon (1): bus: omap_l3_noc: Fix connID for OMAP4 Olof Johansson (3): Merge tag 'fixes-v3.17-rc4' of git://git.kernel.org/.../ssantosh/linux-keystone into fixes Merge tag 'fixes-v3.17-rc4' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'fix-v3.17-io-chain-v3' of git://git.kernel.org/.../tmlind/linux-omap into fixes Roger Quadros (1): ARM: dts: dra7-evm: Fix NAND GPMC timings Shawn Guo (1): ARM: imx: fix .is_enabled() of shared gate clock Srinivas Kandagatla (1): drivers/soc: qcom: do not disable the iface clock in probe Tony Lindgren (2): ARM: OMAP: Fix Kconfig warning for omap1 ARM: OMAP3: Fix I/O chain clock line assertion timed out error .../devicetree/bindings/staging/imx-drm/ldb.txt| 15 ++- arch/arm/boot/dts/dra7-evm.dts | 27 ++-- arch/arm/boot/dts/imx53.dtsi | 12 +- arch/arm/boot/dts/k2e-clocks.dtsi | 6 +-- arch/arm/boot/dts/omap5-cm-t54.dts | 5 +-- arch/arm/mach-imx/clk-gate2.c | 6 +-- arch/arm/mach-omap2/Kconfig| 3 -- arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/prm3xxx.c | 39 +++-- arch/arm/mach-pxa/generic.c| 2 +- arch/arm/plat-omap/Kconfig | 3 ++ drivers/bus/omap_l3_noc.h | 50 +++--- drivers/soc/qcom/qcom_gsbi.c | 46 ++-- 13 files changed, 139 insertions(+), 77 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 v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:39:02PM -0700, Linus Torvalds wrote: > On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds > wrote: > > > > But yeah, I guess we can/should do the trivial ugly thing for 3.17. > > Send me a proper pull-request, > > .. and if it can happen before tomorrow, that would be good. I had to > give up on my wish to release 3.17 tomorrow due to the current size of > changes anyway, so there will be a rc7 (and my travel inconveniences > be damned), but I'd like this to be in that rc7. Works for you? Fine by me. How about that s-o-b? Right now it's commit 4f78a56cd96a3d421852b5a03e10355b0cbe764b Author: Linus Torvalds Date: Wed Sep 24 12:27:39 2014 -0700 fold swapping ->d_name.hash into switch_names() and do it along with ->d_name.len there Signed-off-by: Al Viro diff --git a/fs/dcache.c b/fs/dcache.c index 92f7d76..7599d35 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2412,7 +2412,7 @@ static void switch_names(struct dentry *dentry, struct dentry *target) } } } - swap(dentry->d_name.len, target->d_name.len); + swap(dentry->d_name.hash_len, target->d_name.hash_len); } static void dentry_lock_for_move(struct dentry *dentry, struct dentry *target) @@ -2510,7 +2510,6 @@ static void __d_move(struct dentry *dentry, struct dentry *target, /* Switch the names.. */ switch_names(dentry, target); - swap(dentry->d_name.hash, target->d_name.hash); /* ... and switch them in the tree */ if (IS_ROOT(dentry)) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 08:16:57PM +0100, Al Viro wrote: > On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote: > > > We can get the long name cases right, and I agree that it'll make the > > things nicer, but it might take a couple of days to get right. The thing > > I'm concerned about is not screwing DCACHE_RCUACCESS up. > > FWIW, I suspect that the right approach is to put refcount + rcu_head in > front of external name and do the following: > * __d_free() checks if we have an external name, gets its containing > structure and does if (atomic_dec_and_test(&name->count)) kfree(name); > * switch_names() in non-exchange case (I'd probably call it copy_name, > not move_names, but anyway) sets DCACHE_RCUACCESS on target (source has > already gotten it from __d_rehash()), increments refcount on target's name > if external and, if the source old name is external, decrements its refcount > and calls kfree_rcu() if it has hit zero. > > AFAICS, it guarantees that we'll schedule an RCU callback on name's rch_head > at most once, that we won't free it while RCU callback on it is scheduled > and we won't free it until a grace period has expired since the last time > it had been referenced by observable dentries. Do you see any holes in that? We probably want to put a union of refcount and rcu_head there, actually... Gives the right alignment without padding. As in struct ext_name { union { atomic_t count; struct rcu_head head; }; char name[0]; }; ->count corresponds to the number of dentries that have ->d_name.name pointing to the sucker's ->name. And we use ->head only when it reaches zero in __d_move(). That's 2 words per external name; somewhat unpleasant on 64bit, but I don't see how to avoid an rcu_head in there... The cutoff for external names is 32 bytes on 64bit boxen. That way we get 16 bytes of overhead per long-named dentry... OTOH, we allocate them with kmalloc(), so it means that 32-character names lead to 64-bytes actual allocation. Hmmm... So the old behaviour is 32--63 => 64 byte allocation 64--95 => 96 96--127=> 128 and the new one 32--47 => 64 byte allocation 48--79 => 96 80--111=> 128 112--127=> 192 (components longer than 128 characters are definitely too rare to worry about) IOW, the main worry is about the names in range from 48 to 64 characters; for those we push the allocation from size-64 to size-96... Note, BTW, that git hits external name case on everything except 32-bit UP; a _lot_ of 38-character names there. And IIRC there had been some plans for possible replacement of SHA1 with something wider, right? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
On Saturday, September 27, 2014 01:32:59 PM Wang Weidong wrote: > On 2014/9/27 7:21, Rafael J. Wysocki wrote: > > On Thursday, August 21, 2014 01:55:15 PM Wang Weidong wrote: > >> As the initialized freq_tables maybe different from the p-states > >> values, so the array index is different as well. > >> > >> p-states value: [2400 2400 2000 ...], while the freq_tables: > >> [2400 2000 ... CPUFREQ_TABLE_END]. After setted the freqs 2000, > >> the perf->state is 3 while the freqs_table's index should be 2. > >> So when call the get_cur_freq_on_cpu, the freqs value we get > >> is 2400. > >> > >> So, fix the problem with the correct tables. > > > > What you're saying is basically that freq_table and perf->states > > diverge at one point. Shouldn't we re-generate freq_table in that > > case instead of fixing up get_cur_freq_on_cpu() only in a quite > > indirect way? > > > Hi Rafael, > > Thanks for your reply. > > You mean that we should re-generate the freq_table in that case? > Could we fix the table init like this: > > --- a/drivers/cpufreq/acpi-cpufreq.c > +++ b/drivers/cpufreq/acpi-cpufreq.c > @@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy > *policy) > > /* table init */ > for (i = 0; i < perf->state_count; i++) { > - if (i > 0 && perf->states[i].core_frequency >= > + if (i > 0 && perf->states[i].core_frequency > > data->freq_table[valid_states-1].frequency / 1000) > continue; > > when the value is same, we just keep the value into the freq_table. That would only be OK if it is guaranteed that the set of available states hasn't changed, which I'm not sure is the case. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:37 PM, Linus Torvalds wrote: > > But yeah, I guess we can/should do the trivial ugly thing for 3.17. > Send me a proper pull-request, .. and if it can happen before tomorrow, that would be good. I had to give up on my wish to release 3.17 tomorrow due to the current size of changes anyway, so there will be a rc7 (and my travel inconveniences be damned), but I'd like this to be in that rc7. Works for you? 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: BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
On Saturday, September 27, 2014 08:14:46 AM Mike Galbraith wrote: > On Sat, 2014-09-27 at 00:44 +0200, Rafael J. Wysocki wrote: > > > Shouldn't that be pcc-cpufreq.c rather? > > Yeah, silly mouse copy/pasted the wrong gitk bits. > > > Also moving the spin_lock(&pcc_lock) after the > > cpufreq_freq_transition_begin() > > should fix the problem too (like the below). Have you tried that? > > Have now. Yup, works and is prettier. OK, thanks! Below it goes again with full changelog. --- From: Rafael J. Wysocki Subject: cpufreq: pcc-cpufreq: Fix wait_event() under spinlock Fix the following bug introduced by commit 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) that forgot to move the spin_lock() in pcc_cpufreq_target() past cpufreq_freq_transition_begin() which calls wait_event(): BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] [ 51.025044] CPU: 57 PID: 2636 Comm: modprobe Tainted: GE 3.17.0-default #7 Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 88026c46b828 81589dbd 880037978090 88026c46b848 8108e1df 880037978090 88026c46b878 8108e298 88026d73ec00 Call Trace: [] dump_stack+0x4d/0x90 [] ___might_sleep+0x10f/0x180 [] __might_sleep+0x48/0xd0 [] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); [] ? preempt_count_add+0xb9/0xc0 [] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); [] ? update_ts_time_stats+0x7f/0xb0 [] __cpufreq_driver_target+0x85/0x170 [] od_check_cpu+0xa8/0xb0 [] dbs_check_cpu+0x180/0x1d0 [] cpufreq_governor_dbs+0x3b0/0x720 [] od_cpufreq_governor_dbs+0x33/0xe0 [] __cpufreq_governor+0xa9/0x210 [] cpufreq_set_policy+0x1e2/0x2e0 [] cpufreq_init_policy+0x8c/0x110 [] ? cpufreq_update_policy+0x1b0/0x1b0 [] ? preempt_count_sub+0xb9/0x100 [] __cpufreq_add_dev+0x596/0x6b0 [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [] cpufreq_add_dev+0xe/0x10 [] subsys_interface_register+0xc1/0xf0 [] ? preempt_count_sub+0xb9/0x100 [] cpufreq_register_driver+0x117/0x2a0 [] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [] do_one_initcall+0xc8/0x1f0 [] ? __vunmap+0x9d/0x100 [] do_init_module+0x30/0x1b0 [] load_module+0x686/0x710 [] ? do_init_module+0x1b0/0x1b0 [] SyS_init_module+0x9b/0xc0 [] system_call_fastpath+0x16/0x1b Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) Reported-and-tested-by: Mike Galbraith Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/pcc-cpufreq.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/cpufreq/pcc-cpufreq.c === --- linux-pm.orig/drivers/cpufreq/pcc-cpufreq.c +++ linux-pm/drivers/cpufreq/pcc-cpufreq.c @@ -204,7 +204,6 @@ static int pcc_cpufreq_target(struct cpu u32 input_buffer; int cpu; - spin_lock(&pcc_lock); cpu = policy->cpu; pcc_cpu_data = per_cpu_ptr(pcc_cpu_info, cpu); @@ -216,6 +215,7 @@ static int pcc_cpufreq_target(struct cpu freqs.old = policy->cur; freqs.new = target_freq; cpufreq_freq_transition_begin(policy, &freqs); + spin_lock(&pcc_lock); input_buffer = 0x1 | (((target_freq * 100) / (ioread32(&pcch_hdr->nominal) * 1000)) << 8); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 12:16 PM, Al Viro wrote: > > FWIW, I suspect that the right approach is to put refcount + rcu_head in > front of external name and do the following: That's actually fancier than I was expecting. I was just thinking doing a whole new allocation and freeing the old one using RCU. But I guess you're right, you do need the rcu_head even for that, and once you start adding fields you might as well just add a refcount too, and then you don't have the annoyance of a potential memory allocation in that code. So your approach is better and doesn't sound too painful at all. But yeah, I guess we can/should do the trivial ugly thing for 3.17. Send me a proper pull-request, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] mm/balloon_compaction: add vmstat counters and kpageflags bit
From: Konstantin Khlebnikov Always mark pages with PageBalloon even if balloon compaction is disabled and expose this mark in /proc/kpageflags as KPF_BALLOON. Also this patch adds three counters into /proc/vmstat: "balloon_inflate", "balloon_deflate" and "balloon_migrate". They accumulate balloon activity. Current size of balloon is (balloon_inflate - balloon_deflate) pages. All generic balloon code now gathered under option CONFIG_MEMORY_BALLOON. It should be selected by ballooning driver which wants use this feature. Currently virtio-balloon is the only user. Signed-off-by: Konstantin Khlebnikov Cc: Rafael Aquini Cc: Andrew Morton --- drivers/virtio/Kconfig |1 + drivers/virtio/virtio_balloon.c|1 + fs/proc/page.c |3 +++ include/linux/balloon_compaction.h |2 ++ include/linux/vm_event_item.h |7 +++ include/uapi/linux/kernel-page-flags.h |1 + mm/Kconfig |7 ++- mm/Makefile|3 ++- mm/balloon_compaction.c|2 ++ mm/vmstat.c| 12 +++- tools/vm/page-types.c |1 + 11 files changed, 37 insertions(+), 3 deletions(-) diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index c6683f2..00b2286 100644 --- a/drivers/virtio/Kconfig +++ b/drivers/virtio/Kconfig @@ -25,6 +25,7 @@ config VIRTIO_PCI config VIRTIO_BALLOON tristate "Virtio balloon driver" depends on VIRTIO + select MEMORY_BALLOON ---help--- This driver supports increasing and decreasing the amount of memory within a KVM guest. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 2bad7f9..f893148 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -396,6 +396,7 @@ static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info, spin_lock_irqsave(&vb_dev_info->pages_lock, flags); balloon_page_insert(vb_dev_info, newpage); vb_dev_info->isolated_pages--; + __count_vm_event(BALLOON_MIGRATE); spin_unlock_irqrestore(&vb_dev_info->pages_lock, flags); vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE; set_page_pfns(vb->pfns, newpage); diff --git a/fs/proc/page.c b/fs/proc/page.c index e647c55..1e3187d 100644 --- a/fs/proc/page.c +++ b/fs/proc/page.c @@ -133,6 +133,9 @@ u64 stable_page_flags(struct page *page) if (PageBuddy(page)) u |= 1 << KPF_BUDDY; + if (PageBalloon(page)) + u |= 1 << KPF_BALLOON; + u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked); u |= kpf_copy_bit(k, KPF_SLAB, PG_slab); diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h index bc3d298..9b0a15d 100644 --- a/include/linux/balloon_compaction.h +++ b/include/linux/balloon_compaction.h @@ -166,11 +166,13 @@ static inline gfp_t balloon_mapping_gfp_mask(void) static inline void balloon_page_insert(struct balloon_dev_info *balloon, struct page *page) { + __SetPageBalloon(page); list_add(&page->lru, &balloon->pages); } static inline void balloon_page_delete(struct page *page) { + __ClearPageBalloon(page); list_del(&page->lru); } diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h index ced9234..730334c 100644 --- a/include/linux/vm_event_item.h +++ b/include/linux/vm_event_item.h @@ -72,6 +72,13 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT, THP_ZERO_PAGE_ALLOC, THP_ZERO_PAGE_ALLOC_FAILED, #endif +#ifdef CONFIG_MEMORY_BALLOON + BALLOON_INFLATE, + BALLOON_DEFLATE, +#ifdef CONFIG_BALLOON_COMPACTION + BALLOON_MIGRATE, +#endif +#endif #ifdef CONFIG_DEBUG_TLBFLUSH #ifdef CONFIG_SMP NR_TLB_REMOTE_FLUSH,/* cpu tried to flush others' tlbs */ diff --git a/include/uapi/linux/kernel-page-flags.h b/include/uapi/linux/kernel-page-flags.h index 5116a0e..2f96d23 100644 --- a/include/uapi/linux/kernel-page-flags.h +++ b/include/uapi/linux/kernel-page-flags.h @@ -31,6 +31,7 @@ #define KPF_KSM21 #define KPF_THP22 +#define KPF_BALLOON23 #endif /* _UAPILINUX_KERNEL_PAGE_FLAGS_H */ diff --git a/mm/Kconfig b/mm/Kconfig index 886db21..83250e4 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -228,11 +228,16 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK boolean # +# support for memory balloon +config MEMORY_BALLOON + boolean + +# # support for memory balloon compaction config BALLOON_COMPACTION bool "Allow for balloon memory compaction/migration" def_bool y - depends on COMPACTION && VIRTIO_BALLOON + depends on COMPACTION && MEMORY_BALLOON help Memory fragmentation introduced
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 07:31:39PM +0100, Al Viro wrote: > We can get the long name cases right, and I agree that it'll make the > things nicer, but it might take a couple of days to get right. The thing > I'm concerned about is not screwing DCACHE_RCUACCESS up. FWIW, I suspect that the right approach is to put refcount + rcu_head in front of external name and do the following: * __d_free() checks if we have an external name, gets its containing structure and does if (atomic_dec_and_test(&name->count)) kfree(name); * switch_names() in non-exchange case (I'd probably call it copy_name, not move_names, but anyway) sets DCACHE_RCUACCESS on target (source has already gotten it from __d_rehash()), increments refcount on target's name if external and, if the source old name is external, decrements its refcount and calls kfree_rcu() if it has hit zero. AFAICS, it guarantees that we'll schedule an RCU callback on name's rch_head at most once, that we won't free it while RCU callback on it is scheduled and we won't free it until a grace period has expired since the last time it had been referenced by observable dentries. Do you see any holes in that? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] mm/balloon_compaction: remove balloon mapping and flag AS_BALLOON_MAP
From: Konstantin Khlebnikov Now ballooned pages are detected using PageBalloon(). Fake mapping is no longer required. This patch links ballooned pages to balloon device using field page->private instead of page->mapping. Also this patch embeds balloon_dev_info directly into struct virtio_balloon. Signed-off-by: Konstantin Khlebnikov Cc: Rafael Aquini Cc: Andrew Morton --- drivers/virtio/virtio_balloon.c| 60 +-- include/linux/balloon_compaction.h | 72 +++ include/linux/pagemap.h| 18 --- mm/balloon_compaction.c| 95 ++-- 4 files changed, 39 insertions(+), 206 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index c3eb93fc..2bad7f9 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -59,7 +59,7 @@ struct virtio_balloon * Each page on this list adds VIRTIO_BALLOON_PAGES_PER_PAGE * to num_pages above. */ - struct balloon_dev_info *vb_dev_info; + struct balloon_dev_info vb_dev_info; /* Synchronize access/update to this struct virtio_balloon elements */ struct mutex balloon_lock; @@ -127,7 +127,7 @@ static void set_page_pfns(u32 pfns[], struct page *page) static void fill_balloon(struct virtio_balloon *vb, size_t num) { - struct balloon_dev_info *vb_dev_info = vb->vb_dev_info; + struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info; /* We can only do one array worth at a time. */ num = min(num, ARRAY_SIZE(vb->pfns)); @@ -171,7 +171,7 @@ static void release_pages_by_pfn(const u32 pfns[], unsigned int num) static void leak_balloon(struct virtio_balloon *vb, size_t num) { struct page *page; - struct balloon_dev_info *vb_dev_info = vb->vb_dev_info; + struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info; /* We can only do one array worth at a time. */ num = min(num, ARRAY_SIZE(vb->pfns)); @@ -353,12 +353,11 @@ static int init_vqs(struct virtio_balloon *vb) return 0; } -static const struct address_space_operations virtio_balloon_aops; #ifdef CONFIG_BALLOON_COMPACTION /* * virtballoon_migratepage - perform the balloon page migration on behalf of * a compation thread. (called under page lock) - * @mapping: the page->mapping which will be assigned to the new migrated page. + * @vb_dev_info: the balloon device * @newpage: page that will replace the isolated page after migration finishes. * @page : the isolated (old) page that is about to be migrated to newpage. * @mode : compaction mode -- not used for balloon page migration. @@ -373,17 +372,13 @@ static const struct address_space_operations virtio_balloon_aops; * This function preforms the balloon page migration task. * Called through balloon_mapping->a_ops->migratepage */ -static int virtballoon_migratepage(struct address_space *mapping, +static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info, struct page *newpage, struct page *page, enum migrate_mode mode) { - struct balloon_dev_info *vb_dev_info = balloon_page_device(page); - struct virtio_balloon *vb; + struct virtio_balloon *vb = container_of(vb_dev_info, + struct virtio_balloon, vb_dev_info); unsigned long flags; - BUG_ON(!vb_dev_info); - - vb = vb_dev_info->balloon_device; - /* * In order to avoid lock contention while migrating pages concurrently * to leak_balloon() or fill_balloon() we just give up the balloon_lock @@ -399,7 +394,7 @@ static int virtballoon_migratepage(struct address_space *mapping, /* balloon's page migration 1st step -- inflate "newpage" */ spin_lock_irqsave(&vb_dev_info->pages_lock, flags); - balloon_page_insert(newpage, mapping, &vb_dev_info->pages); + balloon_page_insert(vb_dev_info, newpage); vb_dev_info->isolated_pages--; spin_unlock_irqrestore(&vb_dev_info->pages_lock, flags); vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE; @@ -418,18 +413,11 @@ static int virtballoon_migratepage(struct address_space *mapping, return MIGRATEPAGE_SUCCESS; } - -/* define the balloon_mapping->a_ops callback to allow balloon page migration */ -static const struct address_space_operations virtio_balloon_aops = { - .migratepage = virtballoon_migratepage, -}; #endif /* CONFIG_BALLOON_COMPACTION */ static int virtballoon_probe(struct virtio_device *vdev) { struct virtio_balloon *vb; - struct address_space *vb_mapping; - struct balloon_dev_info *vb_devinfo; int err; vdev->priv = vb = kmalloc(sizeof(*vb), GFP_KERNEL); @@ -445,30 +433,14 @@ static int virtballoon_probe(struct virtio_device *vdev) vb->vdev = vdev; vb->need_stats_update = 0; - vb_de
[PATCH v3 4/4] selftests/vm/transhuge-stress: stress test for memory compaction
This tool induces memory fragmentation via sequential allocation of transparent huge pages and splitting off everything except their last sub-pages. It easily generates pressure to the memory compaction code. $ perf stat -e 'compaction:*' -e 'migrate:*' ./transhuge-stress transhuge-stress: allocate 7858 transhuge pages, using 15716 MiB virtual memory and 61 MiB of ram transhuge-stress: 1.653 s/loop, 0.210 ms/page, 9504.828 MiB/s 7858 succeed, 0 failed, 2439 different pages transhuge-stress: 1.537 s/loop, 0.196 ms/page, 10226.227 MiB/s 7858 succeed, 0 failed, 2364 different pages transhuge-stress: 1.658 s/loop, 0.211 ms/page, 9479.215 MiB/s 7858 succeed, 0 failed, 2179 different pages transhuge-stress: 1.617 s/loop, 0.206 ms/page, 9716.992 MiB/s 7858 succeed, 0 failed, 2421 different pages ^C./transhuge-stress: Interrupt Performance counter stats for './transhuge-stress': 1.744.051 compaction:mm_compaction_isolate_migratepages 1.014 compaction:mm_compaction_isolate_freepages 1.744.051 compaction:mm_compaction_migratepages 1.647 compaction:mm_compaction_begin 1.647 compaction:mm_compaction_end 1.744.051 migrate:mm_migrate_pages 0 migrate:mm_numa_migrate_ratelimit 7,964696835 seconds time elapsed Signed-off-by: Konstantin Khlebnikov Cc: Rafael Aquini Cc: Andrey Ryabinin Cc: Shuah Khan Cc: Andrew Morton --- tools/testing/selftests/vm/Makefile |1 tools/testing/selftests/vm/transhuge-stress.c | 144 + 2 files changed, 145 insertions(+) create mode 100644 tools/testing/selftests/vm/transhuge-stress.c diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile index 3f94e1a..4c4b1f6 100644 --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -3,6 +3,7 @@ CC = $(CROSS_COMPILE)gcc CFLAGS = -Wall BINARIES = hugepage-mmap hugepage-shm map_hugetlb thuge-gen hugetlbfstest +BINARIES += transhuge-stress all: $(BINARIES) %: %.c diff --git a/tools/testing/selftests/vm/transhuge-stress.c b/tools/testing/selftests/vm/transhuge-stress.c new file mode 100644 index 000..fd7f1b4 --- /dev/null +++ b/tools/testing/selftests/vm/transhuge-stress.c @@ -0,0 +1,144 @@ +/* + * Stress test for transparent huge pages, memory compaction and migration. + * + * Authors: Konstantin Khlebnikov + * + * This is free and unencumbered software released into the public domain. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PAGE_SHIFT 12 +#define HPAGE_SHIFT 21 + +#define PAGE_SIZE (1 << PAGE_SHIFT) +#define HPAGE_SIZE (1 << HPAGE_SHIFT) + +#define PAGEMAP_PRESENT(ent) (((ent) & (1ull << 63)) != 0) +#define PAGEMAP_PFN(ent) ((ent) & ((1ull << 55) - 1)) + +int pagemap_fd; + +int64_t allocate_transhuge(void *ptr) +{ + uint64_t ent[2]; + + /* drop pmd */ + if (mmap(ptr, HPAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_FIXED | MAP_ANONYMOUS | + MAP_NORESERVE | MAP_PRIVATE, -1, 0) != ptr) + errx(2, "mmap transhuge"); + + if (madvise(ptr, HPAGE_SIZE, MADV_HUGEPAGE)) + err(2, "MADV_HUGEPAGE"); + + /* allocate transparent huge page */ + *(volatile void **)ptr = ptr; + + if (pread(pagemap_fd, ent, sizeof(ent), + (uintptr_t)ptr >> (PAGE_SHIFT - 3)) != sizeof(ent)) + err(2, "read pagemap"); + + if (PAGEMAP_PRESENT(ent[0]) && PAGEMAP_PRESENT(ent[1]) && + PAGEMAP_PFN(ent[0]) + 1 == PAGEMAP_PFN(ent[1]) && + !(PAGEMAP_PFN(ent[0]) & ((1 << (HPAGE_SHIFT - PAGE_SHIFT)) - 1))) + return PAGEMAP_PFN(ent[0]); + + return -1; +} + +int main(int argc, char **argv) +{ + size_t ram, len; + void *ptr, *p; + struct timespec a, b; + double s; + uint8_t *map; + size_t map_len; + + ram = sysconf(_SC_PHYS_PAGES); + if (ram > SIZE_MAX / sysconf(_SC_PAGESIZE) / 4) + ram = SIZE_MAX / 4; + else + ram *= sysconf(_SC_PAGESIZE); + + if (argc == 1) + len = ram; + else if (!strcmp(argv[1], "-h")) + errx(1, "usage: %s [size in MiB]", argv[0]); + else + len = atoll(argv[1]) << 20; + + warnx("allocate %zd transhuge pages, using %zd MiB virtual memory" + " and %zd MiB of ram", len >> HPAGE_SHIFT, len >> 20, + len >> (20 + HPAGE_SHIFT - PAGE_SHIFT - 1)); + + pagemap_fd = open("/proc/self/pagemap", O_RDONLY); + if (pagemap_fd < 0) + err(2, "open pagemap"); + + len -= len % HPAGE_SIZE; + ptr = mmap(NULL, len + HPAGE_SIZE, PROT_READ | PROT_WRITE, + MAP_ANONYMOUS | MAP_NORESERVE | MAP_PRIVATE, -1, 0); + if (ptr == M
[PATCH v3 0/4] mm/balloon_compaction: fixes and cleanups
Here is reworked and resplitted patchset. patches agains current mmotm. I've merged fixes into first patch. It appyies clearly to v3.16, older kernels has a trivial conflict in mm/migrate.c. Reference counting during isolation and migration of ballooned pages reorganized and now looks similar to scheme used for normal pages (grab extra reference, isolate, migrate, putback/drop extra reference). Changes since v2: * PagePrivate used for fixing race between isolation and deflation * all fixes merged into first patch second patch contains only cleanup third patch adds new interfaces (vmstat, kpageflags) transhuge-stress: no changes except commit message bloat-o-meter (x86_64, defconfig + balloon-compaction): add/remove: 0/7 grow/shrink: 7/9 up/down: 134/-1045 (-911) function old new delta virtballoon_migratepage 322 357 +35 vmstat_text 824 848 +24 vm_event_states 496 520 +24 stable_page_flags378 401 +23 balloon_page_enqueue 138 154 +16 balloon_page_migrate 162 168 +6 balloon_page_dequeue 287 293 +6 leak_balloon 254 246 -8 balloon_page_putback 205 193 -12 __ksymtab_balloon_mapping_alloc 16 - -16 __ksymtab_balloon_devinfo_alloc 16 - -16 virtballoon_remove70 48 -22 __kstrtab_balloon_mapping_alloc 22 - -22 __kstrtab_balloon_devinfo_alloc 22 - -22 balloon_page_isolate 291 243 -48 virtballoon_probe382 318 -64 balloon_devinfo_alloc 96 - -96 isolate_migratepages_block 16821578-104 reclaim_clean_pages_from_list435 330-105 putback_movable_pages312 207-105 migrate_pages 19921875-117 balloon_mapping_alloc128 --128 virtio_balloon_aops 160 --160 even allnoconfig is smaller now: add/remove: 0/3 grow/shrink: 0/0 up/down: 0/-291 (-291) function old new delta balloon_devinfo_alloc 63 - -63 balloon_page_enqueue 82 - -82 balloon_page_dequeue 146 --146 --- Konstantin Khlebnikov (4): mm/balloon_compaction: redesign ballooned pages management mm/balloon_compaction: remove balloon mapping and flag AS_BALLOON_MAP mm/balloon_compaction: add vmstat counters and kpageflags bit selftests/vm/transhuge-stress: stress test for memory compaction drivers/virtio/Kconfig|1 drivers/virtio/virtio_balloon.c | 76 +++ fs/proc/page.c|3 include/linux/balloon_compaction.h| 169 +++-- include/linux/migrate.h | 11 -- include/linux/mm.h| 19 +++ include/linux/pagemap.h | 18 --- include/linux/vm_event_item.h |7 + include/uapi/linux/kernel-page-flags.h|1 mm/Kconfig|7 + mm/Makefile |3 mm/balloon_compaction.c | 123 +++--- mm/compaction.c |2 mm/migrate.c | 16 +- mm/vmstat.c | 12 ++ tools/testing/selftests/vm/Makefile |1 tools/testing/selftests/vm/transhuge-stress.c | 144 + tools/vm/page-types.c |1 18 files changed, 288 insertions(+), 326 deletions(-) create mode 100644 tools/testing/selftests/vm/transhuge-stress.c -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] mm/balloon_compaction: redesign ballooned pages management
From: Konstantin Khlebnikov Sasha Levin reported KASAN splash inside isolate_migratepages_range(). Problem is in the function __is_movable_balloon_page() which tests AS_BALLOON_MAP in page->mapping->flags. This function has no protection against anonymous pages. As result it tried to check address space flags inside struct anon_vma. Further investigation shows more problems in current implementation: * Special branch in __unmap_and_move() never works: balloon_page_movable() checks page flags and page_count. In __unmap_and_move() page is locked, reference counter is elevated, thus balloon_page_movable() always fails. As a result execution goes to the normal migration path. virtballoon_migratepage() returns MIGRATEPAGE_BALLOON_SUCCESS instead of MIGRATEPAGE_SUCCESS, move_to_new_page() thinks this is an error code and assigns newpage->mapping to NULL. Newly migrated page lose connectivity with balloon an all ability for further migration. * lru_lock erroneously required in isolate_migratepages_range() for isolation ballooned page. This function releases lru_lock periodically, this makes migration mostly impossible for some pages. * balloon_page_dequeue have a tight race with balloon_page_isolate: balloon_page_isolate could be executed in parallel with dequeue between picking page from list and locking page_lock. Race is rare because they use trylock_page() for locking. This patch fixes all of them. Instead of fake mapping with special flag this patch uses special state of page->_mapcount: PAGE_BALLOON_MAPCOUNT_VALUE = -256. Buddy allocator uses PAGE_BUDDY_MAPCOUNT_VALUE = -128 for similar purpose. Storing mark directly in struct page makes everything safer and easier. PagePrivate is used to mark pages present in page list (i.e. not isolated, like PageLRU for normal pages). It replaces special rules for reference counter and makes balloon migration similar to migration of normal pages. This flag is protected by page_lock together with link to the balloon device. Signed-off-by: Konstantin Khlebnikov Reported-by: Sasha Levin Link: http://lkml.kernel.org/p/53e6ceaa.9020...@oracle.com Cc: Rafael Aquini Cc: Andrey Ryabinin Cc: Stable (v3.8+) Cc: Andrew Morton --- drivers/virtio/virtio_balloon.c| 15 +++--- include/linux/balloon_compaction.h | 97 +--- include/linux/migrate.h| 11 include/linux/mm.h | 19 +++ mm/balloon_compaction.c| 26 -- mm/compaction.c|2 - mm/migrate.c | 16 +- 7 files changed, 68 insertions(+), 118 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 25ebe8e..c3eb93fc 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -163,8 +163,8 @@ static void release_pages_by_pfn(const u32 pfns[], unsigned int num) /* Find pfns pointing at start of each page, get pages and free them. */ for (i = 0; i < num; i += VIRTIO_BALLOON_PAGES_PER_PAGE) { struct page *page = balloon_pfn_to_page(pfns[i]); - balloon_page_free(page); adjust_managed_page_count(page, 1); + put_page(page); /* balloon reference */ } } @@ -395,6 +395,8 @@ static int virtballoon_migratepage(struct address_space *mapping, if (!mutex_trylock(&vb->balloon_lock)) return -EAGAIN; + get_page(newpage); /* balloon reference */ + /* balloon's page migration 1st step -- inflate "newpage" */ spin_lock_irqsave(&vb_dev_info->pages_lock, flags); balloon_page_insert(newpage, mapping, &vb_dev_info->pages); @@ -404,12 +406,7 @@ static int virtballoon_migratepage(struct address_space *mapping, set_page_pfns(vb->pfns, newpage); tell_host(vb, vb->inflate_vq); - /* -* balloon's page migration 2nd step -- deflate "page" -* -* It's safe to delete page->lru here because this page is at -* an isolated migration list, and this step is expected to happen here -*/ + /* balloon's page migration 2nd step -- deflate "page" */ balloon_page_delete(page); vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE; set_page_pfns(vb->pfns, page); @@ -417,7 +414,9 @@ static int virtballoon_migratepage(struct address_space *mapping, mutex_unlock(&vb->balloon_lock); - return MIGRATEPAGE_BALLOON_SUCCESS; + put_page(page); /* balloon reference */ + + return MIGRATEPAGE_SUCCESS; } /* define the balloon_mapping->a_ops callback to allow balloon page migration */ diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h index 089743a..38aa07d 100644 --- a/include/linux/balloon_compaction.h +++ b/include/linux/balloon_compaction.h @@ -27,10 +27,13 @@ * counter raised only while it is under our special handling; * * iii. after the lockle
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to the source location will fault and cause fresh pages to be mapped in. For consistency, the old_len >= new_len case could decommit the pages instead of unmapping. However, userspace can accomplish the same thing via madvise and a coherent definition of the flag is possible without the extra complexity. Motivation: TCMalloc and jemalloc avoid releasing virtual memory in order to reduce virtual memory fragmentation. A call to munmap or mremap would leave a hole in the address space. Instead, unused pages are lazily returned to the operating system via MADV_DONTNEED. Since mremap cannot be used to elide copies, TCMalloc and jemalloc end up being significantly slower for patterns like repeated vector / hash table reallocations. Consider the typical vector building pattern: #include #include int main(void) { void *ptr = NULL; size_t old_size = 0; for (size_t size = 4; size < (1 << 30); size *= 2) { ptr = realloc(ptr, size); if (!ptr) return 1; memset(ptr + old_size, 0xff, size - old_size); old_size = size; } } glibc: 0.135s jemalloc: 0.226s TCMalloc: 0.238s In practice, in-place growth never occurs because the heap grows in the downwards direction for all 3 allocators. TCMalloc and jemalloc pay for enormous copies while glibc is only spending time writing new elements to the vector. Even if it was grown in the other direction, real-world applications would end up blocking in-place growth with new allocations. The allocators could attempt to map the source location again after an mremap call, but there is no guarantee of success in a multi-threaded program and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay --- include/uapi/linux/mman.h | 1 + mm/mremap.c | 18 +++--- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h index ade4acd..4e9a546 100644 --- a/include/uapi/linux/mman.h +++ b/include/uapi/linux/mman.h @@ -5,6 +5,7 @@ #define MREMAP_MAYMOVE 1 #define MREMAP_FIXED 2 +#define MREMAP_RETAIN 4 #define OVERCOMMIT_GUESS 0 #define OVERCOMMIT_ALWAYS 1 diff --git a/mm/mremap.c b/mm/mremap.c index 05f1180..c01bab6 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -235,7 +235,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, static unsigned long move_vma(struct vm_area_struct *vma, unsigned long old_addr, unsigned long old_len, - unsigned long new_len, unsigned long new_addr, bool *locked) + unsigned long new_len, unsigned long new_addr, bool retain, + bool *locked) { struct mm_struct *mm = vma->vm_mm; struct vm_area_struct *new_vma; @@ -287,6 +288,7 @@ static unsigned long move_vma(struct vm_area_struct *vma, old_len = new_len; old_addr = new_addr; new_addr = -ENOMEM; + retain = false; } /* Conceal VM_ACCOUNT so old reservation is not undone */ @@ -310,7 +312,7 @@ static unsigned long move_vma(struct vm_area_struct *vma, hiwater_vm = mm->hiwater_vm; vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT); - if (do_munmap(mm, old_addr, old_len) < 0) { + if (retain || do_munmap(mm, old_addr, old_len) < 0) { /* OOM: unable to split vma, just get accounts right */ vm_unacct_memory(excess >> PAGE_SHIFT); excess = 0; @@ -392,7 +394,8 @@ Eagain: } static unsigned long mremap_to(unsigned long addr, unsigned long old_len, - unsigned long new_addr, unsigned long new_len, bool *locked) + unsigned long new_addr, unsigned long new_len, bool retain, + bool *locked) { struct mm_struct *mm = current->mm; struct vm_area_struct *vma; @@ -442,7 +445,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len, if (ret & ~PAGE_MASK) goto out1; - ret = move_vma(vma, addr, old_len, new_len, new_addr, locked); + ret = move_vma(vma, addr, old_len, new_len, new_addr, retain, locked); if (!(ret & ~PAGE_MASK)) goto out; out1: @@ -482,7 +485,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, unsigned long charged = 0; bool locked = false; - if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) + if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_RETAIN)) return ret; if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE)) @@ -506,7 +509,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, if (flags & MREMAP_FIXED) {
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Sat, Sep 27, 2014 at 10:56:57AM -0700, Linus Torvalds wrote: > - make a new "move_name(src,dst)" that explicitly moves names, and > explicitly knows that the source needs to be kept alive (although it > *could* also look at the source dentry refcount to decide whether it > needs to be careful or not). And do it right for the long names too, > not just the inline case. Er? Source dentry refcount doesn't matter at all - *that* one gets rehashed, so we must get its name right, no matter what. The target one is where it becomes interesting. And I doubt it's worth bothering with refcount checks on that either, TBH... The reason why we really can't get it right for long names without more serious surgery is that currently the lifetime of external name is the same as of dentry having that name. And that makes "just copy them over, long or not" a problem - we suddenly get two dentries sharing the external name. And we hit that under a shitload of spinlocks, so allocating a separate copy isn't attractive. Mikhail (IIRC - I hadn't watched this thread all that closely back then, so I might be misattributing) had proposed refcounting the external names. That would work, but we'll need to get it right. Sure, we can make that refcount atomic_t; it's not as if we'll be playing with it a lot. However, if the *source* name had been external, we need to drop the refcount on that, and we need to RCU-delay actual freeing. Right now the delay comes from RCU-delaying __d_free(), with some optimisations for dentries that had never been hashed; this will be somewhat hairier. > Al (or Mikhail) - willing to do that extra cleanup? Please? See above. I can do that, but it will be less trivial than you seem to expect it to be. Anyway, the situation right now: vfs.git#for-linus survives the testing (and I'd like your S-o-b on the last one-liner there; if you have saner commit message - even better). That can go in right now, as far as I'm concerned. The minimal port of Mikhail's patch on top of that is below; it doesn't include what you are asking for, it's just an update to the situation past merging __d_move() and __d_materialise_dentry(). We can get the long name cases right, and I agree that it'll make the things nicer, but it might take a couple of days to get right. The thing I'm concerned about is not screwing DCACHE_RCUACCESS up. BTW, the comments about being more careful with ->d_name.hash than with ->d_name.name are from back in 2.3.40s; they became obsolete by 2.3.60s, when we started to unhash the target instead of swapping hash chain positions followed by d_delete() as we used to do when dcache was first introduced. It's a really old piece of detritus... diff --git a/fs/dcache.c b/fs/dcache.c index 7599d35..cb25a1a 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2372,7 +2372,8 @@ void dentry_update_name_case(struct dentry *dentry, struct qstr *name) } EXPORT_SYMBOL(dentry_update_name_case); -static void switch_names(struct dentry *dentry, struct dentry *target) +static void switch_names(struct dentry *dentry, struct dentry *target, +bool exchange) { if (dname_external(target)) { if (dname_external(dentry)) { @@ -2406,6 +2407,12 @@ static void switch_names(struct dentry *dentry, struct dentry *target) */ unsigned int i; BUILD_BUG_ON(!IS_ALIGNED(DNAME_INLINE_LEN, sizeof(long))); + if (!exchange) { + memcpy(dentry->d_iname, target->d_name.name, + target->d_name.len + 1); + dentry->d_name.hash_len = target->d_name.hash_len; + return; + } for (i = 0; i < DNAME_INLINE_LEN / sizeof(long); i++) { swap(((long *) &dentry->d_iname)[i], ((long *) &target->d_iname)[i]); @@ -2456,12 +2463,15 @@ static void dentry_unlock_for_move(struct dentry *dentry, struct dentry *target) * When switching names, the actual string doesn't strictly have to * be preserved in the target - because we're dropping the target * anyway. As such, we can just do a simple memcpy() to copy over - * the new name before we switch. - * - * Note that we have to be a lot more careful about getting the hash - * switched - we have to switch the hash value properly even if it - * then no longer matches the actual (corrupted) string of the target. - * The hash value has to match the hash queue that the dentry is on.. + * the new name before we switch, unless we are going to rehash + * it. Note that if we *do* unhash the target, we are not allowed + * to rehash it without giving it a new name/hash key - whether + * we swap or overwrite the names here, resulting name won't match + * the reality in filesystem; it's only there for d_path() purposes
Re: [PATCH v3 1/3] cap11xx: make driver generic for variant support
On 09/25/2014 07:24 AM, Matt Ranostay wrote: > cap1106 driver can support much more one device make the driver > generic for support of similiar parts. > > Signed-off-by: Matt Ranostay > --- > .../devicetree/bindings/input/cap1106.txt | 53 > .../devicetree/bindings/input/cap11xx.txt | 54 > drivers/input/keyboard/Kconfig | 8 +- > drivers/input/keyboard/Makefile| 2 +- > drivers/input/keyboard/cap1106.c | 341 > - > drivers/input/keyboard/cap11xx.c | 340 > 6 files changed, 399 insertions(+), 399 deletions(-) As I've said, such a patch is really a whole lot more readable if you use the -M switch for git format-patch to detect renames. Other than that, the series now looks good to me. I can't test it, however, as I don't have access to the hardware anymore. Reviewed-by: Daniel Mack Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fork.c: copy_process(): fix cleanup WRT perf_event_free_task()
On 09/26, Sylvain 'ythier' Hitier wrote: > > retval = sched_fork(clone_flags, p); > if (retval) > // // mustn't perf_event_free_task() > goto bad_fork_cleanup_policy; Agreed, this is wrong. Good catch. but, unless I missed something, > retval = perf_event_init_task(p); > if (retval) > // // mustn't perf_event_free_task() ^^ this is not right and thus the patch is not right too. Suppose that perf_event_init_task() -> perf_event_init_context(ctxn => 0) succeeds and then perf_event_init_context(ctxn => 1) fails, we need perf_event_free_task() to cleanup ->perf_event_ctxp[0]. So if perf_event_init_task() fails, we still need "goto bad_fork_cleanup_perf". No? Or, probably better, we need to change perf_event_init_context() to call perf_event_free_task() on failure. Or. We can simply move memset(child->perf_event_ctxp, 0, ...) from perf_event_init_context() up. This reminds that we really need to cleanup copy_process(), in particular I think it asks for the new copy_xxx() helper which should do misc simple initializations which can't fail. What do you think? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to the source location will fault and cause fresh pages to be mapped in. For consistency, the old_len >= new_len case could decommit the pages instead of unmapping. However, userspace can accomplish the same thing via madvise and a coherent definition of the flag is possible without the extra complexity. Motivation: TCMalloc and jemalloc avoid releasing virtual memory in order to reduce virtual memory fragmentation. A call to munmap or mremap would leave a hole in the address space. Instead, unused pages are lazily returned to the operating system via MADV_DONTNEED. Since mremap cannot be used to elide copies, TCMalloc and jemalloc end up being significantly slower for patterns like repeated vector / hash table reallocations. Consider the typical vector building pattern: #include #include int main(void) { void *ptr = NULL; size_t old_size = 0; for (size_t size = 4; size < (1 << 30); size *= 2) { ptr = realloc(ptr, size); if (!ptr) return 1; memset(ptr, 0xff, size - old_size); old_size = size; } } glibc: 0.115s jemalloc: 0.199s TCMalloc: 0.202s In practice, in-place growth never occurs because the heap grows in the downwards direction for all 3 allocators. TCMalloc and jemalloc pay for enormous copies while glibc is only spending time writing new elements to the vector. Even if it was grown in the other direction, real-world applications would end up blocking in-place growth with new allocations. The allocators could attempt to map the source location again after an mremap call, but there is no guarantee of success in a multi-threaded program and fragmentating memory over time is considered unacceptable. Signed-off-by: Daniel Micay --- include/uapi/linux/mman.h | 1 + mm/mremap.c | 18 +++--- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h index ade4acd..4e9a546 100644 --- a/include/uapi/linux/mman.h +++ b/include/uapi/linux/mman.h @@ -5,6 +5,7 @@ #define MREMAP_MAYMOVE 1 #define MREMAP_FIXED 2 +#define MREMAP_RETAIN 4 #define OVERCOMMIT_GUESS 0 #define OVERCOMMIT_ALWAYS 1 diff --git a/mm/mremap.c b/mm/mremap.c index 05f1180..c01bab6 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -235,7 +235,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, static unsigned long move_vma(struct vm_area_struct *vma, unsigned long old_addr, unsigned long old_len, - unsigned long new_len, unsigned long new_addr, bool *locked) + unsigned long new_len, unsigned long new_addr, bool retain, + bool *locked) { struct mm_struct *mm = vma->vm_mm; struct vm_area_struct *new_vma; @@ -287,6 +288,7 @@ static unsigned long move_vma(struct vm_area_struct *vma, old_len = new_len; old_addr = new_addr; new_addr = -ENOMEM; + retain = false; } /* Conceal VM_ACCOUNT so old reservation is not undone */ @@ -310,7 +312,7 @@ static unsigned long move_vma(struct vm_area_struct *vma, hiwater_vm = mm->hiwater_vm; vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT); - if (do_munmap(mm, old_addr, old_len) < 0) { + if (retain || do_munmap(mm, old_addr, old_len) < 0) { /* OOM: unable to split vma, just get accounts right */ vm_unacct_memory(excess >> PAGE_SHIFT); excess = 0; @@ -392,7 +394,8 @@ Eagain: } static unsigned long mremap_to(unsigned long addr, unsigned long old_len, - unsigned long new_addr, unsigned long new_len, bool *locked) + unsigned long new_addr, unsigned long new_len, bool retain, + bool *locked) { struct mm_struct *mm = current->mm; struct vm_area_struct *vma; @@ -442,7 +445,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len, if (ret & ~PAGE_MASK) goto out1; - ret = move_vma(vma, addr, old_len, new_len, new_addr, locked); + ret = move_vma(vma, addr, old_len, new_len, new_addr, retain, locked); if (!(ret & ~PAGE_MASK)) goto out; out1: @@ -482,7 +485,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, unsigned long charged = 0; bool locked = false; - if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) + if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_RETAIN)) return ret; if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE)) @@ -506,7 +509,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, if (flags & MREMAP_FIXED) { ret = m
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Fri, Sep 26, 2014 at 9:45 PM, Al Viro wrote: > > Linus, it's a real userland regression. That's not the part I'm arguing against. I think the patch itself was too ugly to live. Yes, we had that hack before, but we didn't make it conditional. It historically was more of a "it's easier to just memcpy the name" than switch things around. Then that became accidental semantics, and that's all normal. But then when we make this explicit and intentional, I really think we should do it *right*, and either switch() the names around or just copy it. Having a "switch_names()" function that *neither* switches *nor* copies, and giving it an argument to decide which, but not even do it *right*? That's just too f*cking disgusting for words. So seriously, I think we should: - keep the "switch_names()" as is, since it actually does what the name says it does, and some callers want to statically do exactly that. - make a new "move_name(src,dst)" that explicitly moves names, and explicitly knows that the source needs to be kept alive (although it *could* also look at the source dentry refcount to decide whether it needs to be careful or not). And do it right for the long names too, not just the inline case. - make that __d_move() caller just pick one or the other explicitly. See what my complaint is? Not this half-assery that used to be a small random detail, and that the patch makes into an institutionalized and explicit half-assery. (And Mikhail - I'm not ragging on you, even if I'm ragging on the patch. I understand why you did it the way you did, and it makes sense exactly in the "let's reinstate old hackery" model. I just think we can and should do better than that, now that the "exchange" vs "move over" semantics are so explicit). Al (or Mikhail) - willing to do that extra cleanup? Please? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf: Userspace software event and ioctl
2014-09-25 20:33 GMT+02:00 Ingo Molnar : > > * Pawel Moll wrote: > >> On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote: >> > * Pawel Moll wrote: >> > >> > > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote: >> > > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type, >> > > > which can be generated by user with PERF_EVENT_IOC_ENTRY >> > > > ioctl command, which injects an event of said type into >> > > > the perf buffer. >> > > >> > > It occurred to me last night that currently perf doesn't handle "write" >> > > syscall at all, while this seems like the most natural way of >> > > "injecting" userspace events into perf buffer. >> > > >> > > An ioctl would still be needed to set a type of the following events, >> > > something like: >> > > >> > > ioctl(SET_TYPE, 0x42); >> > > write(perf_fd, binaryblob, size); >> > > ioctl(SET_TYPE, 0); >> > > dprintf(perf_fd, "String"); >> > > >> > > which is fine for use cases when the type doesn't change often, >> > > but would double the amount of syscalls when every single event >> > > is of a different type. Perhaps there still should be a >> > > "generating ioctl" taking both type and data/size in one go? >> > >> > Absolutely, there should be a single syscall. >> >> Yeah, it's my gut feeling as well. I just wonder if we still want to >> keep write() handler for operations on perf fds? This seems natural - >> takes data buffer and its size. The only issue is the type. >> >> > I'd even argue it should be a new prctl(): that way we could both >> > generate user events for specific perf fds, but also into any >> > currently active context (that allows just generation/injection >> > of user events). In the latter case we might have no fd to work >> > off from. >> >> When Arnaldo suggested that the "user events" could be used by perf >> trace, it was exactly my first thought. I just didn't have answer how to >> present it to the user (an extra syscall didn't seem like a good idea), >> but prctl seems interesting, something like this? >> >> prctl(PR_TRACE_UEVENT, type, size, data, 0); > > Exactly! > >> How would we select tasks that can write to a given buffer? Maybe an >> ioctl() on a perf fd? Something like this? >> >> ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid); >> ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid); > > No, I think there's a simpler way: this should be a regular > perf_attr flag, which defaults to '0' (tasks cannot do this), but > which can be set to 1 if the profiler explicitly allows such > event injection. Maybe we just don't even need any permission at all. Which harm can that do if this only ever generate events to those interested in the relevant perf context? It could be a simple tracepoint BTW. Oh and I really like the fact we don't use a syscall that requires an fd. The tracee really shouldn't be aware of the tracer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86: irq: Duplicate interrupt name THR
Hello. The interrupt name "THR" used twice for x86 architecture. It is used for "Threshold APIC interrupts" and "Hypervisor callback interrupts". I don't know if duplicates are a valid for /proc/interrupt table, but this could lead to problems with user space applications, as they have to parse not only interrupt name, but a description too. The duplicate was introduced by commit 929320e4b4c10708d3477d7e395f0ce7b0cc8744 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched/nohz: add debugfs control over sched_tick_max_deferment
On Fri, Sep 26, 2014 at 12:45:32PM -0700, Kevin Hilman wrote: > From: Kevin Hilman > > Allow debugfs override of sched_tick_max_deferment in order to ease > finding/fixing the remaining issues with full nohz. > > The value to be written is in jiffies, and -1 means the max deferment > is disabled (scheduler_tick_max_deferment() returns KTIME_MAX.) > > Cc: Frederic Weisbecker > Signed-off-by: Kevin Hilman So, I'm worried that it becomes a hack that everybody uses to shutdown the tick completely then nobody will come and fix the issue that prevents from doing it properly. I seriously doubt this will be used for development purpose to help fixing the real problem. Quite the opposite. If developers want to do testing, they can as well comment out the call to scheduler_max_tick_deferment(). > --- > kernel/sched/core.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index bc1638b33449..dee044a5d447 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -2514,6 +2514,8 @@ void scheduler_tick(void) > } > > #ifdef CONFIG_NO_HZ_FULL > +static u32 sched_tick_max_deferment = HZ; > + > /** > * scheduler_tick_max_deferment > * > @@ -2532,13 +2534,25 @@ u64 scheduler_tick_max_deferment(void) > struct rq *rq = this_rq(); > unsigned long next, now = ACCESS_ONCE(jiffies); > > - next = rq->last_sched_tick + HZ; > + if (sched_tick_max_deferment == -1) > + return KTIME_MAX; > + > + next = rq->last_sched_tick + sched_tick_max_deferment; > > if (time_before_eq(next, now)) > return 0; > > return jiffies_to_nsecs(next - now); > } > + > +static __init int sched_nohz_full_init_debug(void) > +{ > + debugfs_create_u32("sched_tick_max_deferment", 0644, NULL, > +&sched_tick_max_deferment); > + > + return 0; > +} > +late_initcall(sched_nohz_full_init_debug); > #endif > > notrace unsigned long get_parent_ip(unsigned long addr) > -- > 2.1.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 02/16] perf, core: introduce pmu context switch callback
On Sun, Jan 07, 2001 at 09:29:31PM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > The callback is invoked when process is scheduled in or out. > It provides mechanism for later patches to save/store the LBR > stack. For the schedule in case, the callback is invoked at > the same place that flush branch stack callback is invoked. > So it also can replace the flush branch stack callback. To > avoid unnecessary overhead, the callback is enabled only when > there are events use the LBR stack. > > Signed-off-by: Yan, Zheng > --- > arch/x86/kernel/cpu/perf_event.c | 7 + > arch/x86/kernel/cpu/perf_event.h | 2 ++ > include/linux/perf_event.h | 10 +++ > kernel/events/core.c | 59 > > 4 files changed, 78 insertions(+) > > diff --git a/arch/x86/kernel/cpu/perf_event.c > b/arch/x86/kernel/cpu/perf_event.c > index 0646d3b..4c572e8 100644 > --- a/arch/x86/kernel/cpu/perf_event.c > +++ b/arch/x86/kernel/cpu/perf_event.c > @@ -1877,6 +1877,12 @@ static const struct attribute_group > *x86_pmu_attr_groups[] = { > NULL, > }; > > +static void x86_pmu_sched_task(struct perf_event_context *ctx, bool sched_in) > +{ > + if (x86_pmu.sched_task) > + x86_pmu.sched_task(ctx, sched_in); > +} > + > static void x86_pmu_flush_branch_stack(void) > { > if (x86_pmu.flush_branch_stack) > @@ -1910,6 +1916,7 @@ static struct pmu pmu = { > > .event_idx = x86_pmu_event_idx, > .flush_branch_stack = x86_pmu_flush_branch_stack, > + .sched_task = x86_pmu_sched_task, > }; > > void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now) > diff --git a/arch/x86/kernel/cpu/perf_event.h > b/arch/x86/kernel/cpu/perf_event.h > index 86c675c..0617abb 100644 > --- a/arch/x86/kernel/cpu/perf_event.h > +++ b/arch/x86/kernel/cpu/perf_event.h > @@ -467,6 +467,8 @@ struct x86_pmu { > > void(*check_microcode)(void); > void(*flush_branch_stack)(void); > + void(*sched_task)(struct perf_event_context *ctx, > + bool sched_in); > > /* >* Intel Arch Perfmon v2+ > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index 893a0d0..be0e870 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -263,6 +263,14 @@ struct pmu { >* flush branch stack on context-switches (needed in cpu-wide mode) >*/ > void (*flush_branch_stack) (void); > + > + /* > + * context-switches callback for CPU PMU. Other PMUs shouldn't set > + * this callback > + */ > + void (*sched_task) (struct perf_event_context *ctx, > + bool sched_in); > + > }; > > /** > @@ -562,6 +570,8 @@ extern void perf_event_delayed_put(struct task_struct > *task); > extern void perf_event_print_debug(void); > extern void perf_pmu_disable(struct pmu *pmu); > extern void perf_pmu_enable(struct pmu *pmu); > +extern void perf_sched_cb_disable(struct pmu *pmu); > +extern void perf_sched_cb_enable(struct pmu *pmu); > extern int perf_event_task_disable(void); > extern int perf_event_task_enable(void); > extern int perf_event_refresh(struct perf_event *event, int refresh); > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 1212cc4..15d640e 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -154,6 +154,7 @@ enum event_type_t { > struct static_key_deferred perf_sched_events __read_mostly; > static DEFINE_PER_CPU(atomic_t, perf_cgroup_events); > static DEFINE_PER_CPU(atomic_t, perf_branch_stack_events); > +static DEFINE_PER_CPU(int, perf_sched_cb_usages); > > static atomic_t nr_mmap_events __read_mostly; > static atomic_t nr_comm_events __read_mostly; > @@ -2427,6 +2428,58 @@ unlock: > } > } > > +void perf_sched_cb_disable(struct pmu *pmu) > +{ > + this_cpu_dec(perf_sched_cb_usages); > +} > + > +void perf_sched_cb_enable(struct pmu *pmu) > +{ > + this_cpu_inc(perf_sched_cb_usages); > +} > + > +/* > + * This function provides the context switch callback to the lower code > + * layer. It is invoked ONLY when the context switch callback is enabled. > + */ > +static void perf_pmu_sched_task(struct task_struct *prev, > + struct task_struct *next, > + bool sched_in) > +{ > + struct perf_cpu_context *cpuctx; > + struct pmu *pmu; > + unsigned long flags; > + > + if (prev == next) > + return; > + > + local_irq_save(flags); > + > + rcu_read_lock(); > + > + list_for_each_entry_rcu(pmu, &pmus, entry) { > + if (pmu->sched_task) { > + cpuctx = this_cpu_ptr(pmu->pmu_cpu_context); > + > + perf_ctx_lock(cpuctx, cpuctx->task_ctx); > + > + perf_pmu_disable(pmu); > + > +
Re: [PATCH 2/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omapfb
On Fri, Sep 26, 2014 at 06:10:53PM -0700, Behan Webster wrote: > Replace the use of nested functions where a normal function will suffice. > > Nested functions are not liked by upstream kernel developers in general. Their > use breaks the use of clang as a compiler, and doesn't make the code any > better. > > This code now works for both gcc and clang. > > Signed-off-by: Behan Webster > Suggested-by: Arnd Bergmann > Cc: Arnd Bergmann Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss
On Fri, Sep 26, 2014 at 06:10:52PM -0700, Behan Webster wrote: > Replace the use of nested functions where a normal function will suffice. > > Nested functions are not liked by upstream kernel developers in general. Their > use breaks the use of clang as a compiler, and doesn't make the code any > better. > > This code now works for both gcc and clang. > > Signed-off-by: Behan Webster > Suggested-by: Arnd Bergmann > Cc: Arnd Bergmann another one that make sense :-) And probably also deserves checkpatch/coccinelle/sparse. Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
[PATCH 1/1 linux-next] fs/hfs/hfs_fs.h: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h Cc: Andrew Morton Signed-off-by: Fabian Frederick --- fs/hfs/hfs_fs.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h index 0524cda..95d2552 100644 --- a/fs/hfs/hfs_fs.h +++ b/fs/hfs/hfs_fs.h @@ -242,8 +242,6 @@ extern int hfs_mac2asc(struct super_block *, char *, const struct hfs_name *); /* super.c */ extern void hfs_mark_mdb_dirty(struct super_block *sb); -extern struct timezone sys_tz; - /* * There are two time systems. Both are based on seconds since * a particular time/date. -- 1.9.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 v1 2/3] ARM: dts: rockchip: Enable power off in pmic for Radxa Rock
Add "active-semi,system-power-controller" property to act8846 node. shutdown/poweroff commands are now handled for this board. Signed-off-by: Romain Perier --- arch/arm/boot/dts/rk3188-radxarock.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts index e04bf8f..5b6a937 100644 --- a/arch/arm/boot/dts/rk3188-radxarock.dts +++ b/arch/arm/boot/dts/rk3188-radxarock.dts @@ -115,6 +115,8 @@ pinctrl-names = "default"; pinctrl-0 = <&act8846_dvs0_ctl>; + active-semi,system-power-controller; + regulators { vcc_ddr: REG1 { regulator-name = "VCC_DDR"; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 3/3] dt-bindings: Document the property system-power-controller for act8865 regulator
Signed-off-by: Romain Perier --- Documentation/devicetree/bindings/regulator/act8865-regulator.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index 865614b..653ddc1 100644 --- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt @@ -5,6 +5,10 @@ Required properties: - compatible: "active-semi,act8846" or "active-semi,act8865" - reg: I2C slave address +Optional properties: +- active-semi,system-power-controller: Telling whether or not this pmic is controlling + the system power + Any standard regulator properties can be used to configure the single regulator. The valid names for regulators are: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/3] regulator: act8865: Add support to turn off all outputs
When the property "active-semi,system-power-controller" is found in the devicetree, the function pm_power_off is defined. This function sends the rights bit fields to the global off control register. shutdown/poweroff commands are now supported for hardware components which use these PMU. Signed-off-by: Romain Perier --- drivers/regulator/act8865-regulator.c | 29 + 1 file changed, 29 insertions(+) diff --git a/drivers/regulator/act8865-regulator.c b/drivers/regulator/act8865-regulator.c index afd06f9..6cf202d 100644 --- a/drivers/regulator/act8865-regulator.c +++ b/drivers/regulator/act8865-regulator.c @@ -61,6 +61,8 @@ #defineACT8846_REG12_VSET 0xa0 #defineACT8846_REG12_CTRL 0xa1 #defineACT8846_REG13_CTRL 0xb1 +#defineACT8846_GLB_OFF_CTRL0xc3 +#defineACT8846_OFF_SYSMASK 0x18 /* * ACT8865 Global Register Map. @@ -84,6 +86,7 @@ #defineACT8865_LDO3_CTRL 0x61 #defineACT8865_LDO4_VSET 0x64 #defineACT8865_LDO4_CTRL 0x65 +#defineACT8865_MSTROFF 0x20 /* * Field Definitions. @@ -98,6 +101,8 @@ struct act8865 { struct regmap *regmap; + int off_reg; + int off_mask; }; static const struct regmap_config act8865_regmap_config = { @@ -275,6 +280,16 @@ static struct regulator_init_data return NULL; } +static struct i2c_client *act8865_i2c_client; +static void act8865_power_off(void) +{ + struct act8865 *act8865; + + act8865 = i2c_get_clientdata(act8865_i2c_client); + regmap_write(act8865->regmap, act8865->off_reg, act8865->off_mask); + while (1); +} + static int act8865_pmic_probe(struct i2c_client *client, const struct i2c_device_id *i2c_id) { @@ -285,6 +300,7 @@ static int act8865_pmic_probe(struct i2c_client *client, int i, ret, num_regulators; struct act8865 *act8865; unsigned long type; + int off_reg, off_mask; pdata = dev_get_platdata(dev); @@ -304,10 +320,14 @@ static int act8865_pmic_probe(struct i2c_client *client, case ACT8846: regulators = act8846_regulators; num_regulators = ARRAY_SIZE(act8846_regulators); + off_reg = ACT8846_GLB_OFF_CTRL; + off_mask = ACT8846_OFF_SYSMASK; break; case ACT8865: regulators = act8865_regulators; num_regulators = ARRAY_SIZE(act8865_regulators); + off_reg = ACT8865_SYS_CTRL; + off_mask = ACT8865_MSTROFF; break; default: dev_err(dev, "invalid device id %lu\n", type); @@ -345,6 +365,15 @@ static int act8865_pmic_probe(struct i2c_client *client, return ret; } + if (dev->of_node && + of_property_read_bool(dev->of_node, + "active-semi,system-power-controller")) { + act8865_i2c_client = client; + act8865->off_reg = off_reg; + act8865->off_mask = off_mask; + pm_power_off = act8865_power_off; + } + /* Finally register devices */ for (i = 0; i < num_regulators; i++) { const struct regulator_desc *desc = ®ulators[i]; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 linux-next] udf: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h Cc: Jan Kara Signed-off-by: Fabian Frederick --- fs/udf/udftime.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/udf/udftime.c b/fs/udf/udftime.c index 1f11483..77c331f 100644 --- a/fs/udf/udftime.c +++ b/fs/udf/udftime.c @@ -81,8 +81,6 @@ static time_t year_seconds[MAX_YEAR_SECONDS] = { /*2038*/ SPY(68, 17, 0) }; -extern struct timezone sys_tz; - #define SECS_PER_HOUR (60 * 60) #define SECS_PER_DAY (SECS_PER_HOUR * 24) -- 1.9.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 1/1 linux-next] fs/ncpfs/dir.c: remove redundant sys_tz declaration
sys_tz is already declared in include/linux/time.h Cc: Petr Vandrovec Cc: Andrew Morton Signed-off-by: Fabian Frederick --- fs/ncpfs/dir.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c index 08b8ea8..1beb761 100644 --- a/fs/ncpfs/dir.c +++ b/fs/ncpfs/dir.c @@ -1182,9 +1182,6 @@ static int day_n[] = {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 0, 0, 0, 0}; /* Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec */ - -extern struct timezone sys_tz; - static int utc2local(int time) { return time - sys_tz.tz_minuteswest * 60; -- 1.9.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 1/1 linux-next] fs/affs: remove redundant sys_tz declarations
sys_tz is already declared in include/linux/time.h Cc: Andrew Morton Signed-off-by: Fabian Frederick --- fs/affs/amigaffs.c | 2 -- fs/affs/inode.c| 1 - fs/affs/super.c| 2 -- 3 files changed, 5 deletions(-) diff --git a/fs/affs/amigaffs.c b/fs/affs/amigaffs.c index 406b298..abc8539 100644 --- a/fs/affs/amigaffs.c +++ b/fs/affs/amigaffs.c @@ -10,8 +10,6 @@ #include "affs.h" -extern struct timezone sys_tz; - static char ErrorBuffer[256]; /* diff --git a/fs/affs/inode.c b/fs/affs/inode.c index bec2d1a..31c2e37 100644 --- a/fs/affs/inode.c +++ b/fs/affs/inode.c @@ -14,7 +14,6 @@ #include "affs.h" extern const struct inode_operations affs_symlink_inode_operations; -extern struct timezone sys_tz; struct inode *affs_iget(struct super_block *sb, unsigned long ino) { diff --git a/fs/affs/super.c b/fs/affs/super.c index 51f1a95..314b3ff 100644 --- a/fs/affs/super.c +++ b/fs/affs/super.c @@ -20,8 +20,6 @@ #include #include "affs.h" -extern struct timezone sys_tz; - static int affs_statfs(struct dentry *dentry, struct kstatfs *buf); static int affs_remount (struct super_block *sb, int *flags, char *data); -- 1.9.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/
Re: [PATCH] mm/slab: use IS_ENABLED() instead of ZONE_DMA_FLAG
On Sat, 27 Sep 2014, Paul Bolle wrote: > Do your comments require the patch to be redone (partially or entirely)? > In that case someone else should probably take it and improve it, as I > hardly understand the issues you raise. Or is the patch already queued > somewhere, with Cristoph's Ack attached? Please respin the patch taking Johannes feedback into consideration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Remove GFP_DMA and GFP_DMA32 from flags before passing it into kmalloc.
On 27 Sep 2014, at 16:09, Miles MH Chen wrote: > Signed-off-by: Min-Hua Chen > --- > arch/arm64/mm/dma-mapping.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c > index 4164c5a..273cf6d 100644 > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c > @@ -103,7 +103,8 @@ static void *__dma_alloc_noncoherent(struct device *dev, > size_t size, > ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs); > if (!ptr) > goto no_mem; > -map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA); > +map = kmalloc(sizeof(struct page *) << order, > +flags & ~(GFP_DMA | GFP_DMA32)); Do you have an explanation on why this is needed (and such explanation should also be included in the commit log)? We don’t use ZONE_DMA32 on arm64 (we did initially but it was for the wrong reasons). Thanks, Catalin-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/