[REPOST PATCH] autofs - remove autofs dentry mount check
From: David Jeffery
When checking if an autofs mount point is busy it isn't sufficient to
only check if it's a mount point.
For example, if the mount of an offset mountpoint in a tree is denied
for this host by its export and the dentry becomes a process working
directory the check incorrectly returns the mount as not in use at expire.
This can happen since the default when mounting within a tree is nostrict,
which means ingnore mount fails on mounts within the tree and continue. The
nostrict option is meant to allow mounting in this case.
Signed-off-by: David Jeffery
Signed-off-by: Ian Kent
Cc: sta...@vger.kernel.org
---
fs/autofs4/expire.c |9 -
1 file changed, 9 deletions(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 01443ce..13ddec9 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -61,15 +61,6 @@ static int autofs4_mount_busy(struct vfsmount *mnt, struct
dentry *dentry)
/* This is an autofs submount, we can't expire it */
if (autofs_type_indirect(sbi->type))
goto done;
-
- /*
-* Otherwise it's an offset mount and we need to check
-* if we can umount its mount, if there is one.
-*/
- if (!d_mountpoint(path.dentry)) {
- status = 0;
- goto done;
- }
}
/* Update the expiry counter if fs is busy */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[REPOST PATCH] autofs - fix sparse warning for autofs4_d_manage()
From: Claudiu Ghioc
Fixed the sparse warning:
* "fs/autofs4/root.c:411:5: warning:
symbol 'autofs4_d_manage' was not declared.
Should it be static?"
edit: imk
Clearly it should be static as the function is declared static at
the top of root.c.
end edit: imk
Signed-off-by: Claudiu Ghioc
Signed-off-by: Ian Kent
---
fs/autofs4/root.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 9bd1625..085da86 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -408,7 +408,7 @@ done:
return NULL;
}
-int autofs4_d_manage(struct dentry *dentry, bool rcu_walk)
+static int autofs4_d_manage(struct dentry *dentry, bool rcu_walk)
{
struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
struct autofs_info *ino = autofs4_dentry_ino(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 v5 7/7] sched: consider runnable load average in effective_load
On 05/06/2013 11:34 AM, Michael Wang wrote: >> > @@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg, >> > int cpu, long wl, long wg) >> >/* >> > * w = rw_i + @wl >> > */ >> > - w = se->my_q->load.weight + wl; >> > + w = se->my_q->tg_load_contrib + wl; > I've tested the patch set, seems like the last patch caused big > regression on pgbench: > > basepatch 1~6 patch 1~7 > | db_size | clients | tps | | tps | | tps | > +-+-+---+ +---+ +---+ > | 22 MB | 32 | 43420 | | 53387 | | 41625 | > > I guess some magic thing happened in effective_load() while calculating > group decay combined with load decay, what's your opinion? thanks for testing, Michael! Maybe 2 fix worth to try. 1, change back the tg_weight in calc_tg_weight() to use tg_load_contrib not direct load. diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6f4f14b..c770f8d 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1037,8 +1037,8 @@ static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq) * update_cfs_rq_load_contribution(). */ tg_weight = atomic64_read(>load_avg); - tg_weight -= cfs_rq->tg_load_contrib; - tg_weight += cfs_rq->load.weight; + //tg_weight -= cfs_rq->tg_load_contrib; + //tg_weight += cfs_rq->load.weight; return tg_weight; } 2, another try is follow the current calc_tg_weight, so remove the follow change. >> > @@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg, >> > int cpu, long wl, long wg) >> >/* >> > * w = rw_i + @wl >> > */ >> > - w = se->my_q->load.weight + wl; >> > + w = se->my_q->tg_load_contrib + wl; Would you like to try them? -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/7] sched: consider runnable load average in effective_load
Hi, Alex
On 05/06/2013 09:45 AM, Alex Shi wrote:
> effective_load calculates the load change as seen from the
> root_task_group. It needs to engage the runnable average
> of changed task.
[snip]
> */
> @@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg, int
> cpu, long wl, long wg)
> /*
>* w = rw_i + @wl
>*/
> - w = se->my_q->load.weight + wl;
> + w = se->my_q->tg_load_contrib + wl;
I've tested the patch set, seems like the last patch caused big
regression on pgbench:
basepatch 1~6 patch 1~7
| db_size | clients | tps | | tps | | tps |
+-+-+---+ +---+ +---+
| 22 MB | 32 | 43420 | | 53387 | | 41625 |
I guess some magic thing happened in effective_load() while calculating
group decay combined with load decay, what's your opinion?
Regards,
Michael Wang
>
> /*
>* wl = S * s'_i; see (2)
> @@ -3066,7 +3066,7 @@ static long effective_load(struct task_group *tg, int
> cpu, long wl, long wg)
> /*
>* wl = dw_i = S * (s'_i - s_i); see (3)
>*/
> - wl -= se->load.weight;
> + wl -= se->avg.load_avg_contrib;
>
> /*
>* Recursively apply this logic to all parent groups to compute
> @@ -3112,14 +3112,14 @@ static int wake_affine(struct sched_domain *sd,
> struct task_struct *p, int sync)
>*/
> if (sync) {
> tg = task_group(current);
> - weight = current->se.load.weight;
> + weight = current->se.avg.load_avg_contrib;
>
> this_load += effective_load(tg, this_cpu, -weight, -weight);
> load += effective_load(tg, prev_cpu, 0, -weight);
> }
>
> tg = task_group(p);
> - weight = p->se.load.weight;
> + weight = p->se.avg.load_avg_contrib;
>
> /*
>* In low-load situations, where prev_cpu is idle and this_cpu is idle
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 05/21] sched: log the cpu utilization at rq
On 05/06/2013 11:26 AM, Preeti U Murthy wrote: > Hi Alex, > > You can add my Reviewed-by for the below patch. > > Thanks Thanks a lot for the review! -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARC: Remove non existent reference to GENERIC_KERNEL_EXECVE & GENERIC_KERNEL_THREAD
On 05/05/2013 05:27 PM, Alexander Shiyan wrote: > Signed-off-by: Alexander Shiyan Applied to my for-curr for 3.10 (to be pushed to Linus is a day or two). Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages
On 05/04/2013 08:52 AM, Marcelo Tosatti wrote:
> On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
>> On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
>>> On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
>> +
>> +/*
>> + * Fast invalid all shadow pages belong to @slot.
>> + *
>> + * @slot != NULL means the invalidation is caused the memslot specified
>> + * by @slot is being deleted, in this case, we should ensure that rmap
>> + * and lpage-info of the @slot can not be used after calling the
>> function.
>> + *
>> + * @slot == NULL means the invalidation due to other reasons, we need
>> + * not care rmap and lpage-info since they are still valid after calling
>> + * the function.
>> + */
>> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
>> + struct kvm_memory_slot *slot)
>> +{
>> +spin_lock(>mmu_lock);
>> +kvm->arch.mmu_valid_gen++;
>> +
>> +/*
>> + * All shadow paes are invalid, reset the large page info,
>> + * then we can safely desotry the memslot, it is also good
>> + * for large page used.
>> + */
>> +kvm_clear_all_lpage_info(kvm);
>
> Xiao,
>
> I understood it was agreed that simple mmu_lock lockbreak while
> avoiding zapping of newly instantiated pages upon a
>
> if(spin_needbreak)
> cond_resched_lock()
>
> cycle was enough as a first step? And then later introduce root zapping
> along with measurements.
>
> https://lkml.org/lkml/2013/4/22/544
Yes, it is.
See the changelog in 0/0:
" we use lock-break technique to zap all sptes linked on the
invalid rmap, it is not very effective but good for the first step."
Thanks!
>>>
>>> Sure, but what is up with zeroing kvm_clear_all_lpage_info(kvm) and
>>> zapping the root? Only lock-break technique along with generation number
>>> was what was agreed.
>>
>> Marcelo,
>>
>> Please Wait... I am completely confused. :(
>>
>> Let's clarify "zeroing kvm_clear_all_lpage_info(kvm) and zapping the root"
>> first.
>> Are these changes you wanted?
>>
>> void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
>> struct kvm_memory_slot *slot)
>> {
>> spin_lock(>mmu_lock);
>> kvm->arch.mmu_valid_gen++;
>>
>> /* Zero all root pages.*/
>> restart:
>> list_for_each_entry_safe(sp, node, >arch.active_mmu_pages, link) {
>> if (!sp->root_count)
>> continue;
>>
>> if (kvm_mmu_prepare_zap_page(kvm, sp, _list))
>> goto restart;
>> }
>>
>> /*
>> * All shadow paes are invalid, reset the large page info,
>> * then we can safely desotry the memslot, it is also good
>> * for large page used.
>> */
>> kvm_clear_all_lpage_info(kvm);
>>
>> kvm_mmu_commit_zap_page(kvm, _list);
>> spin_unlock(>mmu_lock);
>> }
>>
>> static void rmap_remove(struct kvm *kvm, u64 *spte)
>> {
>> struct kvm_mmu_page *sp;
>> gfn_t gfn;
>> unsigned long *rmapp;
>>
>> sp = page_header(__pa(spte));
>> +
>> + /* Let invalid sp do not access its rmap. */
>> +if (!sp_is_valid(sp))
>> +return;
>> +
>> gfn = kvm_mmu_page_get_gfn(sp, spte - sp->spt);
>> rmapp = gfn_to_rmap(kvm, gfn, sp->role.level);
>> pte_list_remove(spte, rmapp);
>> }
>>
>> If yes, there is the reason why we can not do this that i mentioned before:
>>
>> after call kvm_mmu_invalid_memslot_pages(), the memslot->rmap will be
>> destroyed.
>> Later, if host reclaim page, the mmu-notify handlers, ->invalidate_page and
>> ->invalidate_range_start, can not find any spte using the host page, then
>> Accessed/Dirty for host page is missing tracked.
>> (missing call kvm_set_pfn_accessed and kvm_set_pfn_dirty properly.)
>>
>> What's your idea?
>
>
> Step 1) Fix kvm_mmu_zap_all's behaviour: introduce lockbreak via
> spin_needbreak. Use generation numbers so that in case kvm_mmu_zap_all
> releases mmu_lock and reacquires it again, only shadow pages
> from the generation with which kvm_mmu_zap_all started are zapped (this
> guarantees forward progress and eventual termination).
>
> kvm_mmu_zap_generation()
> spin_lock(mmu_lock)
> int generation = kvm->arch.mmu_generation;
>
> for_each_shadow_page(sp) {
> if (sp->generation == kvm->arch.mmu_generation)
> zap_page(sp)
> if (spin_needbreak(mmu_lock)) {
> kvm->arch.mmu_generation++;
> cond_resched_lock(mmu_lock);
> }
> }
>
> kvm_mmu_zap_all()
> spin_lock(mmu_lock)
> for_each_shadow_page(sp) {
> if (spin_needbreak(mmu_lock)) {
>
linux-next: Tree for May 6
Hi all, Please do not add any v3.11 destined work to your linux-next included branches until after v3.10-rc1 is released. I am receiving a (un)reasonable number of conflicts from there being multiple copies of some commits in various trees. Please clean this up and resist the temptataion to rebase your trees on the way to your upstream ... Changes since 20130506: The akpm tree gained a conflict against Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 224 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (d7ab730 Merge tag 'mfd-3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next) Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (a54292f kbuild: generate generic headers before recursing into scripts) Merging arc-current/for-curr (d403710 ARC: [mm] Lazy D-cache flush (non aliasing VIPT)) Merging arm-current/fixes (1783d45 ARM: 7700/2: Make cpu_init() notrace) Merging m68k-current/for-linus (e00c73e m68k: Remove inline strlen() implementation) Merging powerpc-merge/merge (01227a8 Merge tag 'kvm-3.10-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging sparc/master (f8ce1fa Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux) Merging net/master (efeaa55 tcp: do not expire TCP fastopen cookies) Applying: drivers:net: fix up for code movement from rt2x00pci.c Merging ipsec/master (da241ef Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (4ca231b ALSA: usb-audio: caiaq: fix endianness bug in snd_usb_caiaq_maschine_dispatch) Merging pci-current/for-linus (d46fc8b x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0) Merging wireless/master (db17834 ath5k: do not reschedule tx_complete_work on stop) Merging driver-core.current/driver-core-linus (c1be5a5 Linux 3.9) Merging tty.current/tty-linus (c1be5a5 Linux 3.9) Merging usb.current/usb-linus (c1be5a5 Linux 3.9) Merging staging.current/staging-linus (c1be5a5 Linux 3.9) Merging char-misc.current/char-misc-linus (c1be5a5 Linux 3.9) Merging input-current/for-linus (bf61c88 Merge branch 'next' into for-linus) Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks of hybid raid1/raid10 array) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (3862de1 crypto: caam - fix job ring cleanup code) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (ab28698 of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS) Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error) Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix ichx_gpio_check_available() return
[PATCH 4/4] hwrng: tx4939 - remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/char/hw_random/tx4939-rng.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/char/hw_random/tx4939-rng.c b/drivers/char/hw_random/tx4939-rng.c index d34a24a..00593c8 100644 --- a/drivers/char/hw_random/tx4939-rng.c +++ b/drivers/char/hw_random/tx4939-rng.c @@ -154,7 +154,6 @@ static int __exit tx4939_rng_remove(struct platform_device *dev) struct tx4939_rng *rngdev = platform_get_drvdata(dev); hwrng_unregister(>rng); - platform_set_drvdata(dev, NULL); return 0; } -- 1.7.2.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 3/4] hwrng: timeriomem - remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/char/hw_random/timeriomem-rng.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/timeriomem-rng.c b/drivers/char/hw_random/timeriomem-rng.c index 3e75737..d2120ba 100644 --- a/drivers/char/hw_random/timeriomem-rng.c +++ b/drivers/char/hw_random/timeriomem-rng.c @@ -192,7 +192,6 @@ out_release_io: out_timer: del_timer_sync(>timer); out_free: - platform_set_drvdata(pdev, NULL); kfree(priv); return err; } @@ -209,7 +208,6 @@ static int timeriomem_rng_remove(struct platform_device *pdev) del_timer_sync(>timer); iounmap(priv->io_base); release_mem_region(res->start, resource_size(res)); - platform_set_drvdata(pdev, NULL); kfree(priv); return 0; -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] hwrng: bcm63xx - remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/char/hw_random/bcm63xx-rng.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/bcm63xx-rng.c b/drivers/char/hw_random/bcm63xx-rng.c index f343b7d..36581ea 100644 --- a/drivers/char/hw_random/bcm63xx-rng.c +++ b/drivers/char/hw_random/bcm63xx-rng.c @@ -137,7 +137,6 @@ static int bcm63xx_rng_probe(struct platform_device *pdev) out_clk_disable: clk_disable(clk); out_free_rng: - platform_set_drvdata(pdev, NULL); kfree(rng); out_free_priv: kfree(priv); @@ -154,7 +153,6 @@ static int bcm63xx_rng_remove(struct platform_device *pdev) clk_disable(priv->clk); kfree(priv); kfree(rng); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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/4] hwrng: atmel - remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/char/hw_random/atmel-rng.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c index 7c73d4a..bf9fc6b 100644 --- a/drivers/char/hw_random/atmel-rng.c +++ b/drivers/char/hw_random/atmel-rng.c @@ -108,8 +108,6 @@ static int atmel_trng_remove(struct platform_device *pdev) clk_disable(trng->clk); clk_put(trng->clk); - platform_set_drvdata(pdev, NULL); - return 0; } -- 1.7.2.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 3.9-stable] mmc: dw_mmc: fix fifo access for 64-bit
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Seungwon Jeon "
commit c09fbd7451b797213b3df8bf06b9ec33f954 upstream
mci_writew causes a failure of fifo access for 64-bit.
mci_writeq is correct.
Signed-off-by: Seungwon Jeon
Acked-by: Jaehoon Chung
Signed-off-by: Chris Ball
Signed-off-by: Jonghwan Choi
---
drivers/mmc/host/dw_mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 9834221..cc8d8de 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1353,7 +1353,7 @@ static void dw_mci_push_data64(struct dw_mci *host,
void *buf, int cnt)
buf += len;
cnt -= len;
if (!sg_next(host->sg) || host->part_buf_count == 8) {
- mci_writew(host, DATA(host->data_offset),
+ mci_writeq(host, DATA(host->data_offset),
host->part_buf);
host->part_buf_count = 0;
}
--
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 8/8] twl4030_charger: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/twl4030_charger.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c index bed4581..be98e70 100644 --- a/drivers/power/twl4030_charger.c +++ b/drivers/power/twl4030_charger.c @@ -594,7 +594,6 @@ fail_chg_irq: fail_register_usb: power_supply_unregister(>ac); fail_register_ac: - platform_set_drvdata(pdev, NULL); kfree(bci); return ret; @@ -622,7 +621,6 @@ static int __exit twl4030_bci_remove(struct platform_device *pdev) free_irq(bci->irq_chg, bci); power_supply_unregister(>usb); power_supply_unregister(>ac); - platform_set_drvdata(pdev, NULL); kfree(bci); return 0; -- 1.7.2.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 7/8] rx51_battery: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/power/rx51_battery.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/power/rx51_battery.c b/drivers/power/rx51_battery.c
index cbde1d6..8a6288d 100644
--- a/drivers/power/rx51_battery.c
+++ b/drivers/power/rx51_battery.c
@@ -216,10 +216,8 @@ static int rx51_battery_probe(struct platform_device *pdev)
di->bat.get_property = rx51_battery_get_property;
ret = power_supply_register(di->dev, >bat);
- if (ret) {
- platform_set_drvdata(pdev, NULL);
+ if (ret)
return ret;
- }
return 0;
}
@@ -229,7 +227,6 @@ static int rx51_battery_remove(struct platform_device *pdev)
struct rx51_device_info *di = platform_get_drvdata(pdev);
power_supply_unregister(>bat);
- platform_set_drvdata(pdev, NULL);
return 0;
}
--
1.7.2.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 6/8] jz4740-battery: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/power/jz4740-battery.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/power/jz4740-battery.c b/drivers/power/jz4740-battery.c
index c675553..d9686aa 100644
--- a/drivers/power/jz4740-battery.c
+++ b/drivers/power/jz4740-battery.c
@@ -292,7 +292,7 @@ static int jz_battery_probe(struct platform_device *pdev)
jz_battery);
if (ret) {
dev_err(>dev, "Failed to request irq %d\n", ret);
- goto err;
+ return ret;
}
disable_irq(jz_battery->irq);
@@ -349,8 +349,6 @@ err_free_gpio:
gpio_free(jz_battery->pdata->gpio_charge);
err_free_irq:
free_irq(jz_battery->irq, jz_battery);
-err:
- platform_set_drvdata(pdev, NULL);
return ret;
}
--
1.7.2.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 5/8] gpio-charger: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/gpio-charger.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/power/gpio-charger.c b/drivers/power/gpio-charger.c index e9883ee..4e858a2 100644 --- a/drivers/power/gpio-charger.c +++ b/drivers/power/gpio-charger.c @@ -155,8 +155,6 @@ static int gpio_charger_remove(struct platform_device *pdev) gpio_free(gpio_charger->pdata->gpio); - platform_set_drvdata(pdev, NULL); - return 0; } -- 1.7.2.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 4/8] bq27x00_battery: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/bq27x00_battery.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c index 26037ca..b309713 100644 --- a/drivers/power/bq27x00_battery.c +++ b/drivers/power/bq27x00_battery.c @@ -966,7 +966,6 @@ static int bq27000_battery_probe(struct platform_device *pdev) return 0; err_free: - platform_set_drvdata(pdev, NULL); kfree(di); return ret; @@ -978,7 +977,6 @@ static int bq27000_battery_remove(struct platform_device *pdev) bq27x00_powersupply_unregister(di); - platform_set_drvdata(pdev, NULL); kfree(di); return 0; -- 1.7.2.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 3/8] ab8500_bm: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/ab8500_btemp.c|1 - drivers/power/ab8500_charger.c |2 -- drivers/power/ab8500_fg.c |1 - drivers/power/abx500_chargalg.c |1 - 4 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/power/ab8500_btemp.c b/drivers/power/ab8500_btemp.c index d412d34..7f9a454 100644 --- a/drivers/power/ab8500_btemp.c +++ b/drivers/power/ab8500_btemp.c @@ -1045,7 +1045,6 @@ static int ab8500_btemp_remove(struct platform_device *pdev) flush_scheduled_work(); power_supply_unregister(>btemp_psy); - platform_set_drvdata(pdev, NULL); return 0; } diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c index a558318..f098fda 100644 --- a/drivers/power/ab8500_charger.c +++ b/drivers/power/ab8500_charger.c @@ -3425,8 +3425,6 @@ static int ab8500_charger_remove(struct platform_device *pdev) if (di->ac_chg.enabled && !di->ac_chg.external) power_supply_unregister(>ac_chg.psy); - platform_set_drvdata(pdev, NULL); - return 0; } diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c index c5391f5..1263638 100644 --- a/drivers/power/ab8500_fg.c +++ b/drivers/power/ab8500_fg.c @@ -3070,7 +3070,6 @@ static int ab8500_fg_remove(struct platform_device *pdev) flush_scheduled_work(); ab8500_fg_sysfs_psy_remove_attrs(di->fg_psy.dev); power_supply_unregister(>fg_psy); - platform_set_drvdata(pdev, NULL); return ret; } diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c index 9863e42..6d27236 100644 --- a/drivers/power/abx500_chargalg.c +++ b/drivers/power/abx500_chargalg.c @@ -2035,7 +2035,6 @@ static int abx500_chargalg_remove(struct platform_device *pdev) destroy_workqueue(di->chargalg_wq); power_supply_unregister(>chargalg_psy); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] 88pm860x_charger: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/88pm860x_charger.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/power/88pm860x_charger.c b/drivers/power/88pm860x_charger.c index 36fb4b5..66b 100644 --- a/drivers/power/88pm860x_charger.c +++ b/drivers/power/88pm860x_charger.c @@ -722,7 +722,6 @@ static int pm860x_charger_remove(struct platform_device *pdev) struct pm860x_charger_info *info = platform_get_drvdata(pdev); int i; - platform_set_drvdata(pdev, NULL); power_supply_unregister(>usb); free_irq(info->irq[0], info); for (i = 0; i < info->irq_nums; i++) -- 1.7.2.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/8] 88pm860x_battery: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/power/88pm860x_battery.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/power/88pm860x_battery.c b/drivers/power/88pm860x_battery.c index d338c1c..dfcda3a 100644 --- a/drivers/power/88pm860x_battery.c +++ b/drivers/power/88pm860x_battery.c @@ -992,7 +992,6 @@ static int pm860x_battery_remove(struct platform_device *pdev) free_irq(info->irq_batt, info); free_irq(info->irq_cc, info); power_supply_unregister(>battery); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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: device tree not the answer in the ARM world [was: Re: running Debian on a Cubieboard]
On 05/05/2013 06:27 AM, Luke Kenneth Casson Leighton wrote: this message came up on debian-arm and i figured that it is worthwhile endeavouring to get across to people why device tree cannot and will not ever be the solution it was believed to be, in the ARM world. [just a quick note to david who asked this question on the debian-arm mailing list: any chance you could use replies with plaintext in future? converting from HTML to text proved rather awkward and burdensome, requiring considerable editing. the generally-accepted formatting rules for international technical mailing lists are plaintext only and 7-bit characters] On Sun, May 5, 2013 at 11:14 AM, David Goodenough wrote: On Sunday 05 May 2013, Luke Kenneth Casson Leighton wrote: And I have a question: as the Debian installer takes the arch armhf in charge, do you think a standard install' from a netboot image will work ? this has been on my list for a lng time. as with *all* debian installer images however you are hampered by the fact that there is no BIOS - at all - on ARM devices - and therefore it is impossible to have a "one size fits all" debian installer. I wonder if the device tree is the answer here. If the box comes with a DT or one is available on the web then the installer could read it and know what to install. That and the armmp kernel should solve the problem. you'd think so, and it's a very good question, to which the answer could have been and was predicted to be "not a snowbal in hell's chance", even before work started on device tree, and turns out to *be* "not a snowball in hell's chance" which i believe people are now beginning to learn, based on the ultra-low adoption rate of device tree in the ARM world (side-note: [*0]). in the past, i've written at some length as to why this is the case, however the weighting given to my opinions on linux kernel strategic decision-making is negligeable, so as one associate of mine once wisely said, "you just gotta let the train wreck happen". device tree was designed to take the burden off of the linux kernel due to proliferation of platform-specific hard-coding of support for peripherals. however it was designed ***WITHOUT*** its advocates having a full grasp of the sheer overwhelming diversity of the platforms. specifically i am referring to linus torvald's complete lack of understanding of the ARM linux kernel world, as his primary experience is with x86. in his mind, and the minds of those people who do not understand how ARM-based boxes are built and linux brought up on them, *surely* it cannot be all that complicated, *surely* it cannot be as bad as it is, right? what they're completely missing is the following: * the x86 world resolves around standards such as ACPI, BIOSes and general-purpose dynamic buses. * ACPI normalises every single piece of hardware from the perspective of most low-level peripherals. * the BIOS also helps in that normalisation. DOS INT33 is the classic one i remember. * the general-purpose dynamic buses include: - USB and its speed variants (self-describing peripherals) - PCI and its derivatives (self-describing peripherals) - SATA and its speed variants (self-describing peripherals) exceptions to the above include i2c (unusual, and taken care of by i2c-sensors, which uses good heuristics to "probe" devices from userspace) and the ISA bus and its derivatives such as Compact Flash and IDE. even PCMCIA got sufficient advances to auto-identify devices from userspace at runtime. so as a general rule, supporting a new x86-based piece of hardware is a piece of piss. get datasheet or reverse-engineer, drop it in, it's got BIOS, ACPI, USB, PCIe, SATA, wow big deal, job done. also as a general rule, hardware that conforms to x86-motherboard-like layouts such as the various powerpc architectures are along the same lines. so here, device tree is a real easy thing to add, and to some extent a "nice-to-have". i.e. it's not really essential to have device tree on top of something where 99% of the peripherals can describe themselves dynamically over their bus architecture when they're plugged in! now let's look at the ARM world. * is there a BIOS? no. so all the boot-up procedures including ultra-low-level stuff like DDR3 RAM timings initialisation, which is normally the job of the BIOS - must be taken care of BY YOU (usually in u-boot) and it must be done SPECIFICALLY CUSTOMISED EACH AND EVERY SINGLE TIME FOR EVERY SINGLE SPECIFIC HARDWARE COMBINATION. * is there ACPI present? no. so anything related to power management, fans (if there are any), temperature detection (if there is any), all of that must be taken care of BY YOU. * what about the devices? here's where it becomes absolute hell on earth as far as attempting to "streamline" the linux kernel into a "one size fits all" monolithic package. the classic example i give here is the HTC Universal, which was a device that, after 3 years of
[PATCH 8/8] mfd: tc6393xb: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/tc6393xb.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c index 15e1463..a563dfa 100644 --- a/drivers/mfd/tc6393xb.c +++ b/drivers/mfd/tc6393xb.c @@ -756,7 +756,6 @@ static int tc6393xb_remove(struct platform_device *dev) clk_disable(tc6393xb->clk); iounmap(tc6393xb->scr); release_resource(>rscr); - platform_set_drvdata(dev, NULL); clk_put(tc6393xb->clk); kfree(tc6393xb); -- 1.7.2.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 7/8] mfd: tc6387xb: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/tc6387xb.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/tc6387xb.c b/drivers/mfd/tc6387xb.c index 366f7b9..65c425a 100644 --- a/drivers/mfd/tc6387xb.c +++ b/drivers/mfd/tc6387xb.c @@ -217,7 +217,6 @@ static int tc6387xb_remove(struct platform_device *dev) release_resource(>rscr); clk_disable(tc6387xb->clk32k); clk_put(tc6387xb->clk32k); - platform_set_drvdata(dev, NULL); kfree(tc6387xb); return 0; -- 1.7.2.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 6/8] mfd: t7l66xb: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/t7l66xb.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c index b32940e..a21bff2 100644 --- a/drivers/mfd/t7l66xb.c +++ b/drivers/mfd/t7l66xb.c @@ -422,7 +422,6 @@ static int t7l66xb_remove(struct platform_device *dev) iounmap(t7l66xb->scr); release_resource(>rscr); mfd_remove_devices(>dev); - platform_set_drvdata(dev, NULL); kfree(t7l66xb); return ret; -- 1.7.2.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 5/8] mfd: mcp-sa11x0: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/mcp-sa11x0.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/mcp-sa11x0.c b/drivers/mfd/mcp-sa11x0.c index f99d629..13198d9 100644 --- a/drivers/mfd/mcp-sa11x0.c +++ b/drivers/mfd/mcp-sa11x0.c @@ -225,8 +225,6 @@ static int mcp_sa11x0_probe(struct platform_device *dev) if (ret == 0) return 0; - platform_set_drvdata(dev, NULL); - err_ioremap: iounmap(m->base1); iounmap(m->base0); @@ -252,7 +250,6 @@ static int mcp_sa11x0_remove(struct platform_device *dev) mem0 = platform_get_resource(dev, IORESOURCE_MEM, 0); mem1 = platform_get_resource(dev, IORESOURCE_MEM, 1); - platform_set_drvdata(dev, NULL); mcp_host_del(mcp); iounmap(m->base1); iounmap(m->base0); -- 1.7.2.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 4/8] mfd: twl4030-madc: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/mfd/twl4030-madc.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 42bd3ea..1ea54d4 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -775,12 +775,10 @@ static int twl4030_madc_probe(struct platform_device
*pdev)
IRQF_TRIGGER_RISING, "twl4030_madc", madc);
if (ret) {
dev_dbg(>dev, "could not request irq\n");
- goto err_irq;
+ goto err_i2c;
}
twl4030_madc = madc;
return 0;
-err_irq:
- platform_set_drvdata(pdev, NULL);
err_i2c:
twl4030_madc_set_current_generator(madc, 0, 0);
err_current_generator:
@@ -796,7 +794,6 @@ static int twl4030_madc_remove(struct platform_device *pdev)
struct twl4030_madc_data *madc = platform_get_drvdata(pdev);
free_irq(platform_get_irq(pdev, 0), madc);
- platform_set_drvdata(pdev, NULL);
twl4030_madc_set_current_generator(madc, 0, 0);
twl4030_madc_set_power(madc, 0);
kfree(madc);
--
1.7.2.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 3/8] mfd: twl4030-audio: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/mfd/twl4030-audio.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-audio.c b/drivers/mfd/twl4030-audio.c
index d2ab222..a31fba9 100644
--- a/drivers/mfd/twl4030-audio.c
+++ b/drivers/mfd/twl4030-audio.c
@@ -261,10 +261,8 @@ static int twl4030_audio_probe(struct platform_device
*pdev)
ret = -ENODEV;
}
- if (ret) {
- platform_set_drvdata(pdev, NULL);
+ if (ret)
twl4030_audio_dev = NULL;
- }
return ret;
}
@@ -272,7 +270,6 @@ static int twl4030_audio_probe(struct platform_device *pdev)
static int twl4030_audio_remove(struct platform_device *pdev)
{
mfd_remove_devices(>dev);
- platform_set_drvdata(pdev, NULL);
twl4030_audio_dev = NULL;
return 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] mfd: jz4740-adc: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/jz4740-adc.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/jz4740-adc.c b/drivers/mfd/jz4740-adc.c index e80587f..01e86ce 100644 --- a/drivers/mfd/jz4740-adc.c +++ b/drivers/mfd/jz4740-adc.c @@ -294,7 +294,6 @@ static int jz4740_adc_probe(struct platform_device *pdev) err_clk_put: clk_put(adc->clk); err_iounmap: - platform_set_drvdata(pdev, NULL); iounmap(adc->base); err_release_mem_region: release_mem_region(adc->mem->start, resource_size(adc->mem)); @@ -317,8 +316,6 @@ static int jz4740_adc_remove(struct platform_device *pdev) clk_put(adc->clk); - platform_set_drvdata(pdev, NULL); - return 0; } -- 1.7.2.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/8] mfd: intel_msic: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/intel_msic.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/intel_msic.c b/drivers/mfd/intel_msic.c index 5be3b5e..977506e 100644 --- a/drivers/mfd/intel_msic.c +++ b/drivers/mfd/intel_msic.c @@ -443,7 +443,6 @@ static int intel_msic_remove(struct platform_device *pdev) struct intel_msic *msic = platform_get_drvdata(pdev); intel_msic_remove_devices(msic); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] dma: timb_dma: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/dma/timb_dma.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c index 26107ba..0ef43c1 100644 --- a/drivers/dma/timb_dma.c +++ b/drivers/dma/timb_dma.c @@ -811,8 +811,6 @@ static int td_remove(struct platform_device *pdev) kfree(td); release_mem_region(iomem->start, resource_size(iomem)); - platform_set_drvdata(pdev, NULL); - dev_dbg(>dev, "Removed...\n"); return 0; } -- 1.7.2.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] dma: at_hdmac: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/dma/at_hdmac.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c index e923cda..c093ab7 100644 --- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1472,7 +1472,6 @@ err_of_dma_controller_register: dma_async_device_unregister(>dma_common); dma_pool_destroy(atdma->dma_desc_pool); err_pool_create: - platform_set_drvdata(pdev, NULL); free_irq(platform_get_irq(pdev, 0), atdma); err_irq: clk_disable(atdma->clk); @@ -1497,7 +1496,6 @@ static int at_dma_remove(struct platform_device *pdev) dma_async_device_unregister(>dma_common); dma_pool_destroy(atdma->dma_desc_pool); - platform_set_drvdata(pdev, NULL); free_irq(platform_get_irq(pdev, 0), atdma); list_for_each_entry_safe(chan, _chan, >dma_common.channels, -- 1.7.2.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/
linux-next: manual merge of the akpm tree with the tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in ipc/sem.c
between commit 321310ced2d6 ("ipc: move sem_obtain_lock() rcu locking
into the only caller") from Linus' tree and commit "ipc/sem.c:
alternatives to preempt_disable()" from the akpm tree.
I just dropped the akpm tree commit for now.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpHzWZfqr_Nc.pgp
Description: PGP signature
[PATCH 4/4] pinctrl: u300: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/pinctrl/pinctrl-u300.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-u300.c b/drivers/pinctrl/pinctrl-u300.c index 6a3a750..195191a 100644 --- a/drivers/pinctrl/pinctrl-u300.c +++ b/drivers/pinctrl/pinctrl-u300.c @@ -1100,7 +1100,6 @@ static int u300_pmx_remove(struct platform_device *pdev) struct u300_pmx *upmx = platform_get_drvdata(pdev); pinctrl_unregister(upmx->pctl); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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 3/4] pinctrl: sirf: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/pinctrl/pinctrl-sirf.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
index bc9d1be..d704f3b 100644
--- a/drivers/pinctrl/pinctrl-sirf.c
+++ b/drivers/pinctrl/pinctrl-sirf.c
@@ -1280,9 +1280,8 @@ static int sirfsoc_pinmux_probe(struct platform_device
*pdev)
spmx->gpio_virtbase = of_iomap(np, 0);
if (!spmx->gpio_virtbase) {
- ret = -ENOMEM;
dev_err(>dev, "can't map gpio registers\n");
- goto out_no_gpio_remap;
+ return -ENOMEM;
}
spmx->rsc_virtbase = sirfsoc_rsc_of_iomap();
@@ -1316,8 +1315,6 @@ out_no_pmx:
iounmap(spmx->rsc_virtbase);
out_no_rsc_remap:
iounmap(spmx->gpio_virtbase);
-out_no_gpio_remap:
- platform_set_drvdata(pdev, NULL);
return ret;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] pinctrl: mxs: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/pinctrl/pinctrl-mxs.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-mxs.c b/drivers/pinctrl/pinctrl-mxs.c
index b45c4eb..f5d5643 100644
--- a/drivers/pinctrl/pinctrl-mxs.c
+++ b/drivers/pinctrl/pinctrl-mxs.c
@@ -515,7 +515,6 @@ int mxs_pinctrl_probe(struct platform_device *pdev,
return 0;
err:
- platform_set_drvdata(pdev, NULL);
iounmap(d->base);
return ret;
}
@@ -525,7 +524,6 @@ int mxs_pinctrl_remove(struct platform_device *pdev)
{
struct mxs_pinctrl_data *d = platform_get_drvdata(pdev);
- platform_set_drvdata(pdev, NULL);
pinctrl_unregister(d->pctl);
iounmap(d->base);
--
1.7.2.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/4] pinctrl: coh901: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/pinctrl/pinctrl-coh901.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c index edde3ac..f12546b 100644 --- a/drivers/pinctrl/pinctrl-coh901.c +++ b/drivers/pinctrl/pinctrl-coh901.c @@ -860,7 +860,6 @@ static int __exit u300_gpio_remove(struct platform_device *pdev) } u300_gpio_free_ports(gpio); clk_disable_unprepare(gpio->clk); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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 7/7] gpio: vx855: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-vx855.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index 2b7252c..cddfa22 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -279,7 +279,6 @@ out_release: release_region(res_gpi->start, resource_size(res_gpi)); if (vg->gpo_reserved) release_region(res_gpi->start, resource_size(res_gpo)); - platform_set_drvdata(pdev, NULL); kfree(vg); return ret; } @@ -301,7 +300,6 @@ static int vx855gpio_remove(struct platform_device *pdev) release_region(res->start, resource_size(res)); } - platform_set_drvdata(pdev, NULL); kfree(vg); return 0; } -- 1.7.2.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 6/7] gpio: timberdale: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-timberdale.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-timberdale.c b/drivers/gpio/gpio-timberdale.c index 4377405..4c65f88 100644 --- a/drivers/gpio/gpio-timberdale.c +++ b/drivers/gpio/gpio-timberdale.c @@ -342,8 +342,6 @@ static int timbgpio_remove(struct platform_device *pdev) release_mem_region(iomem->start, resource_size(iomem)); kfree(tgpio); - platform_set_drvdata(pdev, NULL); - return 0; } -- 1.7.2.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 firmware 1/2] rtl_nic: Add firmware rtl8168g-3
On Tue, 2013-04-23 at 20:37 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8168g-3.fw
> Version: 0.0.1
>
> Signed-off-by: Hayes Wang
> ---
Applied, thanks.
Ben.
> WHENCE| 5 -
> rtl_nic/rtl8168g-3.fw | Bin 0 -> 832 bytes
> 2 files changed, 4 insertions(+), 1 deletion(-)
> create mode 100644 rtl_nic/rtl8168g-3.fw
>
> diff --git a/WHENCE b/WHENCE
> index 013f810..54f6388 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1875,8 +1875,11 @@ Version: 0.0.3
> File: rtl_nic/rtl8168g-2.fw
> Version: 0.0.1
>
> +File: rtl_nic/rtl8168g-3.fw
> +Version: 0.0.1
> +
> Licence:
> - * Copyright © 2011, Realtek Semiconductor Corporation
> + * Copyright © 2011-2013, Realtek Semiconductor Corporation
> *
> * Permission is hereby granted for the distribution of this firmware
> * data in hexadecimal or equivalent format, provided this copyright
> diff --git a/rtl_nic/rtl8168g-3.fw b/rtl_nic/rtl8168g-3.fw
> new file mode 100644
> index
> ..0c97d7ea1437ba515c1dbdabe8aa285e79585786
> GIT binary patch
> literal 832
> zcmYk(!AcuZ6b9fwaZ*7`oFrF-f;bOQ z04sFkBM5G0Ep4Hc(rq80MX|9 z{B+?-vQSHybDx)7=UiR9dQnf}q_x%Vu60`5?f0#Urb9|Vbvp~qN
> z|E1PnV=D*za?}K(Ch{liz#`zv)zitn6cHfip{}TXA%D&=8Y|%Fh?_t!DC~`
> z@2%jIu{o}t$k<1tx(AHel(E4m=0_2Xz0ml+A^W;#0Mc7#p22N~2$)IlX5w>oKbJli
> zrl0+O46<8SYtj|pr-an+x8(2bTi+MiN2zhCF*y>SFOTxDOt8mS_I$lp_A~v}+&;o=
> zU+%wBYtR~EmudxCLF}K}25m#^w_1nR5)rPd8*idai8;H5H3ElgG0Z!?s
> z;!|p~v{|u|+70bStfJPYwZ*2@j%Y_>MYVtyh&@!hH}|C4D(hCI}zv%Tb
> e>yD-FyIPS}6#JoeLAwz9sn)0U#hU)T1OEYQX1@Ud
>
> literal 0
> HcmV?d1
>
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH firmware 2/2] rtl_nic: add firmware rtl8106e-2
On Tue, 2013-04-23 at 20:37 +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8106e-2.fw
> Version: 0.0.1
>
> Signed-off-by: Hayes Wang
> ---
Applied, thanks.
Ben.
> WHENCE| 3 +++
> rtl_nic/rtl8106e-2.fw | Bin 0 -> 832 bytes
> 2 files changed, 3 insertions(+)
> create mode 100644 rtl_nic/rtl8106e-2.fw
>
> diff --git a/WHENCE b/WHENCE
> index 54f6388..fedf031 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1869,6 +1869,9 @@ Version: 0.0.1
> File: rtl_nic/rtl8106e-1.fw
> Version: 0.0.1
>
> +File: rtl_nic/rtl8106e-2.fw
> +Version: 0.0.1
> +
> File: rtl_nic/rtl8168g-1.fw
> Version: 0.0.3
>
> diff --git a/rtl_nic/rtl8106e-2.fw b/rtl_nic/rtl8106e-2.fw
> new file mode 100644
> index
> ..ac042757e1392c184b5b75313d6b597c1561cc41
> GIT binary patch
> literal 832
> zcmYk(!AcuZ6b9fwaZ;g{I7x011aTgqjT0wG%_?9i2wg~*ZqlGa7HUOYrsY~96r> zfDLq$M-aN1wNychxa|Y9SlZa7)BoO+Q%rI>neUuAbM74g*xlQFR*M%lp3b-8YFw>F
> zaeZz+nX4ttxz7sM7p}K>^>QJJlh#gqZ>`hXZEv;K-mGs#wZ%pfH|lkKT*mu}Sqp^x
> z`d@1OHFk2qcSlViY9ilX2abS3y!3F^zSyr=j2T-!t=Jrlbr$jeQQp{cpE;Ug44xP}
> zes2Yzjm>eri;SHf)jeR$CXEe7F+Yl6?1sko4cXT{1CZV_^AzqfM8H(~e zVfxkY#~{0NwI+S;`;?IS{g(W_J?r}-`y@3kH6};m^W{+ z9m@T`)Ecyg*o|6>`=QpMb;N$Eb!lC(-)ckJP;97nKsyj~XA`>j1p^G|
> z1Mx|<8QP3kN$r+)D^^i!)7oN>)sAV$Vnwxp7KlAkyEpfQ+A8Z-rOwTGsk3Kt#^-u{
> e!nzZw`=(Z;6~(U9+<1*J?dlPps+RJMa%_vcCZU
>
> literal 0
> HcmV?d1
>
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
[PATCH 5/7] gpio: tc3589x: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-tc3589x.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-tc3589x.c b/drivers/gpio/gpio-tc3589x.c index d34d80d..4a5de27 100644 --- a/drivers/gpio/gpio-tc3589x.c +++ b/drivers/gpio/gpio-tc3589x.c @@ -407,7 +407,6 @@ static int tc3589x_gpio_remove(struct platform_device *pdev) free_irq(irq, tc3589x_gpio); - platform_set_drvdata(pdev, NULL); kfree(tc3589x_gpio); return 0; -- 1.7.2.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 4/7] gpio: stmpe: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-stmpe.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-stmpe.c b/drivers/gpio/gpio-stmpe.c index 3ce5bc3..671913e 100644 --- a/drivers/gpio/gpio-stmpe.c +++ b/drivers/gpio/gpio-stmpe.c @@ -431,7 +431,6 @@ static int stmpe_gpio_remove(struct platform_device *pdev) if (irq >= 0) free_irq(irq, stmpe_gpio); - platform_set_drvdata(pdev, NULL); kfree(stmpe_gpio); return 0; -- 1.7.2.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 3/7] gpio: rdc321x: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-rdc321x.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c index 1bf55f6..368c3c0 100644 --- a/drivers/gpio/gpio-rdc321x.c +++ b/drivers/gpio/gpio-rdc321x.c @@ -187,20 +187,18 @@ static int rdc321x_gpio_probe(struct platform_device *pdev) rdc321x_gpio_dev->reg1_data_base, _gpio_dev->data_reg[0]); if (err) - goto out_drvdata; + goto out_free; err = pci_read_config_dword(rdc321x_gpio_dev->sb_pdev, rdc321x_gpio_dev->reg2_data_base, _gpio_dev->data_reg[1]); if (err) - goto out_drvdata; + goto out_free; dev_info(>dev, "registering %d GPIOs\n", rdc321x_gpio_dev->chip.ngpio); return gpiochip_add(_gpio_dev->chip); -out_drvdata: - platform_set_drvdata(pdev, NULL); out_free: kfree(rdc321x_gpio_dev); return err; @@ -216,7 +214,6 @@ static int rdc321x_gpio_remove(struct platform_device *pdev) dev_err(>dev, "failed to unregister chip\n"); kfree(rdc321x_gpio_dev); - platform_set_drvdata(pdev, NULL); return ret; } -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] gpio: lynxpoint: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-lynxpoint.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c index 86c17de..761c470 100644 --- a/drivers/gpio/gpio-lynxpoint.c +++ b/drivers/gpio/gpio-lynxpoint.c @@ -447,7 +447,6 @@ static int lp_gpio_remove(struct platform_device *pdev) err = gpiochip_remove(>chip); if (err) dev_warn(>dev, "failed to remove gpio_chip.\n"); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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 v7 16/21] sched: no balance for prefer_sibling in power scheduling
Hi Alex,
You can add my Reviewed-by for the below patch.
Thanks
Regards
Preeti U Murthy
On 04/04/2013 07:30 AM, Alex Shi wrote:
> In power aware scheduling, we don't want to balance 'prefer_sibling'
> groups just because local group has capacity.
> If the local group has no tasks at the time, that is the power
> balance hope so.
>
> Signed-off-by: Alex Shi
> ---
> kernel/sched/fair.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0dd29f4..86221e7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4762,8 +4762,12 @@ static inline void update_sd_lb_stats(struct lb_env
> *env,
>* extra check prevents the case where you always pull from the
>* heaviest group when it is already under-utilized (possible
>* with a large weight task outweighs the tasks on the system).
> + *
> + * In power aware scheduling, we don't care load weight and
> + * want not to pull tasks just because local group has capacity.
>*/
> - if (prefer_sibling && !local_group && sds->this_has_capacity)
> + if (prefer_sibling && !local_group && sds->this_has_capacity
> + && env->flags & LBF_PERF_BAL)
> sgs.group_capacity = min(sgs.group_capacity, 1UL);
>
> if (local_group) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v7 05/21] sched: log the cpu utilization at rq
Hi Alex,
You can add my Reviewed-by for the below patch.
Thanks
Regards
Preeti U Murthy
On 04/04/2013 07:30 AM, Alex Shi wrote:
> The cpu's utilization is to measure how busy is the cpu.
> util = cpu_rq(cpu)->avg.runnable_avg_sum * SCHED_POEWR_SCALE
> / cpu_rq(cpu)->avg.runnable_avg_period;
>
> Since the util is no more than 1, we scale its value with 1024, same as
> SCHED_POWER_SCALE and set the FULL_UTIL as 1024.
>
> In later power aware scheduling, we are sensitive for how busy of the
> cpu. Since as to power consuming, it is tight related with cpu busy
> time.
>
> BTW, rq->util can be used for any purposes if needed, not only power
> scheduling.
>
> Signed-off-by: Alex Shi
> ---
> include/linux/sched.h | 2 +-
> kernel/sched/debug.c | 1 +
> kernel/sched/fair.c | 5 +
> kernel/sched/sched.h | 4
> 4 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5a4cf37..226a515 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -793,7 +793,7 @@ enum cpu_idle_type {
> #define SCHED_LOAD_SCALE (1L << SCHED_LOAD_SHIFT)
>
> /*
> - * Increase resolution of cpu_power calculations
> + * Increase resolution of cpu_power and rq->util calculations
> */
> #define SCHED_POWER_SHIFT10
> #define SCHED_POWER_SCALE(1L << SCHED_POWER_SHIFT)
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index 75024a6..f5db759 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -311,6 +311,7 @@ do {
> \
>
> P(ttwu_count);
> P(ttwu_local);
> + P(util);
>
> #undef P
> #undef P64
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2e49c3f..7124244 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1495,8 +1495,13 @@ static void update_cfs_rq_blocked_load(struct cfs_rq
> *cfs_rq, int force_update)
>
> static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
> {
> + u32 period;
> __update_entity_runnable_avg(rq->clock_task, >avg, runnable);
> __update_tg_runnable_avg(>avg, >cfs);
> +
> + period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
> + rq->util = (u64)(rq->avg.runnable_avg_sum << SCHED_POWER_SHIFT)
> + / period;
> }
>
> /* Add the load generated by se into cfs_rq's child load-average */
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 804ee41..8682110 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -351,6 +351,9 @@ extern struct root_domain def_root_domain;
>
> #endif /* CONFIG_SMP */
>
> +/* full cpu utilization */
> +#define FULL_UTILSCHED_POWER_SCALE
> +
> /*
> * This is the main, per-CPU runqueue data structure.
> *
> @@ -482,6 +485,7 @@ struct rq {
> #endif
>
> struct sched_avg avg;
> + unsigned int util;
> };
>
> static inline int cpu_of(struct rq *rq)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] gpio: langwell: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/gpio/gpio-langwell.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c index 634c3d3..de08bc1 100644 --- a/drivers/gpio/gpio-langwell.c +++ b/drivers/gpio/gpio-langwell.c @@ -478,7 +478,6 @@ static int wp_gpio_remove(struct platform_device *pdev) dev_err(>dev, "failed to remove gpio_chip.\n"); iounmap(lnw->reg_base); kfree(lnw); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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 v7 02/21] sched: set initial value of runnable avg for new forked task
Hi Alex,
The below patch looks good to me.
On 04/04/2013 07:30 AM, Alex Shi wrote:
> We need initialize the se.avg.{decay_count, load_avg_contrib} for a
> new forked task.
> Otherwise random values of above variables cause mess when do new task
> enqueue:
> enqueue_task_fair
> enqueue_entity
> enqueue_entity_load_avg
>
> and make forking balancing imbalance since incorrect load_avg_contrib.
>
> set avg.decay_count = 0, and avg.load_avg_contrib = se->load.weight to
> resolve such issues.
>
> Signed-off-by: Alex Shi
> ---
> kernel/sched/core.c | 6 ++
> kernel/sched/fair.c | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 54eaaa2..8843cd3 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1564,6 +1564,7 @@ static void __sched_fork(struct task_struct *p)
> #ifdef CONFIG_SMP
> p->se.avg.runnable_avg_period = 0;
> p->se.avg.runnable_avg_sum = 0;
> + p->se.avg.decay_count = 0;
> #endif
> #ifdef CONFIG_SCHEDSTATS
> memset(>se.statistics, 0, sizeof(p->se.statistics));
> @@ -1651,6 +1652,11 @@ void sched_fork(struct task_struct *p)
> p->sched_reset_on_fork = 0;
> }
>
> + /* New forked task assumed with full utilization */
> +#if defined(CONFIG_SMP)
> + p->se.avg.load_avg_contrib = p->se.load.weight;
> +#endif
> +
> if (!rt_prio(p->prio))
> p->sched_class = _sched_class;
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 9c2f726..2881d42 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1508,6 +1508,10 @@ static inline void enqueue_entity_load_avg(struct
> cfs_rq *cfs_rq,
>* We track migrations using entity decay_count <= 0, on a wake-up
>* migration we use a negative decay count to track the remote decays
>* accumulated while sleeping.
> + *
> + * When enqueue a new forked task, the se->avg.decay_count == 0, so
> + * we bypass update_entity_load_avg(), use avg.load_avg_contrib initial
> + * value: se->load.weight.
>*/
> if (unlikely(se->avg.decay_count <= 0)) {
> se->avg.last_runnable_update = rq_of(cfs_rq)->clock_task;
>
Reviewed-by:Preeti U Murthy
Thanks
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/14] perf ftrace: Add 'record' sub-command
On 5/5/13 7:57 PM, Namhyung Kim wrote:
Hi David,
On Fri, 26 Apr 2013 07:44:18 -0600, David Ahern wrote:
On 4/25/13 12:24 AM, Namhyung Kim wrote:
But it looks there's a race between cond_wait() and cond_broatcast().
I'll take a look at that.
Why not use eventfd or a pipe for the signalling instead?
Thanks for your feedback!
I didn't have an idea of using eventfd for this case. Does it helpful
to prevent such a deadlock like this?
I have used it to replace pthread_cond_wait /
pthread_cond_{signal,broadcast} -- lighter and faster. It was added in
2.6.27 I believe, so will be available for any system that supports perf
(record side). For people compiling perf against say RHEL5 (e.g.
analysis) you will need a check as to whether it exists.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/5] input: pxa27x-keypad: add device tree support
Signed-off-by: Chao Xie
---
.../devicetree/bindings/input/pxa27x-keypad.txt| 60 +
drivers/input/keyboard/pxa27x_keypad.c | 232 +++-
2 files changed, 288 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
new file mode 100644
index 000..f8674f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -0,0 +1,60 @@
+* Marvell PXA Keypad controller
+
+Required Properties
+- compatible : should be "marvell,pxa27x-keypad"
+- reg : Address and length of the register set for the device
+- interrupts : The interrupt for the keypad controller
+- marvell,debounce-interval : How long time the key will be
+ recognized when it is pressed. It is a u32 value, and bit[31:16]
+ is debounce interval for direct key and bit[15:0] is debounce
+ interval for matrix key. The value is in binary number of 2ms
+
+Optional Properties For Matrix Keyes
+Please refer to matrix-keymap.txt
+
+Optional Properties for Direct Keyes
+- marvell,direct-key-count : How many direct keyes are used.
+- marvell,direct-key-mask : The mask indicates which keyes
+ are used. If bit[X] of the mask is set, the direct key X
+ is used.
+- marvell,direct-key-low-active : Direct key status register
+ tells the level of pins that connects to the direct keyes.
+ When this property is set, it means that when the pin level
+ is low, the key is pressed(active).
+- marvell,direct-key-map : It is a u16 array. Each item indicates
+ the linux key-code for the direct key.
+
+Optional Properties For Rotary
+- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
+ linux key-code for rotary up. Bit[15:0] is the linux key-code
+ for rotary down. It is for rotary 0.
+- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
+- marvell,rotary-rel-key : When rotary is used for relative axes
+ in the device, the value indicates the key-code for relative
+ axes measurement in the device. It is a u32 value. Bit[31:16]
+ is for rotary 1, and Bit[15:0] is for rotary 0.
+
+Examples:
+ keypad: keypad@d4012000 {
+ keypad,num-rows = <3>;
+ keypad,num-columns = <5>;
+ linux,keymap = <0x000e /* KEY_BACKSPACE */
+ 0x0001006b /* KEY_END */
+ 0x00020061 /* KEY_RIGHTCTRL */
+ 0x0003000b /* KEY_0 */
+ 0x00040002 /* KEY_1 */
+ 0x018b /* KEY_MENU */
+ 0x01010066 /* KEY_HOME */
+ 0x010200e7 /* KEY_SEND */
+ 0x01030009 /* KEY_8 */
+ 0x0104000a /* KEY_9 */
+ 0x02000160 /* KEY_OK */
+ 0x02010003 /* KEY_2 */
+ 0x02020004 /* KEY_3 */
+ 0x02030005 /* KEY_4 */
+ 0x02040006>;/* KEY_5 */
+ marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
+ marvell,direct-key-count = <1>;
+ marvell,direct-key-map = <0x001c>;
+ marvell,debounce-interval = <0x001e001e>;
+ };
diff --git a/drivers/input/keyboard/pxa27x_keypad.c
b/drivers/input/keyboard/pxa27x_keypad.c
index c9f212a..3b63a12 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,6 +118,217 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
};
+static int pxa27x_keypad_matrix_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+ int ret;
+ u32 rows, cols;
+ struct input_dev *input_dev = keypad->input_dev;
+ struct device *dev = input_dev->dev.parent;
+ struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
+
+ ret = matrix_keypad_parse_of_params(dev, , );
+ if (ret)
+ return ret;
+
+ if (rows > MAX_MATRIX_KEY_ROWS || cols > MAX_MATRIX_KEY_COLS) {
+ dev_err(dev, "rows or cols exceeds maximum value\n");
+ return -EINVAL;
+ }
+
+ pdata->matrix_key_rows = rows;
+ pdata->matrix_key_cols = cols;
+
+ ret = matrix_keypad_build_keymap(NULL, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int pxa27x_keypad_direct_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+ const __be16 *prop;
+ unsigned short code;
+ int i, ret;
+ unsigned int proplen, size;
+
[PATCH V2 0/5] input: pxa27x-keypad: enhancement and device tree support
The patches include 2 parts 1. use matrix_keypad for matrix keyes support 2. add device tree support for pxa27x-keypad V2->V1: Do not copy the members from pdata. For device tree support, directly allocate the pdata structure. Chao Xie (5): input: pxa27x-keypad: use matrix_keymap for matrix keyes arm: mmp: use matrix_keymap for aspenite arm: mmp: use matrix_keymap for teton_bga input: pxa27x-keypad: remove the unused members at platform data input: pxa27x-keypad: add device tree support .../devicetree/bindings/input/pxa27x-keypad.txt| 60 + arch/arm/mach-mmp/aspenite.c | 10 +- arch/arm/mach-mmp/teton_bga.c |8 +- drivers/input/keyboard/Kconfig |1 + drivers/input/keyboard/pxa27x_keypad.c | 266 ++-- include/linux/platform_data/keypad-pxa27x.h|3 +- 6 files changed, 325 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/5] arm: mmp: use matrix_keymap for aspenite
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/aspenite.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..1e23346 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -205,7 +205,7 @@ struct pxa168fb_mach_info aspenite_lcd_info = {
.invert_pixclock= 0,
};
-static unsigned int aspenite_matrix_key_map[] = {
+static const unsigned int aspenite_matrix_key_map[] = {
KEY(0, 6, KEY_UP), /* SW 4 */
KEY(0, 7, KEY_DOWN),/* SW 5 */
KEY(1, 6, KEY_LEFT),/* SW 6 */
@@ -214,11 +214,15 @@ static unsigned int aspenite_matrix_key_map[] = {
KEY(4, 7, KEY_ESC), /* SW 9 */
};
+static struct matrix_keymap_data aspenite_matrix_keymap_data = {
+ .keymap = aspenite_matrix_key_map,
+ .keymap_size= ARRAY_SIZE(aspenite_matrix_key_map),
+};
+
static struct pxa27x_keypad_platform_data aspenite_keypad_info __initdata = {
.matrix_key_rows= 5,
.matrix_key_cols= 8,
- .matrix_key_map = aspenite_matrix_key_map,
- .matrix_key_map_size= ARRAY_SIZE(aspenite_matrix_key_map),
+ .matrix_keymap_data = _matrix_keymap_data,
.debounce_interval = 30,
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/5] arm: mmp: use matrix_keymap for teton_bga
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/teton_bga.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/teton_bga.c b/arch/arm/mach-mmp/teton_bga.c
index 8609967..d8967fa 100644
--- a/arch/arm/mach-mmp/teton_bga.c
+++ b/arch/arm/mach-mmp/teton_bga.c
@@ -56,11 +56,15 @@ static unsigned int teton_bga_matrix_key_map[] = {
KEY(1, 7, KEY_RIGHT),
};
+static struct matrix_keymap_data teton_bga_matrix_keymap_data = {
+ .keymap = teton_bga_matrix_key_map,
+ .keymap_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+};
+
static struct pxa27x_keypad_platform_data teton_bga_keypad_info __initdata = {
.matrix_key_rows= 2,
.matrix_key_cols= 8,
- .matrix_key_map = teton_bga_matrix_key_map,
- .matrix_key_map_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+ .matrix_keymap_data = _bga_matrix_keymap_data,
.debounce_interval = 30,
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/5] input: pxa27x-keypad: remove the unused members at platform data
Now pxa27x-keypad make use matrix_keymap for matrix keyes, so
remove the unused members in platform data.
Signed-off-by: Chao Xie
---
include/linux/platform_data/keypad-pxa27x.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/platform_data/keypad-pxa27x.h
b/include/linux/platform_data/keypad-pxa27x.h
index 0db423b..2462556 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -39,8 +39,6 @@ struct pxa27x_keypad_platform_data {
const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
- unsigned int*matrix_key_map;
- int matrix_key_map_size;
/* direct keys */
int direct_key_num;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/5] input: pxa27x-keypad: use matrix_keymap for matrix keyes
pxa27x-keypad includes matrix keyes. Make use of matrix_keymap
for the matrix keyes.
Signed-off-by: Chao Xie
---
drivers/input/keyboard/Kconfig |1 +
drivers/input/keyboard/pxa27x_keypad.c | 36 +-
include/linux/platform_data/keypad-pxa27x.h |1 +
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index ac05006..fff3751 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -441,6 +441,7 @@ config KEYBOARD_OPENCORES
config KEYBOARD_PXA27x
tristate "PXA27x/PXA3xx keypad support"
depends on PXA27x || PXA3xx || ARCH_MMP
+ select INPUT_MATRIXKMAP
help
Enable support for PXA27x/PXA3xx keypad controller.
diff --git a/drivers/input/keyboard/pxa27x_keypad.c
b/drivers/input/keyboard/pxa27x_keypad.c
index 5330d8f..c9f212a 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,25 +118,29 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
};
-static void pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
+static int pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
{
struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
struct input_dev *input_dev = keypad->input_dev;
unsigned short keycode;
- int i;
+ int ret, i;
+ const struct matrix_keymap_data *keymap_data =
+ pdata ? pdata->matrix_keymap_data : NULL;
- for (i = 0; i < pdata->matrix_key_map_size; i++) {
- unsigned int key = pdata->matrix_key_map[i];
- unsigned int row = KEY_ROW(key);
- unsigned int col = KEY_COL(key);
- unsigned int scancode = MATRIX_SCAN_CODE(row, col,
-MATRIX_ROW_SHIFT);
+ ret = matrix_keypad_build_keymap(keymap_data, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+ if (ret)
+ return ret;
- keycode = KEY_VAL(key);
- keypad->keycodes[scancode] = keycode;
- __set_bit(keycode, input_dev->keybit);
- }
+ /*
+* The keycodes may not only includes matrix key but also the direct
+* key or rotary key.
+*/
+ input_dev->keycodemax = ARRAY_SIZE(keypad->keycodes);
+ /* For direct key. */
for (i = 0; i < pdata->direct_key_num; i++) {
keycode = pdata->direct_key_map[i];
keypad->keycodes[MAX_MATRIX_KEY_NUM + i] = keycode;
@@ -178,6 +182,8 @@ static void pxa27x_keypad_build_keycode(struct
pxa27x_keypad *keypad)
}
__clear_bit(KEY_RESERVED, input_dev->keybit);
+
+ return 0;
}
static void pxa27x_keypad_scan_matrix(struct pxa27x_keypad *keypad)
@@ -555,7 +561,11 @@ static int pxa27x_keypad_probe(struct platform_device
*pdev)
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
input_set_capability(input_dev, EV_MSC, MSC_SCAN);
- pxa27x_keypad_build_keycode(keypad);
+ error = pxa27x_keypad_build_keycode(keypad);
+ if (error) {
+ dev_err(>dev, "failed to build keycode\n");
+ goto failed_put_clk;
+ }
if ((pdata->enable_rotary0 && keypad->rotary_rel_code[0] != -1) ||
(pdata->enable_rotary1 && keypad->rotary_rel_code[1] != -1)) {
diff --git a/include/linux/platform_data/keypad-pxa27x.h
b/include/linux/platform_data/keypad-pxa27x.h
index 5ce8d5e6..0db423b 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -36,6 +36,7 @@
struct pxa27x_keypad_platform_data {
/* code map for the matrix keys */
+ const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
unsigned int*matrix_key_map;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/13] x86, acpi, numa, mem-hotplug: Introduce MEMBLK_HOTPLUGGABLE to mark and reserve hotpluggable memory.
Hi Vasilis, Sorry for the delay and thank you for reviewing and testing. :) On 05/03/2013 06:50 PM, Vasilis Liaskovitis wrote: Should we skip ranges on nodes that the kernel uses? e.g. with if (memblock_is_kernel_node(nid)) continue; Yes. I think I forgot to call it in this patch. Will update in the next version. - I am getting a "PANIC: early exception" when rebooting with movablecore=acpi after hotplugging memory on node0 or node1 of a 2-node VM. The guest kernel is based on git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-mm (e9058baf) + these v2 patches. This happens with or without the above memblock_is_kernel_node(nid) check. Perhaps I am missing something or I need a newer "ACPI, numa: Parse numa info early" patch-set? I didn't test it on a VM. But on my real box, I haven't got a panic when rebooting. I think I can help to test it in a VM, but would you please to tell me how to setup a environment as yours ? A general question: Disabling hot-pluggability/zone-movable eligibility for a whole node sounds a bit inflexible, if the machine only has one node to begin with. Would it be possible to keep movable information per SRAT entry? I.e if the BIOS presents multiple SRAT entries for one node/PXM (say node 0), and there is no memblock/kernel allocation on one of these SRAT entries, could we still mark this SRAT entry's range as hot-pluggable/movable? Not sure if many real machine BIOSes would do this, but seabios could. This implies that SRAT entries are processed for movable-zone eligilibity before they are merged on node/PXM basis entry-granularity (I think numa_cleanup_meminfo currently does this merge). Yes, this can be done. But in real usage, part of the memory in a node is hot-removable makes no sense, I think. We cannot remove the whole node, so we cannot remove a real hardware device. But in virtualization, would you please give a reason why we need this entry-granularity ? Another thinking. Assume I didn't understand your question correctly. :) Now in kernel, we can recognize a node (by PXM in SRAT), but we cannot recognize a memory device. Are you saying if we have this entry-granularity, we can hotplug a single memory device in a node ? (Perhaps there are more than on memory device in a node.) If so, it makes sense. But I don't the kernel is able to recognize which device a memory range belongs to now. And I'm not sure if we can do this. Of course the kernel should still have enough memory(i.e. non movable zone) to boot. Can we ensure that at least certain amount of memory is non-movable, and then, given more separate SRAT entries for node0 not used by kernel, treat these rest entries as movable? I tried this idea before. But as HPA said, it seems no way to calculate how much memory the kernel needs. https://lkml.org/lkml/2012/11/27/29 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 03/26] perf tools: Move arch check into config/Makefile
On Fri, 26 Apr 2013 18:18:09 +0200, Jiri Olsa wrote: > Namhyung, > if you'd like to check, all changes addressing your comments are in here: > > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/core_make > > I'll wait a bit for other comments and resend the patchset later Sorry, I didn't have a time to check it. I'll probably have some time later this week so will review it then. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/14] perf ftrace: Add 'record' sub-command
Hi David, On Fri, 26 Apr 2013 07:44:18 -0600, David Ahern wrote: > On 4/25/13 12:24 AM, Namhyung Kim wrote: >> But it looks there's a race between cond_wait() and cond_broatcast(). >> I'll take a look at that. > > Why not use eventfd or a pipe for the signalling instead? Thanks for your feedback! I didn't have an idea of using eventfd for this case. Does it helpful to prevent such a deadlock like this? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/14] perf ftrace: Use pager for displaying result
On Fri, 26 Apr 2013 10:40:23 +0200, Jiri Olsa wrote: > On Thu, Apr 25, 2013 at 03:50:45PM +0900, Namhyung Kim wrote: >> On Wed, 24 Apr 2013 16:17:24 +0200, Jiri Olsa wrote: >> > On Tue, Apr 23, 2013 at 05:31:10PM +0900, Namhyung Kim wrote: >> >> From: Namhyung Kim >> >> >> >> It's convenient to use pager when seeing many lines of result. >> >> >> > for some reason I'm able to get any output for 'live' command only >> > when using --no-pager option. I dont get any data for: >> > >> > # ./perf ftrace live ls >> > >> > not even ls output > > ok, now with your patch I get allways ls output correctly in pager "ls output" only? What about the ftrace outputs? > >> > >> > But sometime I dont even get ftrace output for: >> > >> > # ./perf --no-pager ftrace live ls >> > >> > just ls output > > this one still persists Hmm.. still hard to reproduce.. :( As it's --no-pager mode, so that it can be reproduced for you without this patch, right? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/7] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
They are the base values in load balance, update them with rq runnable
load average, then the load balance will consider runnable load avg
naturally.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 4 ++--
kernel/sched/fair.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 33bcebf..2f51636 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2536,7 +2536,7 @@ static void __update_cpu_load(struct rq *this_rq,
unsigned long this_load,
void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
- unsigned long load = this_rq->load.weight;
+ unsigned long load = (unsigned long)this_rq->cfs.runnable_load_avg;
unsigned long pending_updates;
/*
@@ -2586,7 +2586,7 @@ static void update_cpu_load_active(struct rq *this_rq)
* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
*/
this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, this_rq->load.weight, 1);
+ __update_cpu_load(this_rq, this_rq->cfs.runnable_load_avg, 1);
calc_load_account_active(this_rq);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2881d42..0bf88e8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2900,7 +2900,7 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
/* Used instead of source_load when we know the type == 0 */
static unsigned long weighted_cpuload(const int cpu)
{
- return cpu_rq(cpu)->load.weight;
+ return (unsigned long)cpu_rq(cpu)->cfs.runnable_load_avg;
}
/*
@@ -2947,7 +2947,7 @@ static unsigned long cpu_avg_load_per_task(int cpu)
unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
if (nr_running)
- return rq->load.weight / nr_running;
+ return (unsigned long)rq->cfs.runnable_load_avg / nr_running;
return 0;
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/7] sched: set initial value of runnable avg for new forked task
We need initialize the se.avg.{decay_count, load_avg_contrib} for a
new forked task.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
and make forking balancing imbalance since incorrect load_avg_contrib.
set avg.decay_count = 0, and avg.load_avg_contrib = se->load.weight to
resolve such issues.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 6 ++
kernel/sched/fair.c | 4
2 files changed, 10 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c8db984..ecec7f1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1566,6 +1566,7 @@ static void __sched_fork(struct task_struct *p)
#ifdef CONFIG_SMP
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
+ p->se.avg.decay_count = 0;
#endif
#ifdef CONFIG_SCHEDSTATS
memset(>se.statistics, 0, sizeof(p->se.statistics));
@@ -1653,6 +1654,11 @@ void sched_fork(struct task_struct *p)
p->sched_reset_on_fork = 0;
}
+ /* New forked task assumed with full utilization */
+#if defined(CONFIG_SMP)
+ p->se.avg.load_avg_contrib = p->se.load.weight;
+#endif
+
if (!rt_prio(p->prio))
p->sched_class = _sched_class;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9c2f726..2881d42 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1508,6 +1508,10 @@ static inline void enqueue_entity_load_avg(struct cfs_rq
*cfs_rq,
* We track migrations using entity decay_count <= 0, on a wake-up
* migration we use a negative decay count to track the remote decays
* accumulated while sleeping.
+*
+* When enqueue a new forked task, the se->avg.decay_count == 0, so
+* we bypass update_entity_load_avg(), use avg.load_avg_contrib initial
+* value: se->load.weight.
*/
if (unlikely(se->avg.decay_count <= 0)) {
se->avg.last_runnable_update = rq_of(cfs_rq)->clock_task;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 7/7] sched: consider runnable load average in effective_load
effective_load calculates the load change as seen from the
root_task_group. It needs to engage the runnable average
of changed task.
Thanks for Morten Rasmussen and PeterZ's reminder of this.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 790e23d..6f4f14b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2976,15 +2976,15 @@ static void task_waking_fair(struct task_struct *p)
#ifdef CONFIG_FAIR_GROUP_SCHED
/*
- * effective_load() calculates the load change as seen from the root_task_group
+ * effective_load() calculates load avg change as seen from the root_task_group
*
* Adding load to a group doesn't make a group heavier, but can cause movement
* of group shares between cpus. Assuming the shares were perfectly aligned one
* can calculate the shift in shares.
*
- * Calculate the effective load difference if @wl is added (subtracted) to @tg
- * on this @cpu and results in a total addition (subtraction) of @wg to the
- * total group weight.
+ * Calculate the effective load avg difference if @wl is added (subtracted) to
+ * @tg on this @cpu and results in a total addition (subtraction) of @wg to the
+ * total group load avg.
*
* Given a runqueue weight distribution (rw_i) we can compute a shares
* distribution (s_i) using:
@@ -2998,7 +2998,7 @@ static void task_waking_fair(struct task_struct *p)
* rw_i = { 2, 4, 1, 0 }
* s_i = { 2/7, 4/7, 1/7, 0 }
*
- * As per wake_affine() we're interested in the load of two CPUs (the CPU the
+ * As per wake_affine() we're interested in load avg of two CPUs (the CPU the
* task used to run on and the CPU the waker is running on), we need to
* compute the effect of waking a task on either CPU and, in case of a sync
* wakeup, compute the effect of the current task going to sleep.
@@ -3008,20 +3008,20 @@ static void task_waking_fair(struct task_struct *p)
*
* s'_i = (rw_i + @wl) / (@wg + \Sum rw_j) (2)
*
- * Suppose we're interested in CPUs 0 and 1, and want to compute the load
+ * Suppose we're interested in CPUs 0 and 1, and want to compute the load avg
* differences in waking a task to CPU 0. The additional task changes the
* weight and shares distributions like:
*
* rw'_i = { 3, 4, 1, 0 }
* s'_i = { 3/8, 4/8, 1/8, 0 }
*
- * We can then compute the difference in effective weight by using:
+ * We can then compute the difference in effective load avg by using:
*
* dw_i = S * (s'_i - s_i) (3)
*
* Where 'S' is the group weight as seen by its parent.
*
- * Therefore the effective change in loads on CPU 0 would be 5/56 (3/8 - 2/7)
+ * Therefore the effective change in load avg on CPU 0 would be 5/56 (3/8 -
2/7)
* times the weight of the group. The effect on CPU 1 would be -4/56 (4/8 -
* 4/7) times the weight of the group.
*/
@@ -3045,7 +3045,7 @@ static long effective_load(struct task_group *tg, int
cpu, long wl, long wg)
/*
* w = rw_i + @wl
*/
- w = se->my_q->load.weight + wl;
+ w = se->my_q->tg_load_contrib + wl;
/*
* wl = S * s'_i; see (2)
@@ -3066,7 +3066,7 @@ static long effective_load(struct task_group *tg, int
cpu, long wl, long wg)
/*
* wl = dw_i = S * (s'_i - s_i); see (3)
*/
- wl -= se->load.weight;
+ wl -= se->avg.load_avg_contrib;
/*
* Recursively apply this logic to all parent groups to compute
@@ -3112,14 +3112,14 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
*/
if (sync) {
tg = task_group(current);
- weight = current->se.load.weight;
+ weight = current->se.avg.load_avg_contrib;
this_load += effective_load(tg, this_cpu, -weight, -weight);
load += effective_load(tg, prev_cpu, 0, -weight);
}
tg = task_group(p);
- weight = p->se.load.weight;
+ weight = p->se.avg.load_avg_contrib;
/*
* In low-load situations, where prev_cpu is idle and this_cpu is idle
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 6/7] sched: consider runnable load average in move_tasks
Except using runnable load average in background, move_tasks is also
the key functions in load balance. We need consider the runnable load
average in it in order to the apple to apple load comparison.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0bf88e8..790e23d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3966,6 +3966,12 @@ static unsigned long task_h_load(struct task_struct *p);
static const unsigned int sched_nr_migrate_break = 32;
+static unsigned long task_h_load_avg(struct task_struct *p)
+{
+ return div_u64(task_h_load(p) * (u64)p->se.avg.runnable_avg_sum,
+ p->se.avg.runnable_avg_period + 1);
+}
+
/*
* move_tasks tries to move up to imbalance weighted load from busiest to
* this_rq, as part of a balancing operation within domain "sd".
@@ -4001,7 +4007,7 @@ static int move_tasks(struct lb_env *env)
if (throttled_lb_pair(task_group(p), env->src_cpu,
env->dst_cpu))
goto next;
- load = task_h_load(p);
+ load = task_h_load_avg(p);
if (sched_feat(LB_MIN) && load < 16 &&
!env->sd->nr_balance_failed)
goto next;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/7] sched: remove SMP cover for runnable variables in cfs_rq
The following variables were covered under CONFIG_SMP in struct cfs_rq.
but similar runnable variables work for UP in struct rq and task_group.
like rq->avg, task_group->load_avg.
So move them out, they also can work with UP.
u64 runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
u32 tg_runnable_contrib;
u64 tg_load_contrib;
Signed-off-by: Alex Shi
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7f36024f..1a02b90 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -226,7 +226,6 @@ struct cfs_rq {
unsigned int nr_spread_over;
#endif
-#ifdef CONFIG_SMP
/*
* CFS Load tracking
* Under CFS, load is tracked on a per-entity basis and aggregated up.
@@ -242,6 +241,7 @@ struct cfs_rq {
u64 tg_load_contrib;
#endif /* CONFIG_FAIR_GROUP_SCHED */
+#ifdef CONFIG_SMP
/*
* h_load = weight * f(tg)
*
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/7] sched: update cpu load after task_tick.
To get the latest runnable info, we need do this cpuload update after task_tick. Signed-off-by: Alex Shi --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index ecec7f1..33bcebf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2692,8 +2692,8 @@ void scheduler_tick(void) raw_spin_lock(>lock); update_rq_clock(rq); - update_cpu_load_active(rq); curr->sched_class->task_tick(rq, curr, 0); + update_cpu_load_active(rq); raw_spin_unlock(>lock); perf_event_task_tick(); -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/7] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking"
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 7 +--
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h | 9 +
4 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e692a02..9539597 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1161,12 +1161,7 @@ struct sched_entity {
struct cfs_rq *my_q;
#endif
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
/* Per-entity load-tracking */
struct sched_avgavg;
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 67d0465..c8db984 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1563,12 +1563,7 @@ static void __sched_fork(struct task_struct *p)
p->se.vruntime = 0;
INIT_LIST_HEAD(>se.group_node);
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
#endif
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7a33e59..9c2f726 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1109,8 +1109,7 @@ static inline void update_cfs_shares(struct cfs_rq
*cfs_rq)
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* Only depends on SMP, FAIR_GROUP_SCHED may be removed when useful in lb */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
/*
* We choose a half-life close to 1 scheduling period.
* Note: The tables below are dependent on this value.
@@ -3394,12 +3393,6 @@ unlock:
}
/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
* Called immediately before a task is migrated to a new cpu; task_cpu(p) and
* cfs_rq_of(p) references at time of call are still valid and identify the
* previous cpu. However, the caller only guarantees p->pi_lock is held; no
@@ -3422,7 +3415,6 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
atomic64_add(se->avg.load_avg_contrib, _rq->removed_load);
}
}
-#endif
#endif /* CONFIG_SMP */
static unsigned long
@@ -6114,9 +6106,8 @@ const struct sched_class fair_sched_class = {
#ifdef CONFIG_SMP
.select_task_rq = select_task_rq_fair,
-#ifdef CONFIG_FAIR_GROUP_SCHED
.migrate_task_rq= migrate_task_rq_fair,
-#endif
+
.rq_online = rq_online_fair,
.rq_offline = rq_offline_fair,
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index cc03cfd..7f36024f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -227,12 +227,6 @@ struct cfs_rq {
#endif
#ifdef CONFIG_SMP
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
/*
* CFS Load tracking
* Under CFS, load is tracked on a per-entity basis and aggregated up.
@@ -242,8 +236,7 @@ struct cfs_rq {
u64 runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
-#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* These always depend on CONFIG_FAIR_GROUP_SCHED */
+
#ifdef CONFIG_FAIR_GROUP_SCHED
u32 tg_runnable_contrib;
u64 tg_load_contrib;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/7] use runnable load avg in load balance
This patchset bases on tip/sched/core. It fixed a UP config bug. And the last of patch changed, it insert the runnable load avg into effective_load(), thus the wake_affine consider load avg via effective_load. I retested on Intel core2, NHM, SNB, IVB, 2 and 4 sockets machines with benchmark kbuild, aim7, dbench, tbench, hackbench, fileio-cfq(sysbench), and tested pthread_cond_broadcast on SNB. The test result is similar with last version. So, clear changes is same: On SNB EP 4 sockets machine, the hackbench increased about 50%, and result become stable. on other machines, hackbench increased about 2~5%. no clear performance change on other benchmarks. Since the change is small, and my results is similar with last, guess Michael and Morten still can keep the advantages. Anyway, for last version result of them, you can find: https://lkml.org/lkml/2013/4/2/1022 Michael Wang had tested previous version on pgbench on his box: http://comments.gmane.org/gmane.linux.kernel/1463371 Morten tested previous version with some benchmarks. Thanks again for Peter's comments! Regards! Alex [PATCH v5 1/7] Revert "sched: Introduce temporary FAIR_GROUP_SCHED [PATCH v5 2/7] sched: remove SMP cover for runnable variables in [PATCH v5 3/7] sched: set initial value of runnable avg for new [PATCH v5 4/7] sched: update cpu load after task_tick. [PATCH v5 5/7] sched: compute runnable load avg in cpu_load and [PATCH v5 6/7] sched: consider runnable load average in move_tasks [PATCH v5 7/7] sched: consider runnable load average in -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/14] perf ftrace: Add 'record' sub-command
Hi Jiri, Sorry for late reply. I've been busy these days. On Thu, 25 Apr 2013 15:24:18 +0900, Namhyung Kim wrote: > On Wed, 24 Apr 2013 16:12:41 +0200, Jiri Olsa wrote: >> I got following lockup for record command: >> >> # ./perf --no-pager ftrace record ls >> ... >> hangs >> >> in other terminal: >> >> # pstack 14237 >> Thread 2 (Thread 0x7f3f1aa1d700 (LWP 14241)): >> #0 0x003cec20b595 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1 0x00446ebe in record_ftrace_raw_buffer (arg=0x21f9ce0) at >> builtin-ftrace.c:451 >> #2 0x003cec207d14 in start_thread () from /lib64/libpthread.so.0 >> #3 0x003cebaf168d in clone () from /lib64/libc.so.6 >> Thread 1 (Thread 0x7f3f1ba209c0 (LWP 14237)): >> #0 0x003cec208e60 in pthread_join () from /lib64/libpthread.so.0 >> #1 0x00449c8c in do_ftrace_record >> (ftrace=ftrace@entry=0x7fff1377d240) at builtin-ftrace.c:682 >> #2 0x0044a57b in __cmd_ftrace_record (argv=0x7fff1377d818, >> argc=, ftrace=0x7fff1377d240) at builtin-ftrace.c:1535 >> #3 cmd_ftrace (argc=2, argv=0x7fff1377d818, prefix=) at >> builtin-ftrace.c:1655 >> #4 0x0041a763 in run_builtin (p=p@entry=0x7d58a0, >> argc=argc@entry=3, argv=argv@entry=0x7fff1377d818) at perf.c:320 >> #5 0x00419faf in handle_internal_command (argv=0x7fff1377d818, >> argc=3) at perf.c:377 >> #6 run_argv (argv=0x7fff1377d600, argcp=0x7fff1377d60c) at perf.c:421 >> #7 main (argc=3, argv=0x7fff1377d818) at perf.c:522 >> > > How often can you reproduce it? I can't. :( > > But it looks there's a race between cond_wait() and cond_broatcast(). > I'll take a look at that. I think the problem is that a recorder can be blocked if it received a broadcast signal before calling cond_wait(). So I modified the code to place signaling ready_cond and waiting start_cond in the same cs. Does the patch below fix your problem? Thanks, Namhyung diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c index 4296948197de..f1ecfa207822 100644 --- a/tools/perf/builtin-ftrace.c +++ b/tools/perf/builtin-ftrace.c @@ -428,12 +428,6 @@ static void *record_ftrace_raw_buffer(void *arg) fra->state = RECORD_STATE__READY; - /* Now I'm ready */ - pthread_mutex_lock(_mutex); - recorder_count++; - pthread_cond_signal(_ready_cond); - pthread_mutex_unlock(_mutex); - /* * block all signals but SIGUSR2. * It'll be used to unblock a recorder to finish. @@ -447,7 +441,10 @@ static void *record_ftrace_raw_buffer(void *arg) fcntl(trace_fd, F_SETFL, O_NONBLOCK); pollfd.fd = trace_fd; + /* Now I'm ready */ pthread_mutex_lock(_mutex); + recorder_count++; + pthread_cond_signal(_ready_cond); pthread_cond_wait(_start_cond, _mutex); pthread_mutex_unlock(_mutex); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On 04/29/2013 02:55 AM, Alan Stern wrote: On Sun, 28 Apr 2013, ZhenHua wrote: In fact, the patch is so easy that I am including it below. Please test this (without either of your patches) to see if it works. Alan Stern Index: usb-3.9/drivers/usb/host/uhci-hub.c === --- usb-3.9.orig/drivers/usb/host/uhci-hub.c +++ usb-3.9/drivers/usb/host/uhci-hub.c @@ -225,7 +225,8 @@ static int uhci_hub_status_data(struct u /* auto-stop if nothing connected for 1 second */ if (any_ports_active(uhci)) uhci->rh_state = UHCI_RH_RUNNING; - else if (time_after_eq(jiffies, uhci->auto_stop_time)) + else if (time_after_eq(jiffies, uhci->auto_stop_time) && + !uhci->wait_for_hp) suspend_rh(uhci, UHCI_RH_AUTO_STOPPED); break; I have tested the UHCI_RH_RUNNING_NODEVS case yeasterday, and it works. But the function suspend_rh is also called in other places, so I think it only fixes the warning when auto stop is called, but not fix the warning when uhci's bus_suspend is called, it will come out again. Have you tried this? I expect the warning will not occur when the bus_suspend routine is called, because then there will be a 1-ms delay, not just a 400-us delay. I tested this, and the warning is gone. Is this patch committed ? I need to paste the link to suse bugzilla. Not joking. I tested both of them , uhci->wait_for_hp and no_auto_stop , for the UHCI_RH_RUNNING_NODEVS case. And as uhci->wait_for_hp is 1 on my system, so they got the same result. You must be joking. I wrote that patch while composing the email message to you, and nobody except you has tested it. Since you confirm that it works, I will submit it. But new patches like this won't be accepted until after the upcoming merge window closes, which won't be for more than two weeks. And if you add uhci->wait_for_hp check in the UHCI_RH_RUNNING_NODEVS case, all hp uhci devices will not auto stop, not only the virtual devices. I guess it may waste resource. If you want, you can add a new flag specifically for virtual controllers. But it shouldn't matter -- as long as your kernels are built with CONFIG_PM_RUNTIME enabled, there won't be any significant waste of resources. Alan Stern I think we can check the product id to determine whether a device is virtual. Do you know if there is another way to check this? I don't know anything at all about your virtual UHCI controllers, other than what you have told me. In particular, I don't know what product IDs are used by HP's virtual and non-virtual controllers. Maybe somebody else at HP can tell you. Alan Stern . So I can only check the product IDs. Thanks for helping me on this bug. Regards Zhen-Hua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 2/3] pwm: pxa: use module_platform_driver()
Old pwm-pxa.c will register driver by arch_initcall. Then other
drivers based on the PWM driver can successully call old
pwm_request because arch_initcall make sure the PWM driver will
be registered earlier.
Now, pwm_request is re-written and done by common layer code. It
will return -EPROBE_DEFER if the PWM device is not probed.
The driver based on PWM driver can make use of -EPROBE_DEFER
to delay its probing.
So arch_initcall can be replaced by module_platform_driver.
Signed-off-by: Chao Xie
---
drivers/pwm/pwm-pxa.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index dee6ab55..aa4bea7 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -187,16 +187,6 @@ static struct platform_driver pwm_driver = {
.id_table = pwm_id_table,
};
-static int __init pwm_init(void)
-{
- return platform_driver_register(_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-module_exit(pwm_exit);
+module_platform_driver(pwm_driver);
MODULE_LICENSE("GPL v2");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 3/3] pwm: pxa: add device tree support
Add the deice tree support for pwm-pxa.
Signed-off-by: Chao Xie
---
drivers/pwm/pwm-pxa.c | 52 -
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index aa4bea7..c8d59a2 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -9,6 +9,8 @@
*
* 2008-02-13 initial version
* eric miao
+ * 2013-04-24 add device tree support
+ * Chao Xie
*/
#include
@@ -18,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -124,6 +128,38 @@ static struct pwm_ops pxa_pwm_ops = {
.owner = THIS_MODULE,
};
+static const struct of_device_id pxa_pwm_of_match[] = {
+ {
+ .compatible = "marvell,pxa25x-pwm",
+ }, {
+ .compatible = "marvell,pxa27x-pwm",
+ .data = (void *)HAS_SECONDARY_PWM
+ }, {
+ .compatible = "marvell,pxa168-pwm",
+ }, {
+ .compatible = "marvell,pxa910-pwm",
+ },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, pxa_pwm_of_match);
+
+static int pxa_pwm_parse_data_dt(struct platform_device *pdev,
+ struct pxa_pwm_chip *pwm)
+{
+ const struct of_device_id *of_id =
+ of_match_device(pxa_pwm_of_match, >dev);
+ unsigned int npwm;
+
+ if (!of_id)
+ return -ENODEV;
+
+ npwm = (unsigned int)of_id->data;
+ pwm->chip.npwm = (npwm & HAS_SECONDARY_PWM) ? 2 : 1;
+
+ return 0;
+}
+
static int pwm_probe(struct platform_device *pdev)
{
const struct platform_device_id *id = platform_get_device_id(pdev);
@@ -144,7 +180,6 @@ static int pwm_probe(struct platform_device *pdev)
pwm->chip.dev = >dev;
pwm->chip.ops = _pwm_ops;
pwm->chip.base = -1;
- pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -156,6 +191,20 @@ static int pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm->mmio_base))
return PTR_ERR(pwm->mmio_base);
+ if (!id) {
+ if (IS_ENABLED(CONFIG_OF))
+ ret = pxa_pwm_parse_data_dt(pdev, pwm);
+ else
+ ret = -ENODEV;
+ } else {
+ pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
+ }
+
+ if (ret) {
+ dev_err(>dev, "failed to parse data from device id\n");
+ return ret;
+ }
+
ret = pwmchip_add(>chip);
if (ret < 0) {
dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
@@ -181,6 +230,7 @@ static struct platform_driver pwm_driver = {
.driver = {
.name = "pxa25x-pwm",
.owner = THIS_MODULE,
+ .of_match_table = pxa_pwm_of_match,
},
.probe = pwm_probe,
.remove = pwm_remove,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 0/3] pwm: pxa: bug fix and device tree support
The patches fix some bugs
1. pwm-pxa driver is shared by ARCH_PXA and ARCH_MMP
2. use module_platform_driver for driver register
The patches also add device tree support for pwm.
V2->V1:
Remove the redundant initialization.
Fix bug of no initialization of .of_match_table.
Use CONFIG_OF for device tree support.
Rebase to for-next
V3->V2:
Change "mrvl,xxx" to "marvell,xxx".
V4->V3
Change comments for "pwm: pxa: use module_platform_driver()"
and "pwm: pxa: ARCH_MMP share same pwm driver with ARCH_PXA".
Use "static const" for pxa_pwm_of_match definition.
Use the below scheme for DT support.
if (!id_entry) {
if (IS_ENABLED(CONFIG_OF))
err = parse_dt();
else
err = -ENODEV;
} else {
err = parse_pdata();
}
if (err < 0)
return err;
Chao Xie (3):
pwm: pxa: ARCH_MMP share same pwm driver with ARCH_PXA
pwm: pxa: use module_platform_driver()
pwm: pxa: add device tree support
drivers/pwm/Kconfig |2 +-
drivers/pwm/pwm-pxa.c | 64 +++-
2 files changed, 53 insertions(+), 13 deletions(-)
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 1/3] pwm: pxa: ARCH_MMP share same pwm driver with ARCH_PXA
The PWM driver is not only used by ARCH_PXA but also ARCH_MMP. Signed-off-by: Chao Xie --- drivers/pwm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 115b644..9ec4040 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -108,7 +108,7 @@ config PWM_PUV3 config PWM_PXA tristate "PXA PWM support" - depends on ARCH_PXA + depends on ARCH_PXA || ARCH_MMP help Generic PWM framework driver for PXA. -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] perf: Expand definition of sysfs format attribute
On Mon, Apr 08, 2013 at 05:24:22PM +1000, Michael Ellerman wrote: > On Mon, Mar 04, 2013 at 03:21:05PM +1100, Michael Ellerman wrote: > > Make it explicit that the format attributes may define overlapping bit > > ranges. Unfortunately this was left unspecified originally, and all the > > examples show non-overlapping ranges. I don't believe this is an ABI > > change, as we are defining something that was previously undefined, but > > others may disagree. > > > > The POWER8 PMU would like to define overlapping ranges, as bit ranges in > > the event code have different meanings for certain events. It will also > > allow us to define an overarching "event" field, that encompasses all > > others. > > > > As far as I can see perf is comfortable with this change, however I am > > not sure if there are any other users of the interface. > > Any comments on this one? Hi Arnaldo, I think the consensus from Peter and Jiri was that this was OK, are you happy to merge it? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: the mips tree is screwed up again
Hi Ralf, It looks like John Crispin has cherry-picked or rebased part of Linus' tree into his branch that you have now merged. Guys, don't rebase your trees - especially this late and especially after they have been merged into a published tree. I will use the mips tree from Friday. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpmgOWsf4Xhw.pgp Description: PGP signature
[GIT] [3.10] MFD pull request
Hi Linus, This is the MFD pull request for the 3.10 merge window. There is one merge conflict with your tree, and I fixed it for reference in my mfd-3.10-merge branch. For 3.10 we have a few new MFD drivers for: - The ChromeOS embedded controller which provides keyboard, battery and power management services. This controller is accessible through i2c or SPI. - Silicon Laboratories 476x controller, providing access to their FM chipset and their audio codec. - Realtek's RTS5249, a memory stick, MMC and SD/SDIO PCI based reader. - Nokia's Tahvo power button and watchdog device. This device is very similar to Retu and is thus supported by the same code base. - STMicroelectronics STMPE1801, a keyboard and GPIO controller supported by the stmpe driver. - ST-Ericsson AB8540 and AB8505 power management and voltage converter controllers through the existing ab8500 code. Some other drivers got cleaned up or improved. In particular: - The Linaro/STE guys got the ab8500 driver in sync with their internal code through a series of optimizations, fixes and improvements. - The AS3711 and OMAP USB drivers now have DT support. - The arizona clock and interrupt handling code got improved. - The wm5102 register patch and boot mechanism also got improved. The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git tags/mfd-3.10-1 for you to fetch changes up to 99f4c6b66a9ae362d21e6df95d04bc74e04d285e: mfd: si476x: Don't use 0bNNN (2013-04-26 17:23:30 +0200) Aaro Koskinen (1): mfd: retu: Add Tahvo support Alessandro Rubini (1): mfd: sta2x11: Build warning fix Alexander Shiyan (4): mfd: syscon: Removed unneeded field "dev" from private driver structure mfd: syscon: Add non-DT support of: Add stub of_get_parent for non-OF builds mfd: syscon: Fix warnings when printing resource_size_t Andrew Morton (1): mfd: si476x: Don't use 0bNNN Andrey Smirnov (4): mfd: si476x: Add commands abstraction layer mfd: si476x: Add the bulk of the core driver mfd: si476x: Add chip properties handling code mfd: si476x: Add header files and Kbuild plumbing Arnd Bergmann (2): ARM: ux500: split out prcmu initialization mfd: ab8500: Export ab8500_gpadc_sw_hw_convert properly Ashish Jangam (1): mfd: da9055: Change irq state to default Charles Keepax (7): mfd: wm5102: Manually apply register patch mfd: arizona: Factor out register polling mfd: arizona: Add a hardware patch mechanism mfd: wm5102: Deactivate standard boot sequence mfd: wm5102: Update defaults to match patch mfd: arizona: Wait for internal clocks to startup after reset mfd: wm5102: Don't wait for boot when boot sequencer is disabled Daniel WILLERUD (1): mfd: ab8500-gpadc: Implemented suspend/resume Dariusz Szymczak (1): mfd: ab8500-core: Hierarchical interrupt registers David Rientjes (1): mfd: cros_ec: Add MFD_CORE dependency Fabio Baltieri (2): mfd: ab8500-core: Ignore masked out interrupts mfd: ab8500-core: Add of_compatilbe property for ab8500-usb Gabriel Fernandez (2): mfd: stmpe: DT: Enable no-irq mode configuration mfd: stmpe: DT: Add stmpe-i2c dt alias to get id device Guennadi Liakhovetski (1): mfd: as3711: Add OF support Hakan Berg (3): ab8500-btemp: Filter btemp readings ab8500-fg: Allow capacity to raise from 1% when charging ab8500-charger: Add AB8505_USB_LINK_STATUS Hans Verkuil (1): mfd: si476x: Fix i2c warning Ian Lartey (1): mfd: palmas: is_palmas_charger needed by multiple drivers J Keerthy (1): mfd: palmas: Change the DT node property names to follow the convention Jean-Nicolas Graux (1): mfd: support stmpe1801 18 bits enhanced port expander Jingoo Han (19): mfd: ab3100-otp: use module_platform_driver_probe() mfd: htc-pasic3: use module_platform_driver_probe() mfd: davinci_voicecodec: use module_platform_driver_probe() mfd: wm8994: Silence bogus warning in wm8994_device_init() mfd: 88pm860x: Drop devm_kfree of devm_kzalloc'd data mfd: lm3533: Use devm_gpio_request_one() mfd: intel_msic: Use devm_gpio_request_one() mfd: omap-usb-host: Use devm_gpio_request_one() mfd: aat2870: Use use devm_*() functions mfd: twl6040: Use devm_*() functions mfd: ezx-pcap: Use devm_*() functions mfd: da903x: Use devm_*() functions mfd: tc3589x: Use devm_*() functions mfd: wm831x: Use spi_get_drvdata() and spi_set_drvdata() mfd: da9052: Use spi_get_drvdata() and spi_set_drvdata() mfd: ezx-pcap: Use spi_get_drvdata() and spi_set_drvdata() mfd: mc13xxx: Use spi_get_drvdata() and spi_set_drvdata()
Re: Re: MIPS : die at free_initmem() function 3.9+
>So on 64bits MIPS platforms, __va(__pa(x)) may not equal to x, that may cause >trouble to free_initmem_default(). Could you please help to do another test >by changing >free_initmem_default(POISON_FREE_INITMEM); >to >free_initmem_default(0); >This test could help to identify whether this panic is caused by >memset((void *)pos, poison, PAGE_SIZE); >in function free_reserved_area(). Hello, as you said i changed "free_initmem_default(POISON_FREE_INITMEM);" to "free_initmem_default(0);". Panic still occurred. Actually, i put the some debug messages. and i confirmed panic occurs in __free_reserved_page() function. Thanks!
Re: [PATCH 1/2] freezer: add unsafe versions of freezable helpers
Hi!
> > NFS calls the freezable helpers with locks held, which is unsafe
> > and caused lockdep warnings when 6aa9707 "lockdep: check that no
> > locks held at freeze time" was applied (reverted in dbf520a).
> > Add new *_unsafe versions of the helpers that will not run the
> > lockdep test when 6aa9707 is reapplied, and call them from NFS.
> >
> > Signed-off-by: Colin Cross
> > ---
> > fs/nfs/inode.c | 2 +-
> > fs/nfs/nfs3proc.c | 2 +-
> > fs/nfs/nfs4proc.c | 4 ++--
> > include/linux/freezer.h | 42 +-
> > net/sunrpc/sched.c | 2 +-
> > 5 files changed, 46 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> > index 1f94167..53cbee5 100644
> > --- a/fs/nfs/inode.c
> > +++ b/fs/nfs/inode.c
> > @@ -79,7 +79,7 @@ int nfs_wait_bit_killable(void *word)
> > {
> > if (fatal_signal_pending(current))
> > return -ERESTARTSYS;
> > - freezable_schedule();
> > + freezable_schedule_unsafe();
>
> I'd suggest naming such variants _unkillable() instead of _unsafe().
>
> There's nothing inherently 'unsafe' about it: the user asked for a hard
> NFS mount and is getting it: with the side effect that it exposes the
> machine to network delays in a 'hard' way as well. Which means suspend may
> block indefinitely as well on network failure.
You only want to use _unsafe() variants when you enter refrigerator
with locks held.
And entering refrigerator with locks is tricky... and unsafe :-). It
is not directly related to killability.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MPILIB: disable usage of floating point registers on parisc
The umul_ppmm() macro for parisc uses the xmpyu assembler statement
which does calculation via a floating point register.
But usage of floating point registers inside the Linux kernel are not
allowed and gcc will stop compilation due to the -mdisable-fpregs
compiler option.
Fix this by disabling the umul_ppmm() and udiv_qrnnd() macros. The
mpilib will then use the generic built-in implementations instead.
Signed-off-by: Helge Deller
diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index 095ab15..d411355 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -318,7 +318,8 @@ extern UDItype __udiv_qrnnd();
"rM" ((USItype)(bh)), \
"rM" ((USItype)(al)), \
"rM" ((USItype)(bl)))
-#if defined(_PA_RISC1_1)
+#if 0 && defined(_PA_RISC1_1)
+/* xmpyu uses floating point register which is not allowed in Linux kernel. */
#define umul_ppmm(wh, wl, u, v) \
do { \
union {UDItype __ll; \
@@ -337,7 +338,7 @@ do { \
#define UMUL_TIME 40
#define UDIV_TIME 80
#endif
-#ifndef LONGLONG_STANDALONE
+#if 0 /* #ifndef LONGLONG_STANDALONE */
#define udiv_qrnnd(q, r, n1, n0, d) \
do { USItype __r; \
(q) = __udiv_qrnnd(&__r, (n1), (n0), (d)); \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel/modsign_certificate.S: fix build on parisc architecture
Module signing functionality breaks the kernel build on parisc with the following error: kernel/built-in.o: In function `load_module_signing_keys': kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end' kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list' make[3]: *** [vmlinux] Error 1 The reason why the build fails is because on parisc assembly syntax is different than on other architectures. Most importantly, a semicolon marks the start of a comment, while exclamation marks separates statements. Currently the GLOBAL(name) macro uses a semicolon to separate the .globl and the ASM_SYMBOL() statements. On PA-RISC the semicolon will now just strip the ASM_SYMBOL() statements since it thinks it is a comment and as such the modsign_certificate_list/modsign_certificate_list_end symbols will not get defined and will not be in the vmlinux binary. Fix this problem by adding an own implementation for GLOBAL() on the PARISC architecture. Signed-off-by: Helge Deller diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S index 246b4c6..9b9c2ab 100644 --- a/kernel/modsign_certificate.S +++ b/kernel/modsign_certificate.S @@ -7,9 +7,17 @@ #define ASM_SYMBOL(sym) PASTE(SYMBOL_PREFIX, sym) #endif -#define GLOBAL(name) \ - .globl ASM_SYMBOL(name);\ +#if defined(__hppa__) + /* HPPA/PA-RISC assembly is special: comments start with semicolon + * and exclamation marks separates statements. */ + #define GLOBAL(name) \ + .globl ASM_SYMBOL(name) ! \ ASM_SYMBOL(name): +#else + #define GLOBAL(name) \ + .globl ASM_SYMBOL(name) ; \ + ASM_SYMBOL(name): +#endif .section ".init.data","aw" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, RFC] Full dynticks, CONFIG_NO_HZ_FULL feature
On Sun, May 05, 2013 at 01:33:45PM -0700, Linus Torvalds wrote: > On Sun, May 5, 2013 at 4:03 AM, Ingo Molnar wrote: > > > > Please consider pulling the latest timers-nohz-for-linus git tree from: > > Ok, it seems to work for me, so pulled. > > However, by "work for me" I mean "doesn't actually seem to make any > difference for me". Maybe I'm odd, but the most common situation is > either a fairly idle machine (in which case the old NOHZ did fine) or > a fairly over-crowded one when I'm running something sufficiently > threaded (in which case the new NOHZ_FULL doesn't do anything either). > > So I really hope the "cpu has more than one running thread" case is > getting a lot of attention. Not for 3.10, but right now it seems to > still result in the same old 1kHz timer interrupts.. > > So I haven't actually found a real load where any of this makes a > noticeable *difference*. The workloads where we expect the most noticeable differences are HPC workloads with short iterations and a HPC-style barrier between each interation on the one hand and real-time workloads on the other. My guess is that you aren't doing too much of either. We do have some measurements taken on an early prototype of this patchset, which are on slides 5 and 6 of: http://linuxplumbersconf.org/2009/slides/Josh-Triplett-painless-kernel.pdf This is for an HPC workload with a 100-microsecond iteration time. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio: don't expose u16 in userspace api
From: Stephen Hemminger Date: Fri, 3 May 2013 17:49:41 -0700 > Programs using virtio headers outside of kernel will no longer > build because u16 type does not exist in userspace. All user ABI > must use __u16 typedef instead. > > Bug introduce by: > commit 986a4f4d452dec004697f667439d27c3fda9c928 > Author: Jason Wang > Date: Fri Dec 7 07:04:56 2012 + > > virtio_net: multiqueue support > > Signed-off-by: Stephen Hemminger Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ext4: implement error handling of ext4_mb_new_preallocation()
If memory allocation in ext4_mb_new_group_pa() is failed,
it returns error code, ext4_mb_new_preallocation() propages it,
but ext4_mb_new_blocks() ignores it.
An observed result was:
- allocation fail means ext4_mb_new_group_pa() does not update
ext4_allocation_context;
- ext4_mb_new_blocks() sets ext4_allocation_request->len (ar->len =
ac->ac_b_ex.fe_len;)
to number of blocks preallocated (512) instead of number of blocks requested
(1);
- that activates update cycle in ext4_splice_branch():
for (i = 1; i < blks; i++) <-- blks is 512 instead of 1 here
*(where->p + i) = cpu_to_le32(current_block++);
- it iterates 511 times and corrupts a chunk of memory including inode
structure;
- page fault happens at EXT4_SB(inode->i_sb) in ext4_mark_inode_dirty();
- system hangs with 'scheduling while atomic' BUG.
The patch implements a check for ext4_mb_new_preallocation() error code
and handles its failure as if ext4_mb_regular_allocator() fails.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
fs/ext4/mballoc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index b1ed9e0..95c6b0d 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4401,17 +4401,18 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
repeat:
/* allocate space in core */
*errp = ext4_mb_regular_allocator(ac);
+ if (!*errp) {
+ /* as we've just preallocated more space than
+* user requested orinally, we store allocated
+* space in a special descriptor */
+ if (ac->ac_status == AC_STATUS_FOUND &&
+ ac->ac_o_ex.fe_len < ac->ac_b_ex.fe_len)
+ *errp = ext4_mb_new_preallocation(ac);
+ }
if (*errp) {
ext4_discard_allocated_blocks(ac);
goto errout;
}
-
- /* as we've just preallocated more space than
-* user requested orinally, we store allocated
-* space in a special descriptor */
- if (ac->ac_status == AC_STATUS_FOUND &&
- ac->ac_o_ex.fe_len < ac->ac_b_ex.fe_len)
- ext4_mb_new_preallocation(ac);
}
if (likely(ac->ac_status == AC_STATUS_FOUND)) {
*errp = ext4_mb_mark_diskspace_used(ac, handle, reserv_clstrs);
--
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/
Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3
After building 3.9 for my HP/Compaq 2510p laptop, the wireless (iwl4965) would seemingly no longer connect. Actually, it seems that it *will* eventually, where that is somewhere between 4 and 21+ retries (from KDE network manager). Going back to 3.8 (and earlier) and the problem goes away. (All on Fedora 18, fwiw, but I don't think that's significant). I bisected the problem to: commit 1672c0e31917f49d31d30d79067103432bc20cc7 Author: Johannes Berg Date: Tue Jan 29 15:02:27 2013 +0100 mac80211: start auth/assoc timeout on frame status but I can't (easily) revert that in 3.9 (maybe I can in -rc1 or something? haven't tried that) What more information is needed from me? I may still mess around with trying to revert that patch just to nail it down for sure, but two separate bisection exercises ended up at the same place. There are a few traps for the unwary if anyone else ends up bisecting in through here -- the first bisection (3.8 - 3.9-rc1) ran into an IPv6 build error along the way, which I "fixed" by configuring it out -- also, the amount of retries goes from *many* (15-21+) to relatively few (4) somewhere in there, which confused me and led to the second bisection (3.8-3.9) ... jake -- Jake Edge - LWN - j...@lwn.net - http://lwn.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
On Sun, May 05, 2013 at 10:24:22PM +0200, Alessandro Rubini wrote: > > Did this got fixed in some tree in the meantime? Because I still see it on > > current Linus + tip/master: > > > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from > > incompatible pointer type [enabled by default] > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for > > âsta2x11_dma_ops.freeâ) [enabled by default] > > Last time I sent the patch was on Feb 22nd: > >The .free field of struct dma_map_ops features a prototype that is >different from what lib/swiotlb.c offers. The new "attrs" argument in >dma_ops.free is missing from the generic implementation. > >This removes the build warning by providing a function that just calls >swiotlb_free_coherent() without passing "attrs", like others do. > > I got no reply. It probably fell through the cracks... > This is the link: > > http://lkml.org/lkml/2013/2/22/111 > > It is in patchwork here: > > https://patchwork.kernel.org/patch/2175551/ Ingo, hpa, can you guys pick it up? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] enable support for AMBA drivers under x86
> Did this got fixed in some tree in the meantime? Because I still see it on > current Linus + tip/master: > > arch/x86/pci/sta2x11-fixup.c:186:2: warning: initialization from incompatible > pointer type [enabled by default] > arch/x86/pci/sta2x11-fixup.c:186:2: warning: (near initialization for > âsta2x11_dma_ops.freeâ) [enabled by default] Last time I sent the patch was on Feb 22nd: The .free field of struct dma_map_ops features a prototype that is different from what lib/swiotlb.c offers. The new "attrs" argument in dma_ops.free is missing from the generic implementation. This removes the build warning by providing a function that just calls swiotlb_free_coherent() without passing "attrs", like others do. I got no reply. This is the link: http://lkml.org/lkml/2013/2/22/111 It is in patchwork here: https://patchwork.kernel.org/patch/2175551/ /alessandro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, RFC] Full dynticks, CONFIG_NO_HZ_FULL feature
On Sun, May 5, 2013 at 4:03 AM, Ingo Molnar wrote: > > Please consider pulling the latest timers-nohz-for-linus git tree from: Ok, it seems to work for me, so pulled. However, by "work for me" I mean "doesn't actually seem to make any difference for me". Maybe I'm odd, but the most common situation is either a fairly idle machine (in which case the old NOHZ did fine) or a fairly over-crowded one when I'm running something sufficiently threaded (in which case the new NOHZ_FULL doesn't do anything either). So I really hope the "cpu has more than one running thread" case is getting a lot of attention. Not for 3.10, but right now it seems to still result in the same old 1kHz timer interrupts.. So I haven't actually found a real load where any of this makes a noticeable *difference*. 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, RFC 11/22] iwlegacy: il_pm_ops is only provided for PM_SLEEP
On Thu, May 02, 2013 at 05:16:15PM +0200, Arnd Bergmann wrote: > This makes sure the conditionals for the declaration match the > definition, so we provide the alternative > > #else > #define IL_LEGACY_PM_OPS NULL > #endif > > in the correct cases. > > drivers/built-in.o:(.data+0x57974): undefined reference to `il_pm_ops' Yep, I see this too here. > > Cc: Johannes Berg > Cc: John W. Linville > Signed-off-by: Arnd Bergmann > --- > drivers/net/wireless/iwlegacy/common.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/iwlegacy/common.h > b/drivers/net/wireless/iwlegacy/common.h > index f8246f2..734f1b4 100644 > --- a/drivers/net/wireless/iwlegacy/common.h > +++ b/drivers/net/wireless/iwlegacy/common.h > @@ -1832,7 +1832,7 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, > u32 beacon_interval); > __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon, > u32 beacon_interval); > > -#ifdef CONFIG_PM > +#ifdef CONFIG_PM_SLEEP > extern const struct dev_pm_ops il_pm_ops; > > #define IL_LEGACY_PM_OPS (_pm_ops) Btw, you might want to adjust the macro comments for consistency too, like so. Alternatively, you could simply remove them since they only clutter two-liner and one can see what it encloses. -- diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h index f8246f2d88f9..4caaf52986a4 100644 --- a/drivers/net/wireless/iwlegacy/common.h +++ b/drivers/net/wireless/iwlegacy/common.h @@ -1832,16 +1832,16 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, u32 beacon_interval); __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon, u32 beacon_interval); -#ifdef CONFIG_PM +#ifdef CONFIG_PM_SLEEP extern const struct dev_pm_ops il_pm_ops; #define IL_LEGACY_PM_OPS (_pm_ops) -#else /* !CONFIG_PM */ +#else /* !CONFIG_PM_SLEEP */ #define IL_LEGACY_PM_OPS NULL -#endif /* !CONFIG_PM */ +#endif /* !CONFIG_PM_SLEEP */ /* * Error Handling Debugging -- -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [tip:timers/urgent] tick: Cleanup NOHZ per cpu data on cpu down
On 05/05/2013 02:20 AM, tip-bot for Thomas Gleixner wrote:
> Commit-ID: ae7868e241c015aadc8632d9fe633a102a5918f6
> Gitweb: http://git.kernel.org/tip/ae7868e241c015aadc8632d9fe633a102a5918f6
> Author: Thomas Gleixner
> AuthorDate: Fri, 3 May 2013 15:02:50 +0200
> Committer: Thomas Gleixner
> CommitDate: Sun, 5 May 2013 08:15:11 +0200
>
> tick: Cleanup NOHZ per cpu data on cpu down
>
> Prarit reported a crash on CPU offline/online. The reason is that on
> CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
> up. If at cpu online an interrupt happens before the per cpu tick
> device is registered the irq_enter() check potentially sees stale data
> and dereferences a NULL pointer.
>
> Cleanup the data after the cpu is dead.
>
> Reported-by: Prarit Bhargava
> Cc: sta...@vger.kernel.org
> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
> Signed-off-by: Thomas Gleixner
> ---
> kernel/time/tick-common.c | 1 +
> kernel/time/tick-internal.h | 6 ++
> kernel/time/tick-sched.c| 7 +++
> 3 files changed, 14 insertions(+)
Whoa -- I thought I said I'll test this first. It doesn't work :( so that means
something else is wrong ... I'm in the middle of debug ATM.
P.
>
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 6176a3e..29b765d 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -387,6 +387,7 @@ static int tick_notify(struct notifier_block *nb,
> unsigned long reason,
> tick_shutdown_broadcast_oneshot(dev);
> tick_shutdown_broadcast(dev);
> tick_shutdown(dev);
> + tick_shutdown_nohz(dev);
> break;
>
> case CLOCK_EVT_NOTIFY_SUSPEND:
> diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
> index f0299ea..9644b29 100644
> --- a/kernel/time/tick-internal.h
> +++ b/kernel/time/tick-internal.h
> @@ -144,3 +144,9 @@ static inline int tick_device_is_functional(struct
> clock_event_device *dev)
> #endif
>
> extern void do_timer(unsigned long ticks);
> +
> +#ifdef CONFIG_NO_HZ
> +extern void tick_shutdown_nohz(unsigned int *cpup);
> +#else
> +static inline void tick_shutdown_nohz(unsigned int *cpup) { }
> +#endif
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 225f8bf..e985ccd 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -797,6 +797,13 @@ static inline void tick_check_nohz(int cpu)
> }
> }
>
> +void tick_shutdown_nohz(unsigned int *cpup)
> +{
> + struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
> +
> + memset(ts, 0, sizeof(*ts));
> +}
> +
> #else
>
> static inline void tick_nohz_switch_to_nohz(void) { }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] USB: ftdi_sio: fix chars_in_buffer overhead
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 6f602912 ("usb:
serial: ftdi_sio: Add missing chars_in_buffer function") without
breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak
and close).
Reported-by: Stas Sergeev
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1159fd4..a62a75a 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -924,7 +924,7 @@ static int ftdi_tiocmset(struct tty_struct *tty,
static int ftdi_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg);
static void ftdi_break_ctl(struct tty_struct *tty, int break_state);
-static int ftdi_chars_in_buffer(struct tty_struct *tty);
+static bool ftdi_tx_empty(struct usb_serial_port *port);
static int ftdi_get_modem_status(struct usb_serial_port *port,
unsigned char status[2]);
@@ -961,7 +961,7 @@ static struct usb_serial_driver ftdi_sio_device = {
.ioctl =ftdi_ioctl,
.set_termios = ftdi_set_termios,
.break_ctl =ftdi_break_ctl,
- .chars_in_buffer = ftdi_chars_in_buffer,
+ .tx_empty = ftdi_tx_empty,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -2056,27 +2056,18 @@ static void ftdi_break_ctl(struct tty_struct *tty, int
break_state)
}
-static int ftdi_chars_in_buffer(struct tty_struct *tty)
+static bool ftdi_tx_empty(struct usb_serial_port *port)
{
- struct usb_serial_port *port = tty->driver_data;
- int chars;
unsigned char buf[2];
int ret;
- chars = usb_serial_generic_chars_in_buffer(tty);
- if (chars)
- goto out;
-
- /* Check if hardware buffer is empty. */
ret = ftdi_get_modem_status(port, buf);
if (ret == 2) {
if (!(buf[1] & FTDI_RS_TEMT))
- chars = 1;
+ return false;
}
-out:
- dev_dbg(>dev, "%s - %d\n", __func__, chars);
- return chars;
+ return true;
}
/* old_termios contains the original termios settings and tty->termios contains
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] USB: serial: clean up chars_in_buffer
No need to grab disconnect mutex in chars_in_buffer now that no
sub-driver is or should be querying hardware buffers anymore. (They
should use wait_until_sent.)
Signed-off-by: Johan Hovold
---
drivers/usb/serial/usb-serial.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 60caf9c..4753c00 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -359,20 +359,13 @@ static int serial_chars_in_buffer(struct tty_struct *tty)
{
struct usb_serial_port *port = tty->driver_data;
struct usb_serial *serial = port->serial;
- int count = 0;
dev_dbg(tty->dev, "%s\n", __func__);
- mutex_lock(>disc_mutex);
- /* if the device was unplugged then any remaining characters
- fell out of the connector ;) */
if (serial->disconnected)
- count = 0;
- else
- count = serial->type->chars_in_buffer(tty);
- mutex_unlock(>disc_mutex);
+ return 0;
- return count;
+ return serial->type->chars_in_buffer(tty);
}
static void serial_wait_until_sent(struct tty_struct *tty, int timeout)
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] USB: io_ti: fix chars_in_buffer overhead
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 263e1f9f ("USB:
io_ti: query hardware-buffer status in chars_in_buffer") without
breaking tty_wait_until_sent (used by, for example, tcdrain, tcsendbreak
and close).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 158bf4b..1be6ba7 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2019,8 +2019,6 @@ static int edge_chars_in_buffer(struct tty_struct *tty)
struct edgeport_port *edge_port = usb_get_serial_port_data(port);
int chars = 0;
unsigned long flags;
- int ret;
-
if (edge_port == NULL)
return 0;
@@ -2028,16 +2026,22 @@ static int edge_chars_in_buffer(struct tty_struct *tty)
chars = kfifo_len(_port->write_fifo);
spin_unlock_irqrestore(_port->ep_lock, flags);
- if (!chars) {
- ret = tx_active(edge_port);
- if (ret > 0)
- chars = ret;
- }
-
dev_dbg(>dev, "%s - returns %d\n", __func__, chars);
return chars;
}
+static bool edge_tx_empty(struct usb_serial_port *port)
+{
+ struct edgeport_port *edge_port = usb_get_serial_port_data(port);
+ int ret;
+
+ ret = tx_active(edge_port);
+ if (ret > 0)
+ return false;
+
+ return true;
+}
+
static void edge_throttle(struct tty_struct *tty)
{
struct usb_serial_port *port = tty->driver_data;
@@ -2557,6 +2561,7 @@ static struct usb_serial_driver edgeport_1port_device = {
.write = edge_write,
.write_room = edge_write_room,
.chars_in_buffer= edge_chars_in_buffer,
+ .tx_empty = edge_tx_empty,
.break_ctl = edge_break,
.read_int_callback = edge_interrupt_callback,
.read_bulk_callback = edge_bulk_in_callback,
@@ -2589,6 +2594,7 @@ static struct usb_serial_driver edgeport_2port_device = {
.write = edge_write,
.write_room = edge_write_room,
.chars_in_buffer= edge_chars_in_buffer,
+ .tx_empty = edge_tx_empty,
.break_ctl = edge_break,
.read_int_callback = edge_interrupt_callback,
.read_bulk_callback = edge_bulk_in_callback,
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] USB: serial: add wait_until_sent operation
Add wait_until_sent operation which can be used to wait for hardware
buffers to drain.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/usb-serial.c | 17 +
include/linux/usb/serial.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index cf75beb..31d2768 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -375,6 +375,22 @@ static int serial_chars_in_buffer(struct tty_struct *tty)
return count;
}
+static void serial_wait_until_sent(struct tty_struct *tty, int timeout)
+{
+ struct usb_serial_port *port = tty->driver_data;
+ struct usb_serial *serial = port->serial;
+
+ dev_dbg(tty->dev, "%s\n", __func__);
+
+ if (!port->serial->type->wait_until_sent)
+ return;
+
+ mutex_lock(>disc_mutex);
+ if (!serial->disconnected)
+ port->serial->type->wait_until_sent(tty, timeout);
+ mutex_unlock(>disc_mutex);
+}
+
static void serial_throttle(struct tty_struct *tty)
{
struct usb_serial_port *port = tty->driver_data;
@@ -1191,6 +1207,7 @@ static const struct tty_operations serial_ops = {
.unthrottle = serial_unthrottle,
.break_ctl =serial_break,
.chars_in_buffer = serial_chars_in_buffer,
+ .wait_until_sent = serial_wait_until_sent,
.tiocmget = serial_tiocmget,
.tiocmset = serial_tiocmset,
.get_icount = serial_get_icount,
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index b9b0f7b4..afbb7ee 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -268,6 +268,7 @@ struct usb_serial_driver {
struct usb_serial_port *port, struct ktermios *old);
void (*break_ctl)(struct tty_struct *tty, int break_state);
int (*chars_in_buffer)(struct tty_struct *tty);
+ void (*wait_until_sent)(struct tty_struct *tty, long timeout);
void (*throttle)(struct tty_struct *tty);
void (*unthrottle)(struct tty_struct *tty);
int (*tiocmget)(struct tty_struct *tty);
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] USB: serial: add generic wait_until_sent implementation
Add generic wait_until_sent implementation which polls for empty
hardware buffers using the new port-operation tx_empty.
The generic implementation will be used for all sub-drivers that
implement tx_empty but does not define wait_until_sent.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/generic.c| 29 +
drivers/usb/serial/usb-serial.c | 2 ++
include/linux/usb/serial.h | 3 +++
3 files changed, 34 insertions(+)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 297665f..70ae019 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -253,6 +253,35 @@ int usb_serial_generic_chars_in_buffer(struct tty_struct
*tty)
}
EXPORT_SYMBOL_GPL(usb_serial_generic_chars_in_buffer);
+void usb_serial_generic_wait_until_sent(struct tty_struct *tty, long timeout)
+{
+ struct usb_serial_port *port = tty->driver_data;
+ unsigned int bps;
+ unsigned long period;
+ unsigned long expire;
+
+ /*
+* Use a poll-period of roughly the time it takes to send one
+* character or at least one jiffy.
+*/
+ bps = tty_get_baud_rate(tty);
+ period = max_t(unsigned long, (10 * HZ / bps), 1);
+ period = min_t(unsigned long, period, timeout);
+
+ dev_dbg(>dev, "%s - timeout = %u ms, period = %u ms\n",
+ __func__, jiffies_to_msecs(timeout),
+ jiffies_to_msecs(period));
+ expire = jiffies + timeout;
+ while (!port->serial->type->tx_empty(port)) {
+ schedule_timeout_interruptible(period);
+ if (signal_pending(current))
+ break;
+ if (time_after(jiffies, expire))
+ break;
+ }
+}
+EXPORT_SYMBOL_GPL(usb_serial_generic_wait_until_sent);
+
static int usb_serial_generic_submit_read_urb(struct usb_serial_port *port,
int index, gfp_t mem_flags)
{
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 31d2768..60caf9c 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -1333,6 +1333,8 @@ static void usb_serial_operations_init(struct
usb_serial_driver *device)
set_to_generic_if_null(device, close);
set_to_generic_if_null(device, write_room);
set_to_generic_if_null(device, chars_in_buffer);
+ if (device->tx_empty)
+ set_to_generic_if_null(device, wait_until_sent);
set_to_generic_if_null(device, read_bulk_callback);
set_to_generic_if_null(device, write_bulk_callback);
set_to_generic_if_null(device, process_read_urb);
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index afbb7ee..302ddf5 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -269,6 +269,7 @@ struct usb_serial_driver {
void (*break_ctl)(struct tty_struct *tty, int break_state);
int (*chars_in_buffer)(struct tty_struct *tty);
void (*wait_until_sent)(struct tty_struct *tty, long timeout);
+ bool (*tx_empty)(struct usb_serial_port *port);
void (*throttle)(struct tty_struct *tty);
void (*unthrottle)(struct tty_struct *tty);
int (*tiocmget)(struct tty_struct *tty);
@@ -328,6 +329,8 @@ extern void usb_serial_generic_close(struct usb_serial_port
*port);
extern int usb_serial_generic_resume(struct usb_serial *serial);
extern int usb_serial_generic_write_room(struct tty_struct *tty);
extern int usb_serial_generic_chars_in_buffer(struct tty_struct *tty);
+extern void usb_serial_generic_wait_until_sent(struct tty_struct *tty,
+ long timeout);
extern void usb_serial_generic_read_bulk_callback(struct urb *urb);
extern void usb_serial_generic_write_bulk_callback(struct urb *urb);
extern void usb_serial_generic_throttle(struct tty_struct *tty);
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] USB: serial: add wait_until_sent-support
These patches add wait_until_sent-support to usb-serial, which removes the need to check hardware buffers in chars_in_buffer. This fixes a problem in ftdi_sio (since 3.7) where select or TIOCMOUTQ would take much longer than before due the hardware buffers being queried. Hardware buffers are also currently checked in chars_in_buffer in io_ti (since 3.8) and ti_usb_3410_5052 (in 3.10). Note that simply removing the hardware-buffer checks (e.g. for the stable trees) would break tty_wait_until_sent, which is used, for instance, by tcdrain, tcsendbreak, and close. Johan Johan Hovold (7): USB: serial: add wait_until_sent operation USB: serial: add generic wait_until_sent implementation USB: ftdi_sio: clean up get_modem_status USB: ftdi_sio: fix chars_in_buffer overhead USB: io_ti: fix chars_in_buffer overhead USB: ti_usb_3410_5052: fix chars_in_buffer overhead USB: serial: clean up chars_in_buffer drivers/usb/serial/ftdi_sio.c | 28 +--- drivers/usb/serial/generic.c | 29 + drivers/usb/serial/io_ti.c| 22 ++ drivers/usb/serial/ti_usb_3410_5052.c | 23 +++ drivers/usb/serial/usb-serial.c | 30 +- include/linux/usb/serial.h| 4 6 files changed, 92 insertions(+), 44 deletions(-) -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] USB: ti_usb_3410_5052: fix chars_in_buffer overhead
Use the new generic usb-serial wait_until_sent implementation to wait
for hardware buffers to drain.
This removes the need to check the hardware buffers in chars_in_buffer
and thus removes the overhead introduced by commit 2c992cd73 ("USB:
ti_usb_3410_5052: query hardware-buffer status in chars_in_buffer")
without breaking tty_wait_until_sent (used by, for example, tcdrain,
tcsendbreak and close).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index cac47ae..c92c5ed 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -101,6 +101,7 @@ static int ti_write(struct tty_struct *tty, struct
usb_serial_port *port,
const unsigned char *data, int count);
static int ti_write_room(struct tty_struct *tty);
static int ti_chars_in_buffer(struct tty_struct *tty);
+static bool ti_tx_empty(struct usb_serial_port *port);
static void ti_throttle(struct tty_struct *tty);
static void ti_unthrottle(struct tty_struct *tty);
static int ti_ioctl(struct tty_struct *tty,
@@ -222,6 +223,7 @@ static struct usb_serial_driver ti_1port_device = {
.write = ti_write,
.write_room = ti_write_room,
.chars_in_buffer= ti_chars_in_buffer,
+ .tx_empty = ti_tx_empty,
.throttle = ti_throttle,
.unthrottle = ti_unthrottle,
.ioctl = ti_ioctl,
@@ -253,6 +255,7 @@ static struct usb_serial_driver ti_2port_device = {
.write = ti_write,
.write_room = ti_write_room,
.chars_in_buffer= ti_chars_in_buffer,
+ .tx_empty = ti_tx_empty,
.throttle = ti_throttle,
.unthrottle = ti_unthrottle,
.ioctl = ti_ioctl,
@@ -684,8 +687,6 @@ static int ti_chars_in_buffer(struct tty_struct *tty)
struct ti_port *tport = usb_get_serial_port_data(port);
int chars = 0;
unsigned long flags;
- int ret;
- u8 lsr;
if (tport == NULL)
return 0;
@@ -694,16 +695,22 @@ static int ti_chars_in_buffer(struct tty_struct *tty)
chars = kfifo_len(>write_fifo);
spin_unlock_irqrestore(>tp_lock, flags);
- if (!chars) {
- ret = ti_get_lsr(tport, );
- if (!ret && !(lsr & TI_LSR_TX_EMPTY))
- chars = 1;
- }
-
dev_dbg(>dev, "%s - returns %d\n", __func__, chars);
return chars;
}
+static bool ti_tx_empty(struct usb_serial_port *port)
+{
+ struct ti_port *tport = usb_get_serial_port_data(port);
+ int ret;
+ u8 lsr;
+
+ ret = ti_get_lsr(tport, );
+ if (!ret && !(lsr & TI_LSR_TX_EMPTY))
+ return false;
+
+ return true;
+}
static void ti_throttle(struct tty_struct *tty)
{
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] USB: ftdi_sio: clean up get_modem_status
Use usb-serial port rather than tty as argument to get_modem_status.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 242b577..1159fd4 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -925,7 +925,7 @@ static int ftdi_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg);
static void ftdi_break_ctl(struct tty_struct *tty, int break_state);
static int ftdi_chars_in_buffer(struct tty_struct *tty);
-static int ftdi_get_modem_status(struct tty_struct *tty,
+static int ftdi_get_modem_status(struct usb_serial_port *port,
unsigned char status[2]);
static unsigned short int ftdi_232am_baud_base_to_divisor(int baud, int base);
@@ -2068,7 +2068,7 @@ static int ftdi_chars_in_buffer(struct tty_struct *tty)
goto out;
/* Check if hardware buffer is empty. */
- ret = ftdi_get_modem_status(tty, buf);
+ ret = ftdi_get_modem_status(port, buf);
if (ret == 2) {
if (!(buf[1] & FTDI_RS_TEMT))
chars = 1;
@@ -2268,10 +2268,9 @@ no_c_cflag_changes:
* Returns the number of status bytes retrieved (device dependant), or
* negative error code.
*/
-static int ftdi_get_modem_status(struct tty_struct *tty,
+static int ftdi_get_modem_status(struct usb_serial_port *port,
unsigned char status[2])
{
- struct usb_serial_port *port = tty->driver_data;
struct ftdi_private *priv = usb_get_serial_port_data(port);
unsigned char *buf;
int len;
@@ -2336,7 +2335,7 @@ static int ftdi_tiocmget(struct tty_struct *tty)
unsigned char buf[2];
int ret;
- ret = ftdi_get_modem_status(tty, buf);
+ ret = ftdi_get_modem_status(port, buf);
if (ret < 0)
return ret;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: frag, fix race conditions in LRU list maintenance
Konstantin Khlebnikov wrote:
> This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add()
> which was introduced in commit 3ef0eb0db4bf92c6d2510fe5c4dc51852746f206
> ("net: frag, move LRU list maintenance outside of rwlock")
>
> One cpu already added new fragment queue into hash but not into LRU.
> Other cpu found it in hash and tries to move it to the end of LRU.
> This leads to NULL pointer dereference inside of list_move_tail().
>
> Another possible race condition is between inet_frag_lru_move() and
> inet_frag_lru_del(): move can happens after deletion.
True, thanks for fixing this problem.
> This patch initializes LRU list head before adding fragment into hash and
> inet_frag_lru_move() doesn't touches it if it's empty.
Acked-by: Florian Westphal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012)
On Sat, May 04, 2013 at 07:39:57AM -0400, Peter Hurley wrote: > On 05/04/2013 07:15 AM, Johan Hovold wrote: > > On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: > >> 04.05.2013 00:34, Greg KH пишет: > >>> On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: > 03.05.2013 21:16, Greg KH пишет: [...] > > But you do have a point, and I have been meaning to look into whether > > the added overhead of checking the hardware buffers could be mitigated > > by adding wait_until_sent support to usb-serial. This way the we would > > only query the hardware buffers on tty_wait_until_sent (e.g. at close) > > and select and TIOCMOUTQ would not suffer. This is also the way things > > are handled in serial_core. > > Agreed. This is the correct solution. > > > I'll prepare a series which adds wait_until_sent to usb-serial, but I > > doubt it would be stable material (even if it could get into 3.10). > > > > What do you think Greg, is this overhead to chars_in_buffer reason > > enough to disable it in the stable trees or should we simply fix it in > > 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port > > fifo is empty, which makes chars_in_buffer about 100 times slower on my > > test system.) > > A better solution for stable would be to set port->drain_delay. It > won't help tcdrain() but at least the port won't shutdown on live > outbound data. Removing the hardware-buffer checks from chars_in_buffer would mean breaking tty_wait_until_sent and thus also, for example, tcdrain, tcsendbreak, and close. Using drain_delay would partially work-around the problem with close, but at the cost of adding delays for all users while still not being able to guarantee that the buffers have been drained. Either way, this seems to amount to a regression. On the other hand, the added overhead to chars_in_buffer seems to break at least one application as well. I've implemented wait_until_sent-support for usb-serial, which fixes the problem without any such trade-offs and which I believe needs to go in to v3.10. For the stable trees I think keeping the current, less efficient (but more complete) chars_in_buffer implementations is preferred over introducing further regressions. Back-porting wait_until_sent-support could perhaps also be considered. I'm responding to this mail with a wait_until_sent-support series. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
