Re: [tip:x86/reboot] x86/reboot: Remove the duplicate C6100 entry in the reboot quirks list
* H. Peter Anvin wrote:
> On 09/26/2013 01:59 PM, Davidlohr Bueso wrote:
> >> - },
> >> - { /* Some C6100 machines were shipped with vendor being 'Dell'. */
> >> - .callback = set_pci_reboot,
> >> - .ident = "Dell PowerEdge C6100",
> >> - .matches = {
> >>DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
> >>DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
> >>},
> >
> > Hmm, I think we should be keeping the 'Dell Inc.' part instead of just
> > 'Dell' - at least the rest of the entries use the same string:
> >
>
> The point is that some of the machines just has "Dell" in their vendor
> string.
Yes, so if then the argument could be made that all the other entries
should probably be changed to 'Dell' as well.
This is yet another reminder that DMI matches are such a fragile method
...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] ipc,msg: prevent race with rmid in msgsnd,msgrcv
Hi Andrew, Could you include the patch in -mm and push it towards Linus? On 09/16/2013 05:04 AM, Davidlohr Bueso wrote: This fixes a race in both msgrcv() and msgsnd() between finding the msg and actually dealing with the queue, as another thread can delete shmid underneath us if we are preempted before acquiring the kern_ipc_perm.lock. Manfred illustrates this nicely: Assume a preemptible kernel that is preempted just after msq = msq_obtain_object_check(ns, msqid) in do_msgrcv(). The only lock that is held is rcu_read_lock(). Now the other thread processes IPC_RMID. When the first task is resumed, then it will happily wait for messages on a deleted queue. Fix this by checking for if the queue has been deleted after taking the lock. Reported-by: Manfred Spraul Cc: sta...@vger.kernel.org # for 3.11 Signed-off-by: Davidlohr Bueso Signed-off-by: Manfred Spraul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 3.12-rc2 fixes] clocksource: Several fixes for 3.12-rc2
* Daniel Lezcano wrote: > Hi Thomas, > > this pull request contains several fixes for the clocksource/clockevent > drivers: > > - Jean Pihet fixed a missing Kconfig option preventing the Armada370/XP > to boot up. > > - Magnus Damm fixed the cpumask on the em_sti driver to have the > broadcast timer working on a SMP system > > - Sebastian Hesselbarth skipped the initialization of a timer for > uninitialized DT nodes > > - Tomasz Figa fixed the irq affinity failing on non online cpus > > Thanks > -- Daniel > > - > > The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: > > Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) > > are available in the git repository at: > > > ssh://daniel.lezc...@git.linaro.org//srv/git.linaro.org/git/people/dlezcano/linux.git > clockevents/3.12-rc2-fixes If you want me to pull this you'll need to send along your SSH password as well! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the omap_dss2 tree with the fbdev tree
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/atmel_lcdfb.c between commit 5e8be022fb5b ("video:
atmel_lcdfb: add device tree suport") from the fbdev tree and commit
a36bf1925539 ("video: atmel_lcdfb: Remove redundant dev_set_drvdata")
from the omap_dss2 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/video/atmel_lcdfb.c
index bf9c5d0,3f7d6dc..000
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@@ -1157,30 -934,19 +1157,30 @@@ static int __init atmel_lcdfb_probe(str
}
sinfo = info->par;
+ sinfo->pdev = pdev;
+ sinfo->info = info;
+
+ INIT_LIST_HEAD(>modelist);
- if (dev_get_platdata(dev)) {
- pdata_sinfo = dev_get_platdata(dev);
- sinfo->default_bpp = pdata_sinfo->default_bpp;
- sinfo->default_dmacon = pdata_sinfo->default_dmacon;
- sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
- sinfo->default_monspecs = pdata_sinfo->default_monspecs;
- sinfo->atmel_lcdfb_power_control =
pdata_sinfo->atmel_lcdfb_power_control;
- sinfo->guard_time = pdata_sinfo->guard_time;
- sinfo->smem_len = pdata_sinfo->smem_len;
- sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
- sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
- sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
+ if (pdev->dev.of_node) {
+ ret = atmel_lcdfb_of_init(sinfo);
+ if (ret)
+ goto free_info;
- } else if (dev->platform_data) {
++ } else if (dev_get_platdata(dev)) {
+ struct fb_monspecs *monspecs;
+ int i;
+
- pdata = dev->platform_data;
++ pdata = dev_get_platdata(dev);
+ monspecs = pdata->default_monspecs;
+ sinfo->pdata = *pdata;
+
+ for (i = 0; i < monspecs->modedb_len; i++)
+ fb_add_videomode(>modedb[i], >modelist);
+
+ sinfo->config = atmel_lcdfb_get_config(pdev);
+
+ info->var.bits_per_pixel = pdata->default_bpp ?
pdata->default_bpp : 16;
+ memcpy(>monspecs, pdata->default_monspecs,
sizeof(info->monspecs));
} else {
dev_err(dev, "cannot get default configuration\n");
goto free_info;
@@@ -1305,11 -1089,16 +1305,11 @@@
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(dev, "failed to register framebuffer device: %d\n",
ret);
- goto reset_drvdata;
+ goto free_cmap;
}
- /* add selected videomode to modelist */
- fb_var_to_videomode(, >var);
- fb_add_videomode(, >modelist);
-
/* Power up the LCDC screen */
- if (sinfo->atmel_lcdfb_power_control)
- sinfo->atmel_lcdfb_power_control(1);
+ atmel_lcdfb_power_control(sinfo, 1);
dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
info->node, info->fix.mmio_start, sinfo->mmio,
sinfo->irq_base);
pgpMzHP6NPKvI.pgp
Description: PGP signature
Re: [PATCH 4/4] [RFC] ipv6: Fix for possible ipv6 seqlock deadlock
* John Stultz wrote:
> On 09/26/2013 12:30 PM, Eric Dumazet wrote:
> > On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
> >> While enabling lockdep on seqlocks, I ran accross the warning below
> >> caused by the ipv6 stats being updated in both irq and non-irq context.
> >>
> >> This is a novice attempt to correct the issue, and with this patch
> >> the warning goes away. Any better solutions would be appreciated!
> > ...
> >
> >>
> >> out_err_release:
> >> - if (err == -ENETUNREACH)
> >> + if (err == -ENETUNREACH) {
> >> + unsigned long flags;
> >> + /* some of the stats are locked in irq context */
> >> + local_irq_save(flags);
> >>IP6_INC_STATS_BH(net, NULL, IPSTATS_MIB_OUTNOROUTES);
> >> + local_irq_restore(flags);
> >> + }
> >>dst_release(*dst);
> >>*dst = NULL;
> >>return err;
> > You better change IP6_INC_STATS_BH() to IP6_INC_STATS()
> >
> > On x86 for example, no extra code will be generated (no need to disable
> > hard or soft irqs)
>
> Ah, thanks! Verified it resolves the warning as well, so I've changed my
> patch to use your suggestion.
Btw., is this a deadlock that could occur upstream? If yes then adding a
Cc: tag might be warranted.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep
* Eric Dumazet wrote:
> On Thu, 2013-09-26 at 11:34 -0700, John Stultz wrote:
> > In order to enable lockdep on seqcount/seqlock structures, we
> > must explicitly initialize any locks.
> >
>
> > diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
> > index 8da8c4e..c450e11 100644
> > --- a/include/linux/u64_stats_sync.h
> > +++ b/include/linux/u64_stats_sync.h
> > @@ -67,6 +67,13 @@ struct u64_stats_sync {
> > #endif
> > };
> >
> > +
> > +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> > +#define u64_stats_init(syncp) seqcount_init(syncp.seq)
> > +#else
> > +#define u64_stats_init(syncp)
> > +#endif
> > +
>
> I would prefer a function.
C cannot pass along symbolic names, unfortunately, so we are stuck with
1970's tech and the C preprocessor.
There's a way to make such macros look a tiny bit more structured and thus
be more palatable:
#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
# define u64_stats_init(syncp) seqcount_init(syncp.seq)
#else
# define u64_stats_init(syncp)
#endif
Note, the 'else' branch should probably be:
# define u64_stats_init(syncp) do { } while (0)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] ipc,shm: prevent race with rmid in shmat(2)
Hi Davidlohr, On 09/16/2013 05:04 AM, Davidlohr Bueso wrote: This fixes a race in shmat() between finding the msq and actually attaching the segment, as another thread can delete shmid underneath us if we are preempted before acquiring the kern_ipc_perm.lock. According the the man page, Linux supports attaching to deleted shm segments: http://linux.die.net/man/2/shmat On Linux, it is possible to attach a shared memory segment even if it is already marked to be deleted. However, POSIX.1-2001 does not specify this behavior and many other implementations do not support it. Does your patch change that? Unfortunately, I have neither any experience with ipc/shm nor any test cases. And: As far as I can see it's not a problem if we are attaching to a deleted segment: shm_close cleans up everything. -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch/um: make it work with defconfig and x86_64
Am 27.09.2013 06:14, schrieb Ramkumar Ramachandra: > arch/um/defconfig only lists one default configuration, and that applies > only to the i386 architecture. Replace it with two minimal > configuration files generated using `make savedefconfig`: > > i386_defconfig and x86_64_defconfig > > The build scripts now require two updates: > > 1. um's Kconfig (arch/x86/um/Kconfig) should specify an ARCH_DEFCONFIG >section explicitly pointing to these scripts if the required >variables are set. Take care to remove the DEFCONFIG_LIST section >defined in the included file arch/um/Kconfig.common. > > 2. um's Makefile (arch/um/Makefile) should set KBUILD_DEFCONFIG properly >for the top-level Makefile to pick up. Copy the logic in >arch/x86/Makefile to properly pick the defconfig file depending on >the actual architecture; except we're working with $SUBARCH here, >instead of $ARCH. > > Now, you can do: > > $ ARCH=um make defconfig > $ ARCH=um make > > and successfully build User-Mode Linux on an x86_64 box in default > configuration. I don't much like the commit message, but I will amend it myself. I.e. defconfig worked always on x86_64, you have to specify SUBARCH=x86_64. Your patch adds the handy feature that make defconfig will use the host arch automatically. Patch queued for 3.13-rc1. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] um/vdso: add .gitignore for a couple of targets
Am 27.09.2013 06:14, schrieb Ramkumar Ramachandra: > Cc: Richard Weinberger > Signed-off-by: Ramkumar Ramachandra > --- > arch/x86/um/vdso/.gitignore | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 arch/x86/um/vdso/.gitignore > > diff --git a/arch/x86/um/vdso/.gitignore b/arch/x86/um/vdso/.gitignore > new file mode 100644 > index 000..9cac6d0 > --- /dev/null > +++ b/arch/x86/um/vdso/.gitignore > @@ -0,0 +1,2 @@ > +vdso-syms.lds > +vdso.lds > Queued for 3.13-rc1. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FROM Mr Micheal Ambali
Dear Friend, Greetings to you and your family. My name is Mr Micheal Ambali, the current Chief Auditor of a formidable bank here in Ouagadougou, Burkina Faso, West Africa. I have a transaction worth of 12.5 Million U.S dollars for transferring into your care for our mutual benefits, so i need your assistance with 100% cooperation to realise this task. Further details about the fund, its source and the administrative procedure to transfer this fund into your receiving bank account shall be made known to you immediately as I have your positive response. Thanks and Regards, FROM Mr Micheal Ambali. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: Use per-file CFLAGS in Makefile
From: Namhyung Kim Some files need additional compiler flags to be built successfully. Cleanup Makefile by using optional per-file CFLAGS which look like CFLAGS_dir_filename.o Cc: Jiri Olsa Cc: Borislav Petkov Signed-off-by: Namhyung Kim --- tools/perf/Makefile| 137 ++--- tools/perf/config/Makefile | 2 +- 2 files changed, 56 insertions(+), 83 deletions(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index b62e12d2ba6b..faf6ba068b74 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -531,7 +531,8 @@ ifdef ASCIIDOC8 export ASCIIDOC8 endif -LIBS = -Wl,--whole-archive $(PERFLIBS) -Wl,--no-whole-archive -Wl,--start-group $(EXTLIBS) -Wl,--end-group +LIBS = -Wl,--whole-archive $(PERFLIBS) -Wl,--no-whole-archive +LIBS += -Wl,--start-group $(EXTLIBS) -Wl,--end-group export INSTALL SHELL_PATH @@ -558,23 +559,20 @@ $(OUTPUT)perf: $(OUTPUT)perf.o $(BUILTIN_OBJS) $(PERFLIBS) $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(OUTPUT)perf.o \ $(BUILTIN_OBJS) $(LIBS) -o $@ +$(OUTPUT)perf-%: %.o $(PERFLIBS) + $(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $(LDFLAGS) $(filter %.o,$^) $(LIBS) + +$(OUTPUT)util/rbtree.o: ../../lib/rbtree.c $(OUTPUT)PERF-CFLAGS + $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $< + $(GTK_OBJS): $(OUTPUT)%.o: %.c $(LIB_H) $(QUIET_CC)$(CC) -o $@ -c -fPIC $(CFLAGS) $(GTK_CFLAGS) $< $(OUTPUT)libperf-gtk.so: $(GTK_OBJS) $(PERFLIBS) $(QUIET_LINK)$(CC) -o $@ -shared $(ALL_LDFLAGS) $(filter %.o,$^) $(GTK_LIBS) -$(OUTPUT)builtin-help.o: builtin-help.c $(OUTPUT)common-cmds.h $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \ - '-DPERF_HTML_PATH="$(htmldir_SQ)"' \ - '-DPERF_MAN_PATH="$(mandir_SQ)"' \ - '-DPERF_INFO_PATH="$(infodir_SQ)"' $< - -$(OUTPUT)builtin-timechart.o: builtin-timechart.c $(OUTPUT)common-cmds.h $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \ - '-DPERF_HTML_PATH="$(htmldir_SQ)"' \ - '-DPERF_MAN_PATH="$(mandir_SQ)"' \ - '-DPERF_INFO_PATH="$(infodir_SQ)"' $< +$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H) +$(patsubst perf-%,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h) $(OUTPUT)common-cmds.h: util/generate-cmdlist.sh command-list.txt @@ -592,15 +590,6 @@ $(OUTPUT)perf.o perf.spec \ .SUFFIXES: .SUFFIXES: .o .c .S .s -# These two need to be here so that when O= is not used they take precedence -# over the general rule for .o - -$(OUTPUT)util/%-flex.o: $(OUTPUT)util/%-flex.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c -Iutil/ $(CFLAGS) -w $< - -$(OUTPUT)util/%-bison.o: $(OUTPUT)util/%-bison.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c -Iutil/ $(CFLAGS) -DYYENABLE_NLS=0 -DYYLTYPE_IS_TRIVIAL=0 -w $< - $(OUTPUT)%.o: %.c $(OUTPUT)PERF-CFLAGS $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $< $(OUTPUT)%.i: %.c $(OUTPUT)PERF-CFLAGS @@ -612,67 +601,51 @@ $(OUTPUT)%.o: %.S $(OUTPUT)%.s: %.S $(QUIET_CC)$(CC) -o $@ -E $(CFLAGS) $< -$(OUTPUT)util/exec_cmd.o: util/exec_cmd.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \ - '-DPERF_EXEC_PATH="$(perfexecdir_SQ)"' \ - '-DPREFIX="$(prefix_SQ)"' \ - $< - -$(OUTPUT)tests/attr.o: tests/attr.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \ - '-DBINDIR="$(bindir_SQ)"' -DPYTHON='"$(PYTHON_WORD)"' \ - $< - -$(OUTPUT)tests/python-use.o: tests/python-use.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \ - -DPYTHONPATH='"$(OUTPUT)python"' \ - -DPYTHON='"$(PYTHON_WORD)"' \ - $< - -$(OUTPUT)util/config.o: util/config.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DETC_PERFCONFIG='"$(ETC_PERFCONFIG_SQ)"' $< - -$(OUTPUT)ui/setup.o: ui/setup.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DLIBDIR='"$(libdir_SQ)"' $< - -$(OUTPUT)ui/browser.o: ui/browser.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $< - -$(OUTPUT)ui/browsers/annotate.o: ui/browsers/annotate.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $< - -$(OUTPUT)ui/browsers/hists.o: ui/browsers/hists.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $< - -$(OUTPUT)ui/browsers/map.o: ui/browsers/map.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $< - -$(OUTPUT)ui/browsers/scripts.o: ui/browsers/scripts.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -DENABLE_SLFUTURE_CONST $< - -$(OUTPUT)util/rbtree.o: ../../lib/rbtree.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -Wno-unused-parameter -DETC_PERFCONFIG='"$(ETC_PERFCONFIG_SQ)"' $< - -$(OUTPUT)util/parse-events.o: util/parse-events.c $(OUTPUT)PERF-CFLAGS - $(QUIET_CC)$(CC)
Re: [dtc PATCH V2] Warn on node name unit-address presence/absence mismatch
On Fri, Sep 27, 2013 at 11:30:38AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2013-09-26 at 17:12 -0600, Stephen Warren wrote: > > Well, ePAPR seems pretty specific that unit address and reg are > > related, > > but says nothing about ranges in the section on node naming, nor about > > node naming in the section about ranges. > > > > I'd claim that the existing PPC trees are nonconforming, and should be > > fixed too:-) > > This is tricky, we should probably fix ePAPR here. > > If you have a "soc" bus covering a given range of addresses which it > forwards to its children devices but doesn't have per-se its own > registers in that area, then it wouldn't have a "reg" property. I would > thus argue that in the absence of a "reg" property, if a "ranges" one is > present, the "parent address" entry in there is an acceptable substitute > for the "reg" property as far as unit addresses are concerned. So, that's been accepted practice in fdt world for a while; I think ePAPR already permits that, in fact. > Also don't forget that in real OFW land, the unit address is something > that's somewhat bus specific ... for example, PCI uses "dev,fn" rather > than the full 96-bit number of the "reg" entry :-) > > Another option which would more strictly conform to ePAPR and in fact to > of1275 would be to require such bus nodes to have a "reg" property with > the address value set to the beginning of the range and the size value > set to 0 :-) > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpePm63AwkZt.pgp Description: PGP signature
Re: [PATCH] tty: Fix SIGTTOU not sent with tcflush()
Hello Oleg, On Thu, 2013-09-26 at 21:10 +0200, Oleg Nesterov wrote: > On 09/26, Oleg Nesterov wrote: > > > > Thanks Peter. > > > > Well. I'am afraid my testing was wrong, because Karel reports > > it fixes the problem... > > > > But. I applied this patch to my 3.11 tree (last commit is bff157b3a) > > which also has the additional patch (03e12617 "tty: disassociate_ctty() > > sends the extra SIGCONT"), and > > > > TET_CONFIG=CFG TET_ROOT=. ./T.tcflush 4 > > > > still fails... T.tcflush was compiled on another (Karel's) machine, > > perhaps there is something in libc, I do not know. > > > > So let me ask just in case, I assume the fix below doesn't depend on > > other changes I could miss? > > > > I'll retest after git-pull and report... > > Still fails under the Linus's tree + this patch. > > However!!! > > Tested-by: Oleg Nesterov > > > > > It turns out, T.tcflush doesn't expect it can start as a process group > leader. In this case setsid() fails, then tty_open() doesn't set > signal->tty, and thus this patch makes no difference: tty_check_change() > fails because tty doesn't match signal->tty. > > And indeed, this test passes if you run it under strace, or simply do > > $ TET_CONFIG=CFG TET_ROOT=. perl -e "system './T.tcflush 4'" > > And damn, the fact it doesn't fail under strace doesn't allow you to > see that setsid() fails ;) > > This is probably explains why Karel reported success, perhaps he > didn't run this test individually. This is true, I didn't execute this particular test directly but through the LSB test suite framework. > > Thanks again Peter. Perhaps my analysis was wrong (and I do not see > setsid() in the sources), I do not really care. but perhaps tcflush.c > should be updated. > > Oleg. > Karel -- Karel Srot Quality Engineer, QE BaseOS Security team Email: ks...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH staging] dgnc: remove useless cast on kzalloc()
On Thu, Sep 26, 2013 at 09:27:57AM -0700, Greg KH wrote: > On Thu, Sep 26, 2013 at 10:12:23AM +0800, Fengguang Wu wrote: > > drivers/staging/dgnc/dgnc_driver.c:510:3-7: WARNING: casting value returned > > by k[cmz]alloc to (char *) is useless. > > drivers/staging/dgnc/dgnc_driver.c:502:2-19: WARNING: casting value > > returned by k[cmz]alloc to (struct dgnc_board *) is useless. > > > > Casting (void *) value returned by kmalloc is useless > > as mentioned in Documentation/CodingStyle, Chap 14. > > > > Generated by: coccinelle/api/alloc/drop_kmalloc_cast.cocci > > > > CC: Lidza Louina > > CC: Greg Kroah-Hartman > > Signed-off-by: Fengguang Wu > > --- > > > > drivers/staging/dgnc/dgnc_driver.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > As Jingoo sent this a few minutes before you did, and also cleaned up > another cast that you missed, I've added your signed-off-by to his > patch, as they were the same (although yours didn't apply and his > did...) That'd be good, thanks! Regards, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 21/21] of: remove empty arch prom.h headers
On 09/27/2013 12:21 AM, Rob Herring wrote: > From: Rob Herring > > Now that prom.h is optional, all the empty prom.h headers can be removed. > > Signed-off-by: Rob Herring Acked-by: Vineet Gupta Thx for the continued cleanup. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/21] of: remove HAVE_ARCH_DEVTREE_FIXUPS
On 09/27/2013 12:21 AM, Rob Herring wrote: > From: Rob Herring > > HAVE_ARCH_DEVTREE_FIXUPS appears to always be needed except for sparc, > but it is only used for /proc/device-teee and sparc does not enable > /proc/device-tree. So this option is redundant. Remove the option and > always enable it. This has the side effect of fixing /proc/device-tree > on arches such as arm64 which failed to define this option. > > Signed-off-by: Rob Herring Acked-by: Vineet Gupta Thx for the continued cleanup. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG REPORT] ZSWAP: theoretical race condition issues
Hello Weijie, On Thu, Sep 26, 2013 at 04:48:03PM +0800, Weijie Yang wrote: > On Thu, Sep 26, 2013 at 3:57 PM, Minchan Kim wrote: > > On Thu, Sep 26, 2013 at 03:26:33PM +0800, Weijie Yang wrote: > >> On Thu, Sep 26, 2013 at 1:58 PM, Minchan Kim wrote: > >> > Hello Weigie, > >> > > >> > On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote: > >> >> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote: > >> >> > On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang > >> >> > wrote: > >> >> >> I think I find a new issue, for integrity of this mail thread, I > >> >> >> reply > >> >> >> to this mail. > >> >> >> > >> >> >> It is a concurrence issue either, when duplicate store and reclaim > >> >> >> concurrentlly. > >> >> >> > >> >> >> zswap entry x with offset A is already stored in zswap backend. > >> >> >> Consider the following scenario: > >> >> >> > >> >> >> thread 0: reclaim entry x (get refcount, but not call > >> >> >> zswap_get_swap_cache_page) > >> >> >> > >> >> >> thread 1: store new page with the same offset A, alloc a new zswap > >> >> >> entry y. > >> >> >> store finished. shrink_page_list() call __remove_mapping(), and now > >> >> >> it is not in swap_cache > >> >> >> > >> >> > > >> >> > But I don't think swap layer will call zswap with the same offset A. > >> >> > >> >> 1. store page of offset A in zswap > >> >> 2. some time later, pagefault occur, load page data from zswap. > >> >> But notice that zswap entry x is still in zswap because it is not > >> >> frontswap_tmem_exclusive_gets_enabled. > >> > > >> > frontswap_tmem_exclusive_gets_enabled is just option to see tradeoff > >> > between CPU burining by frequent swapout and memory footprint by > >> > duplicate > >> > copy in swap cache and frontswap backend so it shouldn't affect the > >> > stability. > >> > >> Thanks for explain this. > >> I don't mean to say this option affects the stability, but that zswap > >> only realize > >> one option. Maybe it's better to realize both options for different > >> workloads. > > > > "zswap only relize one option" > > What does it mena? Sorry. I couldn't parse your intention. :) > > You mean zswap should do something special to support > > frontswap_tmem_exclusive_gets? > > Yes. But I am not sure whether it is worth. > > >> > >> >> this page is with PageSwapCache(page) and page_private(page) = > >> >> entry.val > >> >> 3. change this page data, and it become dirty > >> > > >> > If non-shared swapin page become redirty, it should remove the page from > >> > swapcache. If shared swapin page become redirty, it should do CoW so > >> > it's a > >> > new page so that it doesn't live in swap cache. It means it should have > >> > new > >> > offset which is different with old's one for swap out. > >> > > >> > What's wrong with that? > >> > >> It is really not a right scene for duplicate store. And I can not think > >> out one. > >> If duplicate store is impossible, How about delete the handle code in > >> zswap? > >> If it does exist, I think there is a potential issue as I described. > > > > You mean "zswap_duplicate_entry"? > > AFAIR, I already had a question to Seth when zswap was born but AFAIRC, > > he said that he didn't know exact reason but he saw that case during > > experiement so copy the code peice from zcache. > > > > Do you see the case, too? > > Yes, I mean duplicate store. > I check the /Documentation/vm/frontswap.txt, it mentions "duplicate stores", > but I am still confused. It seems that there are two Minchan in LKML. Other Minchan, not me who have a horrible memory, already was first to figure it out a few month ago. https://lkml.org/lkml/2013/1/31/3 /me slaps self. I'd like to look into that issue more but now I don't have a time. Just FYI. ;-) -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] uvcvideo: fix data type for pan/tilt control
The pan/tilt absolute control value is signed value. If minimum value
is minus, It will be changed to plus by clamp_t() as commit 64ae9958a62.
([media] uvcvideo: Fix control value clamping for unsigned integer controls).
It leads to wrong setting of the control values. For example,
when min and max are -36000 and 36000, the setting value between of this range
is always 36000. So, Its data type should be changed to signed.
Signed-off-by: Chanho Min
---
drivers/media/usb/uvc/uvc_ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index a2f4501..0eb82106 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -664,7 +664,7 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.size = 32,
.offset = 0,
.v4l2_type = V4L2_CTRL_TYPE_INTEGER,
- .data_type = UVC_CTRL_DATA_TYPE_UNSIGNED,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
},
{
.id = V4L2_CID_TILT_ABSOLUTE,
@@ -674,7 +674,7 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.size = 32,
.offset = 32,
.v4l2_type = V4L2_CTRL_TYPE_INTEGER,
- .data_type = UVC_CTRL_DATA_TYPE_UNSIGNED,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
},
{
.id = V4L2_CID_PRIVACY,
--
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 v2 2/5] ARM: shmobile: r8a7790: add I2C clocks and aliases for the DT mode
On Thu, Sep 26, 2013 at 07:20:57PM +0200, Guennadi Liakhovetski wrote: > This patch adds clock definitions for the 4 I2C interfaces on r8a7790 and > clock aliases, suitable for the DT mode. > > Signed-off-by: Guennadi Liakhovetski Thanks, queued up for v3.13. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] ARM: shmobile: r8a7790: add I2C DT nodes
On Thu, Sep 26, 2013 at 07:20:58PM +0200, Guennadi Liakhovetski wrote: > Add DT nodes for the four I2C interfacces on r8a7790. > > Signed-off-by: Guennadi Liakhovetski > --- > > v2: part two of former [PATCH 2/4], set i2c bus status to "disabled" by > default. Thanks, queued up for v3.13. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extending splice for copy offloading
On Thu, Sep 26, 2013 at 11:23 PM, Ric Wheeler wrote: > On 09/26/2013 03:53 PM, Miklos Szeredi wrote: >> >> On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote: >> But I'm not sure it's worth the effort; 99% of the use of this interface will be copying whole files. And for that perhaps we need a different API, one which has been discussed some time ago: asynchronous copyfile() returns immediately with a pollable event descriptor indicating copy progress, and some way to cancel the copy. And that can internally rely on ->direct_splice(), with appropriate algorithms for determine the optimal chunk size. >>> >>> And perhaps we don't. Perhaps we can provide this much simpler >>> data-plane interface that works well enough for most everyone and can >>> avoid going down the async rat hole, yet again. >> >> I think either buffering or async is needed to get good perforrmace >> without too much complexity in the app (which is not good). Buffering >> works quite well for regular I/O, so maybe its the way to go here as >> well. >> >> Thanks, >> Miklos >> > > Buffering misses the whole point of the copy offload - the idea is *not* to > read or write the actual data in the most interesting cases which offload > the operation to a smart target device or file system. I meant buffering the COPY, not the data. Doing the COPY synchronously will always incur a performance penalty, the amount depending on the latency, which can be significant with networking. We think of write(2) as a synchronous interface, because that's the appearance we get from all that hard work the page cache and delayed writeback code does to make an asynchronous operation look as if it was synchronous. So from a userspace API perspective a sync interface is nice, but inside we almost always have async interfaces to do the actual work. Thanks, Miklos > > Regards, > > Ric > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: How to get PGP/GPG public key fingerprint
On Fri, Sep 27, 2013 at 09:33:39AM +0800, Li, Zhen-Hua wrote: > Hi Guys, > In the FAQ page of kernel.org (https://www.kernel.org/faq.html) , > it says if one wants to get a kernel.org account, he needs to provide > "PGP/GPG public key fingerprint", and the key should: > > Key should be signed by as many kernel developers as you know > Accounts will not be issued until key carries enough signatures > Key and signatures must be available on public key servers > > My Question Is: how can I get the key? You create it yourself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clocksource: Consolidate SH and ARM mach-shmobile Kconfig bits
On Thu, Sep 26, 2013 at 08:37:09AM +0900, Magnus Damm wrote: > From: Magnus Damm > > Based on request from Olof Johansson, move ARM mach-shmobile > clocksource entries to drivers/clocksource/Kconfig, and at > the same time make the SH architecture use these entries. > > Kconfig entries for CMT, MTU2, TMU and STI are with this patch > now kept in one place. The SH SYS_SUPPORTS_nnn bits are dropped > to simplye let the user select the appropriate ones using Kconfig > instead of trying to filter available timers based on SoC. > > Known issues: > 1) Not yet wrappend in menu/endmenu, populates the root driver menu > -> proposal: Create separate patch to wrap all the clocksource entries? That seems reasonable to me. > 2) Should the entries be sorted? > -> proposal: Ignore cosmetic bits I propose that you sort the entries are adding but leave the rest of the entries as is. > 3) What is correct dependency for multiplatform and single platform? > -> proposal: Perhaps we should simply default to no? I'm not sure that I understand the issue here. > 4) Is single patch across 2 architectures and drivers/clocksource OK? > -> proposal: Keep it like this if possible Olof, I would like your opinion on this but from my pov this seems reasonable. Especially as one of the architectures (sh) is seeing very little change at this time. > Not-yet-signed-off-by: Magnus Damm > --- > > arch/arm/mach-shmobile/Kconfig | 19 -- > arch/sh/Kconfig| 53 > > drivers/clocksource/Kconfig| 25 ++ > 3 files changed, 25 insertions(+), 72 deletions(-) > > --- 0004/arch/arm/mach-shmobile/Kconfig > +++ work/arch/arm/mach-shmobile/Kconfig 2013-09-26 07:51:06.0 > +0900 > @@ -307,25 +307,6 @@ config SHMOBILE_TIMER_HZ > SH-Mobile systems using a 32768 Hz RCLK for clock events may want > to select a HZ value such as 128 that can evenly divide RCLK. > A HZ value that does not divide evenly may cause timer drift. > - > -config SH_TIMER_CMT > - bool "CMT timer driver" > - default y > - help > - This enables build of the CMT timer driver. > - > -config SH_TIMER_TMU > - bool "TMU timer driver" > - default y > - help > - This enables build of the TMU timer driver. > - > -config EM_TIMER_STI > - bool "STI timer driver" > - default y > - help > - This enables build of the STI timer driver. > - > endmenu > > endif > --- 0001/arch/sh/Kconfig > +++ work/arch/sh/Kconfig 2013-09-26 08:00:49.0 +0900 > @@ -121,15 +121,6 @@ config SYS_SUPPORTS_NUMA > config SYS_SUPPORTS_PCI > bool > > -config SYS_SUPPORTS_CMT > - bool > - > -config SYS_SUPPORTS_MTU2 > - bool > - > -config SYS_SUPPORTS_TMU > - bool > - > config STACKTRACE_SUPPORT > def_bool y > > @@ -189,14 +180,12 @@ config CPU_SH3 > bool > select CPU_HAS_INTEVT > select CPU_HAS_SR_RB > - select SYS_SUPPORTS_TMU > > config CPU_SH4 > bool > select CPU_HAS_INTEVT > select CPU_HAS_SR_RB > select CPU_HAS_FPU if !CPU_SH4AL_DSP > - select SYS_SUPPORTS_TMU > select SYS_SUPPORTS_HUGETLBFS if MMU > > config CPU_SH4A > @@ -211,7 +200,6 @@ config CPU_SH4AL_DSP > config CPU_SH5 > bool > select CPU_HAS_FPU > - select SYS_SUPPORTS_TMU > select SYS_SUPPORTS_HUGETLBFS if MMU > > config CPU_SHX2 > @@ -248,7 +236,6 @@ choice > config CPU_SUBTYPE_SH7619 > bool "Support SH7619 processor" > select CPU_SH2 > - select SYS_SUPPORTS_CMT > > # SH-2A Processor Support > > @@ -256,50 +243,38 @@ config CPU_SUBTYPE_SH7201 > bool "Support SH7201 processor" > select CPU_SH2A > select CPU_HAS_FPU > - select SYS_SUPPORTS_MTU2 > > config CPU_SUBTYPE_SH7203 > bool "Support SH7203 processor" > select CPU_SH2A > select CPU_HAS_FPU > - select SYS_SUPPORTS_CMT > - select SYS_SUPPORTS_MTU2 > select ARCH_WANT_OPTIONAL_GPIOLIB > select PINCTRL > > config CPU_SUBTYPE_SH7206 > bool "Support SH7206 processor" > select CPU_SH2A > - select SYS_SUPPORTS_CMT > - select SYS_SUPPORTS_MTU2 > > config CPU_SUBTYPE_SH7263 > bool "Support SH7263 processor" > select CPU_SH2A > select CPU_HAS_FPU > - select SYS_SUPPORTS_CMT > - select SYS_SUPPORTS_MTU2 > > config CPU_SUBTYPE_SH7264 > bool "Support SH7264 processor" > select CPU_SH2A > select CPU_HAS_FPU > - select SYS_SUPPORTS_CMT > - select SYS_SUPPORTS_MTU2 > select PINCTRL > > config CPU_SUBTYPE_SH7269 > bool "Support SH7269 processor" > select CPU_SH2A > select CPU_HAS_FPU > - select SYS_SUPPORTS_CMT > - select SYS_SUPPORTS_MTU2 > select PINCTRL > > config CPU_SUBTYPE_MXG > bool "Support MX-G processor" > select CPU_SH2A > - select SYS_SUPPORTS_MTU2 >
Re: [PATCH 06/21] arc: remove unnecessary prom.h includes
On 09/27/2013 12:21 AM, Rob Herring wrote: > From: Rob Herring > > Remove unnecessary prom.h includes in preparation to remove prom.h. > > Signed-off-by: Rob Herring > Cc: Vineet Gupta Acked-by: Vineet Gupta Thx for the continued cleanup. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 08/11] iwlwifi: Remove extern from function prototypes
> Subject: [PATCH 08/11] iwlwifi: Remove extern from function prototypes > > There are a mix of function prototypes with and without extern in the kernel > sources. Standardize on not using extern for function prototypes. > > Function prototypes don't need to be written with extern. > extern is assumed by the compiler. Its use is as unnecessary as using auto to > declare automatic/local variables in a block. > > Signed-off-by: Joe Perches > --- > drivers/net/wireless/iwlwifi/dvm/agn.h | 2 +- > drivers/net/wireless/iwlwifi/dvm/dev.h | 2 +- > drivers/net/wireless/iwlwifi/dvm/rs.h | 8 > drivers/net/wireless/iwlwifi/mvm/rs.h | 9 - > 4 files changed, 10 insertions(+), 11 deletions(-) > ACK -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] um/vdso: add .gitignore for a couple of targets
Cc: Richard Weinberger Signed-off-by: Ramkumar Ramachandra --- arch/x86/um/vdso/.gitignore | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 arch/x86/um/vdso/.gitignore diff --git a/arch/x86/um/vdso/.gitignore b/arch/x86/um/vdso/.gitignore new file mode 100644 index 000..9cac6d0 --- /dev/null +++ b/arch/x86/um/vdso/.gitignore @@ -0,0 +1,2 @@ +vdso-syms.lds +vdso.lds -- 1.8.4.299.gb3e7d24.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch/um: make it work with defconfig and x86_64
arch/um/defconfig only lists one default configuration, and that applies only to the i386 architecture. Replace it with two minimal configuration files generated using `make savedefconfig`: i386_defconfig and x86_64_defconfig The build scripts now require two updates: 1. um's Kconfig (arch/x86/um/Kconfig) should specify an ARCH_DEFCONFIG section explicitly pointing to these scripts if the required variables are set. Take care to remove the DEFCONFIG_LIST section defined in the included file arch/um/Kconfig.common. 2. um's Makefile (arch/um/Makefile) should set KBUILD_DEFCONFIG properly for the top-level Makefile to pick up. Copy the logic in arch/x86/Makefile to properly pick the defconfig file depending on the actual architecture; except we're working with $SUBARCH here, instead of $ARCH. Now, you can do: $ ARCH=um make defconfig $ ARCH=um make and successfully build User-Mode Linux on an x86_64 box in default configuration. Cc: Richard Weinberger Cc: Jeff Dike Signed-off-by: Ramkumar Ramachandra --- arch/um/Kconfig.common | 5 - arch/um/Makefile | 11 + arch/um/configs/i386_defconfig | 76 arch/um/configs/x86_64_defconfig | 75 arch/um/defconfig| 899 --- arch/x86/um/Kconfig | 5 + 6 files changed, 167 insertions(+), 904 deletions(-) create mode 100644 arch/um/configs/i386_defconfig create mode 100644 arch/um/configs/x86_64_defconfig delete mode 100644 arch/um/defconfig diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common index 8ddea1f..21ca44c 100644 --- a/arch/um/Kconfig.common +++ b/arch/um/Kconfig.common @@ -1,8 +1,3 @@ -config DEFCONFIG_LIST - string - option defconfig_list - default "arch/$ARCH/defconfig" - config UML bool default y diff --git a/arch/um/Makefile b/arch/um/Makefile index 133f7de..48d92bb 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -6,6 +6,17 @@ # Licensed under the GPL # +# select defconfig based on actual architecture +ifeq ($(SUBARCH),x86) + ifeq ($(shell uname -m),x86_64) +KBUILD_DEFCONFIG := x86_64_defconfig + else +KBUILD_DEFCONFIG := i386_defconfig + endif +else +KBUILD_DEFCONFIG := $(SUBARCH)_defconfig +endif + ARCH_DIR := arch/um OS := $(shell uname -s) # We require bash because the vmlinux link and loader script cpp use bash diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig new file mode 100644 index 000..a12bf68 --- /dev/null +++ b/arch/um/configs/i386_defconfig @@ -0,0 +1,76 @@ +CONFIG_3_LEVEL_PGTABLES=y +# CONFIG_COMPACTION is not set +CONFIG_BINFMT_MISC=m +CONFIG_HOSTFS=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_KERNEL_STACK_ORDER=1 +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_SCHED=y +CONFIG_BLK_CGROUP=y +# CONFIG_PID_NS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SLAB=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_IOSCHED_CFQ=m +CONFIG_SSL=y +CONFIG_NULL_CHAN=y +CONFIG_PORT_CHAN=y +CONFIG_PTY_CHAN=y +CONFIG_TTY_CHAN=y +CONFIG_XTERM_CHAN=y +CONFIG_CON_CHAN="pts" +CONFIG_SSL_CHAN="pts" +CONFIG_UML_SOUND=m +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_BLK_DEV_UBD=y +CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_NBD=m +CONFIG_DUMMY=m +CONFIG_TUN=m +CONFIG_PPP=m +CONFIG_SLIP=m +CONFIG_LEGACY_PTY_COUNT=32 +# CONFIG_HW_RANDOM is not set +CONFIG_UML_RANDOM=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +# CONFIG_INET_LRO is not set +# CONFIG_IPV6 is not set +CONFIG_UML_NET=y +CONFIG_UML_NET_ETHERTAP=y +CONFIG_UML_NET_TUNTAP=y +CONFIG_UML_NET_SLIP=y +CONFIG_UML_NET_DAEMON=y +CONFIG_UML_NET_MCAST=y +CONFIG_UML_NET_SLIRP=y +CONFIG_EXT4_FS=y +CONFIG_REISERFS_FS=y +CONFIG_QUOTA=y +CONFIG_AUTOFS4_FS=m +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_PROC_KCORE=y +CONFIG_TMPFS=y +CONFIG_NLS=y +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_KERNEL=y diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig new file mode 100644 index 000..3aab117 --- /dev/null +++ b/arch/um/configs/x86_64_defconfig @@ -0,0 +1,75 @@ +# CONFIG_COMPACTION is not set +CONFIG_BINFMT_MISC=m +CONFIG_HOSTFS=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_SCHED=y +CONFIG_BLK_CGROUP=y +# CONFIG_PID_NS is not set
[PATCH 0/2] More plesant User-Mode Linux build
Hi, The first patch does the meat of the work of getting rid of the bloated i386-specific defconfig and replacing it with two tiny ones, and updating the Makefile/ Kconfig. SUBARCH is now auto-detected correctly, and can be overridden on the command-line. I've tested both the x86_64 kernel with an x86_64 userland, as well as the i386 kernel with an i386 userland. The second patch is just a related "while we're there". Thanks. Ramkumar Ramachandra (2): arch/um: make it work with defconfig and x86_64 um/vdso: add .gitignore for a couple of targets arch/um/Kconfig.common | 5 - arch/um/Makefile | 11 + arch/um/configs/i386_defconfig | 76 arch/um/configs/x86_64_defconfig | 75 arch/um/defconfig| 899 --- arch/x86/um/Kconfig | 5 + arch/x86/um/vdso/.gitignore | 2 + 7 files changed, 169 insertions(+), 904 deletions(-) create mode 100644 arch/um/configs/i386_defconfig create mode 100644 arch/um/configs/x86_64_defconfig delete mode 100644 arch/um/defconfig create mode 100644 arch/x86/um/vdso/.gitignore -- 1.8.4.299.gb3e7d24.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MAINTAINERS: remove Richard Purdie as backlight maintainer
Remove Richard Purdie as backlight subsystem maintainer, since he is not responding for a few years. Signed-off-by: Jingoo Han Cc: Richard Purdie --- MAINTAINERS |1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 146ade4..398819c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1645,7 +1645,6 @@ S:Maintained F: drivers/net/wireless/b43legacy/ BACKLIGHT CLASS/SUBSYSTEM -M: Richard Purdie M: Jingoo Han S: Maintained F: drivers/video/backlight/ -- 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/
Urgent Confidential Respond.
Dear Friend My Name is Dr. Cabiru Bello .I am a banker by professio .I hail from Ouagadougou, Burkina Faso, West Africa.My reason for contacting you is to transfer an abandoned $10, 300, 000.00 (Ten Million Three Hundred Thousand Dollars) to your account. The owner of this fund died since 2003 with his Next Of Kin. I want to present you to the bank as the Next of Kin/beneficiary of this fund. Further details of the transaction shall be forwarded to you as soon as I receive your return mail indicating your interest.You can contact me at this private email address: cabirubell...@gmail.com Best regards, Dr. Cabiru Bello -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] extcon next for 3.13
On Fri, Sep 27, 2013 at 10:28:20AM +0900, Chanwoo Choi wrote: > Hi Greg, > > This is extcon-next pull request for 3.13. I add detailed description of this > pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: > > Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-3.13 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
Hello, Chen. On Fri, Sep 27, 2013 at 09:30:13AM +0800, Chen Gang wrote: > As an integrator or large source code maintainer, we cannot only depend > on testing, or tracing log, or some short directly causes; we also need > find and solve issues by checking sub-systems' interface or documents. Do you seriously think that you're the only one thinking the above? You're repeating something obvious. The problem is that that's *all* you're doing. Anyone who has *some* coding experience would know that and you didn't move even an inch forward from there. What you have done is obvious from your initial commit message, you read some random piece of code, found something slightly inconsistent with your concept of ideal construction, grepped a bit, and whipped up that patch. It's such a perfect cliche of inexperience. It's something immediately obvious and *exactly* why you were asked to actually try out your hypothesis. It was supposed to serve two purposes - either proving or disproving your patch && if your knee-jerk patch was wrong, which I thought was likely given the circumstances, making you think *why* you got it wrong and learn from the experience. When asked to actually verify your patch, you thought it was something you were unfairly asked to do, and when your previous analysis was shown to be wrong as so easily predicted, instead of thinking about why you got that wrong and learning from the experience, you're now just repeating the same crap in the opposite direction. You're missing massive amount of steps between recognizing that something is inconsistent and producing a proper improvement for it and failing to recognize your shortcoming even when it failed right in front of your face. You need to understand how the subsystem and code actually work before making changes, study the callers and history of the code especially if the code has been stable / stale for long period of time, verify your assumptions using objective measures, and present that in your patch. For a patch like this, preferably with some risk analysis. So, please take some time to mull over why your initial patch was completely wrong and I didn't even have to read the code to predict that your patch has high chance of being wrong. Now, you're doing the *exactly* same thing in the opposite direction. You should be able to recognize that there's something very wrong with that. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] digsig: use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
Signed-off-by: Duan Jiong
---
lib/digsig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/digsig.c b/lib/digsig.c
index 2f31e6a..8793aed 100644
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@ -209,7 +209,7 @@ int digsig_verify(struct key *keyring, const char *sig, int
siglen,
kref = keyring_search(make_key_ref(keyring, 1UL),
_type_user, name);
if (IS_ERR(kref))
- key = ERR_PTR(PTR_ERR(kref));
+ key = ERR_CAST(kref);
else
key = key_ref_to_ptr(kref);
} else {
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
On Thursday, September 26, 2013 9:08 PM, Tomi Valkeinen wrote: > On 26/09/13 14:51, Thierry Reding wrote: > > On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote: > > [...] > >> But if you and Thierry think this version is good, I'll take it. > > > > That sounds like you want to take it through the fbdev tree. Jingoo is > > listed (along with Richard, but he hasn't been responsive to email for > > years) as maintainer for the backlight subsystem. Furthermore back at > > Ah, so they are. I just thought it falls under fbdev, as it's under > drivers/video/ =). > > I don't have any particular "want" to take it through fbdev tree. But I > can take it. > > > the time when I began working on the PWM subsystem, the backlight sub- > > system was pretty much orphaned, and pwm-backlight was by far the > > biggest user of the PWM subsystem. I adopted the driver at the time > > because it needed to be updated for PWM subsystem changes. > > > > What's the plan going forward? Given the coupling between the PWM > > subsystem and the pwm-backlight driver it might be useful to keep > > maintaining it as part of the PWM subsystem. On the other hand, there's > > some coupling between the driver and the backlight subsystem too. > > And backlight is coupled with fbdev... Which is something I don't like. +cc Laurent Pinchart, Yes, right. The backlight should be de-coupled with fbdev. I remember that Laurent Pinchart was doing this patch. Laurent Pinchart, Would you let us know your plan about this? :-) > > > I have a couple of patches queued up for 3.13 that rework parts of the > > driver, so it'd be good to know how you guys want to handle this. > > Well. I'm happy if somebody wants to maintain the backlight side. In > fact, I'd be happy if somebody would start restructuring it totally, > it's rather messy. The link with fbdev should be removed, and some > backlight drivers are actually panel drivers. However, perhaps Common > Display Framework is required until it can be fully cleaned. I think that some backlight drivers can be moved to 'Common Display Framework', after 'Common Display Framework' is merged. But, I am not sure, when it will be completed. Best regards, Jingoo Han > > So... For the time being, I'm fine with merging pwm-backlight via any > tree that works best. I'm presuming here that backlight framework and > fbdev (for the parts that are relevant for backlight) are not really > being changed, so there shouldn't be conflicts. > > Tomi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the bluetooth tree with the wireless tree
Hi Gustavo,
Today's linux-next merge of the bluetooth tree got a conflict in
net/bluetooth/hci_core.c between commit 5e130367d43f ("Bluetooth:
Introduce a new HCI_RFKILLED flag") from the wireless tree and commit
0736cfa8e5bb ("Bluetooth: Introduce user channel flag for HCI devices")
from the bluetooth tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
P.S. that closing brace is badly indented :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/bluetooth/hci_core.c
index 1b66547,3d9f02b..000
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@@ -1570,13 -1642,13 +1646,16 @@@ static int hci_rfkill_set_block(void *d
BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
+ if (test_bit(HCI_USER_CHANNEL, >dev_flags))
+ return -EBUSY;
+
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, >dev_flags);
+ if (!test_bit(HCI_SETUP, >dev_flags))
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, >dev_flags);
+}
return 0;
}
pgpudlRdVHHUm.pgp
Description: PGP signature
[PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
Hello all, Here is the continuation of work of representing hardware thermal properties in device tree infrastructure. The present patch series is the fourth version of this work. Previous versions were sent as RFCs and can be found here: V3: RFCv2: http://lkml.org/lkml/2013/8/23/594 RFCv1: http://lkml.org/lkml/2013/7/22/319 Major difference from V3 is on the parser itself. I have updated the binding documentation and improved the code accordingly to previous comments mainly from Mark R. and Joe P. The changes on hwmon drivers have been accepted by Guenter, and in this series I am including his Acked-by, as I didn't change anything on that side. I also found a bug while using all involved code built as modules, thus I have reworked a bit the cooling device registration part. This is why there are two new patches in this series (patches 02 and 04). Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7, although this series is not including the DRA7 part (I will be sending separately). Thanks all who have been contributing reviewing this code. All best, Eduardo Valentin (18): thermal: allow registering without .get_temp thermal: core: allow binding via .bind when tzp is present thermal: introduce device tree parser thermal: core: introduce thermal_of_cooling_device_register thermal: cpu_cooling: introduce of_cpufreq_cooling_register cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties hwmon: lm75: expose to thermal fw via DT nodes hwmon: tmp102: expose to thermal fw via DT nodes thermal: ti-soc-thermal: use thermal DT infrastructure arm: dts: add omap4 CPU thermal data arm: dts: add omap4430 thermal data arm: dts: add omap4460 thermal data arm: dts: add cooling properties on omap4430 cpu node arm: dts: add cooling properties on omap4460 cpu node arm: dts: add omap5 GPU thermal data arm: dts: add omap5 CORE thermal data arm: dts: add omap5 thermal data arm: dts: add cooling properties on omap5 cpu node .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 + .../devicetree/bindings/thermal/thermal.txt| 537 + arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41 + arch/arm/boot/dts/omap443x.dtsi| 15 +- arch/arm/boot/dts/omap4460.dtsi| 15 +- arch/arm/boot/dts/omap5-core-thermal.dtsi | 28 + arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28 + arch/arm/boot/dts/omap5.dtsi | 15 +- drivers/cpufreq/Kconfig| 2 +- drivers/cpufreq/cpufreq-cpu0.c | 16 + drivers/hwmon/lm75.c | 35 +- drivers/hwmon/tmp102.c | 19 + drivers/thermal/Kconfig| 14 + drivers/thermal/Makefile | 1 + drivers/thermal/cpu_cooling.c | 56 +- drivers/thermal/of-thermal.c | 845 + drivers/thermal/thermal_core.c | 79 +- drivers/thermal/thermal_core.h | 9 + drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +- include/dt-bindings/thermal/thermal.h | 27 + include/linux/cpu_cooling.h| 25 + include/linux/thermal.h| 32 +- 22 files changed, 1880 insertions(+), 43 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi create mode 100644 drivers/thermal/of-thermal.c create mode 100644 include/dt-bindings/thermal/thermal.h -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm-backlight: allow for non-increasing brightness levels
On Thursday, September 26, 2013 10:00 PM, Thierry Reding wrote: > On Thu, Sep 26, 2013 at 03:08:22PM +0300, Tomi Valkeinen wrote: > > On 26/09/13 14:51, Thierry Reding wrote: > > > On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote: > > > [...] > > >> But if you and Thierry think this version is good, I'll take it. > > > > > > That sounds like you want to take it through the fbdev tree. Jingoo is > > > listed (along with Richard, but he hasn't been responsive to email for > > > years) as maintainer for the backlight subsystem. Furthermore back at > > > > Ah, so they are. I just thought it falls under fbdev, as it's under > > drivers/video/ =). > > > > I don't have any particular "want" to take it through fbdev tree. But I > > can take it. > > > > > the time when I began working on the PWM subsystem, the backlight sub- > > > system was pretty much orphaned, and pwm-backlight was by far the > > > biggest user of the PWM subsystem. I adopted the driver at the time > > > because it needed to be updated for PWM subsystem changes. > > > > > > What's the plan going forward? Given the coupling between the PWM > > > subsystem and the pwm-backlight driver it might be useful to keep > > > maintaining it as part of the PWM subsystem. On the other hand, there's > > > some coupling between the driver and the backlight subsystem too. > > > > And backlight is coupled with fbdev... Which is something I don't like. > > > > > I have a couple of patches queued up for 3.13 that rework parts of the > > > driver, so it'd be good to know how you guys want to handle this. > > > > Well. I'm happy if somebody wants to maintain the backlight side. In > > fact, I'd be happy if somebody would start restructuring it totally, > > it's rather messy. The link with fbdev should be removed, and some > > backlight drivers are actually panel drivers. However, perhaps Common > > Display Framework is required until it can be fully cleaned. > > > > So... For the time being, I'm fine with merging pwm-backlight via any > > tree that works best. I'm presuming here that backlight framework and > > fbdev (for the parts that are relevant for backlight) are not really > > being changed, so there shouldn't be conflicts. > > In that case I'll just take it through the PWM tree as I've done for the > past year. I have some other changes planned for the PWM framework for > the near future that'll create dependencies between the PWM tree and the > pwm-backlight driver, so keeping them in one tree will make it easier to > merge them. Yes, I think so. I want you to take the patches for pwm-backlight through the PWM tree, as you have done. > > Longer term it probably makes sense, as you say, for someone to take > over the backlight subsystem completely and give it the love it could > really use. If Jingoo can do that, it'd be great. Perhaps it'd be a good > idea to remove Richard as maintainer since he's obviously no longer > responding to emails. Keeping him Cc'ed on all patches is just > pointless. OK, I will send the patch to remove Richard as maintainer. I will make a git tree and mailing-list for the backlight subsystem later. However, I am not certain when it will be done. :-( 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/
[PATCHv4 12/18] arm: dts: add omap4460 thermal data
This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4460.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..4d93aba 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
- cpu@0 {
+ cpu0: cpu@0 {
operating-points = <
/* kHzuV */
35 1025000
@@ -30,12 +30,18 @@
ti,hwmods = "debugss";
};
- bandgap {
+ thermal-zones{
+ #include "omap4-cpu-thermal.dtsi"
+ };
+
+ bandgap: bandgap {
reg = <0x4a002260 0x4
0x4a00232C 0x4
0x4a002378 0x18>;
compatible = "ti,omap4460-bandgap";
interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
gpios = < 22 0>; /* tshut */
+
+ #thermal-sensor-cells = <0>;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the wireless-next tree with the net-next tree
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/rtlwifi/rtl8192ce/phy.h between commit a958df5dc306
("rtlwifi: Remove extern from function prototypes") from the net-next
tree and commit 3a1ea9fd9351 ("rtlwifi: remove duplicate declarations and
macros in headers") from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
index f8973e5,80a0893..000
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.h
@@@ -217,10 -222,10 +215,9 @@@ void _rtl92ce_phy_lc_calibrate(struct i
void rtl92c_phy_set_rfpath_switch(struct ieee80211_hw *hw, bool bmain);
bool rtl92c_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
enum radio_path rfpath);
-bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw,
-u32 rfpath);
+bool rtl8192_phy_check_is_legal_rfpath(struct ieee80211_hw *hw, u32 rfpath);
- bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
bool rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
-enum rf_pwrstate rfpwr_state);
+ enum rf_pwrstate rfpwr_state);
void rtl92ce_phy_set_rf_on(struct ieee80211_hw *hw);
bool rtl92c_phy_set_io_cmd(struct ieee80211_hw *hw, enum io_type iotype);
void rtl92c_phy_set_io(struct ieee80211_hw *hw);
pgpyWLdBVXVoI.pgp
Description: PGP signature
[PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 187cb71..a35cd61 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,9 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
+
+ /* cooling options */
+ #cooling-cells = <2>; /* min followed by max */
};
cpu@1 {
device_type = "cpu";
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..3e9dc00
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+core_thermal: core_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = < 2>;
+
+ trips {
+ core_crit: core_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 17/18] arm: dts: add omap5 thermal data
This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..187cb71 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,7 +33,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
@@ -45,6 +45,12 @@
};
};
+ thermal-zones {
+ #include "omap4-cpu-thermal.dtsi"
+ #include "omap5-gpu-thermal.dtsi"
+ #include "omap5-core-thermal.dtsi"
+ };
+
timer {
compatible = "arm,armv7-timer";
/* PPI secure/nonsecure IRQ */
@@ -705,13 +711,15 @@
};
};
- bandgap@4a0021e0 {
+ bandgap: bandgap@4a0021e0 {
reg = <0x4a0021e0 0xc
0x4a00232c 0xc
0x4a002380 0x2c
0x4a0023C0 0x3c>;
interrupts = ;
compatible = "ti,omap5430-bandgap";
+
+ #thermal-sensor-cells = <1>;
};
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 CHAR-MISC-NEXT 4/4] Intel MIC Header File warning fix.
On Thu, Sep 26, 2013 at 06:10:23PM -0700, Sudeep Dutt wrote:
> usr/include/linux/mic_ioctl.h:37:
> found __[us]{8,16,32,64} type without #include
What is that from? What does it mean?
confused,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: Russell King Cc: linux-o...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/boot/dts/omap4460.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 4d93aba..dc22719 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,11 @@ 92 1313000 >; clock-latency = <30>; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = <0>; + cooling-max-level = <2>; + #cooling-cells = <2>; /* min followed by max */ }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41
1 file changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..65a6deb
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+thermal-sensors = < 0>;
+
+trips {
+cpu_alert0: cpu_alert {
+temperature = <10>; /* millicelsius */
+hysteresis = <2000>; /* millicelsius */
+type = THERMAL_TRIP_PASSIVE;
+};
+cpu_crit: cpu_crit {
+temperature = <125000>; /* millicelsius */
+hysteresis = <2000>; /* millicelsius */
+type = THERMAL_TRIP_CRITICAL;
+};
+};
+
+ cooling-maps {
+ map0 {
+ trip = <_alert0>;
+ cooling-device =
+ < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..8941c8e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = < 1>;
+
+ trips {
+ gpu_crit: gpu_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 11/18] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points = <
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
- bandgap {
+ thermal-zones{
+ #include "omap4-cpu-thermal.dtsi"
+ };
+
+ bandgap: bandgap {
reg = <0x4a002260 0x4
0x4a00232C 0x4>;
compatible = "ti,omap4430-bandgap";
+
+ #thermal-sensor-cells = <0>;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 CHAR-MISC-NEXT 2/4] Intel MIC Driver Header File Cleanups.
On Thu, Sep 26, 2013 at 06:10:01PM -0700, Sudeep Dutt wrote: > Dont use same name for header files in different folders. > > These changes were suggested by Greg Kroah-Hartman during the > code review @ https://lkml.org/lkml/2013/9/6/18 > > Signed-off-by: Ashutosh Dixit > Signed-off-by: Dasaratharaman Chandramouli > > Signed-off-by: Nikhil Rao > Signed-off-by: Harshavardhan R Kharche > Signed-off-by: Sudeep Dutt > --- > drivers/misc/mic/card/mic_debugfs.c | 2 +- > drivers/misc/mic/card/mic_device.c | 2 +- > drivers/misc/mic/card/mic_virtio.c | 2 +- > drivers/misc/mic/card/mic_x100.c | 2 +- > drivers/misc/mic/common/mic_dev.h| 51 > > drivers/misc/mic/common/mic_device.h | 51 > > drivers/misc/mic/host/mic_boot.c | 2 +- > drivers/misc/mic/host/mic_debugfs.c | 2 +- > drivers/misc/mic/host/mic_fops.c | 2 +- > drivers/misc/mic/host/mic_intr.c | 2 +- > drivers/misc/mic/host/mic_main.c | 2 +- > drivers/misc/mic/host/mic_smpt.c | 2 +- > drivers/misc/mic/host/mic_sysfs.c| 2 +- > drivers/misc/mic/host/mic_virtio.c | 2 +- > drivers/misc/mic/host/mic_x100.c | 2 +- > 15 files changed, 64 insertions(+), 64 deletions(-) > create mode 100644 drivers/misc/mic/common/mic_dev.h > delete mode 100644 drivers/misc/mic/common/mic_device.h git should have shown this file being renamed, not added/removed. Please use the -M option to it when generating patches so it will do the right thing here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Russell King Cc: linux-o...@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/boot/dts/omap443x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index e9c97d6..930ab47 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,11 @@ 1008000 1375000 >; clock-latency = <30>; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = <0>; + cooling-max-level = <3>; + #cooling-cells = <2>; /* min followed by max */ }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 06/18] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
the cpu0 device tree node needs to be properly configured
with cooling device properties.
In case these properties are present,, the driver will
load a cpufreq cooling device in the system. The cpufreq-cpu0
driver is not interested in determining how the system should
be using the cooling device. The driver is responsible
only of loading the cooling device.
Describing how the cooling device will be used can be
accomplished by setting up a thermal zone that references
and is composed by the cpufreq cooling device.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Grant Likely
Cc: Rob Herring
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 +++
drivers/cpufreq/Kconfig | 2 +-
drivers/cpufreq/cpufreq-cpu0.c | 16
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..f055515 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+ Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
Examples:
@@ -33,6 +37,9 @@ cpus {
198000 85
>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
+ cooling-min-level = <0>;
+ cooling-max-level = <2>;
};
cpu@1 {
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 534fcb8..fc1e9a5 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
config GENERIC_CPUFREQ_CPU0
tristate "Generic CPU0 cpufreq driver"
- depends on HAVE_CLK && REGULATOR && PM_OPP && OF
+ depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL &&
CPU_THERMAL
select CPU_FREQ_TABLE
help
This adds a generic cpufreq driver for CPU0 frequency management.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 78c49d8..fd707b8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -13,7 +13,9 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -21,6 +23,7 @@
#include
#include
#include
+#include
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
@@ -29,6 +32,7 @@ static struct device *cpu_dev;
static struct clk *cpu_clk;
static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
+static struct thermal_cooling_device *cdev;
static int cpu0_verify_speed(struct cpufreq_policy *policy)
{
@@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_free_table;
}
+ /*
+* For now, just loading the cooling device;
+* thermal DT code takes care of matching them.
+*/
+ if (of_find_property(np, "#cooling-cells", NULL)) {
+ cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
+ if (IS_ERR(cdev))
+ pr_err("running cpufreq without cooling device: %ld\n",
+ PTR_ERR(cdev));
+ }
+
of_node_put(np);
return 0;
@@ -272,6 +287,7 @@ out_put_node:
static int cpu0_cpufreq_remove(struct platform_device *pdev)
{
+ cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, _table);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 09/18] thermal: ti-soc-thermal: use thermal DT infrastructure
This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.
The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.
In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +-
1 file changed, 62 insertions(+), 15 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 4f8b9af..b80b5b8 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "ti-thermal.h"
#include "ti-bandgap.h"
@@ -44,6 +45,7 @@ struct ti_thermal_data {
enum thermal_device_mode mode;
struct work_struct thermal_wq;
int sensor_id;
+ bool our_zone;
};
static void ti_thermal_work(struct work_struct *work)
@@ -75,11 +77,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int
s, int c)
/* thermal zone ops */
/* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, long *temp)
{
struct thermal_zone_device *pcb_tz = NULL;
- struct ti_thermal_data *data = thermal->devdata;
+ struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +118,14 @@ static inline int ti_thermal_get_temp(struct
thermal_zone_device *thermal,
return ret;
}
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ struct ti_thermal_data *data = thermal->devdata;
+
+ return __ti_thermal_get_temp(data, temp);
+}
+
/* Bind callback functions for thermal zone */
static int ti_thermal_bind(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev)
@@ -229,11 +238,9 @@ static int ti_thermal_get_trip_temp(struct
thermal_zone_device *thermal,
return 0;
}
-/* Get the temperature trend callback functions for thermal zone */
-static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
- int trip, enum thermal_trend *trend)
+static int __ti_thermal_get_trend(void *p, long *trend)
{
- struct ti_thermal_data *data = thermal->devdata;
+ struct ti_thermal_data *data = p;
struct ti_bandgap *bgp;
int id, tr, ret = 0;
@@ -244,6 +251,22 @@ static int ti_thermal_get_trend(struct thermal_zone_device
*thermal,
if (ret)
return ret;
+ *trend = tr;
+
+ return 0;
+}
+
+/* Get the temperature trend callback functions for thermal zone */
+static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
+ int trip, enum thermal_trend *trend)
+{
+ int ret;
+ long tr;
+
+ ret = __ti_thermal_get_trend(thermal->devdata, );
+ if (ret)
+ return ret;
+
if (tr > 0)
*trend = THERMAL_TREND_RAISING;
else if (tr < 0)
@@ -307,16 +330,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int
id,
if (!data)
return -EINVAL;
- /* Create thermal zone */
- data->ti_thermal = thermal_zone_device_register(domain,
+ /* in case this is specified by DT */
+ data->ti_thermal = thermal_zone_of_sensor_register(bgp->dev, id,
+ data, __ti_thermal_get_temp,
+ __ti_thermal_get_trend);
+ if (IS_ERR(data->ti_thermal)) {
+ /* Create thermal zone */
+ data->ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, _thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE);
- if (IS_ERR(data->ti_thermal)) {
- dev_err(bgp->dev, "thermal zone device is NULL\n");
- return PTR_ERR(data->ti_thermal);
+ if
[PATCHv4 07/18] hwmon: lm75: expose to thermal fw via DT nodes
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/lm75.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..1d3600a 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include "lm75.h"
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -90,22 +93,36 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/*---*/
+static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
+{
+ return ((temp >> (16 - resolution)) * 1000) >> (resolution - 8);
+}
+
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, long *temp)
+{
+ struct lm75_data *data = lm75_update_device(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ *temp = lm75_reg_to_mc(data->temp[0], data->resolution);
+
+ return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
struct lm75_data *data = lm75_update_device(dev);
- long temp;
if (IS_ERR(data))
return PTR_ERR(data);
- temp = ((data->temp[attr->index] >> (16 - data->resolution)) * 1000)
- >> (data->resolution - 8);
-
- return sprintf(buf, "%ld\n", temp);
+ return sprintf(buf, "%ld\n", lm75_reg_to_mc(data->temp[attr->index],
+ data->resolution));
}
static ssize_t set_temp(struct device *dev, struct device_attribute *da,
@@ -271,6 +288,13 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+ data->tz = thermal_zone_of_sensor_register(>dev,
+ 0,
+ >dev,
+ lm75_read_temp, NULL);
+ if (IS_ERR(data->tz))
+ data->tz = NULL;
+
dev_info(>dev, "%s: sensor '%s'\n",
dev_name(data->hwmon_dev), client->name);
@@ -285,6 +309,7 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+ thermal_zone_of_sensor_unregister(>dev, data->tz);
hwmon_device_unregister(data->hwmon_dev);
sysfs_remove_group(>dev.kobj, _group);
lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 00/18] device thermal limits represented in device tree nodes (v4)
On 26-09-2013 23:13, Eduardo Valentin wrote: > Hello all, > > Here is the continuation of work of representing hardware thermal properties > in device tree infrastructure. The present patch series is the fourth version > of this work. Previous versions were sent as RFCs and can be found here: > V3: Too fast, hit send too early. For those interested, here is the link to V3: https://lkml.org/lkml/2013/9/15/122 > RFCv2: http://lkml.org/lkml/2013/8/23/594 > RFCv1: http://lkml.org/lkml/2013/7/22/319 > > Major difference from V3 is on the parser itself. I have updated the binding > documentation and improved the code accordingly to previous comments mainly > from Mark R. and Joe P. > > The changes on hwmon drivers have been accepted by Guenter, and in this > series I am including his Acked-by, as I didn't change anything on that side. > > I also found a bug while using all involved code built as modules, thus > I have reworked a bit the cooling device registration part. This is why > there are two new patches in this series (patches 02 and 04). > > Tests were done, just like in V3, on TI OMAP4430, OMAP4460, OMAP5430 and DRA7, > although this series is not including the DRA7 part (I will be sending > separately). > > Thanks all who have been contributing reviewing this code. > > All best, > > Eduardo Valentin (18): > thermal: allow registering without .get_temp > thermal: core: allow binding via .bind when tzp is present > thermal: introduce device tree parser > thermal: core: introduce thermal_of_cooling_device_register > thermal: cpu_cooling: introduce of_cpufreq_cooling_register > cpufreq: cpufreq-cpu0: add dt node parsing for cooling device > properties > hwmon: lm75: expose to thermal fw via DT nodes > hwmon: tmp102: expose to thermal fw via DT nodes > thermal: ti-soc-thermal: use thermal DT infrastructure > arm: dts: add omap4 CPU thermal data > arm: dts: add omap4430 thermal data > arm: dts: add omap4460 thermal data > arm: dts: add cooling properties on omap4430 cpu node > arm: dts: add cooling properties on omap4460 cpu node > arm: dts: add omap5 GPU thermal data > arm: dts: add omap5 CORE thermal data > arm: dts: add omap5 thermal data > arm: dts: add cooling properties on omap5 cpu node > > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 + > .../devicetree/bindings/thermal/thermal.txt| 537 + > arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41 + > arch/arm/boot/dts/omap443x.dtsi| 15 +- > arch/arm/boot/dts/omap4460.dtsi| 15 +- > arch/arm/boot/dts/omap5-core-thermal.dtsi | 28 + > arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28 + > arch/arm/boot/dts/omap5.dtsi | 15 +- > drivers/cpufreq/Kconfig| 2 +- > drivers/cpufreq/cpufreq-cpu0.c | 16 + > drivers/hwmon/lm75.c | 35 +- > drivers/hwmon/tmp102.c | 19 + > drivers/thermal/Kconfig| 14 + > drivers/thermal/Makefile | 1 + > drivers/thermal/cpu_cooling.c | 56 +- > drivers/thermal/of-thermal.c | 845 > + > drivers/thermal/thermal_core.c | 79 +- > drivers/thermal/thermal_core.h | 9 + > drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 77 +- > include/dt-bindings/thermal/thermal.h | 27 + > include/linux/cpu_cooling.h| 25 + > include/linux/thermal.h| 32 +- > 22 files changed, 1880 insertions(+), 43 deletions(-) > create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt > create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi > create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi > create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi > create mode 100644 drivers/thermal/of-thermal.c > create mode 100644 include/dt-bindings/thermal/thermal.h > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
[PATCHv4 08/18] hwmon: tmp102: expose to thermal fw via DT nodes
This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Guenter Roeck
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/tmp102.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..6748b45 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#defineDRIVER_NAME "tmp102"
@@ -50,6 +52,7 @@
struct tmp102 {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client
*client)
return tmp102;
}
+static int tmp102_read_temp(void *dev, long *temp)
+{
+ struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+ *temp = tmp102->temp[0];
+
+ return 0;
+}
+
static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
+ tmp102->tz = thermal_zone_of_sensor_register(>dev, 0,
+>dev,
+tmp102_read_temp, NULL);
+ if (IS_ERR(tmp102->tz))
+ tmp102->tz = NULL;
+
dev_info(>dev, "initialized\n");
return 0;
@@ -220,6 +238,7 @@ static int tmp102_remove(struct i2c_client *client)
{
struct tmp102 *tmp102 = i2c_get_clientdata(client);
+ thermal_zone_of_sensor_unregister(>dev, tmp102->tz);
hwmon_device_unregister(tmp102->hwmon_dev);
sysfs_remove_group(>dev.kobj, _attr_group);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 04/18] thermal: core: introduce thermal_of_cooling_device_register
This patch adds a new API to allow registering cooling devices
in the thermal framework derived from device tree nodes.
This API links the cooling device with the device tree node
so that binding with thermal zones is possible, given
that thermal zones are pointing to cooling device
device tree nodes.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/thermal_core.c | 58 +++---
include/linux/thermal.h| 4 +++
2 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index fec3351..5325fee 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1053,7 +1054,8 @@ static struct class thermal_class = {
};
/**
- * thermal_cooling_device_register() - register a new thermal cooling device
+ * __thermal_cooling_device_register() - register a new thermal cooling device
+ * @np:a pointer to a device tree node.
* @type: the thermal cooling device type.
* @devdata: device private data.
* @ops: standard thermal cooling devices callbacks.
@@ -1061,13 +1063,16 @@ static struct class thermal_class = {
* This interface function adds a new thermal cooling device
(fan/processor/...)
* to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind
itself
* to all the thermal zone devices registered at the same time.
+ * It also gives the opportunity to link the cooling device to a device tree
+ * node, so that it can be bound to a thermal zone created out of device tree.
*
* Return: a pointer to the created struct thermal_cooling_device or an
* ERR_PTR. Caller must check return value with IS_ERR*() helpers.
*/
-struct thermal_cooling_device *
-thermal_cooling_device_register(char *type, void *devdata,
- const struct thermal_cooling_device_ops *ops)
+static struct thermal_cooling_device *
+__thermal_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct thermal_cooling_device_ops *ops)
{
struct thermal_cooling_device *cdev;
int result;
@@ -1092,6 +1097,7 @@ thermal_cooling_device_register(char *type, void *devdata,
strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
mutex_init(>lock);
INIT_LIST_HEAD(>thermal_instances);
+ cdev->np = np;
cdev->ops = ops;
cdev->updated = true;
cdev->device.class = _class;
@@ -1134,9 +1140,53 @@ unregister:
device_unregister(>device);
return ERR_PTR(result);
}
+
+/**
+ * thermal_cooling_device_register() - register a new thermal cooling device
+ * @type: the thermal cooling device type.
+ * @devdata: device private data.
+ * @ops: standard thermal cooling devices callbacks.
+ *
+ * This interface function adds a new thermal cooling device
(fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind
itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_cooling_device_register(char *type, void *devdata,
+ const struct thermal_cooling_device_ops *ops)
+{
+ return __thermal_cooling_device_register(NULL, type, devdata, ops);
+}
EXPORT_SYMBOL_GPL(thermal_cooling_device_register);
/**
+ * thermal_of_cooling_device_register() - register an OF thermal cooling device
+ * @np:a pointer to a device tree node.
+ * @type: the thermal cooling device type.
+ * @devdata: device private data.
+ * @ops: standard thermal cooling devices callbacks.
+ *
+ * This function will register a cooling device with device tree node
reference.
+ * This interface function adds a new thermal cooling device
(fan/processor/...)
+ * to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind
itself
+ * to all the thermal zone devices registered at the same time.
+ *
+ * Return: a pointer to the created struct thermal_cooling_device or an
+ * ERR_PTR. Caller must check return value with IS_ERR*() helpers.
+ */
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct thermal_cooling_device_ops *ops)
+{
+ return __thermal_cooling_device_register(np, type, devdata, ops);
+}
+EXPORT_SYMBOL_GPL(thermal_of_cooling_device_register);
+
+/**
* thermal_cooling_device_unregister - removes the registered thermal cooling
device
* @cdev: the
Re: [PATCH CHAR-MISC-NEXT 1/4] Intel MIC Host Driver Sysfs Cleanups.
On Thu, Sep 26, 2013 at 06:09:51PM -0700, Sudeep Dutt wrote: > + Use DEVICE_ATTR_RO/RW instead of DEVICE_ATTR > + Use ATTRIBUTE_GROUPS > > These changes were suggested by Greg Kroah-Hartman during the > code review @ https://lkml.org/lkml/2013/9/6/13 > > Signed-off-by: Ashutosh Dixit > Signed-off-by: Dasaratharaman Chandramouli > > Signed-off-by: Nikhil Rao > Signed-off-by: Harshavardhan R Kharche > Signed-off-by: Sudeep Dutt > --- Ok, new kernel developer 101 training time :) Your Subject:, while the [PATCH] part is fine the rest of the line needs to be a bit more descriptive. As this is the "mic" subsystem, how about something like: Subject: [PATCH 1/4] misc: mic: host driver sysfs cleanups No need for the whole "Intel MIC" stuff. Also, as I "reported" this, you should have a: Reported-by: Greg Kroah-Hartman <...> line in the patch. And really, all of those people reviewed and signed off on the patch? That's great, just not a normal thing. So, can you resend these 4 patches with those things cleaned up? Same thing goes for Joe's patch, he deserves a "Reported-by:" at the very least, given that he pretty much wrote that whole patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv7 03/18] thermal: introduce device tree parser
This patch introduces a device tree bindings for describing the hardware thermal behavior and limits. Also a parser to read and interpret the data and feed it in the thermal framework is presented. This patch introduces a thermal data parser for device tree. The parsed data is used to build thermal zones and thermal binding parameters. The output data can then be used to deploy thermal policies. This patch adds also documentation regarding this API and how to define tree nodes to use this infrastructure. Note that, in order to be able to have control on the sensor registration on the DT thermal zone, it was required to allow changing the thermal zone .get_temp callback. For this reason, this patch also removes the 'const' modifier from the .ops field of thermal zone devices. Cc: Zhang Rui Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- Hello folks, For those interested on this work, here is a short changelog from v6: - Reviewed binding documentation and added type and size on all properties - Described 'thermal-zones' node in binding documentation - Using now cooling state terminology instead of cooling level - Renamed milliCelsius to millicelsius - Renamed cooling-attachments to 'cooling-maps' - Renamed sensor to thermal sensor - Renamed #sensor-cells to #thermal-sensor-cells - #thermal-sensor-cells now is allowed to be 0 - Renamed 'sensors' property to 'thermal-sensors' - Changed trip type property to be now string and documented possible values - Described better the cooling properties - Now parses 'contribution' instead of 'usage' - Renamed cdev to cooling device - Renamed 'passive-delay' property to 'polling-delay-passive' - Fixed a couple of error messages to match the property name - Fixed a binding issue while using cpufreq as module - Reworked thermal_of_build_thermal_zone function so that it frees requested memory if something goes wrong and checks for sub-nodes with zero children. --- .../devicetree/bindings/thermal/thermal.txt| 537 + drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/of-thermal.c | 845 + drivers/thermal/thermal_core.c | 9 +- drivers/thermal/thermal_core.h | 9 + include/dt-bindings/thermal/thermal.h | 27 + include/linux/thermal.h| 28 +- 8 files changed, 1466 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 drivers/thermal/of-thermal.c create mode 100644 include/dt-bindings/thermal/thermal.h diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt new file mode 100644 index 000..3dbc017 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal.txt @@ -0,0 +1,537 @@ +* Thermal Framework Device Tree descriptor + +Generic binding to provide a way of defining hardware thermal +structure using device tree. A thermal structure includes thermal +zones and their components, such as trip points, polling intervals, +sensors and cooling devices binding descriptors. + +The target of device tree thermal descriptors is to describe only +the hardware thermal aspects, not how the system must control or which +algorithm or policy must be taken in place. + +There are five types of nodes involved to describe thermal bindings: +- sensors: used to describe the device source of temperature sensing; +- cooling devices: used to describe devices source of power dissipation control; +- trip points: used to describe points in temperature domain defined to +make the system aware of hardware limits; +- cooling maps: used to describe links between trip points and +cooling devices; +- thermal zones: used to describe thermal data within the hardware; + +It follows a description of each type of these device tree nodes. + +Note: This binding is a working in progress. + +* Thermal sensor devices + +Thermal sensor devices are nodes providing temperature sensing capabilities on +thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are +nodes providing temperature data to thermal zones. Thermal sensor devices may +control one or more internal sensors. + +Required property: +- #thermal-sensor-cells: Used to provide sensor device specific information + Type: unsignedwhile referring to it. Typically 0, on thermal sensor + Size: one cellnodes with only one sensor, and at least 1 on nodes +with several internal sensors, in order +to identify uniquely the sensor instances within +the IC. See thermal zone binding for more details +on how consumers refer to sensor devices. + +* Cooling device nodes + +Cooling devices are nodes providing
[PATCHv4 05/18] thermal: cpu_cooling: introduce of_cpufreq_cooling_register
This patch introduces an API to register cpufreq cooling device
based on device tree node.
The registration via device tree node differs from normal
registration due to the fact that it is needed to fill
the device_node structure in order to be able to match
the cooling devices with trip points.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfig | 1 +
drivers/thermal/cpu_cooling.c | 56 ++-
include/linux/cpu_cooling.h | 25 +++
3 files changed, 76 insertions(+), 6 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index dd81eb8..9e7cc3f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -91,6 +91,7 @@ config THERMAL_GOV_USER_SPACE
config CPU_THERMAL
bool "generic cpu cooling support"
depends on CPU_FREQ
+ depends on THERMAL_OF
select CPU_FREQ_TABLE
help
This implements the generic cpu cooling mechanism through frequency
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index d179028..b7db93a 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -417,18 +417,21 @@ static struct notifier_block
thermal_cpufreq_notifier_block = {
};
/**
- * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * __cpufreq_cooling_register - helper function to create cpufreq cooling
device
+ * @np: a valid struct device_node to the cooling device device tree node
* @clip_cpus: cpumask of cpus where the frequency constraints will happen.
*
* This interface function registers the cpufreq cooling device with the name
* "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
- * cooling devices.
+ * cooling devices. It also gives the opportunity to link the cooling device
+ * with a device tree node, in order to bind it via the thermal DT code.
*
* Return: a valid struct thermal_cooling_device pointer on success,
* on failure, it returns a corresponding ERR_PTR().
*/
-struct thermal_cooling_device *
-cpufreq_cooling_register(const struct cpumask *clip_cpus)
+static struct thermal_cooling_device *
+__cpufreq_cooling_register(struct device_node *np,
+ const struct cpumask *clip_cpus)
{
struct thermal_cooling_device *cool_dev;
struct cpufreq_cooling_device *cpufreq_dev = NULL;
@@ -467,8 +470,8 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
cpufreq_dev->id);
- cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
- _cooling_ops);
+ cool_dev = thermal_of_cooling_device_register(np, dev_name, cpufreq_dev,
+ _cooling_ops);
if (!cool_dev) {
release_idr(_idr, cpufreq_dev->id);
kfree(cpufreq_dev);
@@ -488,9 +491,50 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus)
return cool_dev;
}
+
+/**
+ * cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+cpufreq_cooling_register(const struct cpumask *clip_cpus)
+{
+ return __cpufreq_cooling_register(NULL, clip_cpus);
+}
EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
/**
+ * of_cpufreq_cooling_register - function to create cpufreq cooling device.
+ * @np: a valid struct device_node to the cooling device device tree node
+ * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
+ *
+ * This interface function registers the cpufreq cooling device with the name
+ * "thermal-cpufreq-%x". This api can support multiple instances of cpufreq
+ * cooling devices. Using this API, the cpufreq cooling device will be
+ * linked to the device tree node provided.
+ *
+ * Return: a valid struct thermal_cooling_device pointer on success,
+ * on failure, it returns a corresponding ERR_PTR().
+ */
+struct thermal_cooling_device *
+of_cpufreq_cooling_register(struct device_node *np,
+ const struct cpumask *clip_cpus)
+{
+ if (!np)
+ return ERR_PTR(-EINVAL);
+
+ return __cpufreq_cooling_register(np, clip_cpus);
+}
+EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
+
+/**
* cpufreq_cooling_unregister - function to remove cpufreq cooling device.
* @cdev: thermal cooling device pointer.
*
diff --git a/include/linux/cpu_cooling.h
[PATCHv4 01/18] thermal: allow registering without .get_temp
This patch changes the thermal core driver to allow
registration of thermal zones without the .get_temp callback.
The idea behind this change is to allow lazy registration
of sensor callbacks.
The thermal zone will be disabled whenever the ops
does not contain a .get_temp callback. The sysfs interface
will be returning -EINVAL on any temperature read operation.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/thermal_core.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 4962a6a..8a94300 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -402,7 +402,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz,
unsigned long *temp)
enum thermal_trip_type type;
#endif
- if (!tz || IS_ERR(tz))
+ if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
goto exit;
mutex_lock(>lock);
@@ -455,6 +455,9 @@ void thermal_zone_device_update(struct thermal_zone_device
*tz)
{
int count;
+ if (!tz->ops->get_temp)
+ return;
+
update_temperature(tz);
for (count = 0; count < tz->trips; count++)
@@ -1384,7 +1387,7 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips)
return ERR_PTR(-EINVAL);
- if (!ops || !ops->get_temp)
+ if (!ops)
return ERR_PTR(-EINVAL);
if (trips > 0 && (!ops->get_trip_type || !ops->get_trip_temp))
@@ -1488,6 +1491,9 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
+ if (!tz->ops->get_temp)
+ thermal_zone_device_set_polling(tz, 0);
+
thermal_zone_device_update(tz);
if (!result)
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 02/18] thermal: core: allow binding via .bind when tzp is present
This patch allows drivers register thermal zone devices
with thermal zone params and .bind callbacks. In this case,
it will use the .bind callback.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/thermal_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8a94300..f7a9f4f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -247,7 +247,7 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (!pos->tzp && !pos->ops->bind)
continue;
- if (!pos->tzp && pos->ops->bind) {
+ if (pos->ops->bind) {
ret = pos->ops->bind(pos, cdev);
if (ret)
print_bind_err_msg(pos, cdev, ret);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gma500: define do_gma_backlight_set only when used
On Thu, Sep 26, 2013 at 11:46 PM, Vincent Stehlé
wrote:
> Make sure static function do_gma_backlight_set() is only defined when
> CONFIG_BACKLIGHT_CLASS_DEVICE is defined, as it is never called otherwise.
>
> This fixes the following warning:
>
> drivers/gpu/drm/gma500/backlight.c:29:13: warning: ‘do_gma_backlight_set’
> defined but not used [-Wunused-function]
>
> While at it, remove some end of line spaces.
>
> Signed-off-by: Vincent Stehlé
> Cc: David Airlie
> ---
>
> Hi,
>
> This can be seen with mainline or linux-next with e.g. allmodconfig on x86.
>
> Best regards,
>
> V.
>
> drivers/gpu/drm/gma500/backlight.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/backlight.c
> b/drivers/gpu/drm/gma500/backlight.c
> index 143eba3..399731e 100644
> --- a/drivers/gpu/drm/gma500/backlight.c
> +++ b/drivers/gpu/drm/gma500/backlight.c
> @@ -26,13 +26,13 @@
> #include "intel_bios.h"
> #include "power.h"
>
> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> static void do_gma_backlight_set(struct drm_device *dev)
> {
> -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> struct drm_psb_private *dev_priv = dev->dev_private;
> backlight_update_status(dev_priv->backlight_device);
> -#endif
> }
> +#endif
>
> void gma_backlight_enable(struct drm_device *dev)
> {
> @@ -43,7 +43,7 @@ void gma_backlight_enable(struct drm_device *dev)
> dev_priv->backlight_device->props.brightness =
> dev_priv->backlight_level;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> void gma_backlight_disable(struct drm_device *dev)
> @@ -55,7 +55,7 @@ void gma_backlight_disable(struct drm_device *dev)
> dev_priv->backlight_device->props.brightness = 0;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> void gma_backlight_set(struct drm_device *dev, int v)
> @@ -67,7 +67,7 @@ void gma_backlight_set(struct drm_device *dev, int v)
> dev_priv->backlight_device->props.brightness = v;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> int gma_backlight_init(struct drm_device *dev)
> --
> 1.8.4.rc3
Thanks, looks good, I'll apply it to the gma500-fixes branch.
Acked-by: Patrik Jakobsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the wireless tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h between commit
db4efbbeb457 ("brcmfmac: obtain platform data upon module
initialization") from the wireless tree and commit 9bd91f3c00bd
("brcm80211: Remove extern from function prototypes") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
index 74156f8,5bc0276..000
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
@@@ -132,35 -132,33 +132,34 @@@ struct pktq *brcmf_bus_gettxq(struct br
* interface functions from common layer
*/
- extern bool brcmf_c_prec_enq(struct device *dev, struct pktq *q,
-struct sk_buff *pkt, int prec);
+ bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff *pkt,
+ int prec);
/* Receive frame for delivery to OS. Callee disposes of rxp. */
- extern void brcmf_rx_frames(struct device *dev, struct sk_buff_head *rxlist);
+ void brcmf_rx_frames(struct device *dev, struct sk_buff_head *rxlist);
/* Indication from bus module regarding presence/insertion of dongle. */
- extern int brcmf_attach(uint bus_hdrlen, struct device *dev);
+ int brcmf_attach(uint bus_hdrlen, struct device *dev);
/* Indication from bus module regarding removal/absence of dongle */
- extern void brcmf_detach(struct device *dev);
+ void brcmf_detach(struct device *dev);
/* Indication from bus module that dongle should be reset */
- extern void brcmf_dev_reset(struct device *dev);
+ void brcmf_dev_reset(struct device *dev);
/* Indication from bus module to change flow-control state */
- extern void brcmf_txflowblock(struct device *dev, bool state);
+ void brcmf_txflowblock(struct device *dev, bool state);
/* Notify the bus has transferred the tx packet to firmware */
- extern void brcmf_txcomplete(struct device *dev, struct sk_buff *txp,
-bool success);
+ void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
- extern int brcmf_bus_start(struct device *dev);
+ int brcmf_bus_start(struct device *dev);
#ifdef CONFIG_BRCMFMAC_SDIO
- extern void brcmf_sdio_exit(void);
- extern void brcmf_sdio_init(void);
- extern void brcmf_sdio_register(void);
+ void brcmf_sdio_exit(void);
+ void brcmf_sdio_init(void);
++void brcmf_sdio_register(void);
#endif
#ifdef CONFIG_BRCMFMAC_USB
- extern void brcmf_usb_exit(void);
- extern void brcmf_usb_register(void);
+ void brcmf_usb_exit(void);
-void brcmf_usb_init(void);
++void brcmf_usb_register(void);
#endif
#endif/* _BRCMF_BUS_H_ */
pgpVTQ_M_ugpB.pgp
Description: PGP signature
Re: [f2fs-dev] [PATCH] f2fs: use rw_sem instead of fs_lock(locks mutex)
Hi Jin,
Thanks for your comments.
On 09/26/2013 08:31 PM, Jin Xu wrote:
> Great to see fs_locks is to be replaced. :)
>
> There is a potential problem with using r/w semaphore this way. The
> thread doing checkpoint might get starved if other threads are
> intensively locking the read semaphore for I/O.
Yes, it's a weakness of r/w semaphore.
> I noticed that Josef
> introduced a rwsem_is_contended for solving similar issue happening
> in btrfs recently. Maybe it's not a problem for f2fs. I haven't
> verified that yet.
All users of r/w semaphore will face this problem, not only btrfs and f2fs.
IMHO, it's easy to fix, just like Josef's rwsem_is_contended, I'll fix this in
version next. And if rwsem_is_contended is merged into mainline kernel, we can
consider using the common function.
>
> In addition, maybe we should avoid using the "rwsem" or "mutex" as
> part of the routine name to make the name independent of actual lock
> mechanism. It seems better using:
> f2fs_lock/unlock_all instead of write_lock/unlock_cp_rwsem
> f2fs_lock/unlock_op instead of read_lock/unlock_cp_rwsem
Got it, the original name seems more suitable.
Best regards,
Gu
>
> Regards,
> Jin
>
> On 26/09/2013 17:40, Gu Zheng wrote:
>> The fs_locks is used to block other ops(ex, recovery) when doing checkpoint.
>> And each other operate routine(besides checkpoint) needs to acquire a
>> fs_lock,
>> there is a terrible problem here, if these are too many concurrency threads
>> acquiring
>> fs_lock, so that they will block each other and may lead to some performance
>> problem.
>> But this is not the phenomenon we want to see.
>> Though there are some optimization patches introduced to enhance the usage
>> of fs_lock,
>> but the thorough solution is using a *rw_sem* to replace the fs_lock.
>> Checkpoint routine takes write_sem, and other ops take read_sem, so that we
>> can block
>> other ops(ex, recovery) when doing checkpoint, and other ops will not
>> disturb each other,
>> this can avoid the problem described above completely.
>>
>> Thanks to Kim's review and test, and other guys' test is also welcome.
>>
>> Reviewed-by: Jaegeuk Kim
>> Tested-by: Jaegeuk Kim
>> Signed-off-by: Gu Zheng
>> ---
>> fs/f2fs/checkpoint.c |7 ++---
>> fs/f2fs/data.c | 11 -
>> fs/f2fs/f2fs.h | 52
>> -
>> fs/f2fs/file.c | 37 ---
>> fs/f2fs/inode.c | 11 -
>> fs/f2fs/namei.c | 50
>> +++-
>> fs/f2fs/recovery.c |7 ++---
>> fs/f2fs/super.c |4 +--
>> fs/f2fs/xattr.c |7 +
>> 9 files changed, 69 insertions(+), 117 deletions(-)
>>
>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>> index ca39442..1f3bd47 100644
>> --- a/fs/f2fs/checkpoint.c
>> +++ b/fs/f2fs/checkpoint.c
>> @@ -619,11 +619,10 @@ static void block_operations(struct f2fs_sb_info *sbi)
>> blk_start_plug();
>>
>> retry_flush_dents:
>> -mutex_lock_all(sbi);
>> -
>> +write_lock_cp_rwsem(sbi);
>
> It seems better to use name f2fs_lock_all instead of
> write_lock_cp_rwsem.
>
>> /* write all the dirty dentry pages */
>> if (get_pages(sbi, F2FS_DIRTY_DENTS)) {
>> -mutex_unlock_all(sbi);
>> +write_unlock_cp_rwsem(sbi);
>
> f2fs_lock_
>> sync_dirty_dir_inodes(sbi);
>> goto retry_flush_dents;
>> }
>> @@ -646,7 +645,7 @@ retry_flush_nodes:
>> static void unblock_operations(struct f2fs_sb_info *sbi)
>> {
>> mutex_unlock(>node_write);
>> -mutex_unlock_all(sbi);
>> +write_unlock_cp_rwsem(sbi);
>> }
>>
>> static void do_checkpoint(struct f2fs_sb_info *sbi, bool is_umount)
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index 941f9b9..5f9ddc1 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -560,9 +560,9 @@ write:
>> inode_dec_dirty_dents(inode);
>> err = do_write_data_page(page);
>> } else {
>> -int ilock = mutex_lock_op(sbi);
>> +read_lock_cp_rwsem(sbi);
>> err = do_write_data_page(page);
>> -mutex_unlock_op(sbi, ilock);
>> +read_unlock_cp_rwsem(sbi);
>> need_balance_fs = true;
>> }
>> if (err == -ENOENT)
>> @@ -641,7 +641,6 @@ static int f2fs_write_begin(struct file *file, struct
>> address_space *mapping,
>> pgoff_t index = ((unsigned long long) pos) >> PAGE_CACHE_SHIFT;
>> struct dnode_of_data dn;
>> int err = 0;
>> -int ilock;
>>
>> f2fs_balance_fs(sbi);
>> repeat:
>> @@ -650,7 +649,7 @@ repeat:
>> return -ENOMEM;
>> *pagep = page;
>>
>> -ilock = mutex_lock_op(sbi);
>> +read_lock_cp_rwsem(sbi);
>>
>> set_new_dnode(, inode, NULL, NULL, 0);
>> err = get_dnode_of_data(, index, ALLOC_NODE);
>> @@ -664,7 +663,7 @@ repeat:
>> if (err)
>> goto err;
>>
>> -mutex_unlock_op(sbi, ilock);
>> +
Re: [PATCH 1/1] arm64: X-Gene AHBC platform bus driver
On Thu, Sep 26, 2013 at 8:19 PM, Feng Kan wrote:
> This driver setup the AHBC for SPI and SD drivers to use.
>
> Signed-off-by: Feng Kan
>
> ---
> arch/arm64/boot/dts/apm-storm.dtsi |6 +
> drivers/bus/Kconfig|9 ++
> drivers/bus/Makefile |2 +
> drivers/bus/xgene_ahbc.c | 193
>
A full driver seems like overkill for just boot and resume time
initialization of a couple of registers.
> 4 files changed, 210 insertions(+), 0 deletions(-)
> create mode 100644 drivers/bus/xgene_ahbc.c
>
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
> b/arch/arm64/boot/dts/apm-storm.dtsi
> index d994806..b9477ec 100644
> --- a/arch/arm64/boot/dts/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -178,6 +178,12 @@
> };
> };
>
> +ahbc: ahbc@1f2a {
> +device_type = "ahbc";
device_type should not be used. It is generally only for legacy, but
there are are few exceptions.
> +compatible = "apm,xgene-ahbc";
Needs to be documented.
> +reg = <0x0 0x1f2a 0x0 0x8>;
> +};
> +
> serial0: serial@1c02 {
> device_type = "serial";
> compatible = "ns16550";
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 1f70e84..6cc361c68 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -42,4 +42,13 @@ config ARM_CCI
> help
> Driver supporting the CCI cache coherent interconnect for ARM
> platforms.
> +
> +config XGENE_AHBC
> + tristate "X-Gene SoC AHB Bus Driver"
> + depends on ARM64 && ARCH_XGENE
> + default y if ARCH_XGENE
> + help
> + X-Gene SoC AHB bus driver is required for SPI and
> + SDIO to function properly.
> +
> endmenu
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 8947bdd..0c7a4ca 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -10,3 +10,5 @@ obj-$(CONFIG_OMAP_OCP2SCP)+= omap-ocp2scp.o
> obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o
> # CCI cache coherent interconnect for ARM platforms
> obj-$(CONFIG_ARM_CCI) += arm-cci.o
> +
> +obj-$(CONFIG_XGENE_AHBC) += xgene_ahbc.o
> diff --git a/drivers/bus/xgene_ahbc.c b/drivers/bus/xgene_ahbc.c
> new file mode 100644
> index 000..9554bb4
> --- /dev/null
> +++ b/drivers/bus/xgene_ahbc.c
> @@ -0,0 +1,193 @@
> +/**
> + * AppliedMicro X-Gene AHBC Driver
> + *
> + * Copyright (c) 2013, Applied Micro Circuits Corporation
> + * Author: Loc Ho
> + * Author: Feng Kan
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + *
> + */
> +#include
> +#include
> +#include
I don't see any clock code...
> +#include
> +#include
or OF address code...
> +#include
> +#include
> +
> +#define AHBC_DRIVER_VER"0.1"
Will this really be maintained or mean anything?
> +
> +#define AIM_8_SIZE_CTL_ADDR0x0104
> +#define AIM_8_AXI_LO_ADDR 0x0108
> +#define AIM_8_AXI_HI_ADDR 0x010c
> +
> +#define ARSB_F8_WR(src)(((u32)(src)<<23) &
> 0x0380)
> +#define AWSB_F8_WR(src)(((u32)(src)<<20) &
> 0x0070)
> +#define AIM_AXI_ADDRESS_LO_8_WR(src) (((u32)(src)) & 0x000f)
> +
> +/* Global Base Address */
> +#define REGSPEC_AHBC_GLBL_DIAG_CSR_I_BASE_ADDR 0x01f2ad000ULL
> +
> +#define REGSPEC_CFG_MEM_RAM_SHUTDOWN_ADDR 0x0070
> +#define REGSPEC_BLOCK_MEM_RDY_ADDR 0x0074
> +
> +static void xgene_ahb_write(void *base, u32 offset, u32 val)
This seems like pointless abstraction.
> +{
> + if (base == NULL)
> + return;
Do you really need to check every access?
> +
> + writel_relaxed(val, base + offset);
> +}
> +
> +static void xgene_ahbc_init_mem(struct platform_device *pdev)
> +{
> + void *ahbc_base = platform_get_drvdata(pdev);
> + u32 diag_offset = REGSPEC_AHBC_GLBL_DIAG_CSR_I_BASE_ADDR &
Re: [PATCH] i2c-designware: define i2c_dw_pci_runtime_idle only with runtime pm
On Fri, Sep 27, 2013 at 12:24:03AM +0200, Vincent Stehlé wrote:
> Make sure i2c_dw_pci_runtime_idle() is defined only when actually used, when
> CONFIG_PM_RUNTIME is defined.
>
> This fixes the following compilation warning:
>
> drivers/i2c/busses/i2c-designware-pcidrv.c:188:12: warning:
> ‘i2c_dw_pci_runtime_idle’ defined but not used [-Wunused-function]
>
> Signed-off-by: Vincent Stehlé
> Cc: Wolfram Sang
I wonder if this fix is complete? Mika?
> ---
> drivers/i2c/busses/i2c-designware-pcidrv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index f6ed06c..2b5d3a6 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -185,6 +185,7 @@ static int i2c_dw_pci_resume(struct device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_RUNTIME
> static int i2c_dw_pci_runtime_idle(struct device *dev)
> {
> int err = pm_schedule_suspend(dev, 500);
> @@ -194,6 +195,7 @@ static int i2c_dw_pci_runtime_idle(struct device *dev)
> return 0;
> return -EBUSY;
> }
> +#endif
>
> static const struct dev_pm_ops i2c_dw_pm_ops = {
Shouldn't this be using UNIVERSAL_DEV_PM_OPS with the suspend and resume
function #ifdeffed by CONFIG_PM_SLEEP?
> .resume = i2c_dw_pci_resume,
> --
> 1.8.4.rc3
>
signature.asc
Description: Digital signature
[PATCH v2] i2c: i2c-dev: Create 'name' attribute automatically
The 'name' attribute is needed for all i2c-dev class devices, meaning
it can be created automatically by pointing to it in the class data
structure. This simplifies the code and reduces the probability for race
conditions (the name attribute should exist by the time the device is
announced to user space).
Signed-off-by: Guenter Roeck
---
v2: Use class->dev_groups instead of class->dev_attrs
Better use of device macros
Simplify changes: there is no need to declare i2c_dev_class statically,
so revert to use class_create/class_destroy.
Test results:
$ grep . /sys/class/i2c-dev/*/name
/sys/class/i2c-dev/i2c-0/name:i915 gmbus ssc
/sys/class/i2c-dev/i2c-1/name:i915 gmbus vga
/sys/class/i2c-dev/i2c-2/name:i915 gmbus panel
/sys/class/i2c-dev/i2c-3/name:i915 gmbus dpc
/sys/class/i2c-dev/i2c-4/name:i915 gmbus dpb
/sys/class/i2c-dev/i2c-5/name:i915 gmbus dpd
/sys/class/i2c-dev/i2c-6/name:DPDDC-B
/sys/class/i2c-dev/i2c-7/name:DPDDC-C
/sys/class/i2c-dev/i2c-8/name:DPDDC-D
/sys/class/i2c-dev/i2c-9/name:SMBus I801 adapter at f040
drivers/i2c/i2c-dev.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index c3ccdea..80b47e8 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -102,8 +102,8 @@ static void return_i2c_dev(struct i2c_dev *i2c_dev)
kfree(i2c_dev);
}
-static ssize_t show_adapter_name(struct device *dev,
-struct device_attribute *attr, char *buf)
+static ssize_t name_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct i2c_dev *i2c_dev = i2c_dev_get_by_minor(MINOR(dev->devt));
@@ -111,7 +111,13 @@ static ssize_t show_adapter_name(struct device *dev,
return -ENODEV;
return sprintf(buf, "%s\n", i2c_dev->adap->name);
}
-static DEVICE_ATTR(name, S_IRUGO, show_adapter_name, NULL);
+static DEVICE_ATTR_RO(name);
+
+static struct attribute *i2c_attrs[] = {
+ _attr_name.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(i2c);
/* - */
@@ -562,15 +568,10 @@ static int i2cdev_attach_adapter(struct device *dev, void
*dummy)
res = PTR_ERR(i2c_dev->dev);
goto error;
}
- res = device_create_file(i2c_dev->dev, _attr_name);
- if (res)
- goto error_destroy;
pr_debug("i2c-dev: adapter [%s] registered as minor %d\n",
adap->name, adap->nr);
return 0;
-error_destroy:
- device_destroy(i2c_dev_class, MKDEV(I2C_MAJOR, adap->nr));
error:
return_i2c_dev(i2c_dev);
return res;
@@ -589,7 +590,6 @@ static int i2cdev_detach_adapter(struct device *dev, void
*dummy)
if (!i2c_dev) /* attach_adapter must have failed */
return 0;
- device_remove_file(i2c_dev->dev, _attr_name);
return_i2c_dev(i2c_dev);
device_destroy(i2c_dev_class, MKDEV(I2C_MAJOR, adap->nr));
@@ -637,6 +637,7 @@ static int __init i2c_dev_init(void)
res = PTR_ERR(i2c_dev_class);
goto out_unreg_chrdev;
}
+ i2c_dev_class->dev_groups = i2c_groups;
/* Keep track of adapters which will be added or removed later */
res = bus_register_notifier(_bus_type, _notifier);
--
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the ceph tree
On 09/26/2013 08:31 PM, Stephen Rothwell wrote:
> Hi Sage,
>
> After merging the ceph tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/ceph/file.c: In function 'ceph_sync_direct_write':
> fs/ceph/file.c:545:24: error: 'struct iov_iter' has no member named 'iov'
>void __user *data = i.iov->iov_base + i.iov_offset;
> ^
> fs/ceph/file.c:546:14: error: 'struct iov_iter' has no member named 'iov'
>u64 len = i.iov->iov_len - i.iov_offset;
> ^
>
> This also happened yesterday but was swamped by the other error (now fixed).
>
> Caused by commit d4ce96db671b ("ceph: Implement writev/pwritev for sync
> operation") interacting with commit f6794d33a5ec ("iov_iter: hide iovec
> details behind ops function pointers") from the aio-direct tree.
>
> I applied the following merge fix patch (but there may be a better
> solution):
>
> From: Stephen Rothwell
> Date: Fri, 27 Sep 2013 11:28:05 +1000
> Subject: [PATCH] ceph: fix up for iov_iter changes
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/ceph/file.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 5cf034e..1216372 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -542,8 +542,8 @@ ceph_sync_direct_write(struct kiocb *iocb, const struct
> iovec *iov,
> iov_iter_init(, iov, nr_segs, count, 0);
>
> while (iov_iter_count() > 0) {
> - void __user *data = i.iov->iov_base + i.iov_offset;
> - u64 len = i.iov->iov_len - i.iov_offset;
> + void __user *data = iov_iter_iovec()->iov_base + i.iov_offset;
> + u64 len = iov_iter_iovec()->iov_len - i.iov_offset;
>
> page_align = (unsigned long)data & ~PAGE_MASK;
>
iov_iter_iovec() will resolve to iov, so this is a little simpler
Signed-off-by: Dave Kleikamp
---
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 5cf034e..d9aa924 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -542,8 +542,8 @@ ceph_sync_direct_write(struct kiocb *iocb, const
struct iovec *iov,
iov_iter_init(, iov, nr_segs, count, 0);
while (iov_iter_count() > 0) {
- void __user *data = i.iov->iov_base + i.iov_offset;
- u64 len = i.iov->iov_len - i.iov_offset;
+ void __user *data = iov->iov_base + i.iov_offset;
+ u64 len = iov->iov_len - i.iov_offset;
page_align = (unsigned long)data & ~PAGE_MASK;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hello
I am Lee Kam Leung, a senior Asset Manager and Actuary with C.T.B Corporation, in Beijing, China. I am contacting you with regards to a discreet and somewhat sensitive business asset available to my knowledge by virtue of my position. I will furnish you with further exclusive and of course, confidential details once I receive your affirmatory response Reply to this e-mail address : l.lee...@yahoo.com.hk Faithfully, Lee Kam Leung. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks()
On 09/27/2013 02:33 AM, Paul E. McKenney wrote: > On Thu, Sep 26, 2013 at 10:57:39AM +0800, Chen Gang wrote: >> On 09/26/2013 04:16 AM, Paul E. McKenney wrote: >>> On Wed, Sep 25, 2013 at 10:55:30AM +0800, Chen Gang wrote: Thank you for your whole work, firstly :-). And your suggestion about testing (in our discussion) is also valuable to me. I need start LTP in q4. After referenced your suggestion, my first step for using/learning LTP is not mainly for finding kernel issues, but for testing kernel (to improve my kernel testing efficiency). When I want to find issues by reading code, I will consider about LTP too (I will try to find issues which can be tested by LTP). >>> >>> Doing more testing will be good! You will probably need more tests >>> than just LTP, but you must of course start somewhere. >> >> Give more testing is good, but also mean more time resources cost. If >> spend the 'cost', also need get additional 'contributions' (not only >> prove an issue), or the 'efficiency' can not be 'acceptable'. >> >> When "I need more tests than just LTP", firstly I need perform this >> test, and then, also try to send "test case" to LTP (I guess, these >> kinds of mails are welcomed by LTP). >> >> And LTP is also a way to find kernel issues, although I will not mainly >> depend on it now (but maybe in future), it is better to familiar with it >> step by step. >> >> LTP (Linux Test Project) is one of main kernel mad user at downstream. >> Tool chain (GCC/Binutils) is one of kernel main mad tools at upstream. >> If we face to the whole kernel, suggest to use them. ;-) > > Yep, starting with just LTP is OK. But if by this time next year you > really should be using more than just LTP. > Hmm... LTP is "Linux Test Project", if I make some test cases which is useful for the issue which I find, I guess, these test cases are also welcomed by LTP. Except testing, "I really should be using more than just LTP" (just like you said). e.g. Tool Chain: just I am trying. According to my current time resources, within this year, I can not finish allmodconfig on all architectures. :-( I am just solving one gcc issue, it seems it is not quite difficult, but at least now, I have no time on it. :-( Documents: just I am trying. I am trying to discuss API definition comments, but it seems I am not well done. :-( I am also trying some of trivial patches, neither seems what I have done is well enough. :-( Communicating and discussing related issues with other members. Only this, it seems not quite bad. :-) LTP: I will try in q4 2013. In fact, when I first comes to our Public Kernel, I already use LTP (and disccus an nfs issue by LTP test), which is still suspending. :-( In my original plan (not declare to outside), I want to start LTP in q3 2013, but fails (because of no time resources). :-( Bugzilla: plan to try in next year. I also want to solve some issues which comes from Bugzilla (especially for some issues which no one wants to try). but according to my current action result and time resources, I can not dare to declare it to outside in next year. :-( And I still have some company internal things to do (which may be urgent, sometimes), it will consume my 20-40% time resources. :-( So, please understand with each other: every members' time resource is expensive, we have to take care of it. and also, I thank all members who can spend their time resources on my mail and disccus with me. Thanks. > Thanx, Paul > On 09/25/2013 09:29 AM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > The for_each_rcu_flavor() loop unconditionally scans all flavors, even > when the first flavor might have some non-lazy callbacks. Once the > loop has seen a non-lazy callback, further passes through the loop > cannot change the state. This is not a huge problem, given that there > can be at most three RCU flavors (RCU-bh, RCU-preempt, and RCU-sched), > but this code is on the path to idle, so speeding it up even a small > amount would have some benefit. > > This commit therefore does two things: > > 1.Rearranges the order of the list of RCU flavors in order to > place the most active flavor first in the list. The most active > RCU flavor is RCU-preempt, or, if there is no RCU-preempt, > RCU-sched. > > 2.Reworks the for_each_rcu_flavor() to exit early when the first > non-lazy callback is seen, or, in the case where the caller > does not care about non-lazy callbacks (RCU_FAST_NO_HZ=n), > when the first callback is seen. > > Reported-by: Chen Gang > Signed-off-by: Paul E. McKenney > --- > kernel/rcutree.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git
Re: [PATCH] perf tools: Add missing -ldl for gtk build
On Thu, 26 Sep 2013 20:55:54 +0200, Jiri Olsa wrote: > If we build perf with NO_LIBPYTHON=1 NO_LIBPERL=1 the '-ldl' > is not added to libs build fails if we have gtk2 code in, > because it depends on it. Argh... Thanks for fixing this! Acked-by: Namhyung Kim Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] cpuidle: calxeda: add support to use PSCI calls
From: Rob Herring
This updates the Calxeda cpuidle driver to use PSCI calls to powergate
cores. This is needed to enable cpuidle for the ECX-2000.
This could possibly become a generic PSCI driver, but there are no other
PSCI users in the kernel other than mach-virt.
Signed-off-by: Rob Herring
Cc: "Rafael J. Wysocki"
Cc: Daniel Lezcano
Cc: linux...@vger.kernel.org
---
drivers/cpuidle/Kconfig.arm | 2 +-
drivers/cpuidle/cpuidle-calxeda.c | 40 ++-
2 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 8e36603..d6f57d5 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -4,7 +4,7 @@
config ARM_HIGHBANK_CPUIDLE
bool "CPU Idle Driver for Calxeda processors"
- depends on ARCH_HIGHBANK
+ depends on ARM_PSCI
select ARM_CPU_SUSPEND
help
Select this to enable cpuidle on Calxeda processors.
diff --git a/drivers/cpuidle/cpuidle-calxeda.c
b/drivers/cpuidle/cpuidle-calxeda.c
index 3460584..01cfecf3 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -22,51 +22,23 @@
#include
#include
-#include
#include
-#include
-#include
-#include
#include
-#include
-#include
#include
-#include
-#include
-
-extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
-extern void __iomem *scu_base_addr;
-
-static noinline void calxeda_idle_restore(void)
-{
- set_cr(get_cr() | CR_C);
- set_auxcr(get_auxcr() | 0x40);
- scu_power_mode(scu_base_addr, SCU_PM_NORMAL);
-}
+#include
static int calxeda_idle_finish(unsigned long val)
{
- /* Already flushed cache, but do it again as the outer cache functions
-* dirty the cache with spinlocks */
- flush_cache_all();
-
- set_auxcr(get_auxcr() & ~0x40);
- set_cr(get_cr() & ~CR_C);
-
- scu_power_mode(scu_base_addr, SCU_PM_DORMANT);
-
- cpu_do_idle();
-
- /* Restore things if we didn't enter power-gating */
- calxeda_idle_restore();
- return 1;
+ const struct psci_power_state ps = {
+ .type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+ };
+ return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
}
static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- highbank_set_cpu_jump(smp_processor_id(), cpu_resume);
cpu_suspend(0, calxeda_idle_finish);
return index;
}
@@ -90,7 +62,7 @@ static struct cpuidle_driver calxeda_idle_driver = {
static int __init calxeda_cpuidle_init(void)
{
- if (!of_machine_is_compatible("calxeda,highbank"))
+ if (!of_machine_is_compatible("calxeda,highbank") ||
!psci_ops.cpu_suspend)
return -ENODEV;
return cpuidle_register(_idle_driver, NULL);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] cpuidle: calxeda: add cpu_pm_enter/exit calls
From: Rob Herring
Wnen powergating the core, we need to call cpu pm notifiers to save VFP
state (!SMP only) and resetting the breakpoint h/w.
Signed-off-by: Rob Herring
Cc: "Rafael J. Wysocki"
Cc: Daniel Lezcano
Cc: linux...@vger.kernel.org
---
drivers/cpuidle/cpuidle-calxeda.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-calxeda.c
b/drivers/cpuidle/cpuidle-calxeda.c
index 01cfecf3..b04767a 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include
#include
#include
@@ -39,7 +40,10 @@ static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
+ cpu_pm_enter();
cpu_suspend(0, calxeda_idle_finish);
+ cpu_pm_exit();
+
return index;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ARM: PSCI: remove unnecessary include of arm-gic.h
From: Rob Herring Now that gic_secondary_init is no longer needed to be called by SMP init functions, the header is not needed. Signed-off-by: Rob Herring Cc: Russell King --- arch/arm/kernel/psci_smp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c index 70ded3f..570a48c 100644 --- a/arch/arm/kernel/psci_smp.c +++ b/arch/arm/kernel/psci_smp.c @@ -14,7 +14,6 @@ */ #include -#include #include #include -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] dts: calxeda: add ARM PSCI binding
From: Rob Herring
Add the PSCI binding node for Calxeda SOCs. Only claiming "arm,psci"
support since there is no agreement on 0.2 binding definition.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/ecx-common.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/ecx-common.dtsi
b/arch/arm/boot/dts/ecx-common.dtsi
index e8559b7..bc22557 100644
--- a/arch/arm/boot/dts/ecx-common.dtsi
+++ b/arch/arm/boot/dts/ecx-common.dtsi
@@ -19,6 +19,14 @@
bootargs = "console=ttyAMA0";
};
+ psci {
+ compatible = "arm,psci";
+ method = "smc";
+ cpu_suspend = <0x8402>;
+ cpu_off = <0x8404>;
+ cpu_on = <0x8406>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ARM: highbank: adapt to use ARM PSCI calls
From: Rob Herring
This adapts highbank to use psci for smp_ops and the cpu_suspend function
for suspend/resume.
Signed-off-by: Rob Herring
---
arch/arm/mach-highbank/Kconfig| 1 +
arch/arm/mach-highbank/Makefile | 2 --
arch/arm/mach-highbank/core.h | 4 ---
arch/arm/mach-highbank/highbank.c | 16 +
arch/arm/mach-highbank/hotplug.c | 37 -
arch/arm/mach-highbank/platsmp.c | 68 ---
arch/arm/mach-highbank/pm.c | 27 ++--
7 files changed, 11 insertions(+), 144 deletions(-)
delete mode 100644 arch/arm/mach-highbank/hotplug.c
delete mode 100644 arch/arm/mach-highbank/platsmp.c
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 8e8437d..965623d 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -10,6 +10,7 @@ config ARCH_HIGHBANK
select ARM_ERRATA_775420
select ARM_ERRATA_798181
select ARM_GIC
+ select ARM_PSCI
select ARM_TIMER_SP804
select CACHE_L2X0
select CLKDEV_LOOKUP
diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile
index 8a1ef57..55840f4 100644
--- a/arch/arm/mach-highbank/Makefile
+++ b/arch/arm/mach-highbank/Makefile
@@ -3,6 +3,4 @@ obj-y := highbank.o system.o
smc.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec)
-obj-$(CONFIG_SMP) += platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_PM_SLEEP) += pm.o
diff --git a/arch/arm/mach-highbank/core.h b/arch/arm/mach-highbank/core.h
index aea1ec5..7ec5edc 100644
--- a/arch/arm/mach-highbank/core.h
+++ b/arch/arm/mach-highbank/core.h
@@ -3,7 +3,6 @@
#include
-extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
extern void highbank_restart(enum reboot_mode, const char *);
extern void __iomem *scu_base_addr;
@@ -14,8 +13,5 @@ static inline void highbank_pm_init(void) {}
#endif
extern void highbank_smc1(int fn, int arg);
-extern void highbank_cpu_die(unsigned int cpu);
-
-extern struct smp_operations highbank_smp_ops;
#endif
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 8e63ccd..d15f24b 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -26,9 +26,7 @@
#include
#include
-#include
-#include
-#include
+#include
#include
#include
#include
@@ -49,17 +47,6 @@ static void __init highbank_scu_map_io(void)
scu_base_addr = ioremap(base, SZ_4K);
}
-#define HB_JUMP_TABLE_PHYS(cpu)(0x40 + (0x10 * (cpu)))
-#define HB_JUMP_TABLE_VIRT(cpu)
phys_to_virt(HB_JUMP_TABLE_PHYS(cpu))
-
-void highbank_set_cpu_jump(int cpu, void *jump_addr)
-{
- cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 0);
- writel(virt_to_phys(jump_addr), HB_JUMP_TABLE_VIRT(cpu));
- __cpuc_flush_dcache_area(HB_JUMP_TABLE_VIRT(cpu), 16);
- outer_clean_range(HB_JUMP_TABLE_PHYS(cpu),
- HB_JUMP_TABLE_PHYS(cpu) + 15);
-}
static void highbank_l2x0_disable(void)
{
@@ -174,7 +161,6 @@ DT_MACHINE_START(HIGHBANK, "Highbank")
#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
.dma_zone_size = (4ULL * SZ_1G),
#endif
- .smp= smp_ops(highbank_smp_ops),
.init_irq = highbank_init_irq,
.init_time = highbank_timer_init,
.init_machine = highbank_init,
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
deleted file mode 100644
index a019e4e..000
--- a/arch/arm/mach-highbank/hotplug.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see
[PATCH 3/6] cpuidle: calxeda: add ecx-2000 support
From: Rob Herring
Add cpuidle support for Calxeda ecx-2000 SoC.
Signed-off-by: Rob Herring
Cc: "Rafael J. Wysocki"
Cc: Daniel Lezcano
Cc: linux...@vger.kernel.org
---
drivers/cpuidle/cpuidle-calxeda.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-calxeda.c
b/drivers/cpuidle/cpuidle-calxeda.c
index b04767a..c6e9d80 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -66,7 +66,9 @@ static struct cpuidle_driver calxeda_idle_driver = {
static int __init calxeda_cpuidle_init(void)
{
- if (!of_machine_is_compatible("calxeda,highbank") ||
!psci_ops.cpu_suspend)
+ if (!of_machine_is_compatible("calxeda,highbank") ||
+ !of_machine_is_compatible("calxeda,ecx-2000") ||
+ !psci_ops.cpu_suspend)
return -ENODEV;
return cpuidle_register(_idle_driver, NULL);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] PSCI support for highbank
From: Rob Herring This series converts highbank to use PSCI calls for smp_ops, suspend and cpuidle. I've dropped system reset and poweroff until we can finalize PSCI 0.2 bindings. Otherwise, this is mostly unchanged from the previous posting. New in this posting is enabling cpuidle on ecx-2000. Rob Herring (6): cpuidle: calxeda: add support to use PSCI calls cpuidle: calxeda: add cpu_pm_enter/exit calls cpuidle: calxeda: add ecx-2000 support ARM: PSCI: remove unnecessary include of arm-gic.h ARM: highbank: adapt to use ARM PSCI calls dts: calxeda: add ARM PSCI binding arch/arm/boot/dts/ecx-common.dtsi | 8 + arch/arm/kernel/psci_smp.c| 1 - arch/arm/mach-highbank/Kconfig| 1 + arch/arm/mach-highbank/Makefile | 2 -- arch/arm/mach-highbank/core.h | 4 --- arch/arm/mach-highbank/highbank.c | 16 + arch/arm/mach-highbank/hotplug.c | 37 - arch/arm/mach-highbank/platsmp.c | 68 --- arch/arm/mach-highbank/pm.c | 27 ++-- drivers/cpuidle/Kconfig.arm | 2 +- drivers/cpuidle/cpuidle-calxeda.c | 46 +++--- 11 files changed, 32 insertions(+), 180 deletions(-) delete mode 100644 arch/arm/mach-highbank/hotplug.c delete mode 100644 arch/arm/mach-highbank/platsmp.c -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf record: mmap output file - RFC
Hi Jiri and David, On Thu, 26 Sep 2013 19:51:05 +0200, Jiri Olsa wrote: > On Sun, Sep 22, 2013 at 08:05:59PM -0600, David Ahern wrote: >> When recording raw_syscalls for the entire system, e.g., >> perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1 >> >> you end up with a negative feedback loop as perf itself calls >> write() fairly often. This patch mmap's the file in chunks of 64M >> at a time and copies events from the event buffers to the file >> avoiding write system calls. > > moved processing into userspace: > > 17.24% -17.10% libpthread-2.15.so [.] __write_nocancel > > ... > 0.07% +0.64% libc-2.15.so[.] __memcpy_sse2 > > 0.02% +51.84% libc-2.15.so[.] __memcpy_ssse3_back > > 0.01% +0.34% libc-2.15.so[.] __mempcpy_sse2 > > ... >> >> Before (with write syscall): >> >> perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- >> sleep 1 >> [ perf record: Woken up 0 times to write data ] >> [ perf record: Captured and wrote 81.843 MB /tmp/perf.data (~3575786 >> samples) ] >> >> After (using mmap): >> >> perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- >> sleep 1 >> [ perf record: Woken up 31 times to write data ] > > > but it's still faster, since we finally get perf a chance to sleep ;-) > > new time: > real0m30.392s > user0m0.041s > sys 0m0.389s > > old time: > real0m32.235s > user0m3.080s > sys 0m14.444s But why the new user time took so short? I guess it should take at least 10 seconds or so. Any ideas? > > >> [ perf record: Captured and wrote 8.203 MB /tmp/perf.data (~358388 samples) ] >> >> Before I get too far down this path I wanted to get comments on the approach. > > I think it's worthwhile doing this Indeed! It looks like a nice improvement. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-designware: 10-bit addressing mode enabling if I2C_DYNAMIC_TAR_UPDATE is set.
On Fri, Sep 27, 2013 at 02:57:35AM +0800, Chew, Chiau Ee wrote: > According to Designware I2C spec, if I2C_DYNAMIC_TAR_UPDATE is set to 1, > the 10-bit addressing mode is controlled by IC_10BITADDR_MASTER bit of > IC_TAR register instead of IC_CON register. The IC_10BITADDR_MASTER > in IC_CON register becomes read-only copy. Since I2C_DYNAMIC_TAR_UPDATE > value can't be detected from hardware register, so we will always set the > IC_10BITADDR_MASTER bit in both IC_CON and IC_TAR register whenever 10-bit > addresing mode is requested by user application. > > Signed-off-by: Chew, Chiau Ee > Reviewed-by: Mika Westerberg Applied to for-current, thanks! signature.asc Description: Digital signature
Re: Re: Re: Re: Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS v4.2 support to the NFS server")
Hi,
>
>--- Original Message ---
>Sender : J. Bruce Fields
>Date : 2013-09-27 10:12 (GMT+09:00)
>Title : Re: Re: Re: Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS
>v4.2 support to the NFS server")
>
>On Thu, Sep 26, 2013 at 11:57:57PM +, Jongman Heo wrote:
>> >--- Original Message ---
>> >Sender : J. Bruce Fields
>> >This is pretty weird--it's not at all obvious how that patch would
>> >affect this.
>> >
>> >You're absolutely positive that the *only* thing you're changing on the
>> >server between the "good" and "bad" cases is that one kernel patch?
>> >You're not changing anything in userspace?
>> >
>>
>> Yes, pretty sure.
>>
>> >What does "cat /proc/fs/nfsd/versions" report in the good and bad cases?
>> >
>> >(BTW, out of curiosity: what kind of client is this that only supports
>> >NFSv2 and NFSv3? Even for an embedded system that's a bit surprising.)
>> >
>> >--b.
>> >
>>
>> Here are /proc/fs/nfsd/versions information for good and bad cases ;
>>
>> good (commit 4bdc33ed reverted)
>>
>> # cat /proc/fs/nfsd/versions
>> +2 +3 +4 +4.1
>>
>>
>> bad (current linus git)
>>
>> # cat /proc/fs/nfsd/versions
>> -2 +3 +4 +4.1 -4.2
>>
>>
>> I don't know why the commit 4bdc33ed makes this difference ( from +2 to -2 ).
>>
>> My NFS server just uses Fedora 19 + latest kernel (which is not a rare
>> setup...),
>
>The thing is, nfs-utils *did* make exactly this change with commit
>6b4e4965a6b82e8d49cea1c0316b951ba4e9e83e "rpc.nfsd: No longer advertise
>NFS v2 support." in 1.2.9-rc4 which entered f19 recently. And that
>kernel commit doesn't look related. So I strongly suspect that you got
>the nfs-utils update (or rebooted after the update) at the same time as
>bisecting, and that confused the bisect results.
>
No, I haven't changed/upgraded nfs-utils package during git bisect.
And I can still reproduce the issue.
# rpm -qa|grep nfs-utils
nfs-utils-1.2.8-4.0.fc19.i686
# rpm -q --changelog nfs-utils|head -6
* Mon Aug 19 2013 Steve Dickson 1.2.8-4.0
- Updated to latest upstream RC release: nfs-utils-1-2-9-rc4
* Tue Jul 23 2013 Steve Dickson 1.2.8-3.0
- Updated to latest upstream RC release: nfs-utils-1-2-9-rc3
As you noticed, 1.2.9-rc4 is applied to Fedora 19's nfs-utils what I'm using...
With the nfs-utils, reverting the commit makes difference to me.
Another workaround from user-space (instead of revert) works for me.
Latest linus git gives following NFS version support (with my server's .config).
# cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 -4.2
I've changed /etc/sysconfig/nfs file as following diff ;
@@ -10,7 +10,7 @@
#LOCKD_UDPPORT=32769
#
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
-RPCNFSDARGS=""
+RPCNFSDARGS="-V 2"
Then. run nfs server again...
# systemctl restart nfs-server.service
# cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1 -4.2
Now NFS boot is working.
Actually I'm OK with this, since NFS boot is just used for debugging purpose,
not for production use, in my case.
FYI, in other Linux machine (Ubuntu 12.04), nfs-utils version is
"1.2.5-3ubuntu3.1", and the kernel commit doesn't cause NFS v2 support issue.
# cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1 -4.2
So, the change in nfs-utils 1.2.9-rc4 seems to be the root cause, but I don't
know why the kernel commit revert resolves the issue.
>> so I think some people can verify if this version information change happens
>> w/ and w/o the commit revert.
>>
>> Don't know the detail of NFS protocol, but our NFS client seems not to try
>> with v3 and v4 in case v2 fails...
>> Is this an unexpected (buggy) behavior of my old embedded box (NFS client of
>> kernel 2.6.35), or expected one from the NFS protocol?
>
>Digging into a historical git repo just for fun It looks like NFSv3
>support was added in 2.3.99pre4-3, probably in 2000? (The date on that
>commit is 2007, so obviously this repo I have is very confused. Maybe I
>should go find if there's a better one someplace.)
>
>So anyway it's either configured out of the kernel or the mount
>commandline's asking for v2, or I don't know what
>
>--b.
>
Thanks,
Jongman
Heo.N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v4)
Hi, On Thu, 26 Sep 2013 11:07:49 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Sep 26, 2013 at 07:46:36AM -0600, David Ahern escreveu: >> On 9/26/13 2:58 AM, Namhyung Kim wrote: >> >This is a new version of callchain improvement patchset. I found and >> >fixed bugs in the previous version. I verified that it produced >> >exactly same output before and after applying rbtree conversion patch >> >(#1). However after Frederic's new comm infrastructure patches are >> >applied it'd be little different. > >> >The patches are on 'perf/callchain-v4' branch in my tree > >> > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > >> Given recent breakage, has the patchset been run through any tests >> on older kernels that do not support sample_id_all? e.g., 2.6.34 >> (WRL4). What about tests with the other perf commands -- script to >> dump events, trace on a file with with multiple processes -- to >> verify no impact on comm output, especially multithreaded processes >> with named threads. I can certainly do those tests in time, but >> can't guarantee a timeframe and want to make sure it gets done >> before merging. > > Right, and I don't think this is perf/urgent material at this point in > time, when merged will be for 3.13. Agreed. It definitely needs more testing. I'll try to do some testing mentioned above. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 0/8] perf tools: Fix scalability problem on callchain merging (v4)
Hi Ingo, On Thu, 26 Sep 2013 11:34:26 +0200, Ingo Molnar wrote: > * Namhyung Kim wrote: > >> Hello, >> >> This is a new version of callchain improvement patchset. I found and >> fixed bugs in the previous version. I verified that it produced >> exactly same output before and after applying rbtree conversion patch >> (#1). However after Frederic's new comm infrastructure patches are >> applied it'd be little different. >> >> The patches are on 'perf/callchain-v4' branch in my tree >> >> git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > > I pulled this into a test-branch and resolved the builtin-trace.c conflict > with tip:master. > > I tried your new code out with Linus's testcase of a parallel kernel > build: > >perf record -g -- make -j8 bzImage > > The 'perf record' session went mostly fine except for lost events: > > Kernel: arch/x86/boot/bzImage is ready (#25) > [ perf record: Woken up 553 times to write data ] > [ perf record: Captured and wrote 196.811 MB perf.data (~8598789 samples) ] > Warning: > Processed 2631982 events and lost 54 chunks! > > Check IO/CPU overload! > > So, for completeness I'll mention that perf fails in two ways here: > > - UI bug: it prints some scary warnings about 'IO/CPU overload' but > does not give any idea what the user could do about it. At minimum it > should print something about increasing --mmap-pages. It should also > print the current value of --mmap-pages so that the user knows to what > value to increase it ... > > - defaults bug: this isn't an extreme workload on an extreme box - it's > a relatively bog standard system with 8 cores and 16 CPUs. The kernel > build was mild as well, with -j8. So losing events in perf record is > absolutely unacceptable. A solution might be to automatically increase > the ring-buffer if -g is used, in expectation of a higher data rate. Both look sensible. I'll try to cook patches for them. > > Once perf record was done I had the ~200 MB perf.data - and the 'perf > report' session went much smoother than ever before: the analysis went > very quickly, it finished within 10 seconds and displayed a nice progress > bar. So this is entirely usable IMO. > > One small 'perf report' annoyance is that during the analysis passes > missing symbol printouts flash in the TUI - without the user having a > chance to read them. So those messages should either linger, or be > displayed at a later stage, for example when the user is confronted with > non-resolved symbols like: > > + 28.63% cc1 cc1[.] > 0x006a92cb ◆ > > that is the point where the message would be useful - but nothing > indicates at all that this is an undesirable symbol entry and nothing > helps the user what to do about it! > > A solution might be to display non-intrusive messages about non-resolved > symbols when such a symbol is manipulated (its children are openened, or > annotation is attempted). Hmm.. I'll think about it more how to do it. > > Here there is a second annoyance: on the detailed screen the 'annotate' > entry is simply missing when the symbol has not been resolved. If I hit > 'a' on the symbol entry itself in the graph view, then sometimes > annotation works - sometimes it does not and there's no UI feedback > whatsoever why it's not working. > > I'm not suggesting to change the keyboard flow - that is very smooth - but > display information about failed annotations in the status line at the > bottom of the screen would be very useful. Remember: it's _always_ an UI > bug if the user hits a key and absolutely nothing happens. At minimum a > low-key, non-intrusive 'key X not bound' message should appear in the > status line bottom. Deterministic action/reaction sequences are utterly > important when interacting with computers. > > Anyway, very nice progress with the tree here! Hehe, thanks! Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/7] improve memcg oom killer robustness v2
> CC: "Michal Hocko" , "Andrew Morton" > , "David Rientjes" , > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" > , linux...@kvack.org, > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, > linux-kernel@vger.kernel.org >Hi azur, > >On Thu, Sep 26, 2013 at 06:54:59PM +0200, azurIt wrote: >> On Wed, Sep 18, 2013 at 02:19:46PM -0400, Johannes Weiner wrote: >> >Here is an update. Full replacement on top of 3.2 since we tried a >> >dead end and it would be more painful to revert individual changes. >> > >> >The first bug you had was the same task entering OOM repeatedly and >> >leaking the memcg reference, thus creating undeletable memcgs. My >> >fixup added a condition that if the task already set up an OOM context >> >in that fault, another charge attempt would immediately return -ENOMEM >> >without even trying reclaim anymore. This dropped __getblk() into an >> >endless loop of waking the flushers and performing global reclaim and >> >memcg returning -ENOMEM regardless of free memory. >> > >> >The update now basically only changes this -ENOMEM to bypass, so that >> >the memory is not accounted and the limit ignored. OOM killed tasks >> >are granted the same right, so that they can exit quickly and release >> >memory. Likewise, we want a task that hit the OOM condition also to >> >finish the fault quickly so that it can invoke the OOM killer. >> > >> >Does the following work for you, azur? >> >> >> Johannes, >> >> bad news everyone! :( >> >> Unfortunaely, two different problems appears today: >> >> 1.) This looks like my very original problem - stucked processes inside one >> cgroup. I took stacks from all of them over time but server was very slow so >> i had to kill them soon: >> http://watchdog.sk/lkmlmemcg-bug-9.tar.gz >> >> 2.) This was just like my last problem where few processes were doing huge >> i/o. As sever was almost unoperable i barely killed them so no more info >> here, sorry. > >From one of the tasks: > >1380213238/11210/stack:[] sys_sched_yield+0x41/0x70 >1380213238/11210/stack:[] free_more_memory+0x21/0x60 >1380213238/11210/stack:[] __getblk+0x14d/0x2c0 >1380213238/11210/stack:[] ext3_getblk+0xeb/0x240 >1380213238/11210/stack:[] ext3_find_entry+0x13f/0x480 >1380213238/11210/stack:[] ext3_lookup+0x4d/0x120 >1380213238/11210/stack:[] d_alloc_and_lookup+0x45/0x90 >1380213238/11210/stack:[] do_lookup+0x278/0x390 >1380213238/11210/stack:[] path_lookupat+0x120/0x800 >1380213238/11210/stack:[] do_path_lookup+0x35/0xd0 >1380213238/11210/stack:[] user_path_at_empty+0x59/0xb0 >1380213238/11210/stack:[] user_path_at+0x11/0x20 >1380213238/11210/stack:[] sys_faccessat+0xd0/0x200 >1380213238/11210/stack:[] sys_access+0x18/0x20 >1380213238/11210/stack:[] system_call_fastpath+0x18/0x1d > >Should have seen this coming... it's still in that braindead >__getblk() loop, only from a syscall this time (no OOM path). The >group's memory.stat looks like this: > >cache 0 >rss 0 >mapped_file 0 >pgpgin 0 >pgpgout 0 >swap 0 >pgfault 0 >pgmajfault 0 >inactive_anon 0 >active_anon 0 >inactive_file 0 >active_file 0 >unevictable 0 >hierarchical_memory_limit 209715200 >hierarchical_memsw_limit 209715200 >total_cache 0 >total_rss 209715200 >total_mapped_file 0 >total_pgpgin 1028153297 >total_pgpgout 1028102097 >total_swap 0 >total_pgfault 1352903120 >total_pgmajfault 45342 >total_inactive_anon 0 >total_active_anon 209715200 >total_inactive_file 0 >total_active_file 0 >total_unevictable 0 > >with anonymous pages to the limit and you probably don't have any swap >space enabled to anything in the group. > >I guess there is no way around annotating that __getblk() loop. The >best solution right now is probably to use __GFP_NOFAIL. For one, we >can let the allocation bypass the memcg limit if reclaim can't make >progress. But also, the loop is then actually happening inside the >page allocator, where it should happen, and not around ad-hoc direct >reclaim in buffer.c. > >Can you try this on top of our ever-growing stack of patches? Installed, thank you! azur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V1] oom: avoid selecting threads sharing mm with init
On 09/27/2013 02:44 AM, David Rientjes wrote:
On Thu, 26 Sep 2013, Ming Liu wrote:
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 314e9d2..7e50a95 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -113,11 +113,22 @@ struct task_struct *find_lock_task_mm(struct task_struct
*p)
static bool oom_unkillable_task(struct task_struct *p,
const struct mem_cgroup *memcg, const nodemask_t *nodemask)
{
+ struct task_struct *init_tsk;
+
if (is_global_init(p))
return true;
if (p->flags & PF_KTHREAD)
return true;
+ /* It won't help free memory if p is sharing mm with init */
+ rcu_read_lock();
+ init_tsk = find_task_by_pid_ns(1, _pid_ns);
+ if(p->mm == init_tsk->mm) {
+ rcu_read_unlock();
+ return true;
+ }
+ rcu_read_unlock();
+
/* When mem_cgroup_out_of_memory() and p is not member of the group */
if (memcg && !task_in_mem_cgroup(p, memcg))
return true;
You're aware of init_mm?
I might mislead you, when I talked about init, I meant the pid 1 process
but not the idle, and isn't the idle a kthread and has not this risk
getting killed by oom?
This panic was observed in a busybox shell with a 2.6.27 kernel, MIPS
board, but after some investigation, I think the upstream also has the
problem, the kernel log is as following:
Out of memory: kill process 938 (crond) score 5 or a child
Killed process 938 (crond)
out_of_memory:tsk_rick info, name:init pid:1 mm:a801e0767700
task_struct:a801e011//struct task_struct *tsk_rick =
find_task_by_vpid(1);
out_of_memory:will close init process pid:1128 mm:a801e0767700
task_strct:a801f37e2800
Out of memory: kill process 1128 (init) score 4 or a child
oom_kill_process:will close init process pid:1128 mm:a801e0767700
task_struct:a801f37e2800
oom_kill_task:will close init process pid:1128 mm:a801e0767700
task_struct:a801f37e2800
Killed process 1128 (init)
do_exit: task_rick name:init , pid:1, mm:a801e0767700,
_stuct:a801e011
do_exit: will kill process name:init , pid:1128, mm:a801e0767700,
_stuct:a801f37e2800
do_exit: task_rick name:init , pid:1, mm:a801e0767700,
_stuct:a801e011
find_new_reaper: will kill process name:init , pid:1128, mm:,
_stuct:a801f37e2800
do_exit: will kill process name:init , pid:1, mm:a801e0767700,
_stuct:a801e011
Call Trace:
[] dump_stack+0x8/0x34
[] do_exit+0x94c/0x978
[] do_group_exit+0x4c/0xd0
[] get_signal_to_deliver+0x1ec/0x498
[] do_notify_resume+0x80/0x2b0
[] work_notifysig+0xc/0x14
find_new_reaper: will kill process name:init , pid:1, mm:,
_stuct:a801e011
Kernel panic - not syncing: Attempted to kill init!
the best,
thank you
Can you post the kernel log when one of these "extreme cases" happens?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1] arm64: X-Gene AHBC platform bus driver
This driver setup the AHBC for SPI and SD drivers to use.
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm-storm.dtsi |6 +
drivers/bus/Kconfig|9 ++
drivers/bus/Makefile |2 +
drivers/bus/xgene_ahbc.c | 193
4 files changed, 210 insertions(+), 0 deletions(-)
create mode 100644 drivers/bus/xgene_ahbc.c
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d994806..b9477ec 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -178,6 +178,12 @@
};
};
+ahbc: ahbc@1f2a {
+device_type = "ahbc";
+compatible = "apm,xgene-ahbc";
+reg = <0x0 0x1f2a 0x0 0x8>;
+};
+
serial0: serial@1c02 {
device_type = "serial";
compatible = "ns16550";
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1f70e84..6cc361c68 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -42,4 +42,13 @@ config ARM_CCI
help
Driver supporting the CCI cache coherent interconnect for ARM
platforms.
+
+config XGENE_AHBC
+ tristate "X-Gene SoC AHB Bus Driver"
+ depends on ARM64 && ARCH_XGENE
+ default y if ARCH_XGENE
+ help
+ X-Gene SoC AHB bus driver is required for SPI and
+ SDIO to function properly.
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 8947bdd..0c7a4ca 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_OMAP_OCP2SCP)+= omap-ocp2scp.o
obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o
# CCI cache coherent interconnect for ARM platforms
obj-$(CONFIG_ARM_CCI) += arm-cci.o
+
+obj-$(CONFIG_XGENE_AHBC) += xgene_ahbc.o
diff --git a/drivers/bus/xgene_ahbc.c b/drivers/bus/xgene_ahbc.c
new file mode 100644
index 000..9554bb4
--- /dev/null
+++ b/drivers/bus/xgene_ahbc.c
@@ -0,0 +1,193 @@
+/**
+ * AppliedMicro X-Gene AHBC Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Loc Ho
+ * Author: Feng Kan
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AHBC_DRIVER_VER"0.1"
+
+#define AIM_8_SIZE_CTL_ADDR0x0104
+#define AIM_8_AXI_LO_ADDR 0x0108
+#define AIM_8_AXI_HI_ADDR 0x010c
+
+#define ARSB_F8_WR(src)(((u32)(src)<<23) & 0x0380)
+#define AWSB_F8_WR(src)(((u32)(src)<<20) & 0x0070)
+#define AIM_AXI_ADDRESS_LO_8_WR(src) (((u32)(src)) & 0x000f)
+
+/* Global Base Address */
+#define REGSPEC_AHBC_GLBL_DIAG_CSR_I_BASE_ADDR 0x01f2ad000ULL
+
+#define REGSPEC_CFG_MEM_RAM_SHUTDOWN_ADDR 0x0070
+#define REGSPEC_BLOCK_MEM_RDY_ADDR 0x0074
+
+static void xgene_ahb_write(void *base, u32 offset, u32 val)
+{
+ if (base == NULL)
+ return;
+
+ writel_relaxed(val, base + offset);
+}
+
+static void xgene_ahbc_init_mem(struct platform_device *pdev)
+{
+ void *ahbc_base = platform_get_drvdata(pdev);
+ u32 diag_offset = REGSPEC_AHBC_GLBL_DIAG_CSR_I_BASE_ADDR & 0x;
+ void *diagcsr_base = ahbc_base + diag_offset;
+ int timeout;
+ u32 val;
+
+ if (ahbc_base == NULL)
+ return;
+
+ if (readl(diagcsr_base + REGSPEC_CFG_MEM_RAM_SHUTDOWN_ADDR) == 0)
+ return;
+
+ dev_dbg(>dev, "AHBC clear memory shutdown\n");
+ writel(0x00, diagcsr_base + REGSPEC_CFG_MEM_RAM_SHUTDOWN_ADDR);
+ readl(diagcsr_base + REGSPEC_CFG_MEM_RAM_SHUTDOWN_ADDR);
+
+ val = readl(diagcsr_base + REGSPEC_BLOCK_MEM_RDY_ADDR);
+ timeout = 5000;
+ while (val != 0x && timeout-- > 0) {
+ val = readl(diagcsr_base + REGSPEC_BLOCK_MEM_RDY_ADDR);
+ if (val != 0x)
+
Re: [PATCH] tools/perf: remove non-existent entries in MANIFEST
Arnaldo Carvalho de Melo wrote: > Could you please describe how it is broken? > > [acme@zoo linux]$ git branch | grep '*' > * perf/urgent > [acme@zoo linux]$ git describe > v3.12-rc1-51-gc1bf214 Oh, I meant the torvalds/linux.git master. $ git describe v3.12-rc2-83-g4b97280 $ make perf-tarbz2-src-pkg TAR $ tar tf perf-3.12.0-rc2.tar.bz2 | grep tools perf-3.12.0-rc2/tools/ As you can see, the tools/perf directory is completely missing. With my patch applied, the archive is totally fine (and perf builds and runs fine). I suspect the issue has to do with non-existent paths given as the pathspec filtering argument to 'git archive'. Note that I'm running the latest git HEAD. 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: linux-next: manual merge of the ipsec-next tree with the net-next tree
Hi Steffen,
On Wed, 25 Sep 2013 07:29:23 +0200 Steffen Klassert
wrote:
>
> On Wed, Sep 25, 2013 at 09:59:19AM +1000, Stephen Rothwell wrote:
> >
> > On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert
> > wrote:
> > >
> > > On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> > > >
> > > > Today's linux-next merge of the ipsec-next tree got a conflict in
> > > > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > > > from function prototypes") from the net-next tree and commit
> > > > aba826958830
> > > > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > > > callback") from the ipsec-next tree.
> > >
> > > Thanks for the information, I'll do a rebase of the ipsec-next
> > > tree tomorrow.
> >
> > Did you miss the end of the next paragraph: "no action is required"?
> > Dave can fix this up (like I did) when he merges your tree into his.
>
> I applied this patch shortly before the merge window opened, it is a left
> over from the last develpoment cycle. I already rebased my tree onto
> net-next in the past if that happened, even if there were no merge
> conflicts. I did that just to see if everything still works. But I
> could also do a test merge to see if everything still works and ask
> to pull without a rebase then if this is the prefered way. Would make
> my life easier :)
That would be up to Dave ...
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpWPWJ7Ujbpg.pgp
Description: PGP signature
Re: [PATCH] perf: fix infinite loop with corrupted header
Hi, On Thu, 26 Sep 2013 11:06:13 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Sep 26, 2013 at 10:59:37PM +0900, Namhyung Kim escreveu: >> 2013-09-26 (목), 10:46 -0300, Arnaldo Carvalho de Melo: >> > Em Thu, Sep 26, 2013 at 07:34:56AM -0600, David Ahern escreveu: >> > > Other changes went in around that time as well. Are you still seeing >> > > the loop on latest source? >> >> Did you mean this? > > Not at that moment, but yes, I looked up the discussion and found this, > which I think is sensible, would like just to do some testing, and if > you could submit a patch combining your change with David's, I think it > would be good. I'll resend it after some testing. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to get PGP/GPG public key fingerprint
Hi Guys, In the FAQ page of kernel.org (https://www.kernel.org/faq.html) , it says if one wants to get a kernel.org account, he needs to provide "PGP/GPG public key fingerprint", and the key should: Key should be signed by as many kernel developers as you know Accounts will not be issued until key carries enough signatures Key and signatures must be available on public key servers My Question Is: how can I get the key? Thanks ZhenHua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [dtc PATCH V2] Warn on node name unit-address presence/absence mismatch
On Thu, 2013-09-26 at 17:12 -0600, Stephen Warren wrote: > Well, ePAPR seems pretty specific that unit address and reg are > related, > but says nothing about ranges in the section on node naming, nor about > node naming in the section about ranges. > > I'd claim that the existing PPC trees are nonconforming, and should be > fixed too:-) This is tricky, we should probably fix ePAPR here. If you have a "soc" bus covering a given range of addresses which it forwards to its children devices but doesn't have per-se its own registers in that area, then it wouldn't have a "reg" property. I would thus argue that in the absence of a "reg" property, if a "ranges" one is present, the "parent address" entry in there is an acceptable substitute for the "reg" property as far as unit addresses are concerned. Also don't forget that in real OFW land, the unit address is something that's somewhat bus specific ... for example, PCI uses "dev,fn" rather than the full 96-bit number of the "reg" entry :-) Another option which would more strictly conform to ePAPR and in fact to of1275 would be to require such bus nodes to have a "reg" property with the address value set to the beginning of the range and the size value set to 0 :-) Cheers, Ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
On 09/26/2013 09:15 PM, Tejun Heo wrote: > Hello, Chen. > > On Thu, Sep 26, 2013 at 02:30:31PM +0800, Chen Gang wrote: >>> Oh, not cause issue, the reason is "'groups' exports extern variable >>> 'init_groups', when start process, default 'cred' will set it to be >>> sure of groups always be initialized". >>> >>> Hmm... but after all, I still think this file need be improved: "remove >>> the group_info checking in groups_search()", please help check, thanks. > > Given the track record upto this point and how marginal the benefit of > the suggested change is, I'd rather not. It's quite possible that we > had specific issue where that extra conditional is necessary and I > don't feel comfortable trusting your evaluation and analysis on the > subject at the moment, so the benefit / risk ratio seems way off from > my pov. > >>> If groups_alloc() fails, the caller must not call any related API again >>> with the related invalid 'group_info'. >>> >>> >>> Signed-off-by: Chen Gang > > Nacked-by: Tejun Heo > The caller should not 'generate' a new 'groups_info' by itself, so, if invalid 'groups_info' should not pass to groups_free(), of cause it should not pass groups_search(), either. If permit passing an invalid 'groups_info' to groups_search(), caller also can pass this invalid 'groups_info' to groups_free(), too. The original author exported extern variable 'init_groups', that means 'groups' wants no duty to be sure 'group_info' whether valid, caller should be sure of that (or it is caller's bug, not 'groups' bug). In my opinion, it is enough to know 'groups' interface is inconsistent, it needs improvement (in fact, I don't think it's a good idea to export 'init_groups', neither good to let caller sure of 'group_info' valid). As an integrator or large source code maintainer, we cannot only depend on testing, or tracing log, or some short directly causes; we also need find and solve issues by checking sub-systems' interface or documents. > Thanks. > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the ceph tree
Hi Sage,
After merging the ceph tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/ceph/file.c: In function 'ceph_sync_direct_write':
fs/ceph/file.c:545:24: error: 'struct iov_iter' has no member named 'iov'
void __user *data = i.iov->iov_base + i.iov_offset;
^
fs/ceph/file.c:546:14: error: 'struct iov_iter' has no member named 'iov'
u64 len = i.iov->iov_len - i.iov_offset;
^
This also happened yesterday but was swamped by the other error (now fixed).
Caused by commit d4ce96db671b ("ceph: Implement writev/pwritev for sync
operation") interacting with commit f6794d33a5ec ("iov_iter: hide iovec
details behind ops function pointers") from the aio-direct tree.
I applied the following merge fix patch (but there may be a better
solution):
From: Stephen Rothwell
Date: Fri, 27 Sep 2013 11:28:05 +1000
Subject: [PATCH] ceph: fix up for iov_iter changes
Signed-off-by: Stephen Rothwell
---
fs/ceph/file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 5cf034e..1216372 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -542,8 +542,8 @@ ceph_sync_direct_write(struct kiocb *iocb, const struct
iovec *iov,
iov_iter_init(, iov, nr_segs, count, 0);
while (iov_iter_count() > 0) {
- void __user *data = i.iov->iov_base + i.iov_offset;
- u64 len = i.iov->iov_len - i.iov_offset;
+ void __user *data = iov_iter_iovec()->iov_base + i.iov_offset;
+ u64 len = iov_iter_iovec()->iov_len - i.iov_offset;
page_align = (unsigned long)data & ~PAGE_MASK;
--
1.8.4.rc3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpcr9unnef5x.pgp
Description: PGP signature
[GIT PULL] extcon next for 3.13
Hi Greg, This is extcon-next pull request for 3.13. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-3.13 for you to fetch changes up to 42d7d7539a7bcf1d493b989465283c464f4a0525: extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter (2013-09-27 09:37:01 +0900) Update extcon for 3.13 This patchset modify extcon core to remove unnecessary allocation sequence for 'dev' instance and change extcon_dev_register() interface. extcon-gpio use gpiolib API to get debounce time and include small fix of extcon core/device driver. Detailed description for patchset: 1. Modify extcon core driver - The extcon-gpio driver use gpio_set_debounce() API provided from gpiolib if gpio driver for SoC support gpio_set_debounce() function and support 'gpio_ activ_low' filed to check whether gpio active state is 1(high) or 0(low). - Change field type of 'dev' in structure extcon_dev and remove the sequence of allocating memory of 'struct dev' on extcon_dev_register() function because extcon device must need 'struct device. - Change extcon_dev_register() prototype to simplify it and remove unnecessary parameter as below: 2. Fix coding style and typo - extcon core : Fix indentation coding style and remove unnecessary casting - extcon-max8997 : Fix checkpatch warning - extcon-max77693 : Fix checkpatch warning - extcon-arizona : Fix typo of comment and modify minor issue - extcon-palmas : Use dev_get_platdata() 3. Modify extcon-arizona driver - Modify minor issue about micbias and comparision statement Chanwoo Choi (3): extcon: Fix indentation coding style to improve readability extcon: Change field type of 'dev' in extcon_dev structure extcon: Simplify extcon_dev_register() prototype by removing unnecessary parameter Charles Keepax (3): extcon: arizona: Clear trig_sts bits on all paths extcon: arizona: Correct typo in headphone detect range transitions extcon: arizona: Don't require micbias to be shifted in pdata Guenter Roeck (3): extcon: gpio: Do not unnecessarily initialize variables extcon: gpio: Use gpio driver/chip debounce if supported extcon: gpio: Add support for active-low presence to detect pins Jingoo Han (2): extcon: Remove casting the return value which is a void pointer extcon: use dev_get_platdata() Sachin Kamat (3): extcon: max8997: Fix checkpatch warning extcon: arizona: Fix a typo in a comment extcon: max77693: Fix checkpatch warning Documentation/extcon/porting-android-switch-class | 6 +- drivers/extcon/extcon-adc-jack.c | 27 +++ drivers/extcon/extcon-arizona.c | 20 ++--- drivers/extcon/extcon-class.c | 95 +++ drivers/extcon/extcon-gpio.c | 19 - drivers/extcon/extcon-max77693.c | 7 +- drivers/extcon/extcon-max8997.c | 5 +- drivers/extcon/extcon-palmas.c| 5 +- include/linux/extcon.h| 72 - include/linux/extcon/extcon-adc-jack.h| 42 +- include/linux/extcon/extcon-gpio.h| 20 +++-- 11 files changed, 170 insertions(+), 148 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 15/27] mmc: mxs-mmc: Move away from using deprecated APIs
On Thu, Sep 26, 2013 at 04:54:40PM +0200, Ulf Hansson wrote: > Suspend and resume of cards are being handled from the protocol layer > and consequently the mmc_suspend|resume_host APIs are deprecated. > > This means we can simplify the suspend|resume callbacks by removing the > use of the deprecated APIs. > > Cc: Shawn Guo Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: Avoid select_idle_sibling() for wake_affine(.sync=true)
On 09/26/2013 11:44 PM, Peter Zijlstra wrote: > On Thu, Sep 26, 2013 at 11:09:46PM +0800, Michael wang wrote: >>> + if (sync) >>> + p->se.last_sync_wakeup = sched_clock_cpu(cpu); >> >> Forgive me but I'm trying to understand it... why not 'current' but 'p' >> here? we want the get off speed of waker or the working time of wakee? > > Because I'm an idiot? ;-) Well, I know you are full of good ideas ;-) Regards, Michael Wang > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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: Re: Re: Regression caused by commit 4bdc33ed ("NFSDv4.2: Add NFS v4.2 support to the NFS server")
On Thu, Sep 26, 2013 at 11:57:57PM +, Jongman Heo wrote: > >--- Original Message --- > >Sender : J. Bruce Fields > >This is pretty weird--it's not at all obvious how that patch would > >affect this. > > > >You're absolutely positive that the *only* thing you're changing on the > >server between the "good" and "bad" cases is that one kernel patch? > >You're not changing anything in userspace? > > > > Yes, pretty sure. > > >What does "cat /proc/fs/nfsd/versions" report in the good and bad cases? > > > >(BTW, out of curiosity: what kind of client is this that only supports > >NFSv2 and NFSv3? Even for an embedded system that's a bit surprising.) > > > >--b. > > > > Here are /proc/fs/nfsd/versions information for good and bad cases ; > > good (commit 4bdc33ed reverted) > > # cat /proc/fs/nfsd/versions > +2 +3 +4 +4.1 > > > bad (current linus git) > > # cat /proc/fs/nfsd/versions > -2 +3 +4 +4.1 -4.2 > > > I don't know why the commit 4bdc33ed makes this difference ( from +2 to -2 ). > > My NFS server just uses Fedora 19 + latest kernel (which is not a rare > setup...), The thing is, nfs-utils *did* make exactly this change with commit 6b4e4965a6b82e8d49cea1c0316b951ba4e9e83e "rpc.nfsd: No longer advertise NFS v2 support." in 1.2.9-rc4 which entered f19 recently. And that kernel commit doesn't look related. So I strongly suspect that you got the nfs-utils update (or rebooted after the update) at the same time as bisecting, and that confused the bisect results. > so I think some people can verify if this version information change happens > w/ and w/o the commit revert. > > Don't know the detail of NFS protocol, but our NFS client seems not to try > with v3 and v4 in case v2 fails... > Is this an unexpected (buggy) behavior of my old embedded box (NFS client of > kernel 2.6.35), or expected one from the NFS protocol? Digging into a historical git repo just for fun It looks like NFSv3 support was added in 2.3.99pre4-3, probably in 2000? (The date on that commit is 2007, so obviously this repo I have is very confused. Maybe I should go find if there's a better one someplace.) So anyway it's either configured out of the kernel or the mount commandline's asking for v2, or I don't know what --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 CHAR-MISC-NEXT 4/4] Intel MIC Header File warning fix.
usr/include/linux/mic_ioctl.h:37:
found __[us]{8,16,32,64} type without #include
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dasaratharaman Chandramouli
Signed-off-by: Nikhil Rao
Signed-off-by: Harshavardhan R Kharche
Signed-off-by: Sudeep Dutt
---
include/uapi/linux/mic_ioctl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/mic_ioctl.h b/include/uapi/linux/mic_ioctl.h
index 0e6cbf3..7fabba5 100644
--- a/include/uapi/linux/mic_ioctl.h
+++ b/include/uapi/linux/mic_ioctl.h
@@ -21,6 +21,8 @@
#ifndef _MIC_IOCTL_H_
#define _MIC_IOCTL_H_
+#include
+
/*
* mic_copy - MIC virtio descriptor copy.
*
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH CHAR-MISC-NEXT 3/4] Intel MIC Driver Cleanups for "--strict" checkpatch.
From: Ashutosh Dixit
These changes were mostly authored by Joe Perches
@ https://lkml.org/lkml/2013/9/5/602
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dasaratharaman Chandramouli
Signed-off-by: Nikhil Rao
Signed-off-by: Harshavardhan R Kharche
Signed-off-by: Sudeep Dutt
---
Documentation/mic/mpssd/mpssd.c | 65 ++-
Documentation/mic/mpssd/sysfs.c | 4 +-
drivers/misc/mic/card/mic_device.c | 1 -
drivers/misc/mic/card/mic_virtio.c | 17 ---
drivers/misc/mic/card/mic_x100.c| 4 +-
drivers/misc/mic/host/mic_debugfs.c | 90 ++---
drivers/misc/mic/host/mic_fops.c| 6 +--
drivers/misc/mic/host/mic_intr.c| 34 +++---
drivers/misc/mic/host/mic_smpt.c| 14 +++---
drivers/misc/mic/host/mic_sysfs.c | 20 -
drivers/misc/mic/host/mic_virtio.c | 37 +++
drivers/misc/mic/host/mic_x100.c| 33 +++---
12 files changed, 158 insertions(+), 167 deletions(-)
diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c
index 8064804..f9327a2 100644
--- a/Documentation/mic/mpssd/mpssd.c
+++ b/Documentation/mic/mpssd/mpssd.c
@@ -246,7 +246,7 @@ static int tun_alloc(struct mic_info *mic, char *dev)
if (*dev)
strncpy(ifr.ifr_name, dev, IFNAMSIZ);
- err = ioctl(fd, TUNSETIFF, (void *) );
+ err = ioctl(fd, TUNSETIFF, (void *));
if (err < 0) {
mpsslog("%s %s %d TUNSETIFF failed %s\n",
mic->name, __func__, __LINE__, strerror(errno));
@@ -363,7 +363,7 @@ static inline void verify_out_len(struct mic_info *mic,
{
if (copy->out_len != sum_iovec_len(copy)) {
mpsslog("%s %s %d BUG copy->out_len 0x%x len 0x%x\n",
- mic->name, __func__, __LINE__,
+ mic->name, __func__, __LINE__,
copy->out_len, sum_iovec_len(copy));
assert(copy->out_len == sum_iovec_len(copy));
}
@@ -372,7 +372,7 @@ static inline void verify_out_len(struct mic_info *mic,
/* Display an iovec */
static void
disp_iovec(struct mic_info *mic, struct mic_copy_desc *copy,
- const char *s, int line)
+ const char *s, int line)
{
int i;
@@ -401,7 +401,7 @@ static inline void txrx_prepare(int type, bool tx, struct
mic_vring *vr,
/* Central API which triggers the copies */
static int
mic_virtio_copy(struct mic_info *mic, int fd,
- struct mic_vring *vr, struct mic_copy_desc *copy)
+ struct mic_vring *vr, struct mic_copy_desc *copy)
{
int ret;
@@ -440,7 +440,7 @@ init_vr(struct mic_info *mic, int fd, int type,
vr0->info = vr0->va +
vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN);
vring_init(>vr,
- MIC_VRING_ENTRIES, vr0->va, MIC_VIRTIO_RING_ALIGN);
+ MIC_VRING_ENTRIES, vr0->va, MIC_VIRTIO_RING_ALIGN);
mpsslog("%s %s vr0 %p vr0->info %p vr_size 0x%x vring 0x%x ",
__func__, mic->name, vr0->va, vr0->info, vr_size,
vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN));
@@ -453,7 +453,7 @@ init_vr(struct mic_info *mic, int fd, int type,
vr1->info = vr1->va + vring_size(MIC_VRING_ENTRIES,
MIC_VIRTIO_RING_ALIGN);
vring_init(>vr,
- MIC_VRING_ENTRIES, vr1->va, MIC_VIRTIO_RING_ALIGN);
+ MIC_VRING_ENTRIES, vr1->va, MIC_VIRTIO_RING_ALIGN);
mpsslog("%s %s vr1 %p vr1->info %p vr_size 0x%x vring 0x%x ",
__func__, mic->name, vr1->va, vr1->info, vr_size,
vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN));
@@ -551,7 +551,7 @@ virtio_net(void *arg)
net_poll[NET_FD_TUN].events = POLLIN;
if (MAP_FAILED == init_vr(mic, mic->mic_net.virtio_net_fd,
- VIRTIO_ID_NET, _vr, _vr,
+ VIRTIO_ID_NET, _vr, _vr,
virtnet_dev_page.dd.num_vq)) {
mpsslog("%s init_vr failed %s\n",
mic->name, strerror(errno));
@@ -576,7 +576,7 @@ virtio_net(void *arg)
}
if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK))
wait_for_card_driver(mic, mic->mic_net.virtio_net_fd,
- VIRTIO_ID_NET);
+VIRTIO_ID_NET);
/*
* Check if there is data to be read from TUN and write to
* virtio net fd if there is.
@@ -587,7 +587,7 @@ virtio_net(void *arg)
copy.iov, copy.iovcnt);
if (len > 0) {
struct virtio_net_hdr *hdr
- = (struct virtio_net_hdr *) vnet_hdr[0];
+ = (struct virtio_net_hdr
[PATCH CHAR-MISC-NEXT 2/4] Intel MIC Driver Header File Cleanups.
Dont use same name for header files in different folders.
These changes were suggested by Greg Kroah-Hartman during the
code review @ https://lkml.org/lkml/2013/9/6/18
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dasaratharaman Chandramouli
Signed-off-by: Nikhil Rao
Signed-off-by: Harshavardhan R Kharche
Signed-off-by: Sudeep Dutt
---
drivers/misc/mic/card/mic_debugfs.c | 2 +-
drivers/misc/mic/card/mic_device.c | 2 +-
drivers/misc/mic/card/mic_virtio.c | 2 +-
drivers/misc/mic/card/mic_x100.c | 2 +-
drivers/misc/mic/common/mic_dev.h| 51
drivers/misc/mic/common/mic_device.h | 51
drivers/misc/mic/host/mic_boot.c | 2 +-
drivers/misc/mic/host/mic_debugfs.c | 2 +-
drivers/misc/mic/host/mic_fops.c | 2 +-
drivers/misc/mic/host/mic_intr.c | 2 +-
drivers/misc/mic/host/mic_main.c | 2 +-
drivers/misc/mic/host/mic_smpt.c | 2 +-
drivers/misc/mic/host/mic_sysfs.c| 2 +-
drivers/misc/mic/host/mic_virtio.c | 2 +-
drivers/misc/mic/host/mic_x100.c | 2 +-
15 files changed, 64 insertions(+), 64 deletions(-)
create mode 100644 drivers/misc/mic/common/mic_dev.h
delete mode 100644 drivers/misc/mic/common/mic_device.h
diff --git a/drivers/misc/mic/card/mic_debugfs.c
b/drivers/misc/mic/card/mic_debugfs.c
index 95cf186..421b3d7 100644
--- a/drivers/misc/mic/card/mic_debugfs.c
+++ b/drivers/misc/mic/card/mic_debugfs.c
@@ -30,7 +30,7 @@
#include
#include
-#include "../common/mic_device.h"
+#include "../common/mic_dev.h"
#include "mic_device.h"
/* Debugfs parent dir */
diff --git a/drivers/misc/mic/card/mic_device.c
b/drivers/misc/mic/card/mic_device.c
index 4125217..175d114 100644
--- a/drivers/misc/mic/card/mic_device.c
+++ b/drivers/misc/mic/card/mic_device.c
@@ -30,7 +30,7 @@
#include
#include
-#include "../common/mic_device.h"
+#include "../common/mic_dev.h"
#include "mic_device.h"
#include "mic_virtio.h"
diff --git a/drivers/misc/mic/card/mic_virtio.c
b/drivers/misc/mic/card/mic_virtio.c
index 38275c1..7420c33 100644
--- a/drivers/misc/mic/card/mic_virtio.c
+++ b/drivers/misc/mic/card/mic_virtio.c
@@ -40,7 +40,7 @@
#include
#include
-#include "../common/mic_device.h"
+#include "../common/mic_dev.h"
#include "mic_virtio.h"
#define VIRTIO_SUBCODE_64 0x0D00
diff --git a/drivers/misc/mic/card/mic_x100.c b/drivers/misc/mic/card/mic_x100.c
index 7cb3469..f491c91 100644
--- a/drivers/misc/mic/card/mic_x100.c
+++ b/drivers/misc/mic/card/mic_x100.c
@@ -28,7 +28,7 @@
#include
#include
-#include "../common/mic_device.h"
+#include "../common/mic_dev.h"
#include "mic_device.h"
#include "mic_x100.h"
diff --git a/drivers/misc/mic/common/mic_dev.h
b/drivers/misc/mic/common/mic_dev.h
new file mode 100644
index 000..92999c2
--- /dev/null
+++ b/drivers/misc/mic/common/mic_dev.h
@@ -0,0 +1,51 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2013 Intel Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel MIC driver.
+ *
+ */
+#ifndef __MIC_DEV_H__
+#define __MIC_DEV_H__
+
+/**
+ * struct mic_mw - MIC memory window
+ *
+ * @pa: Base physical address.
+ * @va: Base ioremap'd virtual address.
+ * @len: Size of the memory window.
+ */
+struct mic_mw {
+ phys_addr_t pa;
+ void __iomem *va;
+ resource_size_t len;
+};
+
+/*
+ * Scratch pad register offsets used by the host to communicate
+ * device page DMA address to the card.
+ */
+#define MIC_DPLO_SPAD 14
+#define MIC_DPHI_SPAD 15
+
+/*
+ * These values are supposed to be in the config_change field of the
+ * device page when the host sends a config change interrupt to the card.
+ */
+#define MIC_VIRTIO_PARAM_DEV_REMOVE 0x1
+#define MIC_VIRTIO_PARAM_CONFIG_CHANGED 0x2
+
+#endif
diff --git a/drivers/misc/mic/common/mic_device.h
b/drivers/misc/mic/common/mic_device.h
deleted file mode 100644
index 01eb74f..000
--- a/drivers/misc/mic/common/mic_device.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Intel MIC Platform Software Stack (MPSS)
- *
- * Copyright(c) 2013 Intel Corporation.
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS
[PATCH CHAR-MISC-NEXT 1/4] Intel MIC Host Driver Sysfs Cleanups.
+ Use DEVICE_ATTR_RO/RW instead of DEVICE_ATTR
+ Use ATTRIBUTE_GROUPS
These changes were suggested by Greg Kroah-Hartman during the
code review @ https://lkml.org/lkml/2013/9/6/13
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dasaratharaman Chandramouli
Signed-off-by: Nikhil Rao
Signed-off-by: Harshavardhan R Kharche
Signed-off-by: Sudeep Dutt
---
drivers/misc/mic/host/mic_sysfs.c | 72 ---
1 file changed, 29 insertions(+), 43 deletions(-)
diff --git a/drivers/misc/mic/host/mic_sysfs.c
b/drivers/misc/mic/host/mic_sysfs.c
index aaf8499..bebbae2 100644
--- a/drivers/misc/mic/host/mic_sysfs.c
+++ b/drivers/misc/mic/host/mic_sysfs.c
@@ -65,7 +65,7 @@ void mic_set_state(struct mic_device *mdev, u8 state)
}
static ssize_t
-mic_show_family(struct device *dev, struct device_attribute *attr, char *buf)
+family_show(struct device *dev, struct device_attribute *attr, char *buf)
{
static const char x100[] = "x100";
static const char unknown[] = "Unknown";
@@ -85,10 +85,10 @@ mic_show_family(struct device *dev, struct device_attribute
*attr, char *buf)
}
return scnprintf(buf, PAGE_SIZE, "%s\n", card);
}
-static DEVICE_ATTR(family, S_IRUGO, mic_show_family, NULL);
+static DEVICE_ATTR_RO(family);
static ssize_t
-mic_show_stepping(struct device *dev, struct device_attribute *attr, char *buf)
+stepping_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
char *string = "??";
@@ -114,10 +114,10 @@ mic_show_stepping(struct device *dev, struct
device_attribute *attr, char *buf)
}
return scnprintf(buf, PAGE_SIZE, "%s\n", string);
}
-static DEVICE_ATTR(stepping, S_IRUGO, mic_show_stepping, NULL);
+static DEVICE_ATTR_RO(stepping);
static ssize_t
-mic_show_state(struct device *dev, struct device_attribute *attr, char *buf)
+state_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
@@ -129,7 +129,7 @@ mic_show_state(struct device *dev, struct device_attribute
*attr, char *buf)
}
static ssize_t
-mic_store_state(struct device *dev, struct device_attribute *attr,
+state_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
int rc = 0;
@@ -160,9 +160,9 @@ mic_store_state(struct device *dev, struct device_attribute
*attr,
done:
return count;
}
-static DEVICE_ATTR(state, S_IRUGO|S_IWUSR, mic_show_state, mic_store_state);
+static DEVICE_ATTR_RW(state);
-static ssize_t mic_show_shutdown_status(struct device *dev,
+static ssize_t shutdown_status_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
@@ -173,11 +173,10 @@ static ssize_t mic_show_shutdown_status(struct device
*dev,
return scnprintf(buf, PAGE_SIZE, "%s\n",
mic_shutdown_status_string[mdev->shutdown_status]);
}
-static DEVICE_ATTR(shutdown_status, S_IRUGO|S_IWUSR,
- mic_show_shutdown_status, NULL);
+static DEVICE_ATTR_RO(shutdown_status);
static ssize_t
-mic_show_cmdline(struct device *dev, struct device_attribute *attr, char *buf)
+cmdline_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
char *cmdline;
@@ -193,7 +192,7 @@ mic_show_cmdline(struct device *dev, struct
device_attribute *attr, char *buf)
}
static ssize_t
-mic_store_cmdline(struct device *dev, struct device_attribute *attr,
+cmdline_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
@@ -220,11 +219,10 @@ unlock:
mutex_unlock(>mic_mutex);
return count;
}
-static DEVICE_ATTR(cmdline, S_IRUGO | S_IWUSR,
- mic_show_cmdline, mic_store_cmdline);
+static DEVICE_ATTR_RW(cmdline);
static ssize_t
-mic_show_firmware(struct device *dev, struct device_attribute *attr, char *buf)
+firmware_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
char *firmware;
@@ -240,7 +238,7 @@ mic_show_firmware(struct device *dev, struct
device_attribute *attr, char *buf)
}
static ssize_t
-mic_store_firmware(struct device *dev, struct device_attribute *attr,
+firmware_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
struct mic_device *mdev = dev_get_drvdata(dev->parent);
@@ -266,11 +264,10 @@ unlock:
mutex_unlock(>mic_mutex);
return count;
}
-static DEVICE_ATTR(firmware, S_IRUGO | S_IWUSR,
- mic_show_firmware, mic_store_firmware);
+static DEVICE_ATTR_RW(firmware);
static ssize_t
-mic_show_ramdisk(struct device *dev, struct device_attribute *attr, char *buf)
