Re: [PATCH v9 1/2] x86/kexec: VMCLEAR VMCSs loaded on all cpus if necessary
于 2012年12月05日 04:14, Eric W. Biederman 写道:
> Zhang Yanfei writes:
>
>> This patch provides a way to VMCLEAR VMCSs related to guests
>> on all cpus before executing the VMXOFF when doing kdump. This
>> is used to ensure the VMCSs in the vmcore updated and
>> non-corrupted.
>
> Apologies for the delay I have been travelling, and I wanted
> to at least read through the code.
>
> Overall I think this is good but I have one nit, and I see one real
> problem with this code.
>
>> +/*
>> + * This is used to VMCLEAR all VMCSs loaded on the
>> + * processor. And when loading kvm_intel module, the
>> + * callback function pointer will be assigned.
>> + */
>> +void (*crash_vmclear_loaded_vmcss)(void) = NULL;
>> +EXPORT_SYMBOL_GPL(crash_vmclear_loaded_vmcss);
>> +
>> +static inline void cpu_emergency_vmclear_loaded_vmcss(void)
>> +{
>> +if (crash_vmclear_loaded_vmcss)
>> +crash_vmclear_loaded_vmcss();
>> +}
>
> The nit is the use of emergency instead of crash in the name.
ok, emergency -> crash
>
> The problem is that this is potentially a NULL pointer dereference if
> kvm-intel is removed. The easist fix would be in your second patch to
> just make it impossible to unload the kvm-intel module. Otherwise
> there the deference of crash_vmclear_loaded_vmcss needs to be rcu
> protected, with a syncrhonize_rcu after the pointer is set to NULL in
> the unload path.
Ah, thanks for this comment.
I think I will use the rcu machanism to solve the problem.
>
> Otherwise I have no objections to this code.
Thanks for your review. I will update the patch and resend it.
Thanks
Zhang Yanfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ccache: FATAL: Could not create /scratch/kisskb/ccache
On Wed, 2012-11-14 at 09:03 +0100, Geert Uytterhoeven wrote: > Hi Stephen, > > On Sat, Nov 3, 2012 at 12:19 AM, Stephen Rothwell > wrote: > > On Fri, 2 Nov 2012 19:44:48 +0100 Geert Uytterhoeven > > wrote: > >> http://kisskb.ellerman.id.au/kisskb/buildresult/7458505/ > >> > >> ccache: FATAL: Could not create > >> /scratch/kisskb/ccache/d/7/f9e308f728ef43aaa482aefb9a00a2-852386.o.tmp.stdout.Sprygo.5748 > >> (permission denied?) > >> make[4]: *** [drivers/media/rc/ene_ir.o] Error 1 > >> > >> http://kisskb.ellerman.id.au/kisskb/buildresult/7461979/ > >> > >> ccache: FATAL: Could not create > >> /scratch/kisskb/ccache/5/e/47d893acad42c07542edec1f826579-1842636.o.tmp.stdout.Sprygo.557 > >> (permission denied?) > >> make[3]: *** [net/core/sock.o] Error 1 > > > > Well, that is weird. I can't find any reason for that to happen :-( > > > > I'll have a chat with the kisskb guy when I next see him. Thanks for the > > heads up. > > As code is migrating to Linus' tree, it's spreading from the linux-next to the > linus branch, e.g.: > http://kisskb.ellerman.id.au/kisskb/buildresult/7536268/ > ccache: FATAL: Could not create > /scratch/kisskb/ccache/1/3/a44cddb2457ad89fe496b0c82b0a09-1211932.o.tmp.stdout.Sprygo.2788 > (permission denied?) > make[3]: *** [drivers/block/aoe/aoecmd.o] Error 1 Hi Geert, This has started happening because of a change in ccache (v3.1.7). It has always checked that the stdout file exists (via stat), but previously if it was missing it would fall back to a full compile, whereas now it is a fatal error. However looking at the ccache code it makes no sense for the file not to exist, because we just created it. So it's a bit of a mystery. At the moment I'm running with a slightly hacked ccache (too much and the bug vanishes), and auditing enabled, to try and work out if someone is actually unlinking the file or what. Hopefully we can sort it out in the next few days. 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/
Re: [PATCH] SUNRPC: connect to UNIX sockets synchronously
04.12.2012 18:20, Eric Paris пишет: On Tue, Dec 4, 2012 at 6:10 AM, Stanislav Kinsbursky wrote: But there should be noted, that such implementation introduces limitation (Trond's quote): "That approach can fall afoul of the selinux restrictions on the process context. Processes that are allowed to write data, may not be allowed to create sockets or call connect(). That is the main reason for doing it in the rpciod context, which is a clean kernel process context." So you tested this and Trond was wrong? This work just fine even on an SELinux box? Or it does break tons and tons of people's computers? -Eric You can read discussion here: https://patchwork.kernel.org/patch/1565111/ We use AF_LOCAL transports only for portmapper calls. So, we decided (or at least I understood that so) to make such connections from process context - i.e. synchronously. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] MODSIGN: Avoid using .incbin in C source
At Tue, 04 Dec 2012 18:17:28 +, David Howells wrote: > > Michal Marek wrote: > > > Using the asm .incbin statement in C sources breaks any gcc wrapper which > > assumes that preprocessed C source is self-contained. Use a separate .S > > file to include the siging key and certificate. > > I was trying to avoid that as .S files generally don't crop up in generic > code and the format of the assembly varies with the arch. However, you don't > seem to have anything that should cause a problem Well, we hit actually the issue... Please check the revised patch again. thanks, Takashi > - so: > > Acked-by: David Howells > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bdi: add a user-tunable cpu_list for the bdi flusher threads
On 2012-12-04 23:26, Jeff Moyer wrote: > Jens Axboe writes: > > @@ -437,6 +488,14 @@ static int bdi_forker_thread(void *ptr) > spin_lock_bh(>wb_lock); > bdi->wb.task = task; > spin_unlock_bh(>wb_lock); > + mutex_lock(>flusher_cpumask_mutex); > + ret = set_cpus_allowed_ptr(task, > + bdi->flusher_cpumask); > + mutex_unlock(>flusher_cpumask_mutex); It'd be very useful if we had a kthread_create_cpu_on_cpumask() instead of a _node() variant, since the latter could easily be implemented on top of the former. But not really a show stopper for the patch... >>> >>> Hmm, if it isn't too scary, I might give this a try. >> >> Should not be, pretty much just removing the node part of the create >> struct passed in and making it a cpumask. And for the on_node() case, >> cpumask_of_ndoe() will do the trick. > > I think it's a bit more involved than that. If you look at > kthread_create_on_node, the node portion only applies to where the > memory comes from, it says nothing of scheduling. To whit: > > /* > > * root may have changed our (kthreadd's) priority or CPU > mask. > * The kernel thread should not inherit these properties. > > */ > sched_setscheduler_nocheck(create.result, SCHED_NORMAL, > ); > set_cpus_allowed_ptr(create.result, cpu_all_mask); > > So, if I were to make the change you suggested, I would be modifying the > existing behaviour. The way things stand, I think > kthread_create_on_node violates the principal of least surprise. ;-) I > would prefer a variant that affected scheduling behaviour as well as > memory placement. Tejun, Peter, Ingo, what are your opinions? Huh you are right, I completely missed that set_cpus_allowed_ptr() uses cpu_all_mask and not mask_of_node(node). Doesn't make a lot of sense to me... And yes, in any case, it definitely is a bad API, not very logical. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] MODSIGN: Avoid using .incbin in C source
At Wed, 05 Dec 2012 10:28:48 +1030,
Rusty Russell wrote:
>
> David Howells writes:
>
> > Michal Marek wrote:
> >
> >> Using the asm .incbin statement in C sources breaks any gcc wrapper which
> >> assumes that preprocessed C source is self-contained. Use a separate .S
> >> file to include the siging key and certificate.
> >
> > I was trying to avoid that as .S files generally don't crop up in generic
> > code and the format of the assembly varies with the arch. However, you
> > don't
> > seem to have anything that should cause a problem - so:
> >
> > Acked-by: David Howells
>
> GLOBAL() is defined in x86 only, AFAICT.
>
> Plus, we now have a patch from James (CC:d) to prepend
> CONFIG_SYMBOL_PREFIX to these as requird.
Yes, I noticed both things yesterday.
>
> I think this will have to be done more carefully...
How about the revised patch below?
thanks,
Takashi
---
From: Takashi Iwai
Subject: [PATCH v2] MODSIGN: Avoid using .incbin in C source
Using the asm .incbin statement in C sources breaks any gcc wrapper which
assumes that preprocessed C source is self-contained. Use a separate .S
file to include the siging key and certificate.
Tested-by: Michal Marek
Signed-off-by: Takashi Iwai
---
kernel/Makefile | 4 ++--
kernel/modsign_certificate.S | 18 ++
kernel/modsign_pubkey.c | 6 --
3 files changed, 20 insertions(+), 8 deletions(-)
create mode 100644 kernel/modsign_certificate.S
diff --git a/kernel/Makefile b/kernel/Makefile
index 86e3285..0bd9d43 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o
obj-$(CONFIG_PROVE_LOCKING) += spinlock.o
obj-$(CONFIG_UID16) += uid16.o
obj-$(CONFIG_MODULES) += module.o
-obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o
+obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o
modsign_certificate.o
obj-$(CONFIG_KALLSYMS) += kallsyms.o
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_KEXEC) += kexec.o
@@ -139,7 +139,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
extra_certificates:
touch $@
-kernel/modsign_pubkey.o: signing_key.x509 extra_certificates
+kernel/modsign_certificate.o: signing_key.x509 extra_certificates
###
#
diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
new file mode 100644
index 000..695d4e3
--- /dev/null
+++ b/kernel/modsign_certificate.S
@@ -0,0 +1,18 @@
+#ifndef SYMBOL_PREFIX
+#define ASM_SYMBOL(sym) sym
+#else
+#define PASTE2(x,y) x##y
+#define PASTE(x,y) PASTE2(x,y)
+#define ASM_SYMBOL(sym) PASTE(SYMBOL_PREFIX, sym)
+#endif
+
+#define GLOBAL(name) \
+ .globl ASM_SYMBOL(name);\
+ ASM_SYMBOL(name):
+
+ .section ".init.data","aw"
+
+GLOBAL(modsign_certificate_list)
+ .incbin "signing_key.x509"
+ .incbin "extra_certificates"
+GLOBAL(modsign_certificate_list_end)
diff --git a/kernel/modsign_pubkey.c b/kernel/modsign_pubkey.c
index 767e559..045504f 100644
--- a/kernel/modsign_pubkey.c
+++ b/kernel/modsign_pubkey.c
@@ -20,12 +20,6 @@ struct key *modsign_keyring;
extern __initdata const u8 modsign_certificate_list[];
extern __initdata const u8 modsign_certificate_list_end[];
-asm(".section .init.data,\"aw\"\n"
-SYMBOL_PREFIX "modsign_certificate_list:\n"
-".incbin \"signing_key.x509\"\n"
-".incbin \"extra_certificates\"\n"
-SYMBOL_PREFIX "modsign_certificate_list_end:"
-);
/*
* We need to make sure ccache doesn't cache the .o file as it doesn't notice
--
1.8.0.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] memory: of_memory.c: remove unnecessary initialization
Infact, your patch does remove an orl operation, but add a new "move" operation.
You can test such two functions:
int func1(int rm1, int rm2){
int i = 0;
i |= rm1;
i |= rm2;
}
and
int func(int rm1, int rm2){
int i;
i = rm1;
i |= rm2;
}
Use gcc to compile them to assemble with "-S" operation, and you will find it.
On Tue, Dec 4, 2012 at 10:46 PM, Santosh Shilimkar
wrote:
> On Tuesday 04 December 2012 07:25 PM, Grant Likely wrote:
>>
>> On Tue, Dec 4, 2012 at 11:44 AM, Santosh Shilimkar
>> wrote:
>>>
>>> On Tuesday 04 December 2012 04:56 PM, Cong Ding wrote:
the initialization of variable ret is unnecessary, we can remove it
while
save
one time "or" operation.
Signed-off-by: Cong Ding
---
>>>
>>>
>>> Looks ok.
>>> Acked-by: Santosh Shilimkar
>>>
>>
>> Thanks for the patch, but I don't think it matters enough to apply it.
>> The existing code isn't wrong.
>>
> The patch was removing an additional operation and hence i didn't
> contest it. I agree with your comment though.
>
> Regards
> Santosh
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tmpfs: fix shared mempolicy leak
From: Mel Gorman
Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount
imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the
refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went
on expecting alloc_page_vma() to drop the refcount it had acquired.
This deserves a rework: but for now fix the leak in shmem_alloc_page().
Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use
the same refcounting there as in shmem_alloc_page(), delete its onstack
mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() -
those were invented to let swapin_readahead() make an unknown number of
calls to alloc_pages_vma() with one mempolicy; but since 00442ad04a5e,
alloc_pages_vma() has kept refcount in balance, so now no problem.
Reported-by: Tommi Rantala
Awaiting-signed-off-by: Mel Gorman
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org
---
include/linux/mempolicy.h | 16
mm/mempolicy.c| 22 --
mm/shmem.c| 26 --
3 files changed, 16 insertions(+), 48 deletions(-)
--- 3.7-rc8/include/linux/mempolicy.h 2012-10-14 16:16:57.637308925 -0700
+++ linux/include/linux/mempolicy.h 2012-12-04 22:38:21.812178829 -0800
@@ -82,16 +82,6 @@ static inline void mpol_cond_put(struct
__mpol_put(pol);
}
-extern struct mempolicy *__mpol_cond_copy(struct mempolicy *tompol,
- struct mempolicy *frompol);
-static inline struct mempolicy *mpol_cond_copy(struct mempolicy *tompol,
- struct mempolicy *frompol)
-{
- if (!frompol)
- return frompol;
- return __mpol_cond_copy(tompol, frompol);
-}
-
extern struct mempolicy *__mpol_dup(struct mempolicy *pol);
static inline struct mempolicy *mpol_dup(struct mempolicy *pol)
{
@@ -215,12 +205,6 @@ static inline void mpol_cond_put(struct
{
}
-static inline struct mempolicy *mpol_cond_copy(struct mempolicy *to,
- struct mempolicy *from)
-{
- return from;
-}
-
static inline void mpol_get(struct mempolicy *pol)
{
}
--- 3078/mm/mempolicy.c 2012-10-20 20:56:24.675917367 -0700
+++ 3078X/mm/mempolicy.c2012-12-04 22:33:31.516171929 -0800
@@ -2037,28 +2037,6 @@ struct mempolicy *__mpol_dup(struct memp
return new;
}
-/*
- * If *frompol needs [has] an extra ref, copy *frompol to *tompol ,
- * eliminate the * MPOL_F_* flags that require conditional ref and
- * [NOTE!!!] drop the extra ref. Not safe to reference *frompol directly
- * after return. Use the returned value.
- *
- * Allows use of a mempolicy for, e.g., multiple allocations with a single
- * policy lookup, even if the policy needs/has extra ref on lookup.
- * shmem_readahead needs this.
- */
-struct mempolicy *__mpol_cond_copy(struct mempolicy *tompol,
- struct mempolicy *frompol)
-{
- if (!mpol_needs_cond_ref(frompol))
- return frompol;
-
- *tompol = *frompol;
- tompol->flags &= ~MPOL_F_SHARED;/* copy doesn't need unref */
- __mpol_put(frompol);
- return tompol;
-}
-
/* Slow path of a mempolicy comparison */
bool __mpol_equal(struct mempolicy *a, struct mempolicy *b)
{
--- 3078/mm/shmem.c 2012-11-16 19:26:56.388459961 -0800
+++ 3078X/mm/shmem.c2012-12-04 22:32:35.328170594 -0800
@@ -910,25 +910,29 @@ static struct mempolicy *shmem_get_sbmpo
static struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
struct shmem_inode_info *info, pgoff_t index)
{
- struct mempolicy mpol, *spol;
struct vm_area_struct pvma;
-
- spol = mpol_cond_copy(,
- mpol_shared_policy_lookup(>policy, index));
+ struct page *page;
/* Create a pseudo vma that just contains the policy */
pvma.vm_start = 0;
/* Bias interleave by inode number to distribute better across nodes */
pvma.vm_pgoff = index + info->vfs_inode.i_ino;
pvma.vm_ops = NULL;
- pvma.vm_policy = spol;
- return swapin_readahead(swap, gfp, , 0);
+ pvma.vm_policy = mpol_shared_policy_lookup(>policy, index);
+
+ page = swapin_readahead(swap, gfp, , 0);
+
+ /* Drop reference taken by mpol_shared_policy_lookup() */
+ mpol_cond_put(pvma.vm_policy);
+
+ return page;
}
static struct page *shmem_alloc_page(gfp_t gfp,
struct shmem_inode_info *info, pgoff_t index)
{
struct vm_area_struct pvma;
+ struct page *page;
/* Create a pseudo vma that just contains the policy */
pvma.vm_start = 0;
@@ -937,10 +941,12 @@ static struct page *shmem_alloc_page(gfp
pvma.vm_ops = NULL;
pvma.vm_policy = mpol_shared_policy_lookup(>policy, index);
- /*
-* alloc_page_vma() will drop the shared policy reference
-
Re: [PATCH] staging: rtl8712: avoid a useless call to memset().
On Wed, Dec 05, 2012 at 02:22:02AM +0100, Cyril Roelandt wrote: > In r8711_wx_get_wap(), make sure we do not call memcpy() on a memory area that > has just been zeroed by a call to memset(). > I look at it like the original code is fine. Your version is also fine but is it worth the churn? Also the curly braces are not needed. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Look Ma, da kernel is b0rken
Hi, drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi': drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] That's already the second less enticing -Wlogical-op issue which was discovered by accident during less than two days of my happy(?) activity of kernel suspend breakage bisection. Why oh why, as a rather *very* critical piece of software, can't the kernel use sufficiently aggressive warning levels *by default*?? IMHO it's simply NOT ACCEPTABLE to have such sloppiness creep into the daily bandwagon of kernel development life (or should I say: being mandated to creep in?). Result: whichever default warning level you set *will* end up as The New Normal, and all those warnings which then remain able to rear their ugly heads according to the chosen default level will be fixed by the community eventually, and *most others won't* (or at least not in time). The amount of warnings spewn by make W=3 (or even W=2) is simply shocking IMNSHO. And there can always be an argument that most of such warnings are fixable. If not directly (e.g. because analysis of that warning type is partially unreliable), then by actively reworking code into something slightly different. So, unless there are very hard and *justified* reasons for keeping builds at such lame-*ss defaults (such as automated compliance test runs which may not fail - but in such cases one could argue that *those* uses should then be required to manually lessen *their* warning level settings), I would strongly vote for having a hard discussion about the status quo. As a somewhat aggravating comment, please note that this warning actually seems to date back to 1da177e (initial repository build) according to blame on that file. Andreas Mohr P.S.: sorry for the subject line ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] sched: fork/exec/wake clean up
On Mon, Dec 3, 2012 at 9:54 PM, Alex Shi wrote: > This patchset try to clean up select_task_rq_fair which used for > fork/exec/wake scheduling. > > With this patchset, our system NHM EX and SNB EP 4 socket machine > has 10% hackbench performance increase. Any comments for this patchset? > > Regards > Alex > > [PATCH 01/4] sched: select_task_rq_fair clean up > [PATCH 02/4] sched: fix find_idlest_group mess logical > [PATCH 03/4] sched: don't need go to smaller sched domain > [PATCH 04/4] sched: remove domain iterations in fork/exec/wake > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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: [V2 PATCH 1/2] rtc: sa1100: move clock enable/disable to probe/remove
On Wed, Dec 5, 2012 at 2:49 PM, Chao Xie wrote:
> The original sa1100_rtc_open/sa1100_rtc_release will be called
> when the /dev/rtc0 is opened or closed.
> In fact, these two functions will enable/disable the clock.
> Disabling clock will make rtc not work.
> So only enable/disable clock when probe/remove the device.
>
> Signed-off-by: Chao Xie
> ---
> drivers/rtc/rtc-sa1100.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
> index 50a5c4a..34f66b8 100644
> --- a/drivers/rtc/rtc-sa1100.c
> +++ b/drivers/rtc/rtc-sa1100.c
> @@ -108,9 +108,6 @@ static int sa1100_rtc_open(struct device *dev)
> struct rtc_device *rtc = info->rtc;
> int ret;
>
> - ret = clk_prepare_enable(info->clk);
> - if (ret)
> - goto fail_clk;
> ret = request_irq(info->irq_1hz, sa1100_rtc_interrupt, 0, "rtc 1Hz",
> dev);
> if (ret) {
> dev_err(dev, "IRQ %d already in use.\n", info->irq_1hz);
> @@ -130,7 +127,6 @@ static int sa1100_rtc_open(struct device *dev)
> free_irq(info->irq_1hz, dev);
> fail_ui:
> clk_disable_unprepare(info->clk);
> - fail_clk:
> return ret;
> }
>
> @@ -144,7 +140,6 @@ static void sa1100_rtc_release(struct device *dev)
>
> free_irq(info->irq_alarm, dev);
> free_irq(info->irq_1hz, dev);
> - clk_disable_unprepare(info->clk);
> }
>
> static int sa1100_rtc_alarm_irq_enable(struct device *dev, unsigned int
> enabled)
> @@ -253,6 +248,9 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
> spin_lock_init(>lock);
> platform_set_drvdata(pdev, info);
>
> + ret = clk_prepare_enable(info->clk);
> + if (ret)
> + goto err_enable_clk;
> /*
> * According to the manual we should be able to let RTTR be zero
> * and then a default diviser for a 32.768KHz clock is used.
> @@ -305,6 +303,8 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
>
> return 0;
> err_dev:
> + clk_disable_unprepare(info->clk);
> +err_enable_clk:
> platform_set_drvdata(pdev, NULL);
> clk_put(info->clk);
> err_clk:
> @@ -318,6 +318,7 @@ static int sa1100_rtc_remove(struct platform_device *pdev)
>
> if (info) {
> rtc_device_unregister(info->rtc);
> + clk_disable_unprepare(info->clk);
> clk_put(info->clk);
> platform_set_drvdata(pdev, NULL);
> kfree(info);
> --
> 1.7.4.1
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V2 PATCH 2/2] rtc: pxa: add pxa95x rtc support
On Wed, Dec 5, 2012 at 2:49 PM, Chao Xie wrote:
> the pxa95x rtc need access PBSR register before write to
> RTTR, RCNR, RDCR, and RYCR registers.
>
> Signed-off-by: Chao Xie
> ---
> drivers/rtc/rtc-pxa.c | 100 +---
> 1 files changed, 85 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
> index f771b2e..aee23cb 100644
> --- a/drivers/rtc/rtc-pxa.c
> +++ b/drivers/rtc/rtc-pxa.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -77,14 +78,28 @@
> #define RTCPICR0x34
> #define PIAR 0x38
>
> +#define PSBR_RTC 0x00
> +
> #define rtc_readl(pxa_rtc, reg)\
> __raw_readl((pxa_rtc)->base + (reg))
> #define rtc_writel(pxa_rtc, reg, value)\
> __raw_writel((value), (pxa_rtc)->base + (reg))
> +#define rtc_readl_psbr(pxa_rtc, reg) \
> + __raw_readl((pxa_rtc)->base_psbr + (reg))
> +#define rtc_writel_psbr(pxa_rtc, reg, value) \
> + __raw_writel((value), (pxa_rtc)->base_psbr + (reg))
> +
> +enum {
> + RTC_PXA27X,
> + RTC_PXA95X,
> +};
>
> struct pxa_rtc {
> struct resource *ress;
> + struct resource *ress_psbr;
> + unsigned intid;
> void __iomem*base;
> + void __iomem*base_psbr;
> int irq_1Hz;
> int irq_Alrm;
> struct rtc_device *rtc;
> @@ -242,9 +257,26 @@ static int pxa_rtc_set_time(struct device *dev, struct
> rtc_time *tm)
> {
> struct pxa_rtc *pxa_rtc = dev_get_drvdata(dev);
>
> + /*
> +* sequence to wirte pxa rtc register RCNR RDCR RYCR is
> +* 1. set PSBR[RWE] bit, take 2x32-khz to complete
> +* 2. write to RTC register,take 2x32-khz to complete
> +* 3. clear PSBR[RWE] bit,take 2x32-khz to complete
> +*/
> + if (pxa_rtc->id == RTC_PXA95X) {
> + rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x01);
> + udelay(100);
> + }
How about define PSBP operation as a new clock, rtc interface clock.
Then you could put
the enable/disable into clock framework. And you only need to check
whether the interface
clock is NULL or not at here. If it's available, you can call
clk_prepare_enable().
> +
> rtc_writel(pxa_rtc, RYCR, ryxr_calc(tm));
> rtc_writel(pxa_rtc, RDCR, rdxr_calc(tm));
>
> + if (pxa_rtc->id == RTC_PXA95X) {
> + udelay(100);
> + rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x00);
> + udelay(100);
> + }
> +
> return 0;
> }
>
> @@ -310,6 +342,20 @@ static const struct rtc_class_ops pxa_rtc_ops = {
> .proc = pxa_rtc_proc,
> };
>
> +static struct of_device_id pxa_rtc_dt_ids[] = {
> + { .compatible = "marvell,pxa-rtc", .data = (void *)RTC_PXA27X },
> + { .compatible = "marvell,pxa95x-rtc", .data = (void *)RTC_PXA95X },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, pxa_rtc_dt_ids);
> +
> +static const struct platform_device_id pxa_rtc_id_table[] = {
> + { "pxa-rtc", RTC_PXA27X },
> + { "pxa95x-rtc", RTC_PXA95X },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, pxa_rtc_id_table);
> +
> static int __init pxa_rtc_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -324,13 +370,34 @@ static int __init pxa_rtc_probe(struct platform_device
> *pdev)
> spin_lock_init(_rtc->lock);
> platform_set_drvdata(pdev, pxa_rtc);
>
> + if (pdev->dev.of_node) {
> + const struct of_device_id *of_id =
> + of_match_device(pxa_rtc_dt_ids, >dev);
> +
> + pxa_rtc->id = (unsigned int)(of_id->data);
> + } else {
> + const struct platform_device_id *id =
> + platform_get_device_id(pdev);
> +
> + pxa_rtc->id = id->driver_data;
> + }
> +
> ret = -ENXIO;
> pxa_rtc->ress = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!pxa_rtc->ress) {
> - dev_err(dev, "No I/O memory resource defined\n");
> + dev_err(dev, "No I/O memory resource(id=0) defined\n");
> goto err_ress;
> }
>
> + if (pxa_rtc->id == RTC_PXA95X) {
> + pxa_rtc->ress_psbr =
> + platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!pxa_rtc->ress_psbr) {
> + dev_err(dev, "No I/O memory resource(id=1)
> defined\n");
> + goto err_ress;
> + }
> + }
> +
> pxa_rtc->irq_1Hz = platform_get_irq(pdev, 0);
> if (pxa_rtc->irq_1Hz < 0) {
> dev_err(dev, "No 1Hz IRQ resource defined\n");
> @@ -347,7 +414,17 @@ static int __init pxa_rtc_probe(struct platform_device
> *pdev)
> resource_size(pxa_rtc->ress));
>
Re: [RFC v2] Support volatile range for anon vma
Hi John, On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote: > On 12/03/2012 11:22 PM, Minchan Kim wrote: > >On Mon, Dec 03, 2012 at 04:57:20PM -0800, John Stultz wrote: > >>On 12/03/2012 04:00 PM, Minchan Kim wrote: > >>>On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote: > On 11/21/2012 04:36 PM, John Stultz wrote: > >2) Being able to use this with tmpfs files. I'm currently trying > >to better understand the rmap code, looking to see if there's a > >way to have try_to_unmap_file() work similarly to > >try_to_unmap_anon(), to allow allow users to madvise() on mmapped > >tmpfs files. This would provide a very similar interface as to > >what I've been proposing with fadvise/fallocate, but just using > >process virtual addresses instead of (fd, offset) pairs. The > >benefit with (fd,offset) pairs for Android is that its easier to > >manage shared volatile ranges between two processes that are > >sharing data via an mmapped tmpfs file (although this actual use > >case may be fairly rare). I believe we should still be able to > >rework the ashmem internals to use madvise (which would provide > >legacy support for existing android apps), so then its just a > >question of if we could then eventually convince Android apps to > >use the madvise interface directly, rather then the ashmem unpin > >ioctl. > Hey Minchan, > I've been playing around with your patch trying to better > understand your approach and to extend it to support tmpfs files. In > doing so I've found a few bugs, and have some rough fixes I wanted > to share. There's still a few edge cases I need to deal with (the > vma-purged flag isn't being properly handled through vma merge/split > operations), but its starting to come along. > >>>Hmm, my patch doesn't allow to merge volatile with another one by > >>>inserting VM_VOLATILE into VM_SPECIAL so I guess merge isn't problem. > >>>In case of split, __split_vma copy old vma to new vma like this > >>> > >>> *new = *vma; > >>> > >>>So the problem shouldn't happen, I guess. > >>>Did you see the real problem about that? > >>Yes, depending on the pattern that MADV_VOLATILE and MADV_NOVOLATILE > >>is applied, we can get a result where data is purged, but we aren't > >>notified of it. Also, since madvise returns early if it encounters > >>an error, in the case where you have checkerboard volatile regions > >>(say every other page is volatile), which you mark non-volatile with > >>one large MADV_NOVOLATILE call, the first volatile vma will be > >>marked non-volatile, but since it returns purged, the madvise loop > >>will stop and the following volatile regions will be left volatile. > >> > >>The patches in the git tree below which handle the perged state > >>better seem to work for my tests, as far as resolving any > >>overlapping calls. Of course there may yet still be problems I've > >>not found. > >> > Anyway, take a look at the tree here and let me know what you think. > http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/minchan-anonvol > >>Eager to hear what you think! > >Below two patches look good to me. > > > >[rmap: Simplify volatility checking by moving it out of try_to_unmap_one] > >[rmap: ClearPageDirty() when returning SWAP_DISCARD] > > > >[madvise: Fix NOVOLATILE bug] > >I can't understand description of the patch. > >Could you elaborate it with example? > The case I ran into here is if you have a range where you mark every > other page as volatile. Then mark all the pages in that range as > non-volatile in one madvise call. > > sys_madvise() will then find the first vma in the range, and call > madvise_vma(), which marks the first vma non-volatile and return the > purged state. If the page has been purged, sys_madvise code will > note that as an error, and break out of the vma iteration loop, > leaving the following vmas in the range volatile. > > >[madvise: Fixup vma->purged handling] > >I included VM_VOLATILE into VM_SPECIAL intentionally. > >If comment of VM_SPECIAL is right, merge with volatile vmas shouldn't happen. > >So I guess you see other problem. When I see my source code today, locking > >scheme/purge handling is totally broken. I will look at it. Maybe you are > >seeing > >bug related that. Part of patch is needed. It could be separate patch. > >I will merge it. > I don't think the problem is when vmas being marked VM_VOLATILE are > being merged, its that when we mark the vma as *non-volatile*, and > remove the VM_VOLATILE flag we merge the non-volatile vmas with > neighboring vmas. So preserving the purged flag during that merge is > important. Again, the example I used to trigger this was an > alternating pattern of volatile and non volatile vmas, then marking > the entire range non-volatile (though sometimes in two overlapping > passes). If I understand correctly, you mean following as. chunk1 =
[PATCH 1/3] perf hists: Exchange order of comparing items when collapsing hists
From: Namhyung Kim
When comparing entries for collapsing put the given entry first, and
then the iterated entry. This is not the case of hist_entry__cmp()
when called if given sort keys don't require collapsing. So change
the order for the sake of consistency. It will be required for
matching and/or linking multiple hist entries.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 82df1b26f0d4..d4471c21ed17 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -285,7 +285,7 @@ static struct hist_entry *add_hist_entry(struct hists
*hists,
parent = *p;
he = rb_entry(parent, struct hist_entry, rb_node_in);
- cmp = hist_entry__cmp(entry, he);
+ cmp = hist_entry__cmp(he, entry);
if (!cmp) {
he_stat__add_period(>stat, period);
@@ -729,7 +729,7 @@ static struct hist_entry *hists__add_dummy_entry(struct
hists *hists,
parent = *p;
he = rb_entry(parent, struct hist_entry, rb_node);
- cmp = hist_entry__cmp(pair, he);
+ cmp = hist_entry__cmp(he, pair);
if (!cmp)
goto out;
@@ -759,7 +759,7 @@ static struct hist_entry *hists__find_entry(struct hists
*hists,
while (n) {
struct hist_entry *iter = rb_entry(n, struct hist_entry,
rb_node);
- int64_t cmp = hist_entry__cmp(he, iter);
+ int64_t cmp = hist_entry__cmp(iter, he);
if (cmp < 0)
n = n->rb_left;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] perf diff: Use internal rb tree for compute resort
From: Namhyung Kim
There's no reason to run hists_compute_resort() using output tree.
Convert it to use internal tree so that it can remove unnecessary
_output_resort. Also move position computation below the resort since
it changes the output ordering.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index b52f5d8c4a6b..4e18cea7c845 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -435,19 +435,25 @@ static void insert_hist_entry_by_compute(struct rb_root
*root,
static void hists__compute_resort(struct hists *hists)
{
- struct rb_root tmp = RB_ROOT;
- struct rb_node *next = rb_first(>entries);
+ struct rb_root *root;
+ struct rb_node *next;
+
+ if (sort__need_collapse)
+ root = >entries_collapsed;
+ else
+ root = hists->entries_in;
+
+ hists->entries = RB_ROOT;
+ next = rb_first(root);
while (next != NULL) {
- struct hist_entry *he = rb_entry(next, struct hist_entry,
rb_node);
+ struct hist_entry *he;
- next = rb_next(>rb_node);
+ he = rb_entry(next, struct hist_entry, rb_node_in);
+ next = rb_next(>rb_node_in);
- rb_erase(>rb_node, >entries);
- insert_hist_entry_by_compute(, he, compute);
+ insert_hist_entry_by_compute(>entries, he, compute);
}
-
- hists->entries = tmp;
}
static void hists__process(struct hists *old, struct hists *new)
@@ -459,16 +465,16 @@ static void hists__process(struct hists *old, struct
hists *new)
else
hists__link(new, old);
- hists__output_resort(new);
-
- if (show_displacement)
- hists__compute_position(new);
-
if (sort_compute) {
hists__precompute(new);
hists__compute_resort(new);
+ } else {
+ hists__output_resort(new);
}
+ if (show_displacement)
+ hists__compute_position(new);
+
hists__fprintf(new, true, 0, 0, stdout);
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] perf hists: Changes on hists__{match,link}
Hi Arnaldo, I exchanged arguments of hist_entry__cmp() and friends as you requested. You can get this on my perf/link-v2 branch at git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (3): perf hists: Exchange order of comparing items when collapsing hists perf hists: Link hist entries before inserting to an output tree perf diff: Use internal rb tree for compute resort tools/perf/builtin-diff.c | 95 +-- tools/perf/util/hist.c| 51 ++--- 2 files changed, 80 insertions(+), 66 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] perf hists: Link hist entries before inserting to an output tree
From: Namhyung Kim
For matching and/or linking hist entries, they need to be sorted by
given sort keys. However current hists__match/link did this on the
output trees, so that the entries in the output tree need to be resort
before doing it.
This looks not so good since we have trees for collecting or
collapsing entries before passing them to an output tree and they're
already sorted by the given sort keys. Since we don't need to print
anything at the time of matching/linking, we can use these internal
trees directly instead of bothering with double resort on the output
tree.
Its only user - at the time of this writing - perf diff can be easily
converted to use the internal tree and can save some lines too by
getting rid of unnecessary resorting codes.
It seems we need to do output resort on baseline hists for
displacement prior to the match/link. But AFAIK it's okay since the
resort doesn't make any change to the internal tree - i.e. every
entries in the internal tree remain as is and just linked to both of
internal and output tree using different keys. So linking entries in
the internal tree after output resorting will not cause any harm IMHO.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 73 ++-
tools/perf/util/hist.c| 49 +++
2 files changed, 65 insertions(+), 57 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index d869029fb75e..b52f5d8c4a6b 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -276,46 +276,19 @@ static struct perf_tool tool = {
.ordering_requires_timestamps = true,
};
-static void insert_hist_entry_by_name(struct rb_root *root,
- struct hist_entry *he)
-{
- struct rb_node **p = >rb_node;
- struct rb_node *parent = NULL;
- struct hist_entry *iter;
-
- while (*p != NULL) {
- parent = *p;
- iter = rb_entry(parent, struct hist_entry, rb_node);
- if (hist_entry__cmp(he, iter) < 0)
- p = &(*p)->rb_left;
- else
- p = &(*p)->rb_right;
- }
-
- rb_link_node(>rb_node, parent, p);
- rb_insert_color(>rb_node, root);
-}
-
-static void hists__name_resort(struct hists *self, bool sort)
+static void hists__compute_position(struct hists *hists)
{
unsigned long position = 1;
- struct rb_root tmp = RB_ROOT;
- struct rb_node *next = rb_first(>entries);
+ struct rb_node *next = rb_first(>entries);
while (next != NULL) {
- struct hist_entry *n = rb_entry(next, struct hist_entry,
rb_node);
+ struct hist_entry *he;
- next = rb_next(>rb_node);
- n->position = position++;
+ he = rb_entry(next, struct hist_entry, rb_node);
+ he->position = position++;
- if (sort) {
- rb_erase(>rb_node, >entries);
- insert_hist_entry_by_name(, n);
- }
+ next = rb_next(next);
}
-
- if (sort)
- self->entries = tmp;
}
static struct perf_evsel *evsel_match(struct perf_evsel *evsel,
@@ -330,34 +303,39 @@ static struct perf_evsel *evsel_match(struct perf_evsel
*evsel,
return NULL;
}
-static void perf_evlist__resort_hists(struct perf_evlist *evlist, bool name)
+static void perf_evlist__resort_hists(struct perf_evlist *evlist, bool base)
{
struct perf_evsel *evsel;
list_for_each_entry(evsel, >entries, node) {
struct hists *hists = >hists;
- hists__output_resort(hists);
+ hists__collapse_resort(hists);
- /*
-* The hists__name_resort only sets possition
-* if name is false.
-*/
- if (name || ((!name) && show_displacement))
- hists__name_resort(hists, name);
+ if (base && show_displacement) {
+ hists__output_resort(hists);
+ hists__compute_position(hists);
+ }
}
}
static void hists__baseline_only(struct hists *hists)
{
- struct rb_node *next = rb_first(>entries);
+ struct rb_root *root;
+ struct rb_node *next;
+
+ if (sort__need_collapse)
+ root = >entries_collapsed;
+ else
+ root = hists->entries_in;
+ next = rb_first(root);
while (next != NULL) {
- struct hist_entry *he = rb_entry(next, struct hist_entry,
rb_node);
+ struct hist_entry *he = rb_entry(next, struct hist_entry,
rb_node_in);
- next = rb_next(>rb_node);
+ next = rb_next(>rb_node_in);
if (!hist_entry__next_pair(he)) {
- rb_erase(>rb_node,
[V2 PATCH 2/2] rtc: pxa: add pxa95x rtc support
the pxa95x rtc need access PBSR register before write to
RTTR, RCNR, RDCR, and RYCR registers.
Signed-off-by: Chao Xie
---
drivers/rtc/rtc-pxa.c | 100 +---
1 files changed, 85 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
index f771b2e..aee23cb 100644
--- a/drivers/rtc/rtc-pxa.c
+++ b/drivers/rtc/rtc-pxa.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
@@ -77,14 +78,28 @@
#define RTCPICR0x34
#define PIAR 0x38
+#define PSBR_RTC 0x00
+
#define rtc_readl(pxa_rtc, reg)\
__raw_readl((pxa_rtc)->base + (reg))
#define rtc_writel(pxa_rtc, reg, value)\
__raw_writel((value), (pxa_rtc)->base + (reg))
+#define rtc_readl_psbr(pxa_rtc, reg) \
+ __raw_readl((pxa_rtc)->base_psbr + (reg))
+#define rtc_writel_psbr(pxa_rtc, reg, value) \
+ __raw_writel((value), (pxa_rtc)->base_psbr + (reg))
+
+enum {
+ RTC_PXA27X,
+ RTC_PXA95X,
+};
struct pxa_rtc {
struct resource *ress;
+ struct resource *ress_psbr;
+ unsigned intid;
void __iomem*base;
+ void __iomem*base_psbr;
int irq_1Hz;
int irq_Alrm;
struct rtc_device *rtc;
@@ -242,9 +257,26 @@ static int pxa_rtc_set_time(struct device *dev, struct
rtc_time *tm)
{
struct pxa_rtc *pxa_rtc = dev_get_drvdata(dev);
+ /*
+* sequence to wirte pxa rtc register RCNR RDCR RYCR is
+* 1. set PSBR[RWE] bit, take 2x32-khz to complete
+* 2. write to RTC register,take 2x32-khz to complete
+* 3. clear PSBR[RWE] bit,take 2x32-khz to complete
+*/
+ if (pxa_rtc->id == RTC_PXA95X) {
+ rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x01);
+ udelay(100);
+ }
+
rtc_writel(pxa_rtc, RYCR, ryxr_calc(tm));
rtc_writel(pxa_rtc, RDCR, rdxr_calc(tm));
+ if (pxa_rtc->id == RTC_PXA95X) {
+ udelay(100);
+ rtc_writel_psbr(pxa_rtc, PSBR_RTC, 0x00);
+ udelay(100);
+ }
+
return 0;
}
@@ -310,6 +342,20 @@ static const struct rtc_class_ops pxa_rtc_ops = {
.proc = pxa_rtc_proc,
};
+static struct of_device_id pxa_rtc_dt_ids[] = {
+ { .compatible = "marvell,pxa-rtc", .data = (void *)RTC_PXA27X },
+ { .compatible = "marvell,pxa95x-rtc", .data = (void *)RTC_PXA95X },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pxa_rtc_dt_ids);
+
+static const struct platform_device_id pxa_rtc_id_table[] = {
+ { "pxa-rtc", RTC_PXA27X },
+ { "pxa95x-rtc", RTC_PXA95X },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, pxa_rtc_id_table);
+
static int __init pxa_rtc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -324,13 +370,34 @@ static int __init pxa_rtc_probe(struct platform_device
*pdev)
spin_lock_init(_rtc->lock);
platform_set_drvdata(pdev, pxa_rtc);
+ if (pdev->dev.of_node) {
+ const struct of_device_id *of_id =
+ of_match_device(pxa_rtc_dt_ids, >dev);
+
+ pxa_rtc->id = (unsigned int)(of_id->data);
+ } else {
+ const struct platform_device_id *id =
+ platform_get_device_id(pdev);
+
+ pxa_rtc->id = id->driver_data;
+ }
+
ret = -ENXIO;
pxa_rtc->ress = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!pxa_rtc->ress) {
- dev_err(dev, "No I/O memory resource defined\n");
+ dev_err(dev, "No I/O memory resource(id=0) defined\n");
goto err_ress;
}
+ if (pxa_rtc->id == RTC_PXA95X) {
+ pxa_rtc->ress_psbr =
+ platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!pxa_rtc->ress_psbr) {
+ dev_err(dev, "No I/O memory resource(id=1) defined\n");
+ goto err_ress;
+ }
+ }
+
pxa_rtc->irq_1Hz = platform_get_irq(pdev, 0);
if (pxa_rtc->irq_1Hz < 0) {
dev_err(dev, "No 1Hz IRQ resource defined\n");
@@ -347,7 +414,17 @@ static int __init pxa_rtc_probe(struct platform_device
*pdev)
resource_size(pxa_rtc->ress));
if (!pxa_rtc->base) {
dev_err(>dev, "Unable to map pxa RTC I/O memory\n");
- goto err_map;
+ goto err_map_base;
+ }
+
+ if (pxa_rtc->id == RTC_PXA95X) {
+ pxa_rtc->base_psbr = ioremap(pxa_rtc->ress_psbr->start,
+ resource_size(pxa_rtc->ress_psbr));
+ if (!pxa_rtc->base_psbr) {
+ dev_err(>dev,
+ "Unable to map pxa RTC PSBR I/O memory\n");
+ goto err_map_base_psbr;
+
[V2 PATCH 1/2] rtc: sa1100: move clock enable/disable to probe/remove
The original sa1100_rtc_open/sa1100_rtc_release will be called
when the /dev/rtc0 is opened or closed.
In fact, these two functions will enable/disable the clock.
Disabling clock will make rtc not work.
So only enable/disable clock when probe/remove the device.
Signed-off-by: Chao Xie
---
drivers/rtc/rtc-sa1100.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 50a5c4a..34f66b8 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -108,9 +108,6 @@ static int sa1100_rtc_open(struct device *dev)
struct rtc_device *rtc = info->rtc;
int ret;
- ret = clk_prepare_enable(info->clk);
- if (ret)
- goto fail_clk;
ret = request_irq(info->irq_1hz, sa1100_rtc_interrupt, 0, "rtc 1Hz",
dev);
if (ret) {
dev_err(dev, "IRQ %d already in use.\n", info->irq_1hz);
@@ -130,7 +127,6 @@ static int sa1100_rtc_open(struct device *dev)
free_irq(info->irq_1hz, dev);
fail_ui:
clk_disable_unprepare(info->clk);
- fail_clk:
return ret;
}
@@ -144,7 +140,6 @@ static void sa1100_rtc_release(struct device *dev)
free_irq(info->irq_alarm, dev);
free_irq(info->irq_1hz, dev);
- clk_disable_unprepare(info->clk);
}
static int sa1100_rtc_alarm_irq_enable(struct device *dev, unsigned int
enabled)
@@ -253,6 +248,9 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
spin_lock_init(>lock);
platform_set_drvdata(pdev, info);
+ ret = clk_prepare_enable(info->clk);
+ if (ret)
+ goto err_enable_clk;
/*
* According to the manual we should be able to let RTTR be zero
* and then a default diviser for a 32.768KHz clock is used.
@@ -305,6 +303,8 @@ static int sa1100_rtc_probe(struct platform_device *pdev)
return 0;
err_dev:
+ clk_disable_unprepare(info->clk);
+err_enable_clk:
platform_set_drvdata(pdev, NULL);
clk_put(info->clk);
err_clk:
@@ -318,6 +318,7 @@ static int sa1100_rtc_remove(struct platform_device *pdev)
if (info) {
rtc_device_unregister(info->rtc);
+ clk_disable_unprepare(info->clk);
clk_put(info->clk);
platform_set_drvdata(pdev, NULL);
kfree(info);
--
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: i915 freakout with latest 3.7 git
On 05.12.2012, Lekensteyn wrote: > > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE > > compositor. Now I'm trying to hit the bug again... > Do you have a reliable reproduce method? As you can see in the linked bug it > was caused by relatively low memory pressure combined with high I/O (caching? > delays? Who knows). No, unfortunately not. I will do my very best to find out how to trigger it. For now, I'm trying with a script which produces max. I/O. Will also try by replaying a lot of high resolution videos and similar. > It is unlikely that Optimus has anything to do with this. Ok. Heinz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/3] virtio_net: multiqueue support
On 12/04/2012 11:11 PM, Michael S. Tsirkin wrote:
> On Tue, Dec 04, 2012 at 10:45:33PM +0800, Jason Wang wrote:
>> On Tuesday, December 04, 2012 03:24:22 PM Michael S. Tsirkin wrote:
>>> I found some bugs, see below.
>>> Also some style nitpicking, this is not mandatory to address.
>> Thanks for the reviewing.
>>> On Tue, Dec 04, 2012 at 07:07:57PM +0800, Jason Wang wrote:
>>>
[...]
+ set = false;
>>> This will overwrite affinity if it was set by userspace.
>>> Just
>>> if (set)
>>> return;
>>> will not have this problem.
>> But we need handle the situtaiton when switch back to sq from mq mode.
>> Otherwise we may still get the affinity hint used in mq.
>> This kind of overwrite
>> is unavoidable or is there some method to detect whether userspac write
>> something new?
> If we didn't set the affinity originally we should not overwrite it.
> I think this means we need a flag that tells us that
> virtio set the affinity.
Ok.
[...]
+
+ /* Parameters for control virtqueue, if any */
+ if (vi->has_cvq) {
+ callbacks[total_vqs - 1] = NULL;
+ names[total_vqs - 1] = kasprintf(GFP_KERNEL, "control");
+ }
+ /* Allocate/initialize parameters for send/receive virtqueues */
+ for (i = 0; i < vi->max_queue_pairs; i++) {
+ callbacks[rxq2vq(i)] = skb_recv_done;
+ callbacks[txq2vq(i)] = skb_xmit_done;
+ names[rxq2vq(i)] = kasprintf(GFP_KERNEL, "input.%d", i);
+ names[txq2vq(i)] = kasprintf(GFP_KERNEL, "output.%d", i);
+ }
>>> We would need to check kasprintf return value.
>> Looks like a better method is to make the name as a memeber of receive_queue
>> and send_queue, and use sprintf here.
>>> Also if you allocate names from slab we'll need to free them
>>> later.
>> Then it could be freed when the send_queue and receive_queue is freed.
>>> It's probably easier to just use fixed names for now -
>>> it's not like the index is really useful.
>> Looks useful for debugging e.g. check whether the irq distribution is as
>> expected.
> Well it doesn't really matter which one goes where, right?
> As long as interrupts are distributed well.
Yes, anyway, we decide to store the name in the send/receive queue, so I
will keep the index.
>
+
+ ret = vi->vdev->config->find_vqs(vi->vdev, total_vqs, vqs, callbacks,
+ (const char **)names);
>>> Please avoid casts, use a proper type for names.
>> I'm consider we need a minor change in this api, we need allocate the names
>> dynamically which could not be a const char **.
> I don't see why. Any use that allocates on the fly as
> you did would leak memory. Any use like you suggest
> e.g. allocating as part of send/receive structure
> would be fine.
True
+ if (ret)
+ goto err_names;
+
+ if (vi->has_cvq) {
+ vi->cvq = vqs[total_vqs - 1];
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VLAN))
vi->dev->features |= NETIF_F_HW_VLAN_FILTER;
}
+
+ for (i = 0; i < vi->max_queue_pairs; i++) {
+ vi->rq[i].vq = vqs[rxq2vq(i)];
+ vi->sq[i].vq = vqs[txq2vq(i)];
+ }
+
+ kfree(callbacks);
+ kfree(vqs);
>>> Who frees names if there's no error?
>>>
>> The virtio core does not copy the name, so it need this and only used for
>> debugging if I'm reading the code correctly.
> No, virtio core does not free either individual vq name or the names
> array passed in. So this leaks memory.
Yes, so when we use the names in receive/send queue, it can be freed
during queue destroying.
[...]
> @@ -1276,24 +1531,29 @@ static int virtnet_freeze(struct virtio_device
> *vdev)>
> static int virtnet_restore(struct virtio_device *vdev)
> {
>
> struct virtnet_info *vi = vdev->priv;
>
> - int err;
> + int err, i;
>
> err = init_vqs(vi);
> if (err)
>
> return err;
>
> if (netif_running(vi->dev))
>
> - virtnet_napi_enable(>rq);
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + virtnet_napi_enable(>rq[i]);
>
> netif_device_attach(vi->dev);
>
> - if (!try_fill_recv(>rq, GFP_KERNEL))
> - schedule_delayed_work(>refill, 0);
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + if (!try_fill_recv(>rq[i], GFP_KERNEL))
> + schedule_delayed_work(>refill, 0);
>
> mutex_lock(>config_lock);
> vi->config_enable = true;
> mutex_unlock(>config_lock);
>
> + if (vi->has_cvq && virtio_has_feature(vi->vdev, VIRTIO_NET_F_RFS))
> + virtnet_set_queues(vi);
> +
>>> I think it's easier to test
>>> if (curr_queue_pairs == max_queue_pairs)
>>> within virtnet_set_queues and make it
>>> a NOP if so.
>> Still need to send the command during restore since we
Re: [PATCH 5/5] mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma()
On Tue, 4 Dec 2012, Hugh Dickins wrote: > > Yes, your patch fixes it Mel, but I prefer it as below, with a couple > of mods: removing the no longer true comment, and leaving shmem_swapin() > alone with just a comment. It appears to be the job of the rather weird > mpol_cond_copy() to drop the reference on the original mempolicy, and > clear MPOL_F_SHARED so the copy won't need one (it's trying to cope with > the fact that swapin_readahead will make an unknown number of calls to > alloc_page_vma). So I'd rather not add another mpol_cond_put there, > whose cond will never be met. Hold on, ignore that patch for now, I think I had my priorities upside down: it would be better for shmem_swapin() to behave as you proposed, and we delete the mpol_cond_copy() weirdness instead. Your 00442ad04a5e changed alloc_pages_vma() to keep its refcounting in balance, so it now does not matter that swapin_readahead() makes an unknown number of calls to it: we should simply take a reference before and drop it after, just as you do in shmem_alloc_page(). I'd still like to revisit alloc_page_vma(), and its refcount manipulations do now appear redundant; but changing that is not something I want to get into in a last minute rush. But getting rid of mpol_cond_copy() should be safe and clear, I'll test that out now and reply with an updated patch (or else admit I got confused). Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver
Hi Henrik, Kamal,
Thanks for your review.
And I add some comments in below.
Thanks.
Dudley Du
d...@cypress.com
> Hi Henrik-
>
> Thanks again for your review. The forthcoming PATCH v4 includes the majority
> of your change requests, except where noted below (and considering my email
> "Subject: SEMI_MT vs. simulated mt")...
>
>
> On Mon, 2012-12-03 at 08:45 +0100, Henrik Rydberg wrote:
>
> > > + /*
> > > + * send extension command 0xE8 or 0xF3,
> > > + * if send extension command failed,
> > > + * try to send recovery command to make
> > > + * trackpad device return to ready wait command state.
> > > + * It alwasy success based on this recovery commands.
> >
> > -EPARSE
>
> I don't understand the meaning of that comment either. Perhaps the original
> author Dudley Du can explain it.
Since all trackpad specific commands are sent as extension command,
the format of extension command series is "0xE8 dd 0xE8 cc 0xE8 bb 0xE8".
And as we know, it may fail when sending the extension command series,
So this comment just want to indicates that if some unknown error occurred when
sending the extension command,
this code will send recovery command to make trackpad firmware go back to ready
state,
so same command can be tried to be re-sent.
Sorry for the bad comments causing confusion.
> > > +static int cypress_read_vital_statistics(struct psmouse *psmouse)
> >
> > Why do you call this statistics?
>
> Perhaps "cypress_read_tp_metrics" would be a better name. Any thoughts on
> this, Dudley?
>
>
> > > +/*
> > > + * reset trackpad device to standard relative mode.
> > > + * This is also the defalut mode when trackpad powered on.
> > > + */
> > > +static void cypress_reset(struct psmouse *psmouse) {
> > > + struct cytp_data *cytp = psmouse->private;
> > > +
> > > + psmouse_reset(psmouse);
> > > +
> > > + CYTP_SET_MODE_BIT(CYTP_BIT_STANDARD_REL);
> > > + CYTP_SET_PACKET_SIZE(3);
> > > +
> > > + cytp->prev_contact_cnt = 0;
> > > +}
> >
> > I suppose it is, but is it necessary to reset to default mode?
>
> I left this unchanged, as I think you and Dmitry agreed.
>
>
> > > +
> > > +static int cypress_set_input_params(struct input_dev *input,
> > > + struct cytp_data *cytp)
> > > +{
> > > + int ret;
> > > +
> > > + if (cytp->mode & CYTP_BIT_ABS_MASK) {
> >
> > It seems the device will always operate in this mode, so please simplify.
>
> I #ifdef'd out the unused relative-mode code, as opposed to deleting it.
> Will that be acceptable?
I think relative-mode code should be reserved,
since for some unknown reason, trackpad may failed in absolution mode,
and in order to make trackpad device kept on usable,
we may set it to relative-mode,
so in this situation, the relative-mode code should be exist.
> > > + /* Remove HSCROLL bit */
> > > + if (report_data->contact_cnt == 4)
> > > + header_byte &= ~(ABS_HSCROLL_BIT);
> >
> > Why conditionally?
>
> Dudley, can you answer this? I left this (and all the scroll code) unchanged.
Yes, this condition should be reserved.
Because ABS_HSCROLL_BIT is will reused to indicate finger numbers when finger
number is bigger than 3.
And when the contact_cnt is 4, the ABS_HSCROLL_BIT is set to indicate 4 fingers
touched, not HSCROLL BIT set.
But it will be confused with the flag of HSCROLL bit with one finger touched.
So we must clear this bit when contact_cnt is 4.
> > > +#if 0
> > > + /* FIXME: cypress_reconnect() never works...
> > > + * just let psmouse re-init() us for now.
> > > + */
> > > + psmouse->reconnect = cypress_reconnect; #endif
> >
> > This needs to be removed or fixed, of course.
>
> Per Dudley, this does work in his disconnect/reconnect scenario, so I
> re-enabled it. We will continue to investigate why it fails
> (harmlessly) in my suspend/resume scenario.
> > > + int tp_max_abs_x; /* Max X absolution units can be reported. */
> > > + int tp_max_abs_y; /* Max Y absolution units can be reported. */
> >
> > I do not think we are seeking absolution here. :-)
>
> Ha! Speak for yourself, Henrik! ;-) I'm starting to feel like maybe I
> should be seeking absolution here!
>
>
> -Kamal
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode if fat_dget() fails
2012/12/4, OGAWA Hirofumi : > Namjae Jeon writes: > >> 2012/12/3, OGAWA Hirofumi : >>> Namjae Jeon writes: >>> From: Namjae Jeon This patch enables rebuilding of directory inodes which are not present in the cache.This is done by traversing the disk clusters to find the directory entry of the parent directory and using its i_pos to build the inode. Do this only if the "nostale_ro" nfs mount option is specified. >>> >>> This became much better than before. However, we have to consolidate the >>> code with fat_search_long() finally. >>> >>> E.g. this version is having the issue already fixed. If there is >>> corruption in fat cluster-chain, it lead to infinite >>> loop. fat_get_cluster() checks infinite loop by limit. >> since, the focus this time was for NFS functionality for FAT (removing >> ESTALE error). The changes were made in that context. >> >> Later, we can make the changes as part of code reorganizing which can >> be controlled via. Separate patches which do not have any impact on >> default functionality and verification can be carried out in that >> scope. > > Right. But non-production code shouldn't go into linus tree. I meant, we > can test this patch series, but not yet production quality. Is there any other thing which seems potential issue than offsetof()? if yes, which problem didn't lead to production quality do you think ? +#define FAT_FID_SIZE_WITHOUT_PARENT (offsetof(struct fat_fid, \ + parent_i_pos_hi)/4) Since this expression does not result proper integer value, so will it be correct to directly put the value like +#define FAT_FID_SIZE_WITHOUT_PARENT 3 Thanks! > -- > OGAWA Hirofumi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/8] fat: restructure export_operations
2012/12/4, OGAWA Hirofumi :
> Namjae Jeon writes:
>
+static struct dentry *fat_fh_to_dentry_nostale(struct super_block *sb,
+ struct fid *fh, int fh_len,
+ int fh_type)
+{
+ struct inode *inode = NULL;
+ struct fat_fid *fid = (struct fat_fid *)fh;
+ loff_t i_pos;
+
+ switch (fh_type) {
+ case FILEID_FAT_WITHOUT_PARENT:
+ if (fh_len < FAT_FID_SIZE_WITHOUT_PARENT)
+ return NULL;
+ case FILEID_FAT_WITH_PARENT:
+ if ((fh_len < FAT_FID_SIZE_WITH_PARENT) &&
+ (fh_type == FILEID_FAT_WITH_PARENT))
+ return NULL;
>>>
>>> Do we have to care (FILEID_FAT_WITH_PARENT and fh_len < 5) here?
>>>
>>> if (fh_len < 2)
>>> return NULL;
>>>
>>> switch (fh_type) {
>>> case FILEID_INO32_GEN:
>>> case FILEID_INO32_GEN_PARENT:
>>> inode = get_inode(sb, fid->i32.ino, fid->i32.gen);
>>> break;
>>> }
>>>
>>> return d_obtain_alias(inode);
>>>
>>> generic_fh_to_dentry() is above. I wonder why we have to care
>>> fat_fid->parent* here.
>> Let me think, if ‘subtree’ checking is enabled then we should check
>> the length condition over here also? Please share if there are any
>> other comments also.
>
> I'm not sure what did you mean. Where is "subtree" check you are
> talking? This is fh_to_dentry(), so we don't use parent at all, so
> length == 3 is enough?
With fileID type="FILEID_FAT_WITHOUT_PARENT", fhlen should be '3'
With fileId type="FILEID_FAT_WITH_PARENT", fhlen should be '5'
While encoding, WITH_PARENT is selected when subtree check is enabled
on the NFS Server.
So, when decoding request is arrived- fileid type will be among the '2' cases:
Now, in case of fh_to_dentry() - when we consider, that the reqquest
for fileid type WITH_PARENT
then i think the conditions in fh_to_dentry should be:
if((fh_type == FILEID_FAT_WITH_PARENT) && fh_len != 5)
return NULL;
else if (fh_len != 3)
return NULL;
So, we took care of these '2' conditions within the switch statement
based on the 'fh_type'. We can just change the comparision condition
from '<' to '!=':
switch (fh_type) {
+ case FILEID_FAT_WITHOUT_PARENT:
+ if (fh_len != FAT_FID_SIZE_WITHOUT_PARENT)
+ return NULL;
+ case FILEID_FAT_WITH_PARENT:
+ if ((fh_len != FAT_FID_SIZE_WITH_PARENT) &&
+ (fh_type == FILEID_FAT_WITH_PARENT))
+ return NULL;
+ i_pos = fid->i_pos_hi;
+ i_pos = (i_pos << 32) | (fid->i_pos_low);
+ inode = __fat_nfs_get_inode(sb, 0, fid->i_gen, i_pos);
+ break;
+ }
I think there is no need to push the comparision statements in the
begining similar to generic_fh_to_dentry.
Thanks OGAWA.
> --
> OGAWA Hirofumi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: 88pm80x: add dt support
On 12/05/2012 10:28 AM, Haojian Zhuang wrote:
On Wed, Dec 5, 2012 at 10:23 AM, Qing Xu wrote:
From: Qing Xu
add dt support for 88pm800 and 88pm805
Signed-off-by: Qing Xu
---
drivers/mfd/88pm800.c | 26 +++---
drivers/mfd/88pm805.c | 26 +++---
drivers/mfd/88pm80x.c | 32
include/linux/mfd/88pm80x.h |3 +++
4 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 3fcc8dd..20b67d7 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -506,6 +506,22 @@ static int __devinit pm800_probe(struct i2c_client *client,
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
struct pm80x_subchip *subchip;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -540,9 +556,6 @@ static int __devinit pm800_probe(struct i2c_client *client,
goto err_800_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_800_init:
@@ -570,11 +583,18 @@ static int __devexit pm800_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm800_dt_ids[] = {
+ { .compatible = "marvell,88pm800", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm800_dt_ids);
+
static struct i2c_driver pm800_driver = {
.driver = {
.name = "88PM800",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm800_dt_ids),
},
.probe = pm800_probe,
.remove = __devexit_p(pm800_remove),
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 39a91bd..b0fb3ff 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -239,6 +239,22 @@ static int __devinit pm805_probe(struct i2c_client *client,
int ret = 0;
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -254,9 +270,6 @@ static int __devinit pm805_probe(struct i2c_client *client,
goto err_805_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_805_init:
@@ -277,11 +290,18 @@ static int __devexit pm805_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm805_dt_ids[] = {
+ { .compatible = "marvell,88pm805", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm805_dt_ids);
+
static struct i2c_driver pm805_driver = {
.driver = {
.name = "88PM805",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm805_dt_ids),
},
.probe = pm805_probe,
.remove = __devexit_p(pm805_remove),
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..bd59202 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -111,6 +111,38 @@ int pm80x_deinit(struct i2c_client *client)
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
+int pm80x_dt_init(struct device_node *np,
+ struct device *dev,
+ struct pm80x_platform_data *pdata)
+{
+ int ret;
+ ret = of_property_read_u32(np, "marvell,88pm80x-irqmode",
+ >irq_mode);
+ if (ret) {
+ dev_err(dev, "Not found \"marvell,88pm80x-irqmode\" "
+ "property\n");
+ return -EINVAL;
+ }
+
+
[PATCH 2/2] Documentation: add docs for 88pm80x dt
From: Qing Xu
Signed-off-by: Qing Xu
---
Documentation/devicetree/bindings/mfd/88pm80x.txt | 52 +
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/88pm80x.txt
diff --git a/Documentation/devicetree/bindings/mfd/88pm80x.txt
b/Documentation/devicetree/bindings/mfd/88pm80x.txt
new file mode 100644
index 000..8a0ed07
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/88pm80x.txt
@@ -0,0 +1,52 @@
+* Marvell 88pm80x Power Management IC
+
+Required parent device properties:
+- compatible : "marvell,88pm80x"
+- reg : the I2C slave address for the 88pm80x chip
+- interrupts : IRQ line for the 88pm80x chip
+- interrupt-controller: describes the 88pm80x as an interrupt controller (has
its own domain)
+- #interrupt-cells : should be 1.
+ - The cell is the 88pm80x local IRQ number
+
+Optional parent device properties:
+- marvell,88pm80x-irqmode: inicates whether interrupt status is cleared by read
+- marvell,88pm80x-poweraddr: 88pm80x are multi-chips solution. stores
the I2C address
+ of one chip, and this property stores the I2C
address of
+ power related chip.
+- marvell,88pm80x-gpadcaddr: 88pm80x are multi-chips solution. stores
the I2C address
+ of one chip, and this property stores the I2C
address of
+ gpadc related chip.
+
+88pm80x consists of various groups of sub-devices:
+
+Device Supply NamesDescription
+-- ---
+88pm80x-onkey : : On key
+88pm80x-rtc: : RTC
+
+Example:
+ pmic: 88pm800@30 {
+ compatible = "marvell,88pm80x";
+ reg = <0x30>;
+ interrupts = <4>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ marvell,88pm80x-irqmode = 0;
+ marvell,88pm80x-poweraddr = <0x31>;
+ marvell,88pm80x-gpadcaddr = <0x32>;
+ };
+
+
+ pmic: 88pm805@38 {
+ compatible = "marvell,88pm80x";
+ reg = <0x38>;
+ interrupts = <124>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ marvell,88pm80x-irqmode = 0;
+ };
+
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mfd: 88pm80x: add dt support
From: Qing Xu
add dt support for 88pm800 and 88pm805
Signed-off-by: Qing Xu
---
drivers/mfd/88pm800.c | 26 +++---
drivers/mfd/88pm805.c | 26 +++---
drivers/mfd/88pm80x.c | 32
include/linux/mfd/88pm80x.h |3 +++
4 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 3fcc8dd..20b67d7 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -506,6 +506,22 @@ static int __devinit pm800_probe(struct i2c_client *client,
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
struct pm80x_subchip *subchip;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -540,9 +556,6 @@ static int __devinit pm800_probe(struct i2c_client *client,
goto err_800_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_800_init:
@@ -570,11 +583,18 @@ static int __devexit pm800_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm800_dt_ids[] = {
+ { .compatible = "marvell,88pm800", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm800_dt_ids);
+
static struct i2c_driver pm800_driver = {
.driver = {
.name = "88PM800",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm800_dt_ids),
},
.probe = pm800_probe,
.remove = __devexit_p(pm800_remove),
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 39a91bd..b0fb3ff 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -239,6 +239,22 @@ static int __devinit pm805_probe(struct i2c_client *client,
int ret = 0;
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -254,9 +270,6 @@ static int __devinit pm805_probe(struct i2c_client *client,
goto err_805_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_805_init:
@@ -277,11 +290,18 @@ static int __devexit pm805_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm805_dt_ids[] = {
+ { .compatible = "marvell,88pm805", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm805_dt_ids);
+
static struct i2c_driver pm805_driver = {
.driver = {
.name = "88PM805",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm805_dt_ids),
},
.probe = pm805_probe,
.remove = __devexit_p(pm805_remove),
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..ad42d2a 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -111,6 +111,38 @@ int pm80x_deinit(struct i2c_client *client)
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
+int pm80x_dt_init(struct device_node *np,
+ struct device *dev,
+ struct pm80x_platform_data *pdata)
+{
+ int ret;
+ ret = of_property_read_u32(np, "marvell,88pm80x-irqmode",
+ >irq_mode);
+ if (ret) {
+ dev_err(dev, "Not found \"marvell,88pm80x-irqmode\" "
+ "property\n");
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(np, "marvell,88pm80x-poweraddr",
+ (u32*)(>power_page_addr));
+ if
Re: [PATCH 5/5] mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma()
On Tue, 4 Dec 2012, Mel Gorman wrote:
> On Tue, Dec 04, 2012 at 02:54:08PM +0200, Tommi Rantala wrote:
> > 2012/10/9 Mel Gorman :
> > > commit 00442ad04a5eac08a98255697c510e708f6082e2 upstream.
> > >
> > > Commit cc9a6c877661 ("cpuset: mm: reduce large amounts of memory barrier
> > > related damage v3") introduced a potential memory corruption.
> > > shmem_alloc_page() uses a pseudo vma and it has one significant unique
> > > combination, vma->vm_ops=NULL and vma->policy->flags & MPOL_F_SHARED.
> > >
> > > get_vma_policy() does NOT increase a policy ref when vma->vm_ops=NULL
> > > and mpol_cond_put() DOES decrease a policy ref when a policy has
> > > MPOL_F_SHARED. Therefore, when a cpuset update race occurs,
> > > alloc_pages_vma() falls in 'goto retry_cpuset' path, decrements the
> > > reference count and frees the policy prematurely.
> >
> > Hello,
> >
> > kmemleak is complaining about memory leaks that point to the mbind()
> > syscall. I've seen this only in v3.7-rcX, so I bisected this, and
> > found that this patch is the first mainline commit where I'm able to
> > reproduce it with Trinity.
> >
>
> Uncool.
>
> I'm writing this from an airport so am not in the position to test properly
> but at a glance I'm not seeing what drops the reference count taken by
> mpol_shared_policy_lookup() in all cases. vm_ops->get_policy() probably
> gets it right but what about shmem_alloc_page() and shmem_swapin()?
>
> This patch is only compile tested. If the reference counts are dropped
> somewhere I did not spot quickly then it'll cause a use-after-free bug
> instead but is worth trying anyway.
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 89341b6..6229a43 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -912,6 +912,7 @@ static struct page *shmem_swapin(swp_entry_t swap, gfp_t
> gfp,
> {
> struct mempolicy mpol, *spol;
> struct vm_area_struct pvma;
> + struct page *page;
>
> spol = mpol_cond_copy(,
> mpol_shared_policy_lookup(>policy, index));
> @@ -922,13 +923,19 @@ static struct page *shmem_swapin(swp_entry_t swap,
> gfp_t gfp,
> pvma.vm_pgoff = index + info->vfs_inode.i_ino;
> pvma.vm_ops = NULL;
> pvma.vm_policy = spol;
> - return swapin_readahead(swap, gfp, , 0);
> + page = swapin_readahead(swap, gfp, , 0);
> +
> + /* Drop reference taken by mpol_shared_policy_lookup() */
> + mpol_cond_put(pvma.vm_policy);
> +
> + return page;
> }
>
> static struct page *shmem_alloc_page(gfp_t gfp,
> struct shmem_inode_info *info, pgoff_t index)
> {
> struct vm_area_struct pvma;
> + struct page *page;
>
> /* Create a pseudo vma that just contains the policy */
> pvma.vm_start = 0;
> @@ -940,7 +947,12 @@ static struct page *shmem_alloc_page(gfp_t gfp,
> /*
>* alloc_page_vma() will drop the shared policy reference
>*/
> - return alloc_page_vma(gfp, , 0);
> + page = alloc_page_vma(gfp, , 0);
> +
> + /* Drop reference taken by mpol_shared_policy_lookup() */
> + mpol_cond_put(pvma.vm_policy);
> +
> + return page;
> }
> #else /* !CONFIG_NUMA */
> #ifdef CONFIG_TMPFS
Thank you, Tommi and Mel. Easy enough for me to reproduce without
kmemleak and trinity, by mounting a tmpfs with mpol= and keeping an
eye on numa_policy in /proc/slabinfo while building a tree there.
Yes, your patch fixes it Mel, but I prefer it as below, with a couple
of mods: removing the no longer true comment, and leaving shmem_swapin()
alone with just a comment. It appears to be the job of the rather weird
mpol_cond_copy() to drop the reference on the original mempolicy, and
clear MPOL_F_SHARED so the copy won't need one (it's trying to cope with
the fact that swapin_readahead will make an unknown number of calls to
alloc_page_vma). So I'd rather not add another mpol_cond_put there,
whose cond will never be met.
I don't much like the result, but that's because it's adding further
cruft on top of the onstack pseudo-vma stuff: more impetus for me to
revisit the alloc_page_mpol() patch I worked on years ago, but gave
up when I couldn't understand the mpol refcounting: hopefully I'll
find that Kosaki's changes have made it all clearer now.
Please consent to the addition of your signoff: thanks!
[PATCH] tmpfs: fix shared mempolicy leak
From: Mel Gorman
Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount
imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the
refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went
on expecting alloc_page_vma() to drop the refcount it had acquired.
This deserves a rework: but for now fix the leak in shmem_alloc_page().
Reported-by: Tommi Rantala
Awaiting-Signed-off-by: Mel Gorman
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org
---
mm/shmem.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
--- 3.7-rc8/mm/shmem.c 2012-11-16 19:26:56.388459961 -0800
+++
Re: [lm-sensors] [PATCH] x86, AMD: Power driver support for AMD's family 16h processors
On Tue, Dec 04, 2012 at 10:26:16AM -0700, Bjorn Helgaas wrote:
> On Tue, Dec 4, 2012 at 5:10 AM, Boris Ostrovsky
> wrote:
> > Add family 16h PCI ID to AMD's power driver to allow it report
> > power consumption on these processors.
> >
> > Signed-off-by: Boris Ostrovsky
> > ---
> > drivers/hwmon/fam15h_power.c |1 +
> > include/linux/pci_ids.h |1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index 4f41104..dda1113 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -248,6 +248,7 @@ static void __devexit fam15h_power_remove(struct
> > pci_dev *pdev)
> >
> > static DEFINE_PCI_DEVICE_TABLE(fam15h_power_id_table) = {
> > { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
> > + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
> > {}
> > };
> > MODULE_DEVICE_TABLE(pci, fam15h_power_id_table);
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 9d36b82..9c9a464 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -524,6 +524,7 @@
> > #define PCI_DEVICE_ID_AMD_15H_NB_F30x1603
> > #define PCI_DEVICE_ID_AMD_15H_NB_F40x1604
> > #define PCI_DEVICE_ID_AMD_15H_NB_F50x1605
> > +#define PCI_DEVICE_ID_AMD_16H_NB_F40x1534
> > #define PCI_DEVICE_ID_AMD_CNB17H_F30x1703
> > #define PCI_DEVICE_ID_AMD_LANCE0x2000
> > #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001
>
> Read the comment at the top of pci_ids.h. Based on just this patch,
> it doesn't seem like the pci_ids.h change is warranted.
>
Boris,
can you move the define into fam15h_power.c and resubmit the patch ?
It would simplify integration.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RT 0/2][RFC] fix RCU stall warning on ARM
On 12/04/12 20:47, Frank Rowand wrote:
> The RCU stall warning functions call trigger_all_cpu_backtrace()
> to print a backtrace on each cpu. This function is only
> implemented for x86. Add a version for ARM.
>
> With CONFIG_PREEMPT_RT_FULL enabled, flushing the output from
> printk() is inhibited in some contexts to avoid increasing
> real time latencies. The RCU stall warnings are inhibited
> on ARM due to this feature. (I have not tested whether this
> is also the case on other architectures.) Add back the
> oops_in_progress flag to allow the RCU stall warnings to
> print immediately.
When I first implemented these patches on a locally modified
3.0.27-rt67, the call to "bust_spinlocks(0)" that I added to
print_cpu_stall() led to LOCKDEP warning of inconsistent
lock state from a trylock in serial_omap_console_write():
else if (oops_in_progress)
locked = spin_trylock_irqsave(>port.lock, flags);
If I understand correctly, the warning is triggered on the
slow lock path. Some more of the warning is:
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&(>lock)->lock)->wait_lock){?.+...}, at: []
rt_spin_trylock_irqsave+0x24/0xe0
...
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&(>lock)->lock)->wait_lock);
lock(&(&(>lock)->lock)->wait_lock);
I have not been able to trigger the warning on recent versions
of the patches, but I suspect the latent problem might still
exist.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RT 0/2][RFC] fix RCU stall warning on ARM
This patch should __not__ be committed to the RT_PREEMPT tree.
Test scaffolding to force printing of rcu detected stall. Each time the
specified value is echoed into the proc file, the routine to be tested
will be called one time, from the context it would normally be called from.
# test print_cpu_stall()
echo 1 > /proc/sys/kernel/zzz_debug_print_stall_once
# test print_other_cpu_stall()
echo 2 > /proc/sys/kernel/zzz_debug_print_stall_once
Signed-off-by: Frank Rowand
---
kernel/rcutree.c | 2626 +0 - 0 !
kernel/sysctl.c | 1111 +0 - 0 !
2 files changed, 37 insertions(+)
Index: b/kernel/rcutree.c
===
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -738,6 +738,7 @@ static void record_gp_stall_check_time(s
rsp->jiffies_stall = jiffies + jiffies_till_stall_check();
}
+int zzz_debug_print_other_cpu_stall;
static void print_other_cpu_stall(struct rcu_state *rsp)
{
int cpu;
@@ -750,10 +751,12 @@ static void print_other_cpu_stall(struct
raw_spin_lock_irqsave(>lock, flags);
delta = jiffies - rsp->jiffies_stall;
+if (!zzz_debug_print_other_cpu_stall) {
if (delta < RCU_STALL_RAT_DELAY || !rcu_gp_in_progress(rsp)) {
raw_spin_unlock_irqrestore(>lock, flags);
return;
}
+}
rsp->jiffies_stall = jiffies + 3 * jiffies_till_stall_check() + 3;
raw_spin_unlock_irqrestore(>lock, flags);
@@ -792,6 +795,10 @@ static void print_other_cpu_stall(struct
ndetected += rcu_print_task_stall(rnp);
raw_spin_unlock_irqrestore(>lock, flags);
+if (zzz_debug_print_other_cpu_stall) {
+ ndetected += 1;
+}
+
print_cpu_stall_info_end();
printk(KERN_CONT "(detected by %d, t=%ld jiffies)\n",
smp_processor_id(), (long)(jiffies - rsp->gp_start));
@@ -843,6 +850,7 @@ static void print_cpu_stall(struct rcu_s
set_need_resched(); /* kick ourselves to get things going. */
}
+int zzz_debug_print_stall_once;
static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
{
unsigned long j;
@@ -851,6 +859,24 @@ static void check_cpu_stall(struct rcu_s
if (rcu_cpu_stall_suppress)
return;
+
+ if (zzz_debug_print_stall_once) {
+ int tmp = zzz_debug_print_stall_once;
+ zzz_debug_print_stall_once = 0;
+ if (tmp & 0x1) {
+ pr_crit("\n\n* DEBUG -- test
print_cpu_stall():\n\n");
+ print_cpu_stall(rsp);
+ }
+ if (tmp & 0x2) {
+ pr_crit("\n\n* DEBUG -- test
print_other_cpu_stall():\n\n");
+ zzz_debug_print_other_cpu_stall = 1;
+ print_other_cpu_stall(rsp);
+ zzz_debug_print_other_cpu_stall = 0;
+ }
+
+ return;
+ }
+
j = ACCESS_ONCE(jiffies);
js = ACCESS_ONCE(rsp->jiffies_stall);
rnp = rdp->mynode;
Index: b/kernel/sysctl.c
===
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -132,6 +132,8 @@ static int one_hundred = 100;
static int ten_thousand = 1;
#endif
+extern int zzz_debug_print_stall_once;
+
/* this is needed for the proc_doulongvec_minmax of vm_dirty_bytes */
static unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
@@ -1000,6 +1002,15 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
#endif
+#ifdef CONFIG_SMP
+ {
+ .procname = "zzz_debug_print_stall_once",
+ .data = _debug_print_stall_once,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec,
+ },
+#endif
{ }
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RT 2/2][RFC] let RCU stall messages escape with CONFIG_PREEMPT_RT_FULL
The printk()s in RCU stall warnings do not get flushed to the console
on ARM. Add the oops_in_progress flag back into the special trylock case in
console_trylock_for_printk(), and set the flag using "bust_spinlocks(1)".
This allows the printk() output to be flushed to the console.
Signed-off-by: Frank Rowand
---
kernel/printk.c |53 + 2 - 0 !
kernel/rcutree.c | 1414 +0 - 0 !
2 files changed, 17 insertions(+), 2 deletions(-)
Index: b/kernel/printk.c
===
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1390,8 +1390,9 @@ static int console_trylock_for_printk(un
{
int retval = 0, wake = 0;
#ifdef CONFIG_PREEMPT_RT_FULL
- int lock = !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
- (preempt_count() <= 1);
+ int lock = oops_in_progress || (
+ !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
+ (preempt_count() <= 1));
#else
int lock = 1;
#endif
Index: b/kernel/rcutree.c
===
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -758,6 +758,11 @@ static void print_other_cpu_stall(struct
raw_spin_unlock_irqrestore(>lock, flags);
/*
+* Allow printk() to flush to device
+*/
+ bust_spinlocks(1);
+
+ /*
* OK, time to rat on our buddy...
* See Documentation/RCU/stallwarn.txt for info on how to debug
* RCU CPU stall warnings.
@@ -799,6 +804,8 @@ static void print_other_cpu_stall(struct
rcu_print_detail_task_stall(rsp);
+ bust_spinlocks(0);
+
force_quiescent_state(rsp, 0); /* Kick them all. */
}
@@ -808,6 +815,11 @@ static void print_cpu_stall(struct rcu_s
struct rcu_node *rnp = rcu_get_root(rsp);
/*
+* Allow printk() to flush to device
+*/
+ bust_spinlocks(1);
+
+ /*
* OK, time to rat on ourselves...
* See Documentation/RCU/stallwarn.txt for info on how to debug
* RCU CPU stall warnings.
@@ -820,6 +832,8 @@ static void print_cpu_stall(struct rcu_s
if (!trigger_all_cpu_backtrace())
dump_stack();
+ bust_spinlocks(0);
+
raw_spin_lock_irqsave(>lock, flags);
if (ULONG_CMP_GE(jiffies, rsp->jiffies_stall))
rsp->jiffies_stall = jiffies +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RT 1/2][RFC] ARM version of arch_trigger_all_cpu_backtrace()
The RCU stall warning functions print_cpu_stall() and print_other_cpu_stall()
call trigger_all_cpu_backtrace() to print a backtrace on each cpu. This
function is only implemented for x86. Add a version for ARM.
Signed-off-by: Frank Rowand
---
arch/arm/include/asm/hardirq.h |2 1 + 1 - 0 !
arch/arm/include/asm/irq.h |5 5 + 0 - 0 !
arch/arm/kernel/smp.c | 70 70 +0 - 0 !
3 files changed, 76 insertions(+), 1 deletion(-)
Index: b/arch/arm/include/asm/irq.h
===
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -30,6 +30,11 @@ extern void asm_do_IRQ(unsigned int, str
void handle_IRQ(unsigned int, struct pt_regs *);
void init_IRQ(void);
+#ifdef CONFIG_SMP
+void arch_trigger_all_cpu_backtrace(void);
+#define arch_trigger_all_cpu_backtrace arch_trigger_all_cpu_backtrace
+#endif
+
#endif
#endif
Index: b/arch/arm/kernel/smp.c
===
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -56,6 +56,7 @@ enum ipi_msg_type {
IPI_CALL_FUNC,
IPI_CALL_FUNC_SINGLE,
IPI_CPU_STOP,
+ IPI_BACKTRACE,
};
static DECLARE_COMPLETION(cpu_running);
@@ -359,6 +360,7 @@ static const char *ipi_types[NR_IPI] = {
S(IPI_CALL_FUNC, "Function call interrupts"),
S(IPI_CALL_FUNC_SINGLE, "Single function call interrupts"),
S(IPI_CPU_STOP, "CPU stop interrupts"),
+ S(IPI_BACKTRACE, "Trigger all cpu backtrace"),
};
void show_ipi_list(struct seq_file *p, int prec)
@@ -493,6 +495,70 @@ static void ipi_cpu_stop(unsigned int cp
cpu_relax();
}
+#ifdef arch_trigger_all_cpu_backtrace
+/*
+ * Based on arch/x86/kernel/apic/hw_nmi.c:
+ * arch_trigger_all_cpu_backtrace_handler()
+ * arch_trigger_all_cpu_backtrace()
+ */
+
+static struct cpumask backtrace_mask;
+
+static unsigned long backtrace_flag;
+static arch_spinlock_t smp_backtrace_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+/*
+ * ipi_backtrace - handle IPI from smp_send_backtrace()
+ */
+static void ipi_backtrace(unsigned int cpu, struct pt_regs *regs)
+{
+ /*
+* serialize cpus
+*/
+ arch_spin_lock(_backtrace_lock);
+
+ pr_crit("\nCPU %u\n", cpu);
+
+ if (regs)
+ __show_regs(regs);
+
+ dump_stack();
+
+ cpumask_clear_cpu(cpu, _mask);
+
+ arch_spin_unlock(_backtrace_lock);
+}
+
+void arch_trigger_all_cpu_backtrace(void)
+{
+ int i;
+
+ if (test_and_set_bit(0, _flag))
+ /*
+* If there is already a trigger_all_cpu_backtrace() in progress
+* (backtrace_flag == 1), don't output double cpu dump infos.
+*/
+ return;
+
+ ipi_backtrace(smp_processor_id(), NULL);
+
+ cpumask_copy(_mask, cpu_online_mask);
+ cpumask_clear_cpu(smp_processor_id(), _mask);
+
+ if (!cpumask_empty(_mask))
+ smp_cross_call(_mask, IPI_BACKTRACE);
+
+ /* Wait for up to 10 seconds for all CPUs to do the backtrace */
+ for (i = 0; i < 10 * 1000; i++) {
+ if (cpumask_empty(_mask))
+ break;
+ mdelay(1);
+ }
+
+ clear_bit(0, _flag);
+}
+#endif
+
/*
* Main handler for inter-processor interrupts
*/
@@ -538,6 +604,10 @@ void handle_IPI(int ipinr, struct pt_reg
irq_exit();
break;
+ case IPI_BACKTRACE:
+ ipi_backtrace(cpu, regs);
+ break;
+
default:
printk(KERN_CRIT "CPU%u: Unknown IPI message 0x%x\n",
cpu, ipinr);
Index: b/arch/arm/include/asm/hardirq.h
===
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
#include
#include
-#define NR_IPI 5
+#define NR_IPI 6
typedef struct {
unsigned int __softirq_pending;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RT 0/2][RFC] fix RCU stall warning on ARM
The RCU stall warning functions call trigger_all_cpu_backtrace() to print a backtrace on each cpu. This function is only implemented for x86. Add a version for ARM. With CONFIG_PREEMPT_RT_FULL enabled, flushing the output from printk() is inhibited in some contexts to avoid increasing real time latencies. The RCU stall warnings are inhibited on ARM due to this feature. (I have not tested whether this is also the case on other architectures.) Add back the oops_in_progress flag to allow the RCU stall warnings to print immediately. A third patch contains test scaffolding to force the stall warnings to occur so that the other patches can be tested. The third patch should __not__ added to the mainline RT PREEMPT patch tree. These patches apply to 3.6.7-rt18. They do not apply cleanly to 3.0.xx. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2] Support volatile range for anon vma
On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote: > On 12/03/2012 11:22 PM, Minchan Kim wrote: > >On Mon, Dec 03, 2012 at 04:57:20PM -0800, John Stultz wrote: > >>On 12/03/2012 04:00 PM, Minchan Kim wrote: > >>>On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote: > On 11/21/2012 04:36 PM, John Stultz wrote: > >2) Being able to use this with tmpfs files. I'm currently trying > >to better understand the rmap code, looking to see if there's a > >way to have try_to_unmap_file() work similarly to > >try_to_unmap_anon(), to allow allow users to madvise() on mmapped > >tmpfs files. This would provide a very similar interface as to > >what I've been proposing with fadvise/fallocate, but just using > >process virtual addresses instead of (fd, offset) pairs. The > >benefit with (fd,offset) pairs for Android is that its easier to > >manage shared volatile ranges between two processes that are > >sharing data via an mmapped tmpfs file (although this actual use > >case may be fairly rare). I believe we should still be able to > >rework the ashmem internals to use madvise (which would provide > >legacy support for existing android apps), so then its just a > >question of if we could then eventually convince Android apps to > >use the madvise interface directly, rather then the ashmem unpin > >ioctl. > Hey Minchan, > I've been playing around with your patch trying to better > understand your approach and to extend it to support tmpfs files. In > doing so I've found a few bugs, and have some rough fixes I wanted > to share. There's still a few edge cases I need to deal with (the > vma-purged flag isn't being properly handled through vma merge/split > operations), but its starting to come along. > >>>Hmm, my patch doesn't allow to merge volatile with another one by > >>>inserting VM_VOLATILE into VM_SPECIAL so I guess merge isn't problem. > >>>In case of split, __split_vma copy old vma to new vma like this > >>> > >>> *new = *vma; > >>> > >>>So the problem shouldn't happen, I guess. > >>>Did you see the real problem about that? > >>Yes, depending on the pattern that MADV_VOLATILE and MADV_NOVOLATILE > >>is applied, we can get a result where data is purged, but we aren't > >>notified of it. Also, since madvise returns early if it encounters > >>an error, in the case where you have checkerboard volatile regions > >>(say every other page is volatile), which you mark non-volatile with > >>one large MADV_NOVOLATILE call, the first volatile vma will be > >>marked non-volatile, but since it returns purged, the madvise loop > >>will stop and the following volatile regions will be left volatile. > >> > >>The patches in the git tree below which handle the perged state > >>better seem to work for my tests, as far as resolving any > >>overlapping calls. Of course there may yet still be problems I've > >>not found. > >> > Anyway, take a look at the tree here and let me know what you think. > http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/minchan-anonvol > >>Eager to hear what you think! > >Below two patches look good to me. > > > >[rmap: Simplify volatility checking by moving it out of try_to_unmap_one] > >[rmap: ClearPageDirty() when returning SWAP_DISCARD] > > > >[madvise: Fix NOVOLATILE bug] > >I can't understand description of the patch. > >Could you elaborate it with example? > The case I ran into here is if you have a range where you mark every > other page as volatile. Then mark all the pages in that range as > non-volatile in one madvise call. > > sys_madvise() will then find the first vma in the range, and call > madvise_vma(), which marks the first vma non-volatile and return the > purged state. If the page has been purged, sys_madvise code will > note that as an error, and break out of the vma iteration loop, > leaving the following vmas in the range volatile. > > >[madvise: Fixup vma->purged handling] > >I included VM_VOLATILE into VM_SPECIAL intentionally. > >If comment of VM_SPECIAL is right, merge with volatile vmas shouldn't happen. > >So I guess you see other problem. When I see my source code today, locking > >scheme/purge handling is totally broken. I will look at it. Maybe you are > >seeing > >bug related that. Part of patch is needed. It could be separate patch. > >I will merge it. > I don't think the problem is when vmas being marked VM_VOLATILE are > being merged, its that when we mark the vma as *non-volatile*, and > remove the VM_VOLATILE flag we merge the non-volatile vmas with > neighboring vmas. So preserving the purged flag during that merge is > important. Again, the example I used to trigger this was an > alternating pattern of volatile and non volatile vmas, then marking > the entire range non-volatile (though sometimes in two overlapping > passes). Understood. Thanks. Below patch solves your problems? It's simple than
Re: [PATCH] staging: rtl8712: avoid a useless call to memset().
On 12/04/2012 07:22 PM, Cyril Roelandt wrote:
In r8711_wx_get_wap(), make sure we do not call memcpy() on a memory area that
has just been zeroed by a call to memset().
Signed-off-by: Cyril Roelandt
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Larry Finger
Thanks,
Larry
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 3a64790..2c73319 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1131,10 +1131,11 @@ static int r8711_wx_get_wap(struct net_device *dev,
struct ndis_wlan_bssid_ex *pcur_bss = >cur_network.network;
wrqu->ap_addr.sa_family = ARPHRD_ETHER;
- memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);
if (check_fwstate(pmlmepriv, _FW_LINKED |
WIFI_ADHOC_MASTER_STATE|WIFI_AP_STATE)) {
memcpy(wrqu->ap_addr.sa_data, pcur_bss->MacAddress, ETH_ALEN);
+ } else {
+ memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);
}
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] kmod 12
kmod 12 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-12.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-12.tar.sign Bug fix release only. Copying the NEWS section here for brevity: - Fix removing vermagic from module when told to force load a module - Fix removing __versions section when told to force load a module: we need to mangle the section header, not the section. - modinfo no longer fails while loading a module from file when path contains ".ko" substring Interesting that there was no previous bug report of "modprobe -f" failing, yet before this release it was not working properly. Maybe people are not tainting their kernel as frequently as I imagined. Shortlog is below. Cheers Lucas De Marchi --- Aleksey Makarov (1): fix is_module_filename() Lucas De Marchi (7): depmod: fix hash lookup by relpath instead of uncrelpath depmod: fix asserting mod->kmod == NULL libkmod-module: Remove key+value vermagic from .modinfo section libkmod-module: mangle the section header, not the section Use bool instead of int depmod: fix checking file extension kmod 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/
Re: [RFC PATCH 01/10] CPU hotplug: Introduce "stable" cpu online mask, for atomic hotplug readers
On 12/05/2012 10:56 AM, Michael Wang wrote:
[...]
>>
>> I wonder about the cpu-online case. A typical caller might want to do:
>>
>>
>> /*
>> * Set each online CPU's "foo" to "bar"
>> */
>>
>> int global_bar;
>>
>> void set_cpu_foo(int bar)
>> {
>> get_online_cpus_stable_atomic();
>> global_bar = bar;
>> for_each_online_cpu_stable()
>> cpu->foo = bar;
>> put_online_cpus_stable_atomic()
>> }
>>
>> void_cpu_online_notifier_handler(void)
>> {
>> cpu->foo = global_bar;
>> }
Oh, forgive me for misunderstanding your question :(
In this case, we have to prevent hotplug happen, not just ensure the
online mask is correct.
Hmm..., we need more consideration.
Regards,
Michael Wang
>>
>> And I think that set_cpu_foo() would be buggy, because a CPU could come
>> online before global_bar was altered, and that newly-online CPU would
>> pick up the old value of `bar'.
>>
>> So what's the rule here? global_bar must be written before we run
>> get_online_cpus_stable_atomic()?
>>
>> Anyway, please have a think and spell all this out?
>
> That's right, actually this related to one question, should the hotplug
> happen during get_online and put_online?
>
> Answer will be YES according to old API which using mutex, the hotplug
> won't happen in critical section, but the cost is get_online() will
> block, which will kill the performance.
>
> So we designed this mechanism to do acceleration, but as you pointed
> out, although the result will never be wrong, but the 'stable' mask is
> not stable since it could be changed in critical section.
>
> And we have two solution.
>
> One is from Srivatsa, using 'read_lock' and 'write_lock', it will
> prevent hotplug happen just like the old rule, the cost is we need a
> global 'rw_lock' which perform bad on NUMA system, and no doubt,
> get_online() will block for short time when doing hotplug.
>
> Another is to maintain a per-cpu cache mask, this mask will only be
> updated in get_online(), and be used in critical section, then we will
> get a real stable mask, but one flaw is, on different cpu in critical
> section, online mask will be different.
>
> We will be appreciate if we could collect some comments on which one to
> be used in next version.
>
> Regards,
> Michael Wang
>
>>
>>> struct take_cpu_down_param {
>>> unsigned long mod;
>>> void *hcpu;
>>> @@ -246,7 +351,9 @@ struct take_cpu_down_param {
>>> static int __ref take_cpu_down(void *_param)
>>> {
>>> struct take_cpu_down_param *param = _param;
>>> - int err;
>>> + int err, cpu = (long)(param->hcpu);
>>> +
>>
>> Like this please:
>>
>> int err;
>> int cpu = (long)(param->hcpu);
>>
>>> + prepare_cpu_take_down(cpu);
>>>
>>> /* Ensure this CPU doesn't handle any more interrupts. */
>>> err = __cpu_disable();
>>>
>>> ...
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why a host not ping-able?
On 2012-12-04, Rob Landley wrote: > On 12/04/2012 12:17:25 AM, Woody Wu wrote: >> Hi, list >> >> I am not sure this has something with kernel. > > It doesn't. > >> But the system I just >> generated cannot be reached from ping. It can ping outside, but if I >> ping it from outside, I just get "Destination Host Unreachable". > > Some distributions' default firewall rules respond to icmp packets with > a host unreachable packet. This is a system/network administration > thing (iptables) and nothing to do with kernel development. > >> I think there is not firewall in between, > > There's a firewall built into linux, read the man page for the > "iptables" command. The "iptables-save" command dumps your entire > current ruleset to stdout so you can see what's in there. (You might > have to run it as root, I forget.) > > https://help.ubuntu.com/community/IptablesHowTo > This 'distribution' I am running is a tailor linux 3.4.19 on an embedded system (Samsung S3C2410). Because this is a very small system, I believe I did not add any ip-table options in the kernel. And, I did not install any user space firware packet for it. So maybe this is really a firewall play in between. Now I run tcpdump on the target system with 'tcpdump -i eth0'. Then when I ping it from another Linux box, I see nothing from the tcpdump output. Does this confirm there is a firewall blocked the ping packets? Thanks in advance. -- woody I can't go back to yesterday - because I was a different person then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Update atime from future.
On 2012-12-04, at 13:24, Dave Chinner wrote: > On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote: >> Relatime should update the inode atime if it is more than a day in the >> future. The original problem seen was a tarball that had a bad atime, >> but could also happen if someone fat-fingers a "touch". The future >> atime will never be fixed. Before the relatime patch, the future atime >> would be updated back to the current time on the next access. > > So if someone accidentally changes time back a few days, access > times go backwards for everything? And they will go forward again if the files are accessed again in the future. > That doesn't sound right to me - > it's going to seriously screw up backups and other scanners that use > atime to determine "newly accessed files" I think it is equally as easy to say that if someone accidentally sets the time too far in the future (e.g. 2102 instead of 2012) for a while, then the atimes will be even more broken since the kernel will never update them again even after the clock is fixed. The point is that the behaviour before the relatime patch was that the kernel updated the atime to the current time as the kernel knows about it, it didn't make any decision about "the past" or "the future". Relatime is about reducing the frequency of atime updates, not about deciding that one timestamp is more correct than another. I'd be ok to change the margin for what constitutes a "future" time (a few days or a week?), but if atime updates happen once a day for times in the past I don't think it is incorrect to update the atime if it is more than a day in the future. Cheers, Andreas > IMO, if you fat-finger a manual atime update or use atimes direct > from tarballs, then that's your problem as a user and not the > responsibility of the kernel to magically fix for you > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v4 08/12] memory-hotplug: remove memmap of sparse-vmemmap
Hi Tang,
On 2012/12/5 10:07, Tang Chen wrote:
> Hi Wu,
>
> On 12/04/2012 08:20 PM, Jianguo Wu wrote:
> (snip)
>>>
>>> Seems that we have different ways to handle pages allocated by bootmem
>>> or by regular allocator. Is the checking way in [PATCH 09/12] available
>>> here ?
>>>
>>> +/* bootmem page has reserved flag */
>>> +if (PageReserved(page)) {
>>> ..
>>> +}
>>>
>>> If so, I think we can just merge these two functions.
>>
>> Hmm, direct mapping table isn't allocated by bootmem allocator such as
>> memblock, can't be free by put_page_bootmem().
>> But I will try to merge these two functions.
>>
>
> Oh, I didn't notice this, thanks. :)
>
> (snip)
>
+
+__split_large_page(kpte, address, pbase);
>>>
>>> Is this patch going to replace [PATCH 08/12] ?
>>>
>>
>> I wish to replace [PATCH 08/12], but need Congyang and Yasuaki to confirm
>> first:)
>>
>>> If so, __split_large_page() was added and exported in [PATCH 09/12],
>>> then we should move it here, right ?
>>
>> yes.
>>
>> and what do you think about moving vmemmap_pud[pmd/pte]_remove() to
>> arch/x86/mm/init_64.c,
>> to be consistent with vmemmap_populate() ?
>
> It is a good idea since pud/pmd/pte related code could be platform
> dependent. And I'm also trying to move vmemmap_free() to
> arch/x86/mm/init_64.c too. I want to have a common interface just
> like vmemmap_populate(). :)
>
Great.
>>
>> I will rework [PATCH 08/12] and [PATCH 09/12] soon.
>
> I am rebasing the whole patch set now. And I think I chould finish part
> of your work too. A new patch-set is coming soon, and your rework is
> also welcome. :)
>
Since you are rebasing now, I will wait for your new patche-set :).
Thanks.
Jianguo Wu
> 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 RFC] PM/Devfreq: Add Exynos5-bus devfreq driver for Exynos5250.
Cc'ing missed out recipients -- Forwarded message -- From: Abhilash Kesavan Date: Tue, Dec 4, 2012 at 9:48 PM Subject: Re: [PATCH RFC] PM/Devfreq: Add Exynos5-bus devfreq driver for Exynos5250. To: linux...@vger.kernel.org Jonghwan Choi samsung.com> writes: > > > Hi Abhilash Kesavan. Hi, > > I compiled in 3.7-rc8 > I got a compile error & warning. > > Compile error. > > CC drivers/devfreq/exynos5_ppmu.o > drivers/devfreq/exynos5_ppmu.c:56:14: error: 'S5P_VA_PPMU_DDR_C' undeclared > here (not in a function) > drivers/devfreq/exynos5_ppmu.c:59:14: error: 'S5P_VA_PPMU_DDR_R1' undeclared > here (not in a function) > drivers/devfreq/exynos5_ppmu.c:62:13: error: 'S5P_VA_PPMU_DDR_L' undeclared > here (not in a function) > drivers/devfreq/exynos5_ppmu.c:65:13: error: 'S5P_VA_PPMU_RIGHT' undeclared > here (not in a function) > drivers/devfreq/exynos5_ppmu.c:68:14: error: 'S5P_VA_PPMU_CPU' undeclared > here (not in a function) > make[2]: *** [drivers/devfreq/exynos5_ppmu.o] Error 1 I have submitted only the driver changes. As mentioned in the commit message I will post the arch side changes after the drivers gets a complete review. However, if you want to test the driver I will post it tommorrow. [...] > drivers/devfreq/exynos5_bus.c: In function 'exynos5_busfreq_int_probe': > drivers/devfreq/exynos5_bus.c:388:9: warning: passing argument 3 of > 'devfreq_add_device' from incompatible pointer type [enabled by default] > include/linux/devfreq.h:170:24: note: expected 'struct devfreq_governor > const *' but argument is of type 'char *' [...] > Need change? These changes are based on git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git : for-rafael devfreq_add_device prototype has recently changed and that might be the cause of the compilation error. Can you please try on this tree. > How to change the INT clock? I think you have to change > arch/arm/mach-exynos/clock-exynos5250.c > (If you want to control via clock framework.) [...] > exynos5_int_clk.ops = _clk_int_ops; This is part of the arch side patch that has not been posted. Regards, Abhilash -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd craziness in 3.7
On Tue, Dec 04, 2012 at 16:42:10 -0500, Johannes Weiner wrote: kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686 and kernel-3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.x86_64 for over 24hours with no evidence of problems with kswapd" Now waiting for results from Jiri, Zdenek and Bruno... I have been running 3.7.0-0.rc7.git1.2.van.main.knurd.kswap.4.fc18.i686.PAE a bit over 23 hours and kswapd has accumalated one minute 8 seconds of CPU time. I did several yum operations during that time and didn't see kswapd spike to 90+% CPU usage as I had seen in the past. With some kernels I wasn't reliably triggering the kswapd issue, so it may not be long enough to know for sure that the problem is fixed. I also should note that when I tried 3.7.0-0.rc7.git3.2.fc19.i686.PAE I did see problems with kswapd hitting 90+% usage of a CPU. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2, v2] mm/migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable
On Sun, Dec 2, 2012 at 7:12 AM, Ingo Molnar wrote: > Subject: [PATCH] mm/rmap, migration: Make rmap_walk_anon() and > try_to_unmap_anon() more scalable > > rmap_walk_anon() and try_to_unmap_anon() appears to be too > careful about locking the anon vma: while it needs protection > against anon vma list modifications, it does not need exclusive > access to the list itself. > > Transforming this exclusive lock to a read-locked rwsem removes > a global lock from the hot path of page-migration intense > threaded workloads which can cause pathological performance like > this: > > 96.43%process 0 [kernel.kallsyms] [k] perf_trace_sched_switch > | > --- perf_trace_sched_switch > __schedule > schedule > schedule_preempt_disabled > __mutex_lock_common.isra.6 > __mutex_lock_slowpath > mutex_lock > | > |--50.61%-- rmap_walk > | move_to_new_page > | migrate_pages > | migrate_misplaced_page > | __do_numa_page.isra.69 > | handle_pte_fault > | handle_mm_fault > | __do_page_fault > | do_page_fault > | page_fault > | __memset_sse2 > | | > | --100.00%-- worker_thread > | | > | --100.00%-- start_thread > | > --49.39%-- page_lock_anon_vma > try_to_unmap_anon > try_to_unmap > migrate_pages > migrate_misplaced_page > __do_numa_page.isra.69 > handle_pte_fault > handle_mm_fault > __do_page_fault > do_page_fault > page_fault > __memset_sse2 > | > --100.00%-- worker_thread >start_thread > > With this change applied the profile is now nicely flat > and there's no anon-vma related scheduling/blocking. Wouldn't the same reasoning apply to i_mmap_mutex ? Should we make that a rwsem as well ? I take it that Ingo's test case does not show this, but i_mmap_mutex's role with file pages is actually quite similar to the anon_vma lock with anon pages... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/10] CPU hotplug: Introduce "stable" cpu online mask, for atomic hotplug readers
On 12/05/2012 06:10 AM, Andrew Morton wrote:
> On Tue, 04 Dec 2012 14:23:41 +0530
> "Srivatsa S. Bhat" wrote:
>
>> From: Michael Wang
>>
>> There are places where preempt_disable() is used to prevent any CPU from
>> going offline during the critical section. Let us call them as "atomic
>> hotplug readers" (atomic because they run in atomic contexts).
>>
>> Often, these atomic hotplug readers have a simple need : they want the cpu
>> online mask that they work with (inside their critical section), to be
>> stable, i.e., it should be guaranteed that CPUs in that mask won't go
>> offline during the critical section. An important point here is that they
>> don't really care if such a "stable" mask is a subset of the actual
>> cpu_online_mask.
>>
>> The intent of this patch is to provide such a "stable" cpu online mask
>> for that class of atomic hotplug readers.
>>
>> Fundamental idea behind the design:
>> ---
>>
>> Simply put, have a separate mask called the stable cpu online mask; and
>> at the hotplug writer (cpu_down()), note down the CPU that is about to go
>> offline, and remove it from the stable cpu online mask. Then, feel free
>> to take that CPU offline, since the atomic hotplug readers won't see it
>> from now on. Also, don't start any new cpu_down() operations until all
>> existing atomic hotplug readers have completed (because they might still
>> be working with the old value of the stable online mask).
>>
>> Some important design requirements and considerations:
>> -
>>
>> 1. The atomic hotplug readers should ideally *never* wait for the hotplug
>>writer (cpu_down()) for *anything*. Because, these atomic hotplug readers
>>can be in very hot-paths like interrupt handling/IPI and hence, if they
>>have to wait for an ongoing cpu_down() to complete, it would pretty much
>>introduce the same performance/latency problems as stop_machine().
>>
>> 2. Any synchronization at the atomic hotplug readers side must be highly
>>scalable - avoid global locks/counters etc. Because, these paths currently
>>use the extremely fast preempt_disable(); our replacement to
>>preempt_disable() should not become ridiculously costly.
>>
>> 3. preempt_disable() was recursive. The replacement should also be recursive.
>>
>> Implementation of the design:
>>
>>
>> Atomic hotplug reader side:
>>
>> We use per-cpu counters to mark the presence of atomic hotplug readers.
>> A reader would increment its per-cpu counter and continue, without waiting
>> for anything. And no locks are used in this path. Together, these satisfy
>> all the 3 requirements mentioned above.
>>
>> The hotplug writer uses (reads) the per-cpu counters of all CPUs in order to
>> ensure that all existing atomic hotplug readers have completed. Only after
>> that, it will proceed to actually take the CPU offline.
>>
>> [ Michael: Designed the synchronization for the IPI case ]
>
> Like this:
>
> [wang...@linux.vnet.ibm.com: designed the synchronization for the IPI case]
>
>> Signed-off-by: Michael Wang
>> [ Srivatsa: Generalized it to work for all cases and wrote the changelog ]
>> Signed-off-by: Srivatsa S. Bhat
>>
>> ...
>>
>> --- a/include/linux/cpu.h
>> +++ b/include/linux/cpu.h
>> @@ -175,6 +175,8 @@ extern struct bus_type cpu_subsys;
>>
>> extern void get_online_cpus(void);
>> extern void put_online_cpus(void);
>> +extern void get_online_cpus_stable_atomic(void);
>> +extern void put_online_cpus_stable_atomic(void);
>> #define hotcpu_notifier(fn, pri)cpu_notifier(fn, pri)
>> #define register_hotcpu_notifier(nb)register_cpu_notifier(nb)
>> #define unregister_hotcpu_notifier(nb) unregister_cpu_notifier(nb)
>> @@ -198,6 +200,8 @@ static inline void cpu_hotplug_driver_unlock(void)
>>
>> #define get_online_cpus() do { } while (0)
>> #define put_online_cpus() do { } while (0)
>> +#define get_online_cpus_stable_atomic() do { } while (0)
>> +#define put_online_cpus_stable_atomic() do { } while (0)
>
> static inline C functions would be preferred if possible. Feel free to
> fix up the wrong crufty surrounding code as well ;)
>
>>
>> ...
>>
>> @@ -705,12 +707,15 @@ extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
>>
>> #define for_each_possible_cpu(cpu) for_each_cpu((cpu), cpu_possible_mask)
>> #define for_each_online_cpu(cpu) for_each_cpu((cpu), cpu_online_mask)
>> +#define for_each_online_cpu_stable(cpu)
>> \
>> +for_each_cpu((cpu), cpu_online_stable_mask)
>> #define for_each_present_cpu(cpu) for_each_cpu((cpu), cpu_present_mask)
>>
>> /* Wrappers for arch boot code to manipulate normally-constant masks */
>> void set_cpu_possible(unsigned int cpu, bool possible);
>> void set_cpu_present(unsigned int cpu, bool present);
>> void set_cpu_online(unsigned int cpu, bool online);
>> +void
[PATCH] mfd: arizona: Log if we fail to create the primary IRQ domain
This is the only thing in probe for which we don't log an error.
Signed-off-by: Mark Brown
---
drivers/mfd/arizona-irq.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 113805d..2bec5f0 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -210,6 +210,7 @@ int arizona_irq_init(struct arizona *arizona)
arizona->virq = irq_domain_add_linear(NULL, 2, _domain_ops,
arizona);
if (!arizona->virq) {
+ dev_err(arizona->dev, "Failed to add core IRQ domain\n");
ret = -EINVAL;
goto err;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: arizona: Disable control interface reporting for WM5102 and WM5110
Rather than disabling the error reporting only for earlier revisions
unconditionally disable it.
Signed-off-by: Mark Brown
---
This is a bug fix for later chip revisons.
drivers/mfd/arizona-irq.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index b1b0091..113805d 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -176,14 +176,7 @@ int arizona_irq_init(struct arizona *arizona)
aod = _aod;
irq = _irq;
- switch (arizona->rev) {
- case 0:
- case 1:
- ctrlif_error = false;
- break;
- default:
- break;
- }
+ ctrlif_error = false;
break;
#endif
#ifdef CONFIG_MFD_WM5110
@@ -191,14 +184,7 @@ int arizona_irq_init(struct arizona *arizona)
aod = _aod;
irq = _irq;
- switch (arizona->rev) {
- case 0:
- case 1:
- ctrlif_error = false;
- break;
- default:
- break;
- }
+ ctrlif_error = false;
break;
#endif
default:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dt/platform: Use cell-index for device naming if available
On 11/20/2012 8:19 AM, Grant Likely wrote: What if instead we added something like OF_ALIASES to the uevent attribute? Then userspace would have access to all the aliases for a device. Heck, even a shell script can parse the uevent attribute. There is also precedence for exporting OF data using a uevent. This is from the versatile device tree support: # cat /sys/devices/amba.0/uevent OF_NAME=amba OF_FULLNAME=/amba OF_COMPATIBLE_0=arm,amba-bus OF_COMPATIBLE_N=1 MODALIAS=of:NambaTCarm,amba-bus This sounds like a good idea. I have just sent out a new patch to do this. I followed the OF_COMPATIBLE uevent convention for listing the aliases, but I can follow another convention if someone objects. Steve -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: Output devicetree alias names in uevent
In some situations, userspace may want to resolve a
device by function and logical number (ie, "serial0")
rather than by the base address or full device path. Being
able to resolve a device by alias frees userspace from the
burden of otherwise having to maintain a mapping between
device addresses and their logical assignments on each
platform when multiple instances of the same hardware block
are present in the system.
Although the uevent device attribute contains devicetree
compatible information and the full device path, the uevent
does not list the alises that may have been defined for the
device.
Signed-off-by: Stepan Moskovchenko
---
I have followed the OF_COMPATIBLE convention for adding the
uevent variables for the alias names, but I can follow some
other convention if people feel something else is more
appropriate.
drivers/of/base.c | 25 +
drivers/of/device.c |1 +
include/linux/of_device.h |2 ++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..291f0a0 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -19,6 +19,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -1177,6 +1178,30 @@ static void of_alias_add(struct alias_prop *ap, struct
device_node *np,
}
/**
+ * of_device_uevent_aliases - Display OF alises in uevent
+ */
+void of_device_uevent_aliases(struct device_node *node,
+ struct kobj_uevent_env *env)
+{
+ struct alias_prop *app;
+ int seen = 0;
+
+ mutex_lock(_aliases_mutex);
+ list_for_each_entry(app, _lookup, link) {
+ if (node == app->np) {
+ add_uevent_var(env, "OF_ALIAS_%d=%s%d", seen, app->stem,
+ app->id);
+ seen++;
+ }
+ }
+
+ if (seen)
+ add_uevent_var(env, "OF_ALIAS_N=%d", seen);
+
+ mutex_unlock(_aliases_mutex);
+}
+
+/**
* of_alias_scan - Scan all properties of 'aliases' node
*
* The function scans all the properties of 'aliases' node and populate
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 4c74e4f..06e122d 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -153,6 +153,7 @@ void of_device_uevent(struct device *dev, struct
kobj_uevent_env *env)
seen++;
}
add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen);
+ of_device_uevent_aliases(dev->of_node, env);
}
int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 901b743..748056d 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -36,6 +36,8 @@ extern ssize_t of_device_get_modalias(struct device *dev,
char *str, ssize_t len);
extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
+extern void of_device_uevent_aliases(struct device_node *node,
+ struct kobj_uevent_env *env);
extern int of_device_uevent_modalias(struct device *dev, struct
kobj_uevent_env *env);
static inline void of_device_node_put(struct device *dev)
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: 88pm80x: add dt support
On Wed, Dec 5, 2012 at 10:23 AM, Qing Xu wrote:
> From: Qing Xu
>
> add dt support for 88pm800 and 88pm805
>
> Signed-off-by: Qing Xu
> ---
> drivers/mfd/88pm800.c | 26 +++---
> drivers/mfd/88pm805.c | 26 +++---
> drivers/mfd/88pm80x.c | 32
> include/linux/mfd/88pm80x.h |3 +++
> 4 files changed, 81 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index 3fcc8dd..20b67d7 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -506,6 +506,22 @@ static int __devinit pm800_probe(struct i2c_client
> *client,
> struct pm80x_chip *chip;
> struct pm80x_platform_data *pdata = client->dev.platform_data;
> struct pm80x_subchip *subchip;
> + struct device_node *node = client->dev.of_node;
> +
> + if (node && !pdata) {
> + /* parse DT to get platform data */
> + pdata = devm_kzalloc(>dev,
> +sizeof(struct pm80x_platform_data),
> +GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> + ret = pm80x_dt_init(node, >dev, pdata);
> + if (ret)
> + return -EINVAL;
> + } else if (!pdata) {
> + pr_info("No platform data in %s!\n", __func__);
> + return -EINVAL;
> + }
>
> ret = pm80x_init(client, id);
> if (ret) {
> @@ -540,9 +556,6 @@ static int __devinit pm800_probe(struct i2c_client
> *client,
> goto err_800_init;
> }
>
> - if (pdata->plat_config)
> - pdata->plat_config(chip, pdata);
> -
> return 0;
>
> err_800_init:
> @@ -570,11 +583,18 @@ static int __devexit pm800_remove(struct i2c_client
> *client)
> return 0;
> }
>
> +static const struct of_device_id pm800_dt_ids[] = {
> + { .compatible = "marvell,88pm800", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pm800_dt_ids);
> +
> static struct i2c_driver pm800_driver = {
> .driver = {
> .name = "88PM800",
> .owner = THIS_MODULE,
> .pm = _pm_ops,
> + .of_match_table = of_match_ptr(pm800_dt_ids),
> },
> .probe = pm800_probe,
> .remove = __devexit_p(pm800_remove),
> diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
> index 39a91bd..b0fb3ff 100644
> --- a/drivers/mfd/88pm805.c
> +++ b/drivers/mfd/88pm805.c
> @@ -239,6 +239,22 @@ static int __devinit pm805_probe(struct i2c_client
> *client,
> int ret = 0;
> struct pm80x_chip *chip;
> struct pm80x_platform_data *pdata = client->dev.platform_data;
> + struct device_node *node = client->dev.of_node;
> +
> + if (node && !pdata) {
> + /* parse DT to get platform data */
> + pdata = devm_kzalloc(>dev,
> +sizeof(struct pm80x_platform_data),
> +GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> + ret = pm80x_dt_init(node, >dev, pdata);
> + if (ret)
> + return -EINVAL;
> + } else if (!pdata) {
> + pr_info("No platform data in %s!\n", __func__);
> + return -EINVAL;
> + }
>
> ret = pm80x_init(client, id);
> if (ret) {
> @@ -254,9 +270,6 @@ static int __devinit pm805_probe(struct i2c_client
> *client,
> goto err_805_init;
> }
>
> - if (pdata->plat_config)
> - pdata->plat_config(chip, pdata);
> -
> return 0;
>
> err_805_init:
> @@ -277,11 +290,18 @@ static int __devexit pm805_remove(struct i2c_client
> *client)
> return 0;
> }
>
> +static const struct of_device_id pm805_dt_ids[] = {
> + { .compatible = "marvell,88pm805", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pm805_dt_ids);
> +
> static struct i2c_driver pm805_driver = {
> .driver = {
> .name = "88PM805",
> .owner = THIS_MODULE,
> .pm = _pm_ops,
> + .of_match_table = of_match_ptr(pm805_dt_ids),
> },
> .probe = pm805_probe,
> .remove = __devexit_p(pm805_remove),
> diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
> index 1adb355..bd59202 100644
> --- a/drivers/mfd/88pm80x.c
> +++ b/drivers/mfd/88pm80x.c
> @@ -111,6 +111,38 @@ int pm80x_deinit(struct i2c_client *client)
> }
> EXPORT_SYMBOL_GPL(pm80x_deinit);
>
> +int pm80x_dt_init(struct device_node *np,
> + struct device *dev,
> + struct pm80x_platform_data *pdata)
> +{
> + int ret;
> + ret = of_property_read_u32(np, "marvell,88pm80x-irqmode",
> +
[PATCH] mfd: 88pm80x: add dt support
From: Qing Xu
add dt support for 88pm800 and 88pm805
Signed-off-by: Qing Xu
---
drivers/mfd/88pm800.c | 26 +++---
drivers/mfd/88pm805.c | 26 +++---
drivers/mfd/88pm80x.c | 32
include/linux/mfd/88pm80x.h |3 +++
4 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 3fcc8dd..20b67d7 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -506,6 +506,22 @@ static int __devinit pm800_probe(struct i2c_client *client,
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
struct pm80x_subchip *subchip;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -540,9 +556,6 @@ static int __devinit pm800_probe(struct i2c_client *client,
goto err_800_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_800_init:
@@ -570,11 +583,18 @@ static int __devexit pm800_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm800_dt_ids[] = {
+ { .compatible = "marvell,88pm800", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm800_dt_ids);
+
static struct i2c_driver pm800_driver = {
.driver = {
.name = "88PM800",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm800_dt_ids),
},
.probe = pm800_probe,
.remove = __devexit_p(pm800_remove),
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index 39a91bd..b0fb3ff 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -239,6 +239,22 @@ static int __devinit pm805_probe(struct i2c_client *client,
int ret = 0;
struct pm80x_chip *chip;
struct pm80x_platform_data *pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
+
+ if (node && !pdata) {
+ /* parse DT to get platform data */
+ pdata = devm_kzalloc(>dev,
+sizeof(struct pm80x_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ ret = pm80x_dt_init(node, >dev, pdata);
+ if (ret)
+ return -EINVAL;
+ } else if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
ret = pm80x_init(client, id);
if (ret) {
@@ -254,9 +270,6 @@ static int __devinit pm805_probe(struct i2c_client *client,
goto err_805_init;
}
- if (pdata->plat_config)
- pdata->plat_config(chip, pdata);
-
return 0;
err_805_init:
@@ -277,11 +290,18 @@ static int __devexit pm805_remove(struct i2c_client
*client)
return 0;
}
+static const struct of_device_id pm805_dt_ids[] = {
+ { .compatible = "marvell,88pm805", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pm805_dt_ids);
+
static struct i2c_driver pm805_driver = {
.driver = {
.name = "88PM805",
.owner = THIS_MODULE,
.pm = _pm_ops,
+ .of_match_table = of_match_ptr(pm805_dt_ids),
},
.probe = pm805_probe,
.remove = __devexit_p(pm805_remove),
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..bd59202 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -111,6 +111,38 @@ int pm80x_deinit(struct i2c_client *client)
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
+int pm80x_dt_init(struct device_node *np,
+ struct device *dev,
+ struct pm80x_platform_data *pdata)
+{
+ int ret;
+ ret = of_property_read_u32(np, "marvell,88pm80x-irqmode",
+ >irq_mode);
+ if (ret) {
+ dev_err(dev, "Not found \"marvell,88pm80x-irqmode\" "
+ "property\n");
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(np, "marvell,88pm80x-poweraddr",
+ (u32*)(>power_page_addr));
+ if
[PATCH v4 2/4] input: Cypress PS/2 Trackpad psmouse driver
From: Dudley Du
Input/mouse driver for Cypress PS/2 Trackpad.
Original code contributed by Dudley Du (Cypress Semiconductor Corporation),
modified by Kamal Mostafa and Kyle Fazzari.
BugLink: http://launchpad.net/bugs/978807
Signed-off-by: Dudley Du
Signed-off-by: Kamal Mostafa
Signed-off-by: Kyle Fazzari
Signed-off-by: Mario Limonciello
Signed-off-by: Tim Gardner
Acked-by: Herton Krzesinski
---
drivers/input/mouse/cypress_ps2.c | 835 +
drivers/input/mouse/cypress_ps2.h | 219 ++
2 files changed, 1054 insertions(+)
create mode 100644 drivers/input/mouse/cypress_ps2.c
create mode 100644 drivers/input/mouse/cypress_ps2.h
diff --git a/drivers/input/mouse/cypress_ps2.c
b/drivers/input/mouse/cypress_ps2.c
new file mode 100644
index 000..fab4d18
--- /dev/null
+++ b/drivers/input/mouse/cypress_ps2.c
@@ -0,0 +1,835 @@
+/*
+ * Cypress Trackpad PS/2 mouse driver
+ *
+ * Copyright (c) 2012 Cypress Semiconductor Corporation.
+ *
+ * Author:
+ * Dudley Du
+ *
+ * Additional contributors include:
+ * Kamal Mostafa
+ * Kyle Fazzari
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cypress_ps2.h"
+
+#undef CYTP_DEBUG_VERBOSE /* define this and DEBUG for more verbose dump */
+
+#undef CYTP_RELATIVE_SUPPORT /* define to enable unused EV_REL code */
+
+#define cytp_dbg(fmt, ...) psmouse_dbg(psmouse, pr_fmt(fmt), ##__VA_ARGS__)
+
+
+static int is_cypress_key(const unsigned char *param)
+{
+ return (param[0] == CYPRESS_KEY_1) && (param[1] == CYPRESS_KEY_2);
+}
+
+static void cypress_set_packet_size(struct psmouse *psmouse, unsigned int n)
+{
+ struct cytp_data *cytp = psmouse->private;
+ psmouse->pktsize = cytp->pkt_size = n;
+}
+
+static void cypress_set_abs_rel_mode(struct cytp_data *cytp,
+ unsigned int cytp_mode_bit)
+{
+ cytp->mode = (cytp->mode & ~CYTP_BIT_ABS_REL_MASK) | cytp_mode_bit;
+}
+
+static const unsigned char cytp_rate[] = {10, 20, 40, 60, 100, 200};
+static const unsigned char cytp_resolution[] = {0x00, 0x01, 0x02, 0x03};
+
+static int cypress_ps2_sendbyte(struct psmouse *psmouse, int value)
+{
+ struct ps2dev *ps2dev = >ps2dev;
+
+ if (ps2_sendbyte(ps2dev, value & 0xff, CYTP_CMD_TIMEOUT) < 0) {
+ cytp_dbg("send command 0x%02x failed, resp 0x%02x\n",
+value & 0xff, ps2dev->nak);
+ if (ps2dev->nak == CYTP_PS2_RETRY)
+ return CYTP_PS2_RETRY;
+ else
+ return CYTP_PS2_ERROR;
+ }
+
+ cytp_dbg("send command 0x%02x success, resp 0xfa\n", value & 0xff);
+
+ return 0;
+}
+
+static int cypress_ps2_ext_cmd(struct psmouse *psmouse, unsigned short cmd,
+ unsigned char data)
+{
+ struct ps2dev *ps2dev = >ps2dev;
+ int tries = CYTP_PS2_CMD_TRIES;
+ int rc;
+
+ ps2_begin_command(ps2dev);
+
+ do {
+ /*
+* send extension command 0xE8 or 0xF3,
+* if send extension command failed,
+* try to send recovery command to make
+* trackpad device return to ready wait command state.
+* It alwasy success based on this recovery commands.
+*/
+ rc = cypress_ps2_sendbyte(psmouse, cmd & 0xff);
+ if (rc == CYTP_PS2_RETRY) {
+ rc = cypress_ps2_sendbyte(psmouse, 0x00);
+ if (rc == CYTP_PS2_RETRY)
+ rc = cypress_ps2_sendbyte(psmouse, 0x0a);
+ }
+ if (rc == CYTP_PS2_ERROR)
+ continue;
+
+ rc = cypress_ps2_sendbyte(psmouse, data);
+ if (rc == CYTP_PS2_RETRY)
+ rc = cypress_ps2_sendbyte(psmouse, data);
+ if (rc == CYTP_PS2_ERROR)
+ continue;
+ else
+ break;
+ } while (--tries > 0);
+
+ ps2_end_command(ps2dev);
+
+ return rc;
+}
+
+static int cypress_ps2_read_cmd_status(struct psmouse *psmouse,
+ unsigned char cmd,
+ unsigned char *param)
+{
+ int i;
+ int rc;
+ struct ps2dev *ps2dev = >ps2dev;
+ enum psmouse_state old_state;
+ unsigned char old_pktsize;
+
+ ps2_begin_command(>ps2dev);
+
+ old_state = psmouse->state;
+ psmouse->state = PSMOUSE_CMD_MODE;
+ psmouse->pktcnt = 0;
+ old_pktsize = psmouse->pktsize;
+ psmouse->pktsize = 3;
+ if (cmd == CYTP_CMD_READ_VITAL_STATISTICS)
+ psmouse->pktsize = 8;
+
[PATCH v4 4/4] input: Cypress PS/2 Trackpad simulated multitouch (disabled)
This feature is disabled by default; enable with CYPRESS_SIMULATED_MT.
Instead of SEMI_MT, present a full mt interface with simulated contact
positions for >=3 fingers. Enables e.g. multi-finger tap and drag for
old userspace applications which only count the contact positions.
Signed-off-by: Kamal Mostafa
---
drivers/input/mouse/cypress_ps2.c | 18 ++
drivers/input/mouse/cypress_ps2.h | 16 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/cypress_ps2.c
b/drivers/input/mouse/cypress_ps2.c
index fab4d18..088cdb8 100644
--- a/drivers/input/mouse/cypress_ps2.c
+++ b/drivers/input/mouse/cypress_ps2.c
@@ -408,7 +408,9 @@ static int cypress_set_input_params(struct input_dev *input,
if (ret < 0)
return ret;
+#if ( CYPRESS_SIMULATED_MT != 1 )
__set_bit(INPUT_PROP_SEMI_MT, input->propbit);
+#endif
if (cytp->tp_res_x && cytp->tp_res_y) {
input_abs_set_res(input, ABS_X, cytp->tp_res_x);
@@ -531,6 +533,22 @@ static int cypress_parse_packet(struct psmouse *psmouse,
((packet[5] & 0x0f) << 8) | packet[7];
if (cytp->mode & CYTP_BIT_ABS_PRESSURE)
report_data->contacts[1].z =
report_data->contacts[0].z;
+#if ( CYPRESS_SIMULATED_MT == 1 )
+ /* simulate contact positions for >2 fingers */
+ if ( report_data->contact_cnt >= 3 ) {
+ int i;
+ for ( i=1; icontact_cnt; i++ ) {
+ report_data->contacts[i].x =
+ report_data->contacts[0].x
+ + 100*(i)*((i%2)?-1:1);
+ report_data->contacts[i].y =
+ report_data->contacts[0].y;
+ if (cytp->mode & CYTP_BIT_ABS_PRESSURE)
+ report_data->contacts[i].z =
+ report_data->contacts[0].z;
+ }
+ }
+#endif
}
report_data->left = (header_byte & BTN_LEFT_BIT) ? 1 : 0;
diff --git a/drivers/input/mouse/cypress_ps2.h
b/drivers/input/mouse/cypress_ps2.h
index a74f985..c38cb6f 100644
--- a/drivers/input/mouse/cypress_ps2.h
+++ b/drivers/input/mouse/cypress_ps2.h
@@ -133,8 +133,20 @@
#define RESP_REMOTE_BIT 0x40
#define RESP_SMBUS_BIT 0x80
-#define CYTP_MAX_CONTACTS 2
-#define CYTP_MAX_MT_SLOTS 2
+/*
+ * CYPRESS_SIMULATED_MT
+ * set to 1 for simulated multitouch (up to CTYP_MAX_CONTACTS fingers)
+ * set to 0 for SEMI_MT (2 fingers only)
+ */
+#define CYPRESS_SIMULATED_MT 0
+
+#if ( CYPRESS_SIMULATED_MT == 1 )
+# define CYTP_MAX_CONTACTS 5
+# define CYTP_MAX_MT_SLOTS 16
+#else
+# define CYTP_MAX_CONTACTS 2
+# define CYTP_MAX_MT_SLOTS 2
+#endif
enum cytp_type {
CYTP_STG,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/4] input: Cypress PS/2 Trackpad link into psmouse-base
From: Dudley Du
Original code contributed by Dudley Du (Cypress Semiconductor Corporation),
modified by Kamal Mostafa.
BugLink: http://launchpad.net/bugs/978807
Signed-off-by: Dudley Du
Signed-off-by: Kamal Mostafa
Signed-off-by: Mario Limonciello
Signed-off-by: Tim Gardner
---
drivers/input/mouse/Kconfig| 10 ++
drivers/input/mouse/Makefile |1 +
drivers/input/mouse/psmouse-base.c | 32
drivers/input/mouse/psmouse.h |1 +
4 files changed, 44 insertions(+)
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index cd6268c..88954dd 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -68,6 +68,16 @@ config MOUSE_PS2_SYNAPTICS
If unsure, say Y.
+config MOUSE_PS2_CYPRESS
+ bool "Cypress PS/2 mouse protocol extension" if EXPERT
+ default y
+ depends on MOUSE_PS2
+ help
+ Say Y here if you have a Cypress PS/2 Trackpad connected to
+ your system.
+
+ If unsure, say Y.
+
config MOUSE_PS2_LIFEBOOK
bool "Fujitsu Lifebook PS/2 mouse protocol extension" if EXPERT
default y
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 46ba755..323e352 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -32,3 +32,4 @@ psmouse-$(CONFIG_MOUSE_PS2_LIFEBOOK) += lifebook.o
psmouse-$(CONFIG_MOUSE_PS2_SENTELIC) += sentelic.o
psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT) += trackpoint.o
psmouse-$(CONFIG_MOUSE_PS2_TOUCHKIT) += touchkit_ps2.o
+psmouse-$(CONFIG_MOUSE_PS2_CYPRESS)+= cypress_ps2.o
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index 22fe254..cff065f 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -34,6 +34,7 @@
#include "touchkit_ps2.h"
#include "elantech.h"
#include "sentelic.h"
+#include "cypress_ps2.h"
#define DRIVER_DESC"PS/2 mouse driver"
@@ -759,6 +760,28 @@ static int psmouse_extensions(struct psmouse *psmouse,
}
/*
+ * Try Cypress Trackpad.
+ * Must try it before Finger Sensing Pad because Finger Sensing Pad probe
+ * upsets some modules of Cypress Trackpads.
+ */
+ if (max_proto > PSMOUSE_IMEX &&
+ cypress_detect(psmouse, set_properties) == 0) {
+ if (cypress_supported()) {
+ if (cypress_init(psmouse) == 0)
+ return PSMOUSE_CYPRESS;
+
+ /*
+* Finger Sensing Pad probe upsets some modules of
+* Cypress Trackpad, must avoid Finger Sensing Pad
+* probe if Cypress Trackpad device detected.
+*/
+ return PSMOUSE_PS2;
+ }
+
+ max_proto = PSMOUSE_IMEX;
+ }
+
+/*
* Try ALPS TouchPad
*/
if (max_proto > PSMOUSE_IMEX) {
@@ -896,6 +919,15 @@ static const struct psmouse_protocol psmouse_protocols[] =
{
.alias = "thinkps",
.detect = thinking_detect,
},
+#ifdef CONFIG_MOUSE_PS2_CYPRESS
+ {
+ .type = PSMOUSE_CYPRESS,
+ .name = "CyPS/2",
+ .alias = "cypress",
+ .detect = cypress_detect,
+ .init = cypress_init,
+ },
+#endif
{
.type = PSMOUSE_GENPS,
.name = "GenPS/2",
diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h
index fe1df23..2f0b39d 100644
--- a/drivers/input/mouse/psmouse.h
+++ b/drivers/input/mouse/psmouse.h
@@ -95,6 +95,7 @@ enum psmouse_type {
PSMOUSE_ELANTECH,
PSMOUSE_FSP,
PSMOUSE_SYNAPTICS_RELATIVE,
+ PSMOUSE_CYPRESS,
PSMOUSE_AUTO/* This one should always be last */
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/4] Cypress PS/2 Trackpad driver
This driver, submitted on behalf of Cypress Semiconductor Corporation and additional contributors, provides support for the Cypress PS/2 Trackpad. This [PATCH v4] version differs from my previous submitted version[2]: Patch #1 (cmdbuf to 8 bytes) and #3 (link in driver) are unchanged. Patch #2 (main driver) changes, as recommended by Henrik Rydberg, Dmitry Torokhov, and Dudley Du: - call input_mt_report_finger_count() directly; drop INPUT_MT_POINTER. - #ifdef out all the CYTP_RELATIVE_SUPPORT code. - convert CYTP_ macros to functions. - propagate error return codes. - fixed tp_res_y typo. - list Dudley Du as the primary author of the driver. - additional misc cleanups. Patch #4 (selectable simulated multitouch instead of SEMI_MT): - this is now #ifdef-disabled by default but needed for (older?) userspace X/Unity-desktop which does not support the input_mt_report_finger_count events (e.g. BTN_TOOL_TRIPLETAP). Remaining known problems (assistance or advice appreciated): - Patch #4 (simulated multitouch) does not work after rmmod/insmod, and stops working after suspend/resume. Restarting X fixes it in both cases. SEMI_MT appears to work normally in any case (per input-events). - cypress_reconnect() doesn't actually work after suspend/resume, but psmouse re-inits the driver after _reconnect fails. Per Dudley Du, this routine does work when physically disconnecting the device though and its harmless regardless, so I am leaving it in pending further investigation. -Kamal Mostafa [0] PATCH v1: http://www.spinics.net/lists/linux-input/msg23690.html [1] PATCH v2: http://www.spinics.net/lists/linux-input/msg23718.html [2] PATCH v3: http://www.spinics.net/lists/linux-input/msg23943.html Dudley Du (2): input: Cypress PS/2 Trackpad psmouse driver input: Cypress PS/2 Trackpad link into psmouse-base Kamal Mostafa (2): input: increase struct ps2dev cmdbuf[] to 8 bytes input: Cypress PS/2 Trackpad simulated multitouch (disabled) drivers/input/mouse/Kconfig| 10 + drivers/input/mouse/Makefile |1 + drivers/input/mouse/cypress_ps2.c | 853 drivers/input/mouse/cypress_ps2.h | 231 ++ drivers/input/mouse/psmouse-base.c | 32 ++ drivers/input/mouse/psmouse.h |1 + include/linux/libps2.h |2 +- 7 files changed, 1129 insertions(+), 1 deletion(-) create mode 100644 drivers/input/mouse/cypress_ps2.c create mode 100644 drivers/input/mouse/cypress_ps2.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] input: increase struct ps2dev cmdbuf[] to 8 bytes
Cypress PS/2 Trackpad (drivers/input/mouse/cypress_ps2.c) needs
this larger cmdbuf[] to handle 8-byte packet responses.
Signed-off-by: Kamal Mostafa
---
include/linux/libps2.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/libps2.h b/include/linux/libps2.h
index 79603a6..4ad06e8 100644
--- a/include/linux/libps2.h
+++ b/include/linux/libps2.h
@@ -36,7 +36,7 @@ struct ps2dev {
wait_queue_head_t wait;
unsigned long flags;
- unsigned char cmdbuf[6];
+ unsigned char cmdbuf[8];
unsigned char cmdcnt;
unsigned char nak;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] input: Cypress PS/2 Trackpad psmouse driver
Hi Henrik-
Thanks again for your review. The forthcoming PATCH v4 includes the
majority of your change requests, except where noted below (and
considering my email "Subject: SEMI_MT vs. simulated mt")...
On Mon, 2012-12-03 at 08:45 +0100, Henrik Rydberg wrote:
> > + /*
> > +* send extension command 0xE8 or 0xF3,
> > +* if send extension command failed,
> > +* try to send recovery command to make
> > +* trackpad device return to ready wait command state.
> > +* It alwasy success based on this recovery commands.
>
> -EPARSE
I don't understand the meaning of that comment either. Perhaps the
original author Dudley Du can explain it.
> > +static int cypress_read_vital_statistics(struct psmouse *psmouse)
>
> Why do you call this statistics?
Perhaps "cypress_read_tp_metrics" would be a better name. Any thoughts
on this, Dudley?
> > +/*
> > + * reset trackpad device to standard relative mode.
> > + * This is also the defalut mode when trackpad powered on.
> > + */
> > +static void cypress_reset(struct psmouse *psmouse)
> > +{
> > + struct cytp_data *cytp = psmouse->private;
> > +
> > + psmouse_reset(psmouse);
> > +
> > + CYTP_SET_MODE_BIT(CYTP_BIT_STANDARD_REL);
> > + CYTP_SET_PACKET_SIZE(3);
> > +
> > + cytp->prev_contact_cnt = 0;
> > +}
>
> I suppose it is, but is it necessary to reset to default mode?
I left this unchanged, as I think you and Dmitry agreed.
> > +
> > +static int cypress_set_input_params(struct input_dev *input,
> > + struct cytp_data *cytp)
> > +{
> > + int ret;
> > +
> > + if (cytp->mode & CYTP_BIT_ABS_MASK) {
>
> It seems the device will always operate in this mode, so please simplify.
I #ifdef'd out the unused relative-mode code, as opposed to deleting it.
Will that be acceptable?
> > + /* Remove HSCROLL bit */
> > + if (report_data->contact_cnt == 4)
> > + header_byte &= ~(ABS_HSCROLL_BIT);
>
> Why conditionally?
Dudley, can you answer this? I left this (and all the scroll code)
unchanged.
> > +#if 0
> > + /* FIXME: cypress_reconnect() never works...
> > +* just let psmouse re-init() us for now.
> > +*/
> > + psmouse->reconnect = cypress_reconnect;
> > +#endif
>
> This needs to be removed or fixed, of course.
Per Dudley, this does work in his disconnect/reconnect scenario, so I
re-enabled it. We will continue to investigate why it fails
(harmlessly) in my suspend/resume scenario.
> > + int tp_max_abs_x; /* Max X absolution units can be reported. */
> > + int tp_max_abs_y; /* Max Y absolution units can be reported. */
>
> I do not think we are seeking absolution here. :-)
Ha! Speak for yourself, Henrik! ;-) I'm starting to feel like maybe I
should be seeking absolution here!
-Kamal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SEMI_MT vs. simulated mt (was Re: [PATCH v3 0/4] Cypress PS/2 Trackpad driver)
Hi Dmitry and Henrik- Regarding SEMI_MT vs. "simulated multitouch" . . . > > > > Patch #4 (new) reintroduces simulated multitouch for up to 5 fingers > > (#if CYPRESS_SIMULATE_MT), disabling SEMI_MT again. > > > > If that functionality (support for >2 fingers) can be acheived in some > > better way, please advise. On Sun, 2012-12-02 at 23:36 -0800, Dmitry Torokhov wrote: > You can still report true number of fingers on the pad via BTN_TOOL_*TAP > while reporting the bounding box, the same way as Synaptics, Elantech, > ALPS and Sentelic drivers are doing it. On Mon, 2012-12-03 at 08:45 +0100, Henrik Rydberg wrote: > + ret = input_mt_init_slots(input, CYTP_MAX_MT_SLOTS, > + INPUT_MT_POINTER|INPUT_MT_DROP_UNUSED|INPUT_MT_TRACK); > > Here, INPUT_MT_POINTER needs to be dropped; for semi-mt devices, the > number of fingers is propagated separately using > >input_mt_report_finger_count(dev, finger_count_as_reported_by_the_device), > > which conflicts with automatic handling of pointer logic. Well... The forthcoming PATCH v4 version now implements all that ^^ as you requested, but it appears that my desktop (X with Unity desktop in Ubuntu 12.10) does not actually respond to input_mt_report_finger_count events (e.g. BTN_TOOL_TRIPLETAP). I asked a colleague test a couple of other semi-mt touchpads (Synaptics and ALPS) and we found the same result: The desktop doesn't see >2 finger events with any of these semi-mt devices, even though 'input-events' does show that the BTN_TOOL_*TAP events are in the input stream. (Do other X desktops actually support BTN_TOOL_*TAP?) I understand that this may be "a userspace problem", but from my perspective the "simulated multitouch" patch is still necessary for >2 finger tap/drag. I have left it in my PATCH v4 set for that reason (patch 4/4; disabled by an ifdef). It can be included and left disabled, or enabled, or dropped as you see fit. -Kamal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mmc: sdhci: check voltage range only on regulators aware of voltage value
2012/12/5 Mark Brown
>
> On Tue, Dec 04, 2012 at 10:50:03PM +0800, Kevin Liu wrote:
> > 2012/12/4 Marek Szyprowski :
>
> > > + if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
> > > ret = regulator_is_supported_voltage(host->vmmc,
> > > 270,
> > > 360);
> > > if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
>
> > Good idea. But how about the regulator is disabled at this point? So I
> > suggest to change to
> > if (host->vmmc && regulator_get_voltage(host->vmmc) >= 0)
>
> I'd not expect regulator_get_voltage() to return 0 for disabled
> regulators, I'd expect it to return the voltage the regulator will have
> when enabled.
Understand.
Thanks
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v4 08/12] memory-hotplug: remove memmap of sparse-vmemmap
Hi Wu,
On 12/04/2012 08:20 PM, Jianguo Wu wrote:
(snip)
Seems that we have different ways to handle pages allocated by bootmem
or by regular allocator. Is the checking way in [PATCH 09/12] available
here ?
+/* bootmem page has reserved flag */
+if (PageReserved(page)) {
..
+}
If so, I think we can just merge these two functions.
Hmm, direct mapping table isn't allocated by bootmem allocator such as
memblock, can't be free by put_page_bootmem().
But I will try to merge these two functions.
Oh, I didn't notice this, thanks. :)
(snip)
+
+__split_large_page(kpte, address, pbase);
Is this patch going to replace [PATCH 08/12] ?
I wish to replace [PATCH 08/12], but need Congyang and Yasuaki to confirm
first:)
If so, __split_large_page() was added and exported in [PATCH 09/12],
then we should move it here, right ?
yes.
and what do you think about moving vmemmap_pud[pmd/pte]_remove() to
arch/x86/mm/init_64.c,
to be consistent with vmemmap_populate() ?
It is a good idea since pud/pmd/pte related code could be platform
dependent. And I'm also trying to move vmemmap_free() to
arch/x86/mm/init_64.c too. I want to have a common interface just
like vmemmap_populate(). :)
I will rework [PATCH 08/12] and [PATCH 09/12] soon.
I am rebasing the whole patch set now. And I think I chould finish part
of your work too. A new patch-set is coming soon, and your rework is
also welcome. :)
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] synclink fix ldisc buffer argument
于 2012年12月04日 00:03, Paul Fulghum 写道:
> On 12/2/2012 8:20 PM, Chen Gang wrote:
>> pardon (I am just learning)
>> does 65535 mean HDLC_MAX_FRAME_SIZE ?
>> why do we need info->max_frame_size >= 4096 ?
>> in drivers/tty/synclink_gt.c:
>> 3550 if (info->max_frame_size < 4096)
>> 3551 info->max_frame_size = 4096;
>> 3552 else if (info->max_frame_size > 65535)
>> 3553 info->max_frame_size = 65535;
>> 3554
>> ...
>> 3603 info->max_frame_size = 4096;
>
> The hardware can send and receive HDLC frames up to
> 64K in size. The driver defaults to 4K max frame size
> to save buffer space for the common case
> (line 3603 in alloc_dev()).
>
> The module parameter max_frame_size can override the default
> in add_device() (lines 3550-3554 are from add_device()
> range checking the module parameter)
>
thank you.
sorry for reply late (yesterday, I have an annual leave for personal things,
and not connect net).
by the way:
does it also need check the length in function rx_get_buf ?
(it seems not, but I am not quite sure, can you give a confirm ?)
4779 /*
4780 * pass receive buffer (RAW synchronous mode) to tty layer
4781 * return true if buffer available, otherwise false
4782 */
4783 static bool rx_get_buf(struct slgt_info *info)
4784 {
4785 unsigned int i = info->rbuf_current;
4786 unsigned int count;
4787
4788 if (!desc_complete(info->rbufs[i]))
4789 return false;
4790 count = desc_count(info->rbufs[i]);
4791 switch(info->params.mode) {
4792 case MGSL_MODE_MONOSYNC:
4793 case MGSL_MODE_BISYNC:
4794 case MGSL_MODE_XSYNC:
4795 /* ignore residue in byte synchronous modes */
4796 if (desc_residue(info->rbufs[i]))
4797 count--;
4798 break;
4799 }
4800 DBGDATA(info, info->rbufs[i].buf, count, "rx");
4801 DBGINFO(("rx_get_buf size=%d\n", count));
4802 if (count)
4803 ldisc_receive_buf(info->port.tty, info->rbufs[i].buf,
4804 info->flag_buf, count);
4805 free_rbufs(info, i, i);
4806 return true;
4807 }
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mmc: sdhci: check voltage range only on regulators aware of voltage value
On Tue, Dec 04, 2012 at 10:50:03PM +0800, Kevin Liu wrote:
> 2012/12/4 Marek Szyprowski :
> > + if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
> > ret = regulator_is_supported_voltage(host->vmmc, 270,
> > 360);
> > if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
> Good idea. But how about the regulator is disabled at this point? So I
> suggest to change to
> if (host->vmmc && regulator_get_voltage(host->vmmc) >= 0)
I'd not expect regulator_get_voltage() to return 0 for disabled
regulators, I'd expect it to return the voltage the regulator will have
when enabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL] More module signing fixes.
David gave me these a month ago, during my git workflow churn :( The following changes since commit df2fc246c8ee8b6067af1fa55d3bc23107457f61: Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2012-12-04 09:32:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git for you to fetch changes up to f3537f91f9be2ce5fcbaa1aa6d787ad0436daec6: ASN.1: Fix an indefinite length skip error (2012-12-05 11:27:39 +1030) David Howells (2): MODSIGN: Don't use enum-type bitfields in module signature info block ASN.1: Fix an indefinite length skip error kernel/module_signing.c | 14 +++--- lib/asn1_decoder.c |2 +- 2 files changed, 8 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] MODSIGN: Fix comparison erros in scripts/sign-file
Michal Marek writes:
> Signed-off-by: Michal Marek
> ---
> scripts/sign-file |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/sign-file b/scripts/sign-file
> index 87ca59d..974a20b 100755
> --- a/scripts/sign-file
> +++ b/scripts/sign-file
> @@ -156,12 +156,12 @@ sub asn1_extract($$@)
>
> if ($l == 0x1) {
> $len = unpack("C", substr(${$cursor->[2]}, $cursor->[0], 1));
> - } elsif ($l = 0x2) {
> + } elsif ($l == 0x2) {
> $len = unpack("n", substr(${$cursor->[2]}, $cursor->[0], 2));
> - } elsif ($l = 0x3) {
> + } elsif ($l == 0x3) {
> $len = unpack("C", substr(${$cursor->[2]}, $cursor->[0], 1)) << 16;
> $len = unpack("n", substr(${$cursor->[2]}, $cursor->[0] + 1, 2));
> - } elsif ($l = 0x4) {
> + } elsif ($l == 0x4) {
> $len = unpack("N", substr(${$cursor->[2]}, $cursor->[0], 4));
> } else {
> die $x509, ": ", $cursor->[0], ": ASN.1 element too long (", $l,
> ")\n";
This was already applied to Linus' tree as
commit 916492b1e1a186260951831c53a53d8a448dc026
Author: Chun-Yi Lee
Date: Wed Nov 21 11:26:09 2012 +
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] MODSIGN: Avoid using .incbin in C source
David Howells writes:
> Michal Marek wrote:
>
>> Using the asm .incbin statement in C sources breaks any gcc wrapper which
>> assumes that preprocessed C source is self-contained. Use a separate .S
>> file to include the siging key and certificate.
>
> I was trying to avoid that as .S files generally don't crop up in generic
> code and the format of the assembly varies with the arch. However, you don't
> seem to have anything that should cause a problem - so:
>
> Acked-by: David Howells
GLOBAL() is defined in x86 only, AFAICT.
Plus, we now have a patch from James (CC:d) to prepend
CONFIG_SYMBOL_PREFIX to these as requird.
I think this will have to be done more carefully...
Thanks,
Rusty.
From: Takashi Iwai
Using the asm .incbin statement in C sources breaks any gcc wrapper which
assumes that preprocessed C source is self-contained. Use a separate .S
file to include the siging key and certificate.
Tested-by: Michal Marek
Signed-off-by: Takashi Iwai
---
kernel/Makefile |4 ++--
kernel/modsign_certificate.S |9 +
kernel/modsign_pubkey.c |6 --
3 files changed, 11 insertions(+), 8 deletions(-)
create mode 100644 kernel/modsign_certificate.S
diff --git a/kernel/Makefile b/kernel/Makefile
index 86e3285..0bd9d43 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o
obj-$(CONFIG_PROVE_LOCKING) += spinlock.o
obj-$(CONFIG_UID16) += uid16.o
obj-$(CONFIG_MODULES) += module.o
-obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o
+obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o
modsign_certificate.o
obj-$(CONFIG_KALLSYMS) += kallsyms.o
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_KEXEC) += kexec.o
@@ -139,7 +139,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
extra_certificates:
touch $@
-kernel/modsign_pubkey.o: signing_key.x509 extra_certificates
+kernel/modsign_certificate.o: signing_key.x509 extra_certificates
###
#
diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
new file mode 100644
index 000..6bde029
--- /dev/null
+++ b/kernel/modsign_certificate.S
@@ -0,0 +1,9 @@
+#include
+
+ .section ".init.data","aw"
+
+GLOBAL(modsign_certificate_list)
+ .incbin "signing_key.x509"
+ .incbin "extra_certificates"
+END(modsign_certificate_list)
+GLOBAL(modsign_certificate_list_end)
diff --git a/kernel/modsign_pubkey.c b/kernel/modsign_pubkey.c
index 4646eb2..045504f 100644
--- a/kernel/modsign_pubkey.c
+++ b/kernel/modsign_pubkey.c
@@ -20,12 +20,6 @@ struct key *modsign_keyring;
extern __initdata const u8 modsign_certificate_list[];
extern __initdata const u8 modsign_certificate_list_end[];
-asm(".section .init.data,\"aw\"\n"
-"modsign_certificate_list:\n"
-".incbin \"signing_key.x509\"\n"
-".incbin \"extra_certificates\"\n"
-"modsign_certificate_list_end:"
-);
/*
* We need to make sure ccache doesn't cache the .o file as it doesn't notice
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
On Thu, Nov 22, 2012 at 2:26 AM, Doug Anderson wrote:
> The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
> present" adds support for automatically picking the bus number based
> on the alias ID. Remove the now unnecessary code from i2c-pxa that
> did the same thing.
>
> Signed-off-by: Doug Anderson
> ---
> drivers/i2c/busses/i2c-pxa.c |8 +---
> 1 files changed, 1 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index 1034d93..8ee9fa0 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1053,16 +1053,10 @@ static int i2c_pxa_probe_dt(struct platform_device
> *pdev, struct pxa_i2c *i2c,
> struct device_node *np = pdev->dev.of_node;
> const struct of_device_id *of_id =
> of_match_device(i2c_pxa_dt_ids, >dev);
> - int ret;
>
> if (!of_id)
> return 1;
> - ret = of_alias_get_id(np, "i2c");
> - if (ret < 0) {
> - dev_err(>dev, "failed to get alias id, errno %d\n",
> ret);
> - return ret;
> - }
> - pdev->id = ret;
> + pdev->id = -1;
> if (of_get_property(np, "mrvl,i2c-polling", NULL))
> i2c->use_pio = 1;
> if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> --
> 1.7.7.3
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
On Thu, Nov 22, 2012 at 2:26 AM, Doug Anderson wrote:
> This allows you to get the equivalent functionality of
> i2c_add_numbered_adapter() with all data in the device tree and no
> special case code in your driver. This is a common device tree
> technique.
>
> For quick reference, the FDT syntax for using an alias to provide an
> ID looks like:
> aliases {
> i2c0 = _0;
> i2c1 = _1;
> };
>
> Signed-off-by: Doug Anderson
> CC: Mark Brown
>
> ---
> drivers/i2c/i2c-core.c | 105
> +++-
> 1 files changed, 77 insertions(+), 28 deletions(-)
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v2 PATCH 5/8] watchdog/at91sam9_wdt: Remove the __initdata of at91wdt_wdd
For this variable will be used in the timer handler.
Signed-off-by: Wenyou Yang
Cc: w...@iguana.be
Cc: linux-watch...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/watchdog/at91sam9_wdt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index f1e21dd..5afd3fb 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -201,7 +201,7 @@ static struct watchdog_ops at91wdt_ops = {
.ping = at91wdt_ping,
};
-static struct watchdog_device at91wdt_wdd __initdata = {
+static struct watchdog_device at91wdt_wdd = {
.timeout = WDT_HEARTBEAT,
.min_timeout = MIN_HEARTBEAT,
.max_timeout = MAX_HEARTBEAT,
--
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/
[v2 PATCH 6/8] watchdog/at91sam9_wdt: Use module_platform_driver()
Using module_platform_driver() replaces module_init() and module_exit()
and makes the code simpler.
Signed-off-by: Wenyou Yang
Cc: w...@iguana.be
Cc: linux-watch...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/watchdog/at91sam9_wdt.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index 5afd3fb..a7c0881 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -278,6 +278,7 @@ MODULE_DEVICE_TABLE(of, at91_wdt_dt_ids);
#endif
static struct platform_driver at91wdt_driver = {
+ .probe = at91wdt_probe,
.remove = __exit_p(at91wdt_remove),
.driver = {
.name = "at91_wdt",
@@ -286,18 +287,7 @@ static struct platform_driver at91wdt_driver = {
},
};
-static int __init at91sam_wdt_init(void)
-{
- return platform_driver_probe(_driver, at91wdt_probe);
-}
-
-static void __exit at91sam_wdt_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-
-module_init(at91sam_wdt_init);
-module_exit(at91sam_wdt_exit);
+module_platform_driver(at91wdt_driver);
MODULE_AUTHOR("Renaud CERRATO ");
MODULE_DESCRIPTION("Watchdog driver for Atmel AT91SAM9x processors");
--
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/
[v2 PATCH 2/8] watchdog/at91sam9_wdt: Convert to use the watchdog framework
According to the kernel document: convert_drivers_to_kernel_api.txt,
remove the file_operations struct, miscdevice, and obsolete includes
Since the at91sam watchdog inherent characteristics, add the watchdog
operations: at91wdt_start, at91wdt_stop and at91wdt_ping.
Signed-off-by: Wenyou Yang
Cc: w...@iguana.be
Cc: linux-watch...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/watchdog/at91sam9_wdt.c | 203 +++
1 file changed, 75 insertions(+), 128 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index f10a897..92467d4 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -13,16 +13,17 @@
* The Watchdog Timer Mode Register can be only written to once. If the
* timeout need to be set from Linux, be sure that the bootstrap or the
* bootloader doesn't write to this register.
+ * The Watchdog Timer default is running with maximum counter value
+ * (WDV=0xfff) at reset, i.e., at power-up. It MUST be either disabled
+ * or be reprogrammed within the maxinum margin(16s).
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
-#include
#include
#include
#include
-#include
#include
#include
#include
@@ -31,7 +32,6 @@
#include
#include
#include
-#include
#include
#include "at91sam9_wdt.h"
@@ -65,8 +65,6 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
-static void at91_ping(unsigned long data);
-
struct at91wdt_drvdata {
void __iomem*phybase;
boolis_enable; /* indicate if the watchdog is eabled */
@@ -88,6 +86,11 @@ static inline void wdt_write(struct at91wdt_drvdata
*driver_data,
writel_relaxed((val), driver_data->phybase + field);
}
+static inline bool watchdog_is_open(struct watchdog_device *wddev)
+{
+ return test_bit(WDOG_DEV_OPEN, >status);
+}
+
/*
* Reload the watchdog timer. (ie, pat the watchdog)
*/
@@ -99,7 +102,7 @@ static inline void at91_wdt_reset(struct at91wdt_drvdata
*driver_data)
/*
* Timer tick
*/
-static void at91_ping(unsigned long data)
+static void at91wdt_timer_tick(unsigned long data)
{
struct watchdog_device *wddev = (struct watchdog_device *)data;
struct at91wdt_drvdata *driver_data = watchdog_get_drvdata(wddev);
@@ -107,45 +110,30 @@ static void at91_ping(unsigned long data)
if (time_before(jiffies, driver_data->next_heartbeat)) {
at91_wdt_reset(driver_data);
mod_timer(_data->timer, jiffies + WDT_TIMEOUT);
+
+ if (!watchdog_is_open(wddev))
+ driver_data->next_heartbeat = jiffies
+ + wddev->timeout * HZ;
} else
pr_crit("I will reset your machine !\n");
}
-/*
- * Watchdog device is opened, and watchdog starts running.
- */
-static int at91_wdt_open(struct inode *inode, struct file *file)
-{
- driver_data->next_heartbeat = jiffies + heartbeat * HZ;
- mod_timer(_data->timer, jiffies + WDT_TIMEOUT);
-
- return nonseekable_open(inode, file);
-}
-
-/*
- * Close the watchdog device.
- */
-static int at91_wdt_close(struct inode *inode, struct file *file)
-{
- del_timer(_data->timer);
-
- return 0;
-}
-
-/*
- * Set the watchdog time interval in 1/256Hz (write-once)
- * Counter is 12 bit.
- */
-static int at91_wdt_settimeout(unsigned int timeout)
+static int at91wdt_enable(struct watchdog_device *wddev, unsigned int timeout)
{
+ struct at91wdt_drvdata *driver_data = watchdog_get_drvdata(wddev);
unsigned int reg;
- unsigned int mr;
- /* Check if disabled */
- mr = wdt_read(AT91_WDT_MR);
- if (mr & AT91_WDT_WDDIS) {
- pr_err("sorry, watchdog is disabled\n");
- return -EIO;
+ /*
+* Check if the watchdog is disabled,
+* if disabled, the reason is the bootstrap or the bootloader has
+* written the Watchdog Timer Mode Register to disable the
+* watchdog timer
+*/
+ reg = wdt_read(driver_data, AT91_WDT_MR);
+ if (reg & AT91_WDT_WDDIS) {
+ driver_data->is_enable = false;
+ pr_info("sorry, watchdog is disabled\n");
+ return -1;
}
/*
@@ -159,7 +147,9 @@ static int at91_wdt_settimeout(unsigned int timeout)
| AT91_WDT_WDDBGHLT /* disabled in debug mode */
| AT91_WDT_WDD /* restart at any time */
| (timeout & AT91_WDT_WDV); /* timer value */
- wdt_write(AT91_WDT_MR, reg);
+ wdt_write(driver_data, AT91_WDT_MR, reg);
+
+ driver_data->is_enable = true;
return 0;
}
@@ -170,99 +160,61 @@ static const struct watchdog_info at91_wdt_info = {
[v2 PATCH 1/8] watchdog/at91sam9_wdt: Remove at91wdt_private and add at91wdt_drvdata struct
Remove the global variable at91wdt_private, add the struct at91wdt_drvdata
as a substitute, and set it as the driver data of the at91wdt_wdd.
Signed-off-by: Wenyou Yang
Cc: w...@iguana.be
Cc: linux-watch...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/watchdog/at91sam9_wdt.c | 88 +--
1 file changed, 47 insertions(+), 41 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index d864dc4..f10a897 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -38,11 +38,6 @@
#define DRV_NAME "AT91SAM9 Watchdog"
-#define wdt_read(field) \
- __raw_readl(at91wdt_private.base + field)
-#define wdt_write(field, val) \
- __raw_writel((val), at91wdt_private.base + field)
-
/* AT91SAM9 watchdog runs a 12bit counter @ 256Hz,
* use this to convert a watchdog
* value from/to milliseconds.
@@ -72,23 +67,33 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once
started "
static void at91_ping(unsigned long data);
-static struct {
- void __iomem *base;
- unsigned long next_heartbeat; /* the next_heartbeat for the timer */
- unsigned long open;
- char expect_close;
- struct timer_list timer;/* The timer that pings the watchdog */
-} at91wdt_private;
+struct at91wdt_drvdata {
+ void __iomem*phybase;
+ boolis_enable; /* indicate if the watchdog is eabled */
+ unsigned long next_heartbeat; /* the next_heartbeat for the timer */
+ struct timer_list timer; /* The timer that pings the watchdog */
+};
/* . */
+static inline unsigned int wdt_read(struct at91wdt_drvdata *driver_data,
+ unsigned int field)
+{
+ return readl_relaxed(driver_data->phybase + field);
+}
+
+static inline void wdt_write(struct at91wdt_drvdata *driver_data,
+ unsigned int field, unsigned int val)
+{
+ writel_relaxed((val), driver_data->phybase + field);
+}
/*
* Reload the watchdog timer. (ie, pat the watchdog)
*/
-static inline void at91_wdt_reset(void)
+static inline void at91_wdt_reset(struct at91wdt_drvdata *driver_data)
{
- wdt_write(AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
+ wdt_write(driver_data, AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
}
/*
@@ -96,10 +101,12 @@ static inline void at91_wdt_reset(void)
*/
static void at91_ping(unsigned long data)
{
- if (time_before(jiffies, at91wdt_private.next_heartbeat) ||
- (!nowayout && !at91wdt_private.open)) {
- at91_wdt_reset();
- mod_timer(_private.timer, jiffies + WDT_TIMEOUT);
+ struct watchdog_device *wddev = (struct watchdog_device *)data;
+ struct at91wdt_drvdata *driver_data = watchdog_get_drvdata(wddev);
+
+ if (time_before(jiffies, driver_data->next_heartbeat)) {
+ at91_wdt_reset(driver_data);
+ mod_timer(_data->timer, jiffies + WDT_TIMEOUT);
} else
pr_crit("I will reset your machine !\n");
}
@@ -109,11 +116,8 @@ static void at91_ping(unsigned long data)
*/
static int at91_wdt_open(struct inode *inode, struct file *file)
{
- if (test_and_set_bit(0, _private.open))
- return -EBUSY;
-
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
- mod_timer(_private.timer, jiffies + WDT_TIMEOUT);
+ driver_data->next_heartbeat = jiffies + heartbeat * HZ;
+ mod_timer(_data->timer, jiffies + WDT_TIMEOUT);
return nonseekable_open(inode, file);
}
@@ -123,13 +127,8 @@ static int at91_wdt_open(struct inode *inode, struct file
*file)
*/
static int at91_wdt_close(struct inode *inode, struct file *file)
{
- clear_bit(0, _private.open);
+ del_timer(_data->timer);
- /* stop internal ping */
- if (!at91wdt_private.expect_close)
- del_timer(_private.timer);
-
- at91wdt_private.expect_close = 0;
return 0;
}
@@ -191,7 +190,7 @@ static long at91_wdt_ioctl(struct file *file,
return put_user(0, p);
case WDIOC_KEEPALIVE:
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
+ driver_data->next_heartbeat = jiffies + heartbeat * HZ;
return 0;
case WDIOC_SETTIMEOUT:
@@ -199,7 +198,7 @@ static long at91_wdt_ioctl(struct file *file,
return -EFAULT;
heartbeat = new_value;
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
+ driver_data->next_heartbeat = jiffies + heartbeat * HZ;
return put_user(new_value, p); /* return current value */
@@ -222,20 +221,16 @@ static ssize_t at91_wdt_write(struct file *file, const
char *data, size_t len,
if (!nowayout) {
[v2 PATCH 4/8] watchdog/at91sam9_wdt: Add nowayout helpers to Watchdog Timer Driver Kernel API
Signed-off-by: Wenyou Yang Cc: w...@iguana.be Cc: linux-watch...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/watchdog/at91sam9_wdt.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c index 4dc6d61..f1e21dd 100644 --- a/drivers/watchdog/at91sam9_wdt.c +++ b/drivers/watchdog/at91sam9_wdt.c @@ -240,6 +240,8 @@ static int __init at91wdt_probe(struct platform_device *pdev) return ret; } + watchdog_set_nowayout(_wdd, nowayout); + watchdog_init_timeout(_wdd, heartbeat, pdev->dev.of_node); ret = at91wdt_enable(_wdd, ms_to_ticks(WDT_HW_TIMEOUT * 1000)); -- 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/
[v2 PATCH 7/8] ARM: dts: add the watchdog nodes for at91sam9x5 and at91sam9n12 SoC
Signed-off-by: Wenyou Yang
Cc: li...@arm.linux.org.uk
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/at91sam9n12.dtsi |6 ++
arch/arm/boot/dts/at91sam9x5.dtsi |6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 82508d6..4c3b411 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -202,6 +202,12 @@
#size-cells = <0>;
status = "disabled";
};
+
+ watchdog@fe40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfe40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand@4000 {
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi
b/arch/arm/boot/dts/at91sam9x5.dtsi
index 03fc136..e8e7afe 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -263,6 +263,12 @@
trigger-value = <0x6>;
};
};
+
+ watchdog@fe40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfe40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand@4000 {
--
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/
[v2 PATCH 8/8] ARM: dts: add the watchdog nodes for at91sam9g25ek boards
Tested on the at91sam9g25ek boards
Signed-off-by: Wenyou Yang
Cc: li...@arm.linux.org.uk
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/at91sam9g25ek.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g25ek.dts
b/arch/arm/boot/dts/at91sam9g25ek.dts
index 877c08f..2f03edc 100644
--- a/arch/arm/boot/dts/at91sam9g25ek.dts
+++ b/arch/arm/boot/dts/at91sam9g25ek.dts
@@ -44,6 +44,10 @@
i2c2: i2c@f8018000 {
status = "okay";
};
+
+ watchdog@fe40 {
+ status = "okay";
+ };
};
usb0: ohci@0060 {
--
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/
[v2 PATCH 3/8] watchdog/at91sam9_wdt: Adjust the options of watchdog_info
Since the Watchdog Timer Mode Register can be only written only once,
so the watchdog_info shall not support WDIOF_SETTIMEOUT
and WDIOF_MAGICCLOSE options, remove them.
Signed-off-by: Wenyou Yang
Cc: w...@iguana.be
Cc: linux-watch...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/watchdog/at91sam9_wdt.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index 92467d4..4dc6d61 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -156,8 +156,7 @@ static int at91wdt_enable(struct watchdog_device *wddev,
unsigned int timeout)
static const struct watchdog_info at91_wdt_info = {
.identity = DRV_NAME,
- .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
- WDIOF_MAGICCLOSE,
+ .options= WDIOF_KEEPALIVEPING,
};
static int at91wdt_start(struct watchdog_device *wddev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
>The following should print the traces when we hand over ENOMEM to the >caller. It should catch all charge paths (migration is not covered but >that one is not important here). If we don't see any traces from here >and there is still global OOM striking then there must be something else >to trigger this. >Could you test this with the patch which aims at fixing your deadlock, >please? I realise that this is a production environment but I do not see >anything relevant in the code. Michal, i think/hope this is what you wanted: http://www.watchdog.sk/lkml/oom_mysqld2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] synclink fix ldisc buffer argument
于 2012年12月04日 01:13, Paul Fulghum 写道: > Fix call to line discipline receive_buf by synclink drivers. > Dummy flag buffer argument is ignored by N_HDLC line discipline but might > be of insufficient size if accessed by a different line discipline > selected by mistake. flag buffer allocation now matches max size of data > buffer. Unused char_buf buffers are removed. > > Signed-off-by: Paul Fulghum > thank you very much. might we use macro instead of hard code number ? (such as 4096, 65535). it is only an idea, not means need regression. thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8712: avoid a useless call to memset().
In r8711_wx_get_wap(), make sure we do not call memcpy() on a memory area that
has just been zeroed by a call to memset().
Signed-off-by: Cyril Roelandt
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 3a64790..2c73319 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1131,10 +1131,11 @@ static int r8711_wx_get_wap(struct net_device *dev,
struct ndis_wlan_bssid_ex *pcur_bss = >cur_network.network;
wrqu->ap_addr.sa_family = ARPHRD_ETHER;
- memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);
if (check_fwstate(pmlmepriv, _FW_LINKED |
WIFI_ADHOC_MASTER_STATE|WIFI_AP_STATE)) {
memcpy(wrqu->ap_addr.sa_data, pcur_bss->MacAddress, ETH_ALEN);
+ } else {
+ memset(wrqu->ap_addr.sa_data, 0, ETH_ALEN);
}
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
On Wednesday, December 05, 2012 7:58 AM, Andrew Morton wrote
> On Tue, 04 Dec 2012 14:28:15 +0900
> Jingoo Han wrote:
>
> > From: Marko Katic
> >
> > Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
> > triggers WARN_ON message:
>
> Well, I queued it up.
>
> > ...
> >
> > --- a/drivers/video/backlight/corgi_lcd.c
> > +++ b/drivers/video/backlight/corgi_lcd.c
> > @@ -408,11 +408,20 @@ static int corgi_bl_set_intensity(struct corgi_lcd
> > *lcd, int intensity)
> > /* Bit 5 via GPIO_BACKLIGHT_CONT */
> > cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
> >
> > - if (gpio_is_valid(lcd->gpio_backlight_cont))
> > - gpio_set_value(lcd->gpio_backlight_cont, cont);
> > + if (gpio_is_valid(lcd->gpio_backlight_cont)) {
> > + if (gpio_cansleep(lcd->gpio_backlight_cont))
> > + gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
> > + else
> > + gpio_set_value(lcd->gpio_backlight_cont, cont);
> > + }
>
> But this looks utterly daft. Grant, these two things are the same - do
> we need both of them?
Hi Andrew,
There is another difference, except for warning message.
There is might_sleep_if(extra_checks) in gpio_set_value_cansleep().
Also, I saw the Documentation/gpio.txt as below:
172 /* GPIO OUTPUT */
173 void gpio_set_value(unsigned gpio, int value);
...
213 /* GPIO OUTPUT, might sleep */
214 void gpio_set_value_cansleep(unsigned gpio, int value);
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] sta2x11_vip: convert to videobuf2 and control framework
On Tuesday 04 December 2012 14:15:15 Mauro Carvalho Chehab wrote:
> Em 24-09-2012 07:58, Federico Vaga escreveu:
> > This patch re-write the driver and use the videobuf2
> > interface instead of the old videobuf. Moreover, it uses also
> > the control framework which allows the driver to inherit
> > controls from its subdevice (ADV7180)
> >
> > Signed-off-by: Federico Vaga
> > Acked-by: Giancarlo Asnaghi
> >
> > [..]
> >
> > /*
> >
> >* This is the driver for the STA2x11 Video Input Port.
> >*
> >
> > + * Copyright (C) 2012 ST Microelectronics
> >
> >* Copyright (C) 2010 WindRiver Systems, Inc.
> >*
> >* This program is free software; you can redistribute it and/or modify
> >it
> >
> > @@ -19,36 +20,30 @@
> >
> >* The full GNU General Public License is included in this distribution
> >in
> >* the file called "COPYING".
> >*
> >
> > - * Author: Andreas Kies
> > - * Vlad Lungu
>
> Why are you dropping those authorship data?
>
> Ok, it is clear to me that most of the code there got rewritten, and,
> while IANAL, I think they still have some copyrights on it.
>
> So, if you're willing to do that, you need to get authors ack
> on such patch.
I re-write the driver, and also the first version of the driver has many
modification made by me, many bug fix, style review, remove useless code.
The first time I didn't add myself as author because the logic of the driver
did not change. This time, plus the old change I think there is nothing of the
original driver because I rewrite it from the hardware manual. Practically, It
is a new driver for the same device.
Anyway I will try to contact the original authors for the acked-by.
> > MODULE_DESCRIPTION("STA2X11 Video Input Port driver");
> >
> > -MODULE_AUTHOR("Wind River");
>
> Same note applies here: we need Wind River's ack on that to drop it.
I will try also for this. But I think that this is not a windriver driver
because I re-wrote it from the hardware manual. I used the old driver because
I thought that it was better than propose a patch that remove the old driver
and add my driver.
I did not remove the 2010 Copyright from windriver, because they did the job,
but this work was paid by ST (copyright 2012) and made completely by me.
Is my thinking wrong?
Just a question for the future so I avoid to redo the same error. If I re-
wrote most of a driver I cannot change the authorship automatically without
the acked-by of the previous author. If I ask to the previous author and he
does not give me the acked-by (or he is unreachable, he change email address),
then the driver is written by me but the author is someone else? Right? So, it
is better if I propose a patch which remove a driver and a patch which add my
driver?
Thank you
--
Federico Vaga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
From: Marko Katic
Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
triggers WARN_ON message:
WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4()
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r6:c0158fc8 r5:0009 r4: r3:c03d4f70
[] (dump_stack+0x0/0x1c) from []
(warn_slowpath_common+0x54/0x6c)
[] (warn_slowpath_common+0x0/0x6c) from []
(warn_slowpath_null+0x24/0x2c)
r8:c38d5c00 r7:c03f82c0 r6: r5:00d0 r4:c384e4fc
r3:0009
[] (warn_slowpath_null+0x0/0x2c) from []
(__gpio_set_value+0x38/0xa4)
[] (__gpio_set_value+0x0/0xa4) from []
(corgi_bl_set_intensity+0x44/0x74)
r7:c3933418 r6:c3933400 r5:c392cdf0 r4:002f
[] (corgi_bl_set_intensity+0x0/0x74) from []
(corgi_bl_update_status+0x5c/0x64)
r5:c03d31f0 r4:c3933400
[] (corgi_bl_update_status+0x0/0x64) from []
(corgi_lcd_probe+0x1a8/0x258)
r4:c392cdf0 r3:c0169bc0
[] (corgi_lcd_probe+0x0/0x258) from []
(spi_drv_probe+0x20/0x24)
r8:0052 r7:c0192d9c r6:c03da6e8 r5:c38d5c34 r4:c38d5c00
[] (spi_drv_probe+0x0/0x24) from []
(driver_probe_device+0xb0/0x208)
[] (driver_probe_device+0x0/0x208) from []
(__driver_attach+0x70/0x94)
r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 r3:
[] (__driver_attach+0x0/0x94) from []
(bus_for_each_dev+0x54/0x90)
r6:c03da6e8 r5:c3827e80 r4: r3:
[] (bus_for_each_dev+0x0/0x90) from []
(driver_attach+0x20/0x28)
r7: r6:c03e29ec r5:c3932980 r4:c03da6e8
[] (driver_attach+0x0/0x28) from []
(bus_add_driver+0xd4/0x22c)
[] (bus_add_driver+0x0/0x22c) from []
(driver_register+0xa4/0x134)
r8:0052 r7:c03ea900 r6:c03c32ac r5:c03bdfc8 r4:c03da6e8
[] (driver_register+0x0/0x134) from []
(spi_register_driver+0x4c/0x60)
[] (spi_register_driver+0x0/0x60) from []
(corgi_lcd_driver_init+0x14/0x1c)
[] (corgi_lcd_driver_init+0x0/0x1c) from []
(do_one_initcall+0x9c/0x174)
[] (do_one_initcall+0x0/0x174) from []
(kernel_init+0xf4/0x2a8)
[] (kernel_init+0x0/0x2a8) from [] (ret_from_fork+0x14/0x24)
---[ end trace a863a63f242ee38c ]---
Akita machines have backlight controls hooked to a gpio expander chip,
max7310 using i2c transfers which can sleep.
In this case, pca953x_gpio_set_value() can be called to control
gpio, and pca953x_setup_gpio() sets can_sleep flag. Therefore,
gpio_set_value_cansleep() should be used in order to avoid WARN_ON on
akita machines.
Akita is the only exception in this case since other users of corgi_lcd
access backlight gpio controls through a different gpio expander
which does not set the can_sleep flag.
[jg1@samsung.com: used gpio_cansleep()]
Signed-off-by: Marko Katic
Signed-off-by: Jingoo Han
---
Change since v3:
- remove redundant wording from commit message
Change since v2:
- use gpio_cansleep()
drivers/video/backlight/corgi_lcd.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index e2e1b62..e5168f4 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -408,11 +408,20 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd,
int intensity)
/* Bit 5 via GPIO_BACKLIGHT_CONT */
cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
- if (gpio_is_valid(lcd->gpio_backlight_cont))
- gpio_set_value(lcd->gpio_backlight_cont, cont);
+ if (gpio_is_valid(lcd->gpio_backlight_cont)) {
+ if (gpio_cansleep(lcd->gpio_backlight_cont))
+ gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
+ else
+ gpio_set_value(lcd->gpio_backlight_cont, cont);
+ }
- if (gpio_is_valid(lcd->gpio_backlight_on))
- gpio_set_value(lcd->gpio_backlight_on, intensity);
+ if (gpio_is_valid(lcd->gpio_backlight_on)) {
+ if (gpio_cansleep(lcd->gpio_backlight_on))
+ gpio_set_value_cansleep(lcd->gpio_backlight_on,
+ intensity);
+ else
+ gpio_set_value(lcd->gpio_backlight_on, intensity);
+ }
if (lcd->kick_battery)
lcd->kick_battery();
--
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 20/52] mm, numa: Implement migrate-on-fault lazy NUMA strategy for regular and THP pages
Commit "mm, numa: Implement migrate-on-fault lazy NUMA strategy for
regular and THP pages" breaks the build because HPAGE_PMD_SHIFT and
HPAGE_PMD_MASK defined to explode without CONFIG_TRANSPARENT_HUGEPAGE:
mm/migrate.c: In function 'migrate_misplaced_transhuge_page_put':
mm/migrate.c:1549: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
mm/migrate.c:1564: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
mm/migrate.c:1566: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
mm/migrate.c:1573: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
mm/migrate.c:1606: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
mm/migrate.c:1648: error: call to '__build_bug_failed' declared with attribute
error: BUILD_BUG failed
CONFIG_NUMA_BALANCING allows compilation without enabling transparent
hugepages, so define the dummy function for such a configuration and only
define migrate_misplaced_transhuge_page_put() when transparent hugepages
are enabled.
Signed-off-by: David Rientjes
---
include/linux/migrate.h | 18 +++---
mm/migrate.c|3 +++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -78,12 +78,6 @@ static inline int migrate_huge_page_move_mapping(struct
address_space *mapping,
#ifdef CONFIG_NUMA_BALANCING
extern bool migrate_balanced_pgdat(struct pglist_data *pgdat, int
nr_migrate_pages);
extern int migrate_misplaced_page_put(struct page *page, int node);
-extern int migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
- struct vm_area_struct *vma,
- pmd_t *pmd, pmd_t entry,
- unsigned long address,
- struct page *page, int node);
-
#else
static inline bool migrate_balanced_pgdat(struct pglist_data *pgdat, int
nr_migrate_pages)
{
@@ -93,6 +87,16 @@ static inline int migrate_misplaced_page_put(struct page
*page, int node)
{
return -EAGAIN; /* can't migrate now */
}
+#endif /* CONFIG_NUMA_BALANCING */
+
+#if defined(CONFIG_NUMA_BALANCING) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
+extern int migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ pmd_t *pmd, pmd_t entry,
+ unsigned long address,
+ struct page *page, int node);
+
+#else
static inline int migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
struct vm_area_struct *vma,
pmd_t *pmd, pmd_t entry,
@@ -101,6 +105,6 @@ static inline int
migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
{
return -EAGAIN;
}
-#endif /* CONFIG_NUMA_BALANCING */
+#endif /* CONFIG_NUMA_BALANCING && CONFIG_TRANSPARENT_HUGEPAGE */
#endif /* _LINUX_MIGRATE_H */
diff --git a/mm/migrate.c b/mm/migrate.c
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1540,6 +1540,7 @@ out:
return isolated;
}
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
int migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
struct vm_area_struct *vma,
pmd_t *pmd, pmd_t entry,
@@ -1653,6 +1654,8 @@ out_dropref:
out_keep_locked:
return 0;
}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+
#endif /* CONFIG_NUMA_BALANCING */
#endif /* CONFIG_NUMA */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ACPI / PM: Export ACPI power states of devices via sysfs
Hi All, In some situations it is very useful to know the current ACPI power states of devices. For this reason, the following series of patches makes it possible to retrieve that information via sysfs. Patches [1-2/3] are trivial function renames, patch [3/3] is the real thing. The series is on top of the master branch of linux-pm.git. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] ACPI / PM: Common string representations of device power states
From: Rafael J. Wysocki
The function returning string representations of ACPI device power
states, state_string((), is now static, because it is only used
internally in drivers/acpi/bus.c. However, it will be used outside
of that file going forward, so rename it to
acpi_power_state_string(), add a kerneldoc comment to it and add its
header to acpi_bus.h.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/bus.c | 18 --
include/acpi/acpi_bus.h |1 +
2 files changed, 13 insertions(+), 6 deletions(-)
Index: linux/drivers/acpi/bus.c
===
--- linux.orig/drivers/acpi/bus.c
+++ linux/drivers/acpi/bus.c
@@ -182,7 +182,11 @@ EXPORT_SYMBOL(acpi_bus_get_private_data)
Power Management
--
*/
-static const char *state_string(int state)
+/**
+ * acpi_power_state_string - String representation of ACPI device power state.
+ * @state: ACPI device power state to return the string representation of.
+ */
+const char *acpi_power_state_string(int state)
{
switch (state) {
case ACPI_STATE_D0:
@@ -260,7 +264,7 @@ int acpi_device_get_power(struct acpi_de
out:
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] power state is %s\n",
- device->pnp.bus_id, state_string(*state)));
+ device->pnp.bus_id, acpi_power_state_string(*state)));
return 0;
}
@@ -287,13 +291,13 @@ int acpi_device_set_power(struct acpi_de
if (state == device->power.state) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device is already at %s\n",
- state_string(state)));
+ acpi_power_state_string(state)));
return 0;
}
if (!device->power.states[state].flags.valid) {
printk(KERN_WARNING PREFIX "Device does not support %s\n",
- state_string(state));
+ acpi_power_state_string(state));
return -ENODEV;
}
if (device->parent && (state < device->parent->power.state)) {
@@ -354,12 +358,14 @@ int acpi_device_set_power(struct acpi_de
if (result)
printk(KERN_WARNING PREFIX
"Device [%s] failed to transition to %s\n",
- device->pnp.bus_id, state_string(state));
+ device->pnp.bus_id,
+ acpi_power_state_string(state));
else {
device->power.state = state;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Device [%s] transitioned to %s\n",
- device->pnp.bus_id, state_string(state)));
+ device->pnp.bus_id,
+ acpi_power_state_string(state)));
}
return result;
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -340,6 +340,7 @@ acpi_status acpi_bus_get_status_handle(a
unsigned long long *sta);
int acpi_bus_get_status(struct acpi_device *device);
int acpi_bus_set_power(acpi_handle handle, int state);
+const char *acpi_power_state_string(int state);
int acpi_device_get_power(struct acpi_device *device, int *state);
int acpi_device_set_power(struct acpi_device *device, int state);
int acpi_bus_update_power(acpi_handle handle, int *state_p);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] ACPI / PM: Export power states of ACPI devices via sysfs
From: Rafael J. Wysocki
Make it possible to retrieve the current power state of an ACPI
device from user space via sysfs by adding a new attribute
power_state to the power subdirectory of the sysfs directory
associated with the struct acpi_device representing the device's
ACPI node.
Signed-off-by: Rafael J. Wysocki
---
Documentation/ABI/testing/sysfs-devices-power | 13
drivers/acpi/scan.c | 41 ++
2 files changed, 54 insertions(+)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -174,6 +174,43 @@ err_out:
}
EXPORT_SYMBOL(acpi_bus_hot_remove_device);
+#ifdef CONFIG_PM
+static ssize_t power_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct acpi_device *adev = to_acpi_device(dev);
+ int state;
+ int ret;
+
+ ret = acpi_device_get_power(adev, );
+ return ret ? ret : sprintf(buf, "%s\n", acpi_power_state_string(state));
+}
+
+static DEVICE_ATTR(power_state, 0444, power_state_show, NULL);
+
+static struct attribute *acpi_dev_pm_attrs[] = {
+ _attr_power_state.attr,
+ NULL,
+};
+static struct attribute_group acpi_dev_pm_attr_group = {
+ .name = power_group_name,
+ .attrs = acpi_dev_pm_attrs,
+};
+
+static void acpi_dev_pm_sysfs_add(struct device *dev)
+{
+ sysfs_merge_group(>kobj, _dev_pm_attr_group);
+}
+
+static void acpi_dev_pm_sysfs_remove(struct device *dev)
+{
+ sysfs_unmerge_group(>kobj, _dev_pm_attr_group);
+}
+#else /* !CONFIG_PM */
+static inline void acpi_dev_pm_sysfs_add(struct device *dev) {}
+static inline void acpi_dev_pm_sysfs_remove(struct device *dev) {}
+#endif /* !CONFIG_PM */
+
static ssize_t
acpi_eject_store(struct device *d, struct device_attribute *attr,
const char *buf, size_t count)
@@ -367,6 +404,9 @@ static int acpi_device_setup_files(struc
status = acpi_get_handle(dev->handle, "_EJ0", );
if (ACPI_SUCCESS(status))
result = device_create_file(>dev, _attr_eject);
+
+ acpi_dev_pm_sysfs_add(>dev);
+
end:
return result;
}
@@ -376,6 +416,7 @@ static void acpi_device_remove_files(str
acpi_status status;
acpi_handle temp;
+ acpi_dev_pm_sysfs_remove(>dev);
/*
* If device has _STR, remove 'description' file
*/
Index: linux/Documentation/ABI/testing/sysfs-devices-power
===
--- linux.orig/Documentation/ABI/testing/sysfs-devices-power
+++ linux/Documentation/ABI/testing/sysfs-devices-power
@@ -235,3 +235,16 @@ Description:
This attribute has no effect on system-wide suspend/resume and
hibernation.
+
+What: /sys/devices/.../power/power_state
+Date: December 2012
+Contact: Rafael J. Wysocki
+Description:
+ The /sys/devices/.../power/power_state attribute is only present
+ for ACPI device nodes (i.e. objects of type struct acpi_device).
+
+ If present, it contains the string representation of the current
+ ACPI power state of the device represented by the given ACPI
+ device node.
+
+ This attribute is read-only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ACPI / PM: More visible function for retrieving device power states
From: Rafael J. Wysocki
The function used for retrieving ACPI device power states,
__acpi_bus_get_power(), is now static, because it is only used
internally in drivers/acpi/bus.c. However, it will be used
outside of that file going forward, so rename it to
acpi_device_get_power(), in analogy with acpi_device_set_power(),
add a kerneldoc comment to it and add its header to acpi_bus.h.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/bus.c | 15 ---
include/acpi/acpi_bus.h |1 +
2 files changed, 13 insertions(+), 3 deletions(-)
Index: linux/drivers/acpi/bus.c
===
--- linux.orig/drivers/acpi/bus.c
+++ linux/drivers/acpi/bus.c
@@ -200,7 +200,16 @@ static const char *state_string(int stat
}
}
-static int __acpi_bus_get_power(struct acpi_device *device, int *state)
+/**
+ * acpi_device_get_power - Get power state of an ACPI device.
+ * @device: Device to get the power state of.
+ * @state: Place to store the power state of the device.
+ *
+ * This function does not update the device's power.state field, but it may
+ * update its parent's power.state field (when the parent's power state is
+ * unknown and the device's power state turns out to be D0).
+ */
+int acpi_device_get_power(struct acpi_device *device, int *state)
{
int result = ACPI_STATE_UNKNOWN;
@@ -389,7 +398,7 @@ int acpi_bus_init_power(struct acpi_devi
device->power.state = ACPI_STATE_UNKNOWN;
- result = __acpi_bus_get_power(device, );
+ result = acpi_device_get_power(device, );
if (result)
return result;
@@ -413,7 +422,7 @@ int acpi_bus_update_power(acpi_handle ha
if (result)
return result;
- result = __acpi_bus_get_power(device, );
+ result = acpi_device_get_power(device, );
if (result)
return result;
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -340,6 +340,7 @@ acpi_status acpi_bus_get_status_handle(a
unsigned long long *sta);
int acpi_bus_get_status(struct acpi_device *device);
int acpi_bus_set_power(acpi_handle handle, int state);
+int acpi_device_get_power(struct acpi_device *device, int *state);
int acpi_device_set_power(struct acpi_device *device, int state);
int acpi_bus_update_power(acpi_handle handle, int *state_p);
bool acpi_bus_power_manageable(acpi_handle handle);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
On Wednesday, December 05, 2012 8:28 AM, Marko Katic wrote
> On Tue, Dec 4, 2012 at 6:28 AM, Jingoo Han wrote:
> > From: Marko Katic
> >
> > Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
> > triggers WARN_ON message:
> >
> > WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4()
> > Modules linked in:
> > Backtrace:
> > [] (dump_backtrace+0x0/0x110) from []
> > (dump_stack+0x18/0x1c)
> > r6:c0158fc8 r5:0009 r4: r3:c03d4f70
> > [] (dump_stack+0x0/0x1c) from []
> > (warn_slowpath_common+0x54/0x6c)
> > [] (warn_slowpath_common+0x0/0x6c) from []
> > (warn_slowpath_null+0x24/0x2c)
> > r8:c38d5c00 r7:c03f82c0 r6: r5:00d0 r4:c384e4fc
> > r3:0009
> > [] (warn_slowpath_null+0x0/0x2c) from []
> > (__gpio_set_value+0x38/0xa4)
> > [] (__gpio_set_value+0x0/0xa4) from []
> > (corgi_bl_set_intensity+0x44/0x74)
> > r7:c3933418 r6:c3933400 r5:c392cdf0 r4:002f
> > [] (corgi_bl_set_intensity+0x0/0x74) from []
> > (corgi_bl_update_status+0x5c/0x64)
> > r5:c03d31f0 r4:c3933400
> > [] (corgi_bl_update_status+0x0/0x64) from []
> > (corgi_lcd_probe+0x1a8/0x258)
> > r4:c392cdf0 r3:c0169bc0
> > [] (corgi_lcd_probe+0x0/0x258) from []
> > (spi_drv_probe+0x20/0x24)
> > r8:0052 r7:c0192d9c r6:c03da6e8 r5:c38d5c34 r4:c38d5c00
> > [] (spi_drv_probe+0x0/0x24) from []
> > (driver_probe_device+0xb0/0x208)
> > [] (driver_probe_device+0x0/0x208) from []
> > (__driver_attach+0x70/0x94)
> > r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 r3:
> > [] (__driver_attach+0x0/0x94) from []
> > (bus_for_each_dev+0x54/0x90)
> > r6:c03da6e8 r5:c3827e80 r4: r3:
> > [] (bus_for_each_dev+0x0/0x90) from []
> > (driver_attach+0x20/0x28)
> > r7: r6:c03e29ec r5:c3932980 r4:c03da6e8
> > [] (driver_attach+0x0/0x28) from []
> > (bus_add_driver+0xd4/0x22c)
> > [] (bus_add_driver+0x0/0x22c) from []
> > (driver_register+0xa4/0x134)
> > r8:0052 r7:c03ea900 r6:c03c32ac r5:c03bdfc8 r4:c03da6e8
> > [] (driver_register+0x0/0x134) from []
> > (spi_register_driver+0x4c/0x60)
> > [] (spi_register_driver+0x0/0x60) from []
> > (corgi_lcd_driver_init+0x14/0x1c)
> > [] (corgi_lcd_driver_init+0x0/0x1c) from []
> > (do_one_initcall+0x9c/0x174)
> > [] (do_one_initcall+0x0/0x174) from []
> > (kernel_init+0xf4/0x2a8)
> > [] (kernel_init+0x0/0x2a8) from []
> > (ret_from_fork+0x14/0x24)
> > ---[ end trace a863a63f242ee38c ]---
> >
> > Akita machines have backlight controls hooked to a gpio expander chip,
> > max7310. In this case, pca953x_gpio_set_value() can be called to control
> > gpio, and pca953x_setup_gpio() sets can_sleep flag. Therefore,
> > gpio_set_value_cansleep() should be used in order to avoid WARN_ON on
> > akita machines.
> >
> > Akita is the only exception in this case since other users of corgi_lcd
> > access backlight gpio controls through a different gpio expander such as
> > max7310 which does not set the can_sleep flag.
>
> I think you forgot to delete "such as max7310". Akita has
> the max7310, all the other models have a different expander.
Yes, you're right.
I added an unnecessary word, 'such as max7310'.
It should be deleted.
I will send v4 patch, soon.
Best regards,
Jingoo Han
>
> >
> > [jg1@samsung.com: used gpio_cansleep()]
> > Signed-off-by: Marko Katic
> > Signed-off-by: Jingoo Han
> > ---
> > drivers/video/backlight/corgi_lcd.c | 17 +
> > 1 files changed, 13 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/backlight/corgi_lcd.c
> > b/drivers/video/backlight/corgi_lcd.c
> > index e2e1b62..e5168f4 100644
> > --- a/drivers/video/backlight/corgi_lcd.c
> > +++ b/drivers/video/backlight/corgi_lcd.c
> > @@ -408,11 +408,20 @@ static int corgi_bl_set_intensity(struct corgi_lcd
> > *lcd, int intensity)
> > /* Bit 5 via GPIO_BACKLIGHT_CONT */
> > cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
> >
> > - if (gpio_is_valid(lcd->gpio_backlight_cont))
> > - gpio_set_value(lcd->gpio_backlight_cont, cont);
> > + if (gpio_is_valid(lcd->gpio_backlight_cont)) {
> > + if (gpio_cansleep(lcd->gpio_backlight_cont))
> > + gpio_set_value_cansleep(lcd->gpio_backlight_cont,
> > cont);
> > + else
> > + gpio_set_value(lcd->gpio_backlight_cont, cont);
> > + }
> >
> > - if (gpio_is_valid(lcd->gpio_backlight_on))
> > - gpio_set_value(lcd->gpio_backlight_on, intensity);
> > + if (gpio_is_valid(lcd->gpio_backlight_on)) {
> > + if (gpio_cansleep(lcd->gpio_backlight_on))
> > + gpio_set_value_cansleep(lcd->gpio_backlight_on,
> > + intensity);
> > + else
> > + gpio_set_value(lcd->gpio_backlight_on, intensity);
> > + }
> >
> > if (lcd->kick_battery)
> > lcd->kick_battery();
> > --
> > 1.7.2.5
> >
> >
--
To
Re: [PATCH 1/2] Staging: android: binder: Add support for 32bit binder calls in a 64bit kernel
On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu wrote: > Android's IPC, Binder, does not support calls from a 32-bit userspace > in a 64 bit kernel. This patch adds support for syscalls coming from a > 32-bit userspace in a 64-bit kernel. > It also seems to remove support for 64-bit user-space in a 64 bit kernel at the same time. While we have not started fixing this problem yet, it is not clear that we want to go in this direction. If we want to have any 64 bit user-space processes, the 32-bit processes need to use 64 bit pointers when talking to other processes. It may make more sense to change the user-space binder library to probe for needed pointer size (either by adding an ioctl to the driver to return the pointer size in an ioctl with a fixed size pointer or by calling BINDER_VERSION with the two pointer sizes you support (assuming long and void * are the same size)). > Most of the changes were applied to types that change sizes between > 32 and 64 bit world. This will also fix some of the issues around > checking the size of an incoming transaction package in the ioctl > switch. Since the transaction's ioctl number are generated using > _IOC(dir,type,nr,size), a different userspace size will generate > a different ioctl number, thus switching by _IOC_NR is a better > solution. > I don't understand this change. If you use _IOC_NR you lose the protection that the _IOC macros added. If the size does not match you still dereference the pointer using the size that the kernel has (expect where you added a new size check to replace the one you removed). -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI/PM: Keep runtime PM enabled for unbound PCI devices
On Wed, Nov 28, 2012 at 3:43 PM, Rafael J. Wysocki wrote: > On Wednesday, November 28, 2012 03:25:59 PM Bjorn Helgaas wrote: >> On Tue, Nov 20, 2012 at 1:08 AM, Huang Ying wrote: >> > For unbound PCI devices, what we need is: >> > >> > - Always in D0 state, because some devices does not work again after >> >being put into D3 by the PCI bus. >> > >> > - In SUSPENDED state if allowed, so that the parent devices can still >> >be put into low power state. >> > >> > To satisfy these requirement, the runtime PM for the unbound PCI >> > devices are disabled and set to SUSPENDED state. One issue of this >> > solution is that the PCI devices will be put into SUSPENDED state even >> > if the SUSPENDED state is forbidden via the sysfs interface >> > (.../power/control) of the device. This is not an issue for most >> > devices, because most PCI devices are not used at all if unbounded. >> > But there are exceptions. For example, unbound VGA card can be used >> > for display, but suspend its parents make it stop working. >> > >> > To fix the issue, we keep the runtime PM enabled when the PCI devices >> > are unbound. But the runtime PM callbacks will do nothing if the PCI >> > devices are unbound. This way, we can put the PCI devices into >> > SUSPENDED state without put the PCI devices into D3 state. >> >> Does this fix a reported problem? Is there a bug report URL? What >> problem would a user notice? > > There is a BZ: https://bugzilla.kernel.org/show_bug.cgi?id=48201 I added the BZ link and put this in my -next branch. Thanks! Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 12/05/2012 01:05 AM, Arnd Bergmann wrote: On Tuesday 04 December 2012, Eli Billauer wrote: On 12/04/2012 10:43 PM, Arnd Bergmann wrote: On Tuesday 04 December 2012, Eli Billauer wrote: It's also a bit confusing because it doesn't appear to be a "bus" in the Linux sense of being something that provides an abstract interface between hardware and kernel device drivers. Instead, you just have a user interface for those FPGA models that don't need a kernel level driver themselves. I'm not sure I would agree on that. Xillybus consists of an IP core (sort-of library function for an FPGA), and a driver. At the OS level, it's no different than any PCI card and its driver. I call it "generic" because it's not tailored to transport a certain kind of data (say, audio samples or video frames). In the FPGA world, passing data to or from a processor is a project in itself, in particular if the latter runs a fullblown operating system. What Xillybus does, is supplying a simple interface on both sides: A hardware FIFO on the logic side for the FPGA designer to interface with, and a plain device file on the host's side. The whole point of this project is to make everything simple and intuitive. The problem with this approach is that it cannot be used to provide standard OS interfaces: when you have an audio/video device implemented in an FPGA, all Linux applications expect to use the alsa and v4l interfaces, not xillybus, which means you need a kernel-level driver. For special-purpose applications, having a generic kernel-level driver and a custom user application works fine, but you don't save any complexity for a lot of other use cases, you just move it somewhere else by requiring a redesign of existing user applications, which is often not a reasonable approach. Xillybus is there exactly for special-purpose applications. In fact, the main reason people turn to FPGAs is because there are no general-purpose chips to do the job. Besides, if the FPGA implements a well-known function (e.g. a video card) there is no reason to treat it differently IMHO. For example, drivers/video/xilinxfb.c, drivers/tty/serial/xilinx_uartps.c work only with Xilinx' IP cores, and they're mixed with the "hardware" drivers. It's when it doesn't make sense to represent the FPGA logic as something standard, that Xillybus comes in. Even if the reason is not being ready to spend the effort. I'm not sure what you meant here, but I'll mention this: FPGA designers using the IP core don't need to care what the transport is, PCIe, AMBA or anything else. They just see a FIFO. Neither is the host influenced by this, except for loading a different front end module. I mean some IP cores can use your driver just fine, while other IP cores require a driver that interfaces with a kernel subsystem (alsa, v4l, network, iio, etc). Whether xillybus is a good design choice for those IP cores is a different question, but for all I can tell, it would be entirely possible to implement an ethernet adapter based on this, as long as it can interface to the kernel. Xillybus' strength is its simplicity in sending plain streams of data. If the data is looped back into the kernel to implement a network interface, that's indeed possible. As for dedicated interfaces, I'll say this: I wrote a simple video adapter for Zynq lately. To some extent, the logic is based upon things I took from Xillybus, but no more than some basic blocks. As for the driver, I started from a completely different one. What I'm trying to say, is that it's possible to implement dedicated functions based upon Xillybus, but in practice it doesn't make much sense. For the user interface, something that is purely read/write based is really nice, though I wonder if using debugfs or sysfs for this would be more appropriate than having lots of character devices for a single piece of hardware. And this is where the term "hardware" becomes elusive with an FPGA: One could look at the entire FPGA chip as a single piece of hardware, and expect everything to be packed into a few device nodes. Or, one could look at each of the hardware FIFOs in the FPGA as something like a sound card, an independent piece of hardware, which is the way I chose to look at it. That's why I allocated a character device for each. Most interfaces we have in the kernel are on a larger scale. E.g. a network adapter is a single instance rather than an input and an output queue. Since the project has been in use by others for about a year (academic users and in the industry), I know at this point that the user interface is convenient to work with (judging from feedback I received). So I would be quite reluctant to make radical changes in the user interface, in particular knowing that it works well and makes UNIX guys feel at home. Changing to sysfs or debugfs is not a radical change: you would still have multiple nodes in a file
Re: [PATCH] PCI: add PCIe 8.0 GT/s supported link speed define
On Tue, Nov 20, 2012 at 11:58 AM, Betty Dall wrote:
> Add a new define for the 8.0 GT/s supported link speed added in the PCI
> 3.0 specification. This is used to identify a device's current link speed
> (PCI_EXP_CLS).
>
> Here is the section of the PCI 3.0 specification:
> "Supported Link Speeds Vector – This field indicates the
> supported Link speed(s) of the associated Port. For each bit, a
> value of 1b indicates that the corresponding Link speed is
> supported; otherwise, the Link speed is not supported.
> Bit definitions within this field are:
> Bit 0 2.5 GT/s
> Bit 1 5.0 GT/s
> Bit 2 8.0 GT/s
> Bits 6:3 RsvdP
> Multi-Function devices associated with an Upstream Port must
> report the same value in this field for all Functions."
>
> Signed-off-by: Betty Dall
> ---
> include/uapi/linux/pci_regs.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 20ae747..0cf8abb 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -469,6 +469,7 @@
> #define PCI_EXP_LNKSTA_CLS0x000f /* Current Link Speed */
> #define PCI_EXP_LNKSTA_CLS_2_5GB 0x01 /* Current Link Speed 2.5GT/s */
> #define PCI_EXP_LNKSTA_CLS_5_0GB 0x02 /* Current Link Speed 5.0GT/s */
> +#define PCI_EXP_LNKSTA_CLS_8_0GB 0x04 /* Current Link Speed 8.0GT/s */
This isn't right, is it? The Link Status Current Link Speed field is
a four-bit field that's encoded. The currently defined values are 1-7
(not 1, 2, 4, 8). So I think you would want to add this instead:
#define PCI_EXP_LNKSTA_CLS_8_0GB 0x03 /* Current Link Speed 8.0GT/s */
That corresponds to bit 2 in the Supported Link Speeds Vector in the
Link Capabilities 2 register:
#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x04 /* Supported Link Speed 8.0GT/s */
This whole mess looks like potential off-by-one errors everywhere, and
I could be mistaken about this :)
While you're here, can you fix the typo ("Nogotiated") in the line below?
> #define PCI_EXP_LNKSTA_NLW0x03f0 /* Nogotiated Link Width */
> #define PCI_EXP_LNKSTA_NLW_SHIFT 4/* start of NLW mask in link status */
> #define PCI_EXP_LNKSTA_LT 0x0800 /* Link Training */
> --
> 1.7.7.6
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] Remove VLAIS usage from gadget code
On 12-12-04 11:24 PM, Sebastian Andrzej Siewior wrote: On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote: However, in order to approximate what gcc is doing in code, obviously some math is required. The thought was that macros would hide the worst of it, trying not to obfuscate what was actually being done. Why hide? The thing that is done here is setting up pointers and keep this struct as a container. It is never used again, just freed. Therefore I would suggest to remove and do something different. Fair enough. That works too. I've been profiling some sample code around this implementation comparing it between compilers, and it approximates the code size and speed of using VLAIS in gcc (especially with -O2). It actually performs better than the previously proposed macros. I'm not concerned about speed here. This is an one time setup. Which is all good in the case of the gadget code. However VLAIS is used in other places too where code size and speed are very important. The proposal was for something which might be used for more than just the gadget code. VLAIS is used in only a handful of places in the kernel. They just happen to be in important parts of the kernel which was why the approach was to change as little as necessary. But certainly if anyone has a solution which works for everyone, then I'm more than happy to adopt it. The LLVM community has made quite a few changes in order to help get Linux working with clang. However, That is nice to hear. Besides gcc there is the icc. Lots of people have brought up icc. Although in the same breath most also say nobody is using it anymore. However, I have no idea whether that is true. The difference is that clang is widely available in most distros; icc is not. VLAIS is not something they are willing to accept (for various reasons). There are other patches to LLVM that are still working Is this not described in C99 6.7.2.1p16? You're thinking of "Flexible Array Members". Essentially the last element in a structure can be the equivalent of a zero length array; something which both gcc and clang support today. From C99 6.7.2.1p16: 16 As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply. Howev er, when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it. However if we're considering the C99 standard, it also explicitly disallows the use of VLAs in structs (VLAIS). From C99 6.7.2.1 p2: 2 A structure or union shall not contain a member with incomplete or function type (hence, a structure shall not contain an instance of itself, but may contain a pointer to an instance of itself), except that the last member of a structure with more than one named member may have incomplete array type; such a structure (and any union containing, possibly recursively, a member that is such a structure) shall not be a member of a structure or an element of an array. From C99 6.7.5.2 p4: 4 If the size is not present, the array type is an incomplete type. Essentially all arrays in a structure must not be variable length except the last member of the array which can be a zero length array (which can be used to approximate a VLA at the end). It also says that a struct which uses a flexible array member can't be used inside another struct. their way upstream that are required to be able to compile Linux as well. I hope the other are "simple" to get in :) I hope so too. But like the Linux kernel community, the LLVM community have standards and procedures for getting code accepted which take time. Thanks, Behan -- Behan Webster beh...@converseincode.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] aoe: avoid races between device destruction and discovery
On Mon, 3 Dec 2012 20:42:56 -0500
Ed Cashin wrote:
> This change avoids a race that could result in a NULL pointer
> derference following a WARNing from kobject_add_internal, "don't
> try to register things with the same name in the same directory."
>
> The problem was found with a test that forgets and discovers an
> aoe device in a loop:
>
> while test ! -r /tmp/stop; do
> aoe-flush -a
> aoe-discover
> done
>
> The race was between aoedev_flush taking aoedevs out of the
> devlist, allowing a new discovery of the same AoE target to take
> place before the driver gets around to calling
> sysfs_remove_group. Fixing that one revealed another race
> between do_open and add_disk, and this patch avoids that, too.
>
> The fix required some care, because for flushing (forgetting) an
> aoedev, some of the steps must be performed under lock and some
> must be able to sleep. Also, for discovering a new aoedev, some
> steps might sleep.
>
> The check for a bad aoedev pointer remains from a time when about
> half of this patch was done, and it was possible for the
> bdev->bd_disk->private_data to become corrupted. The check
> should be removed eventually, but it is not expected to add
> significant overhead, occurring in the aoeblk_open routine.
>
>
> ...
>
> --- a/drivers/block/aoe/aoeblk.c
> +++ b/drivers/block/aoe/aoeblk.c
> @@ -147,9 +147,18 @@ aoeblk_open(struct block_device *bdev, fmode_t mode)
> struct aoedev *d = bdev->bd_disk->private_data;
> ulong flags;
>
> + if (!virt_addr_valid(d)) {
> + pr_crit("aoe: invalid device pointer in %s\n",
> + __func__);
> + WARN_ON(1);
> + return -ENODEV;
> + }
Can this ever happen?
> + if (!(d->flags & DEVFL_UP) || d->flags & DEVFL_TKILL)
> + return -ENODEV;
> +
> mutex_lock(_mutex);
> spin_lock_irqsave(>lock, flags);
> - if (d->flags & DEVFL_UP) {
> + if (d->flags & DEVFL_UP && !(d->flags & DEVFL_TKILL)) {
> d->nopen++;
> spin_unlock_irqrestore(>lock, flags);
> mutex_unlock(_mutex);
> @@ -259,6 +268,18 @@ aoeblk_gdalloc(void *vp)
> struct request_queue *q;
> enum { KB = 1024, MB = KB * KB, READ_AHEAD = 2 * MB, };
> ulong flags;
> + int late = 0;
> +
> + spin_lock_irqsave(>lock, flags);
> + if (d->flags & DEVFL_GDALLOC
> + && !(d->flags & DEVFL_TKILL)
> + && !(d->flags & DEVFL_GD_NOW))
That's pretty sickly-looking code layout.
We often do
if ((d->flags & (DEVFL_GDALLOC|DEVFL_TKILL|DEVFL_GD_NOW)) ==
DEVFL_GDALLOC)
in these cases.
> + d->flags |= DEVFL_GD_NOW;
> + else
> + late = 1;
> + spin_unlock_irqrestore(>lock, flags);
> + if (late)
> + return;
>
> gd = alloc_disk(AOE_PARTITIONS);
> if (gd == NULL) {
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly
"Srivatsa S. Bhat" writes: > From: Michael Wang > > With stop_machine() gone from the CPU offline path, we can't depend on > preempt_disable() to prevent CPUs from going offline from under us. Minor gripe: I'd prefer this paragraph to use the future rather than past tense, like: "Once stop_machine() is gone ... we won't be able to depend". Since you're not supposed to use the _stable() accessors without calling get_online_cpus_stable_atomic(), why not have get_online_cpus_stable_atomic() return a pointer to the stable cpumask? (Which is otherwise static, at least for debug). Might make the patches messier though... Oh, and I'd love to see actual benchmarks to make sure we've actually fixed a problem with this ;) Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] aoe: improve handling of misbehaving network paths
On Mon, 3 Dec 2012 20:40:55 -0500
Ed Cashin wrote:
> An AoE target can have multiple network ports used for AoE, and
> in the aoe driver, those are tracked by the aoetgt struct. These
> changes allow the aoe driver to handle network paths, or aoetgts,
> that are not working well, compared to the others.
>
> Paths that do not get responses despite the retransmission of AoE
> commands are marked as "tainted", and non-tainted paths are
> preferred.
>
> Meanwhile, the aoe driver attempts to "probe" the tainted path in
> the background by issuing reads of LBA 0 that are padded out to
> full (possibly jumbo-frame) size. If the probes get responses,
> then the path is "redeemed", and its taint is removed.
>
> This mechanism has been shown to be helpful in transparently
> handling and recovering from real-world network "brown outs" in
> ways that the earlier "shoot the help-needing target in the head"
> mechanism could not.
>
>
> ...
>
> +static void
> +ata_rw_frameinit(struct frame *f)
> +{
> + struct aoetgt *t;
> + struct aoe_hdr *h;
> + struct aoe_atahdr *ah;
> + struct sk_buff *skb;
> + char writebit, extbit;
> +
> + skb = f->skb;
> + h = (struct aoe_hdr *) skb_mac_header(skb);
> + ah = (struct aoe_atahdr *) (h + 1);
Well. It would be neater to have a
struct whatever {
struct aoe_hdr hdr;
struct aoe_atahdr atahdr;
};
> + skb_put(skb, sizeof(*h) + sizeof(*ah));
> + memset(h, 0, skb->len);
> +
> + writebit = 0x10;
> + extbit = 0x4;
> +
>
> ...
>
> @@ -462,11 +488,14 @@ resend(struct aoedev *d, struct frame *f)
> h = (struct aoe_hdr *) skb_mac_header(skb);
> ah = (struct aoe_atahdr *) (h+1);
>
> - snprintf(buf, sizeof buf,
> - "%15s e%ld.%d oldtag=%08x@%08lx newtag=%08x s=%pm d=%pm
> nout=%d\n",
> - "retransmit", d->aoemajor, d->aoeminor, f->tag, jiffies, n,
> - h->src, h->dst, t->nout);
> - aoechr_error(buf);
> + if (!(f->flags & FFL_PROBE)) {
> + snprintf(buf, sizeof(buf),
> + "%15s e%ld.%d oldtag=%08x@%08lx newtag=%08x s=%pm d=%pm
> nout=%d\n",
> + "retransmit", d->aoemajor, d->aoeminor,
> + f->tag, jiffies, n,
> + h->src, h->dst, t->nout);
> + aoechr_error(buf);
Could use kasprintf() here. That avoids the fixed-size local buffer
and avoids the GFP_ATOMIC allocation and copy in aoechr_error().
> + }
>
> f->tag = n;
> fhash(f);
>
> ...
>
> aoecmd_init(void)
> {
> + void *p;
> +
> + /* get_zeroed_page returns page with ref count 1 */
> + p = (void *) get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
> + if (!p)
> + return -ENOMEM;
> + empty_page = virt_to_page(p);
Could use alloc_pages() and remove `p' and the virt_to_page().
Why is __GFP_REPEAT used? I don't think this __init function is more
important than all the other ones in the kernel?
> INIT_LIST_HEAD();
> spin_lock_init();
> init_waitqueue_head();
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation
On Tue, 2012-12-04 at 17:16 +0800, Hanjun Guo wrote:
> On 2012/12/4 8:10, Toshi Kani wrote:
> > On Mon, 2012-12-03 at 12:25 +0800, Hanjun Guo wrote:
> >> On 2012/11/30 6:27, Toshi Kani wrote:
> >>> On Thu, 2012-11-29 at 12:48 +0800, Hanjun Guo wrote:
> On 2012/11/29 2:41, Toshi Kani wrote:
> > On Wed, 2012-11-28 at 19:05 +0800, Hanjun Guo wrote:
> >> On 2012/11/24 1:50, Vasilis Liaskovitis wrote:
> >> As you may know, the ACPI based hotplug framework we are working on
> >> already addressed
> >> this problem, and the way we slove this problem is a bit like yours.
> >>
> >> We introduce hp_ops in struct acpi_device_ops:
> >> struct acpi_device_ops {
> >>acpi_op_add add;
> >>acpi_op_remove remove;
> >>acpi_op_start start;
> >>acpi_op_bind bind;
> >>acpi_op_unbind unbind;
> >>acpi_op_notify notify;
> >> #ifdef CONFIG_ACPI_HOTPLUG
> >>struct acpihp_dev_ops *hp_ops;
> >> #endif /* CONFIG_ACPI_HOTPLUG */
> >> };
> >>
> >> in hp_ops, we divide the prepare_remove into six small steps, that is:
> >> 1) pre_release(): optional step to mark device going to be removed/busy
> >> 2) release(): reclaim device from running system
> >> 3) post_release(): rollback if cancelled by user or error happened
> >> 4) pre_unconfigure(): optional step to solve possible dependency issue
> >> 5) unconfigure(): remove devices from running system
> >> 6) post_unconfigure(): free resources used by devices
> >>
> >> In this way, we can easily rollback if error happens.
> >> How do you think of this solution, any suggestion ? I think we can
> >> achieve
> >> a better way for sharing ideas. :)
> >
> > Yes, sharing idea is good. :) I do not know if we need all 6 steps (I
> > have not looked at all your changes yet..), but in my mind, a hot-plug
> > operation should be composed with the following 3 phases.
>
> Good idea ! we also implement a hot-plug operation in 3 phases:
> 1) acpihp_drv_pre_execute
> 2) acpihp_drv_execute
> 3) acpihp_drv_post_execute
> you may refer to :
> https://lkml.org/lkml/2012/11/4/79
> >>>
> >>> Great. Yes, I will take a look.
> >>
> >> Thanks, any comments are welcomed :)
> >
> > If I read the code right, the framework calls ACPI drivers differently
> > at boot-time and hot-add as follows. That is, the new entry points are
> > called at hot-add only, but .add() is called at both cases. This
> > requires .add() to work differently.
>
> Hi Toshi,
> Thanks for your comments!
>
> >
> > Boot: .add()
>
> Actually, at boot time: .add(), .start()
Right.
> > Hot-Add : .add(), .pre_configure(), configure(), etc.
>
> Yes, we did it as you said in the framework. We use .pre_configure(),
> configure(),
> and post_configure() to instead of .start() for better error handling and
> recovery.
I think we should have hot-plug interfaces at the module level, not at
the ACPI-internal level. In this way, the interfaces can be
platform-neutral and allow any modules to register, which makes it more
consistent with the boot-up sequence. It can also allow ordering of the
sequence among the registered modules. Right now, we initiate all
procedures from ACPI during hot-plug, which I think is inflexible and
steps into other module's role.
I am also concerned about the slot handling, which is the core piece of
the infrastructure and only allows hot-plug operations on ACPI objects
where slot objects are previously created by checking _EJ0. The
infrastructure should allow hot-plug operations on any objects, and it
should not be dependent on the slot design.
I have some rough idea, and it may be easier to review / explain if I
make some code changes. So, let me prototype it, and send it you all if
that works out. Hopefully, it won't take too long.
> > I think the boot-time and hot-add initialization should be done
> > consistently. While there is difficulty with the current boot sequence,
> > the framework should be designed to allow them consistent, not make them
> > diverged.
> >
> > 1. Validate phase - Verify if the request is a supported operation. All
> > known restrictions are verified at this phase. For instance, if a
> > hot-remove request involves kernel memory, it is failed in this phase.
> > Since this phase makes no change, no rollback is necessary to fail.
>
> Yes, we have done this in acpihp_drv_pre_execute, and check following
> things:
>
> 1) Hot-plugble or not. the instance kernel memory you mentioned is also
> checked
> when memory device remove;
> >>>
> >>> Agreed.
> >>>
> 2) Dependency check involved. For instance, if hot-add a memory device,
> processor should be added first, otherwise it's not valid to this
> operation.
> >>>
> >>> I think FW should be the one that assures such
Re: [PATCH v3] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
On Tue, Dec 4, 2012 at 6:28 AM, Jingoo Han wrote:
> From: Marko Katic
>
> Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
> triggers WARN_ON message:
>
> WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4()
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x110) from []
> (dump_stack+0x18/0x1c)
> r6:c0158fc8 r5:0009 r4: r3:c03d4f70
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x54/0x6c)
> [] (warn_slowpath_common+0x0/0x6c) from []
> (warn_slowpath_null+0x24/0x2c)
> r8:c38d5c00 r7:c03f82c0 r6: r5:00d0 r4:c384e4fc
> r3:0009
> [] (warn_slowpath_null+0x0/0x2c) from []
> (__gpio_set_value+0x38/0xa4)
> [] (__gpio_set_value+0x0/0xa4) from []
> (corgi_bl_set_intensity+0x44/0x74)
> r7:c3933418 r6:c3933400 r5:c392cdf0 r4:002f
> [] (corgi_bl_set_intensity+0x0/0x74) from []
> (corgi_bl_update_status+0x5c/0x64)
> r5:c03d31f0 r4:c3933400
> [] (corgi_bl_update_status+0x0/0x64) from []
> (corgi_lcd_probe+0x1a8/0x258)
> r4:c392cdf0 r3:c0169bc0
> [] (corgi_lcd_probe+0x0/0x258) from []
> (spi_drv_probe+0x20/0x24)
> r8:0052 r7:c0192d9c r6:c03da6e8 r5:c38d5c34 r4:c38d5c00
> [] (spi_drv_probe+0x0/0x24) from []
> (driver_probe_device+0xb0/0x208)
> [] (driver_probe_device+0x0/0x208) from []
> (__driver_attach+0x70/0x94)
> r6:c03da6e8 r5:c38d5c34 r4:c38d5c00 r3:
> [] (__driver_attach+0x0/0x94) from []
> (bus_for_each_dev+0x54/0x90)
> r6:c03da6e8 r5:c3827e80 r4: r3:
> [] (bus_for_each_dev+0x0/0x90) from []
> (driver_attach+0x20/0x28)
> r7: r6:c03e29ec r5:c3932980 r4:c03da6e8
> [] (driver_attach+0x0/0x28) from []
> (bus_add_driver+0xd4/0x22c)
> [] (bus_add_driver+0x0/0x22c) from []
> (driver_register+0xa4/0x134)
> r8:0052 r7:c03ea900 r6:c03c32ac r5:c03bdfc8 r4:c03da6e8
> [] (driver_register+0x0/0x134) from []
> (spi_register_driver+0x4c/0x60)
> [] (spi_register_driver+0x0/0x60) from []
> (corgi_lcd_driver_init+0x14/0x1c)
> [] (corgi_lcd_driver_init+0x0/0x1c) from []
> (do_one_initcall+0x9c/0x174)
> [] (do_one_initcall+0x0/0x174) from []
> (kernel_init+0xf4/0x2a8)
> [] (kernel_init+0x0/0x2a8) from []
> (ret_from_fork+0x14/0x24)
> ---[ end trace a863a63f242ee38c ]---
>
> Akita machines have backlight controls hooked to a gpio expander chip,
> max7310. In this case, pca953x_gpio_set_value() can be called to control
> gpio, and pca953x_setup_gpio() sets can_sleep flag. Therefore,
> gpio_set_value_cansleep() should be used in order to avoid WARN_ON on
> akita machines.
>
> Akita is the only exception in this case since other users of corgi_lcd
> access backlight gpio controls through a different gpio expander such as
> max7310 which does not set the can_sleep flag.
I think you forgot to delete "such as max7310". Akita has
the max7310, all the other models have a different expander.
>
> [jg1@samsung.com: used gpio_cansleep()]
> Signed-off-by: Marko Katic
> Signed-off-by: Jingoo Han
> ---
> drivers/video/backlight/corgi_lcd.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/backlight/corgi_lcd.c
> b/drivers/video/backlight/corgi_lcd.c
> index e2e1b62..e5168f4 100644
> --- a/drivers/video/backlight/corgi_lcd.c
> +++ b/drivers/video/backlight/corgi_lcd.c
> @@ -408,11 +408,20 @@ static int corgi_bl_set_intensity(struct corgi_lcd
> *lcd, int intensity)
> /* Bit 5 via GPIO_BACKLIGHT_CONT */
> cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
>
> - if (gpio_is_valid(lcd->gpio_backlight_cont))
> - gpio_set_value(lcd->gpio_backlight_cont, cont);
> + if (gpio_is_valid(lcd->gpio_backlight_cont)) {
> + if (gpio_cansleep(lcd->gpio_backlight_cont))
> + gpio_set_value_cansleep(lcd->gpio_backlight_cont,
> cont);
> + else
> + gpio_set_value(lcd->gpio_backlight_cont, cont);
> + }
>
> - if (gpio_is_valid(lcd->gpio_backlight_on))
> - gpio_set_value(lcd->gpio_backlight_on, intensity);
> + if (gpio_is_valid(lcd->gpio_backlight_on)) {
> + if (gpio_cansleep(lcd->gpio_backlight_on))
> + gpio_set_value_cansleep(lcd->gpio_backlight_on,
> + intensity);
> + else
> + gpio_set_value(lcd->gpio_backlight_on, intensity);
> + }
>
> if (lcd->kick_battery)
> lcd->kick_battery();
> --
> 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 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On Tuesday 04 December 2012, Eli Billauer wrote: > On 12/04/2012 10:43 PM, Arnd Bergmann wrote: > > On Tuesday 04 December 2012, Eli Billauer wrote: > > It's also a bit confusing because it doesn't appear > > to be a "bus" in the Linux sense of being something that provides > > an abstract interface between hardware and kernel device drivers. > > > > Instead, you just have a user interface for those FPGA models that > > don't need a kernel level driver themselves. > > I'm not sure I would agree on that. Xillybus consists of an IP core > (sort-of library function for an FPGA), and a driver. At the OS level, > it's no different than any PCI card and its driver. I call it "generic" > because it's not tailored to transport a certain kind of data (say, > audio samples or video frames). > > In the FPGA world, passing data to or from a processor is a project in > itself, in particular if the latter runs a fullblown operating system. > What Xillybus does, is supplying a simple interface on both sides: A > hardware FIFO on the logic side for the FPGA designer to interface with, > and a plain device file on the host's side. The whole point of this > project is to make everything simple and intuitive. The problem with this approach is that it cannot be used to provide standard OS interfaces: when you have an audio/video device implemented in an FPGA, all Linux applications expect to use the alsa and v4l interfaces, not xillybus, which means you need a kernel-level driver. For special-purpose applications, having a generic kernel-level driver and a custom user application works fine, but you don't save any complexity for a lot of other use cases, you just move it somewhere else by requiring a redesign of existing user applications, which is often not a reasonable approach. > > This is something > > that sits on a somewhat higher level -- if we want a generic FPGA > > interface, this would not be directly connected to a PCI or AMBA > > bus, but instead connect to an FPGA bus that still needs to be > > invented. > > > For what it's worth, the driver is now divided into three parts: A > xillybus_core, a module for PCIe and a module for Open Firmware > interface. The two latter depend on the first, of course. Ok, that is certainly a good step in the right direction. > > In the user interface side that you provide seems to be on the > > same interface level as the USB passthrough interface implemented > > in drivers/usb/core/devio.c, which has a complex set of ioctls > > but does serve a very similar purpose. Greg may want to comment > > on whether that is actually a good interface or not, since I assume > > he has some experience with how well it worked for USB. > > > > My feeling for now is that we actually need both an in-kernel > > interface and a user interface, with the complication that the > > hardware should not care which of the two is used for a particular > > instance. > > I'm not sure what you meant here, but I'll mention this: FPGA designers > using the IP core don't need to care what the transport is, PCIe, AMBA > or anything else. They just see a FIFO. Neither is the host influenced > by this, except for loading a different front end module. I mean some IP cores can use your driver just fine, while other IP cores require a driver that interfaces with a kernel subsystem (alsa, v4l, network, iio, etc). Whether xillybus is a good design choice for those IP cores is a different question, but for all I can tell, it would be entirely possible to implement an ethernet adapter based on this, as long as it can interface to the kernel. > > For the user interface, something that is purely read/write > > based is really nice, though I wonder if using debugfs or sysfs > > for this would be more appropriate than having lots of character > > devices for a single piece of hardware. > > > And this is where the term "hardware" becomes elusive with an FPGA: One > could look at the entire FPGA chip as a single piece of hardware, and > expect everything to be packed into a few device nodes. > > Or, one could look at each of the hardware FIFOs in the FPGA as > something like a sound card, an independent piece of hardware, which is > the way I chose to look at it. That's why I allocated a character device > for each. Most interfaces we have in the kernel are on a larger scale. E.g. a network adapter is a single instance rather than an input and an output queue. > Since the project has been in use by others for about a year (academic > users and in the industry), I know at this point that the user interface > is convenient to work with (judging from feedback I received). So I > would be quite reluctant to make radical changes in the user interface, > in particular knowing that it works well and makes UNIX guys feel at home. Changing to sysfs or debugfs is not a radical change: you would still have multiple nodes in a file system that each represent a queue, but rather than using a
