Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera wrote:
> On 31 October 2013 21:46, Lee Jones wrote:
>> On Thu, 31 Oct 2013, Tushar Behera wrote:
>>
>>> S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
>>> supported by s2mps11-clk driver.
>>>
>>> Signed-off-by: Tushar Behera
>>> CC: Lee Jones
>>> ---
>>> drivers/mfd/sec-core.c |4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>>> index 34c18fb..020b86b 100644
>>> --- a/drivers/mfd/sec-core.c
>>> +++ b/drivers/mfd/sec-core.c
>>> @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
>>> .name = "s5m8767-pmic",
>>> }, {
>>> .name = "s5m-rtc",
>>> - },
>>> + }, {
>>> + .name = "s5m8767-clk",
Do you want to handle these as "clock"? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
>>> + }
>>> };
>>>
>>> static struct mfd_cell s2mps11_devs[] = {
>>
>> Acked-by: Lee Jones
>>
>
> Thanks.
>
>> I'd prefer to take this patch in via the MFD tree once you have
>> support from the other maintainers for the set.
>>
>
> Ok. I will let you know once I get the clock patches through.
>
> --
> Tushar Behera
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: IOMMU: hva align mapping page size
On Mon, Nov 04, 2013 at 09:08:12AM -0700, Greg Edwards wrote: > When determining the page size we could use to map with the IOMMU, the > page size should also be aligned with the hva, not just the gfn. The > gfn may not reflect the real alignment within the hugetlbfs file. > For some reason you dropped very good commit message from v1. I applied v2 with v1 commit message. > Signed-off-by: Greg Edwards > Cc: sta...@vger.kernel.org > --- > virt/kvm/iommu.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c > index 72a130b..c329c8f 100644 > --- a/virt/kvm/iommu.c > +++ b/virt/kvm/iommu.c > @@ -103,6 +103,10 @@ int kvm_iommu_map_pages(struct kvm *kvm, struct > kvm_memory_slot *slot) > while ((gfn << PAGE_SHIFT) & (page_size - 1)) > page_size >>= 1; > > + /* Make sure hva is aligned to the page size we want to map */ > + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1)) > + page_size >>= 1; > + > /* >* Pin all pages we are about to map in memory. This is >* important because we unmap and unpin in 4kb steps later. > -- > 1.8.3.2 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/29] perf/core improvements and fixes
hm, probably one of these commits: 8a0c4c2843d3 perf tools: Fix libunwind build and feature detection for 32-bit build 28e962b9d79f perf tools: Fix 32-bit cross build 74af377bc25d perf tools: Fix non-debug build 9402802a416c perf tools: Fix test_on_exit for 32-bit build broke the suppression of the auto-detection messages on repeat invocations of 'make', if all testcases pass. 'make' used to display this on repeat invocations: comet:~/tip/tools/perf> make BUILD: Doing 'make -j12' parallel build comet:~/tip/tools/perf> make BUILD: Doing 'make -j12' parallel build comet:~/tip/tools/perf> make BUILD: Doing 'make -j12' parallel build Now it displays the spammy auto-detection all the time: comet:~/tip/tools/perf> make BUILD: Doing 'make -j12' parallel build Auto-detecting system features: ... backtrace: [ on ] ... dwarf: [ on ] ...fortify-source: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... gtk2-infobar: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libelf-getphdrnum: [ on ] ... libelf-mmap: [ on ] ... libnuma: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libpython-version: [ on ] ... libslang: [ on ] ... libunwind: [ on ] ... on-exit: [ on ] ...stackprotector: [ on ] ...stackprotector-all: [ on ] maybe a new testcase fails on my box, but is not properly displayed? 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/05/2013 03:51 PM, Gao feng wrote: > Ping... > I want to catch up the merge window.. > On 10/31/2013 11:52 AM, Gao feng wrote: >> Hi Eric Paris, >> >> Can you give me some comments? >> >> You think the tying audit namespace to user namespace is a bad idea, >> so this patchset doesn't assign auditns to userns and introduce an >> new audit netlink type to help to create audit namespace. >> >> and this patchset also introduces an new proc interface to make >> sure container can't influence the whole system. >> >> and the audit rules are not namespace aware, all of audit namespaces >> should comply with the rules. in next step, if we find it's need to >> make audit rules per audit namespace, then it's the time to do that >> job. >> >> This patchset also makes all of net namespaces have ability to send/ >> receive audit netlink message. >> >> I may miss some points, if you find there are some shortage or loophole, >> please let me know. >> >> Thanks! >> >> On 10/24/2013 03:31 PM, Gao feng wrote: >>> Here is the v1 patchset: http://lwn.net/Articles/549546/ >>> >>> The main target of this patchset is allowing user in audit >>> namespace to generate the USER_MSG type of audit message, >>> some userspace tools need to generate audit message, or >>> these tools will broken. >>> >>> And the login process in container may want to setup >>> /proc//loginuid, right now this value is unalterable >>> once it being set. this will also broke the login problem >>> in container. After this patchset, we can reset this loginuid >>> to zero if task is running in a new audit namespace. >>> >>> Same with v1 patchset, in this patchset, only the privileged >>> user in init_audit_ns and init_user_ns has rights to >>> add/del audit rules. and these rules are gloabl. all >>> audit namespace will comply with the rules. >>> >>> Compared with v1, v2 patch has some big changes. >>> 1, the audit namespace is not assigned to user namespace. >>>since there is no available bit of flags for clone, we >>>create audit namespace through netlink, patch[18/20] >>>introduces a new audit netlink type AUDIT_CREATE_NS. >>>the privileged user in userns has rights to create a >>>audit namespace, it means the unprivileged user can >>>create auditns through create userns first. In order >>>to prevent them from doing harm to host, the default >>>audit_backlog_limit of un-init-audit-ns is zero(means >>>audit is unavailable in audit namespace). and it can't >>>be changed in auditns through netlink. >>> >>> 2, introduce /proc//audit_log_limit >>>this interface is used to setup log_limit of audit >>>namespace. we need this interface to make audit >>>available in un-init-audit-ns. Only the privileged user >>>has right to set this value, it means only the root user >>>of host can change it. >>> >>> 3, make audit namespace don't depend on net namespace. >>>patch[1/20] add a compare function audit_compare for >>>audit netlink, it always return true, it means the >>>netlink subsystem will find out the netlink socket >>>only through portid and netlink type. So we needn't >>>to create kernel side audit netlink socket for per >>>net namespace, all userspace audit netlink socket >>>can find out the audit_sock, and audit_sock can >>>communicate with them through the proper portid. >>>it's just like the behavior we don't have net >>>namespace before. >>> >>> >>> This patchset still need some work, such as allow changing >>> audit_enabled in audit namespace, auditd wants this feature. >>> >>> I send this patchset now in order to get more comments, so >>> I can keep on improving namespace support for audit. >>> >>> Gao feng (20): >>> Audit: make audit netlink socket net namespace unaware >>> audit: introduce configure option CONFIG_AUDIT_NS >>> audit: make audit_skb_queue per audit namespace >>> audit: make audit_skb_hold_queue per audit namespace >>> audit: make audit_pid per audit namespace >>> audit: make kauditd_task per audit namespace >>> aduit: make audit_nlk_portid per audit namespace >>> audit: make kaudit_wait queue per audit namespace >>> audit: make audit_backlog_wait per audit namespace >>> audit: allow un-init audit ns to change pid and portid only >>> audit: use proper audit namespace in audit_receive_msg >>> audit: use proper audit_namespace in kauditd_thread >>> audit: introduce new audit logging interface for audit namespace >>> audit: pass proper audit namespace to audit_log_common_recv_msg >>> audit: Log audit pid config change in audit namespace >>> audit: allow GET,SET,USER MSG operations in audit namespace >>> nsproxy: don't make create_new_namespaces static >>> audit: add new message type AUDIT_CREATE_NS >>> audit: make audit_backlog_limit per audit namespace >>> audit: introduce /proc//audit_backlog_limit >>> >>> fs/proc/base.c | 53 ++ >>> include/linux/audit.h | 26 ++-
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Ping... On 10/31/2013 11:52 AM, Gao feng wrote: > Hi Eric Paris, > > Can you give me some comments? > > You think the tying audit namespace to user namespace is a bad idea, > so this patchset doesn't assign auditns to userns and introduce an > new audit netlink type to help to create audit namespace. > > and this patchset also introduces an new proc interface to make > sure container can't influence the whole system. > > and the audit rules are not namespace aware, all of audit namespaces > should comply with the rules. in next step, if we find it's need to > make audit rules per audit namespace, then it's the time to do that > job. > > This patchset also makes all of net namespaces have ability to send/ > receive audit netlink message. > > I may miss some points, if you find there are some shortage or loophole, > please let me know. > > Thanks! > > On 10/24/2013 03:31 PM, Gao feng wrote: >> Here is the v1 patchset: http://lwn.net/Articles/549546/ >> >> The main target of this patchset is allowing user in audit >> namespace to generate the USER_MSG type of audit message, >> some userspace tools need to generate audit message, or >> these tools will broken. >> >> And the login process in container may want to setup >> /proc//loginuid, right now this value is unalterable >> once it being set. this will also broke the login problem >> in container. After this patchset, we can reset this loginuid >> to zero if task is running in a new audit namespace. >> >> Same with v1 patchset, in this patchset, only the privileged >> user in init_audit_ns and init_user_ns has rights to >> add/del audit rules. and these rules are gloabl. all >> audit namespace will comply with the rules. >> >> Compared with v1, v2 patch has some big changes. >> 1, the audit namespace is not assigned to user namespace. >>since there is no available bit of flags for clone, we >>create audit namespace through netlink, patch[18/20] >>introduces a new audit netlink type AUDIT_CREATE_NS. >>the privileged user in userns has rights to create a >>audit namespace, it means the unprivileged user can >>create auditns through create userns first. In order >>to prevent them from doing harm to host, the default >>audit_backlog_limit of un-init-audit-ns is zero(means >>audit is unavailable in audit namespace). and it can't >>be changed in auditns through netlink. >> >> 2, introduce /proc//audit_log_limit >>this interface is used to setup log_limit of audit >>namespace. we need this interface to make audit >>available in un-init-audit-ns. Only the privileged user >>has right to set this value, it means only the root user >>of host can change it. >> >> 3, make audit namespace don't depend on net namespace. >>patch[1/20] add a compare function audit_compare for >>audit netlink, it always return true, it means the >>netlink subsystem will find out the netlink socket >>only through portid and netlink type. So we needn't >>to create kernel side audit netlink socket for per >>net namespace, all userspace audit netlink socket >>can find out the audit_sock, and audit_sock can >>communicate with them through the proper portid. >>it's just like the behavior we don't have net >>namespace before. >> >> >> This patchset still need some work, such as allow changing >> audit_enabled in audit namespace, auditd wants this feature. >> >> I send this patchset now in order to get more comments, so >> I can keep on improving namespace support for audit. >> >> Gao feng (20): >> Audit: make audit netlink socket net namespace unaware >> audit: introduce configure option CONFIG_AUDIT_NS >> audit: make audit_skb_queue per audit namespace >> audit: make audit_skb_hold_queue per audit namespace >> audit: make audit_pid per audit namespace >> audit: make kauditd_task per audit namespace >> aduit: make audit_nlk_portid per audit namespace >> audit: make kaudit_wait queue per audit namespace >> audit: make audit_backlog_wait per audit namespace >> audit: allow un-init audit ns to change pid and portid only >> audit: use proper audit namespace in audit_receive_msg >> audit: use proper audit_namespace in kauditd_thread >> audit: introduce new audit logging interface for audit namespace >> audit: pass proper audit namespace to audit_log_common_recv_msg >> audit: Log audit pid config change in audit namespace >> audit: allow GET,SET,USER MSG operations in audit namespace >> nsproxy: don't make create_new_namespaces static >> audit: add new message type AUDIT_CREATE_NS >> audit: make audit_backlog_limit per audit namespace >> audit: introduce /proc//audit_backlog_limit >> >> fs/proc/base.c | 53 ++ >> include/linux/audit.h | 26 ++- >> include/linux/audit_namespace.h | 92 ++ >> include/linux/nsproxy.h | 15 +- >> include/uapi/linux/audit.h | 1 + >> init/Kconfig| 10
Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
* Namhyung Kim wrote: > Hi Ingo, > > On Fri, 1 Nov 2013 10:27:59 +0100, Ingo Molnar wrote: > > * Namhyung Kim wrote: > > > >> >> > 2) > >> >> > > >> >> > Is it possible to configure the default 'report -g' style, so that > >> >> > people who'd like to use it all the time don't have to type '-g > >> >> > cumulative' all the time? > >> >> > >> >> Hmm.. maybe I can add support for the 'report.call-graph' config option. > >> > > >> > If we display your new 'total' field by default then it's not as > >> > pressing to me :) > >> > >> Do you mean -g cumulative without 'self' column? > > > > So, if by default we display both 'self' and 'total' and sort by > > 'total', then I'm personally a happy camper: while it's a change of > > the default perf report output, it's also a step forward. > > > > But some people might complain about it once this hits v3.13 (or > > v3.14) and might want to hide individual columns and have different > > sorting preferences. > > > > So out of defensive caution you might want to provide toggles for > > such things, maybe even generalize it a bit to allow arbitrary > > hiding/display of individual colums in perf report. > > > > That would probably also make it easier to do minimal tweaks to the > > upstream reporting defaults. > > Okay, so what would the interface look like? > > I think it'd better to separate the option and pass column and > (optional) sort key argument. > > --cumulative both,total (default) > --cumulative both,self > --cumulative total > --cumulative self (meaningless?) > > Maybe we need a config option and a single letter option for the default > case like --call-graph and -g options do. > > What do you think? So why restrict it to 'cumulative'? Why not have a generic --fields/-F, with a good default. The ordering of the fields determines sorting behavior. The default would be something like: -F total,self,process,dso,name Whether 'cumulative' data is calculated is not a function of any direct option, but simply a function of whether the 'total' field is in the -F list of columns displayed or not. With that scheme we could also do things like this to get old-style sorting: -F self,process,dso,name Or a really frugal 'readprofile'-style output: -F self,name if one is only interested in percentages and raw function names. Wrt. sorting order, by default the first column in the list of columns would be the primary (and only) sort key. (The -F field setup list could also be specified in the .perfconfig.) With this method we could do away with all this geometrical explosion of somewhat inconsistent formatting and sorting options... If there's demand then we could decouple sort keys from the display order, by slightly augmenting the field format: -F total,self:2,process:0,dso:1,name This would sort by 'process' field as the primary key, 'dso' the secondary key and 'self' as the tertiary key. And we could also keep the -s/--sort option: -s process,dso,self So the above -F line would be equivalent to: -F total,self,process,dso,name -s process,dso,self What do you think? 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 14/14] perf report: Add -g cumulative option
On Fri, 1 Nov 2013 14:17:34 +0100, Jiri Olsa wrote:
> On Thu, Oct 31, 2013 at 03:56:16PM +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> The -g cumulative option is for showing accumulated overhead (period)
>> value as well as self overhead.
[SNIP]
>> +static void
>> +sort_chain_cumulative(struct rb_root *rb_root __maybe_unused,
>> + struct callchain_root *chain_root __maybe_unused,
>> + u64 min_hit __maybe_unused,
>> + struct callchain_param *param __maybe_unused)
>> +{
>> +}
>
> maybe add some commentary explaning that it's intentionaly empty
>
> or maybe dont set it and do following check
> in __hists__insert_output_entry:
>
> if (symbol_conf.use_callchain && callchain_param.sort)
> callchain_param.sort(>sorted_chain, he->callchain,
> min_callchain_hits, _param);
Yeah, I'm fine with either way.
Hmm.. but now I think that checking existence of the sort function would
be better than having an empty function. Will change in v3.
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 07/14] perf tools: Update cpumode for each cumulative entry
On Fri, 1 Nov 2013 13:55:51 +0100, Jiri Olsa wrote:
> On Thu, Oct 31, 2013 at 03:56:09PM +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> The cpumode and level in struct addr_localtion was set for a sample
>> and but updated as cumulative callchains were added. This led to have
>> non-matching symbol and cpumode in the output.
>>
>> Update it accordingly based on the fact whether the map is a part of
>> the kernel or not.
[SNIP]
>> @@ -468,6 +470,27 @@ iter_next_cumulative_entry(struct add_entry_iter *iter
>> __maybe_unused,
>> if (al->sym == NULL)
>> return 0;
>>
>> +if (al->map->groups == >machine->kmaps) {
>> +if (machine__is_host(iter->machine)) {
>> +al->cpumode = PERF_RECORD_MISC_KERNEL;
>> +al->level = 'k';
>> +} else {
>> +al->cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
>> +al->level = 'g';
>> +}
>> +} else {
>> +if (machine__is_host(iter->machine)) {
>> +al->cpumode = PERF_RECORD_MISC_USER;
>> +al->level = '.';
>> +} else if (perf_guest) {
>> +al->cpumode = PERF_RECORD_MISC_GUEST_USER;
>> +al->level = 'u';
>> +} else {
>> +al->cpumode = PERF_RECORD_MISC_HYPERVISOR;
>> +al->level = 'H';
>> +}
>> +}
>> +
>
> Looks like this is what thread__find_addr_map does as well.
> Could above code go into a function used by both places?
In fact, it does the reverse - the thread__find_addr_map() tries to find
a map group (and map) using cpumode, but it wants to know cpumode using
map (and map group).
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] perf tools: Allow multiple cpus record for -p option
On Fri, 1 Nov 2013 16:52:45 +0100, Jiri Olsa wrote: > Currently we don't create default CPU map for task related > target, like: > > $ perf record -p > > This makes record command to disable inherited events. > which is not desired behaviour (we have special option > for that (-i) anyway). > > Fixing this by creating default CPU map for task related > processes. > > Signed-off-by: Jiri Olsa > Cc: Adrian Hunter > Cc: Corey Ashford > Cc: David Ahern > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Cc: Namhyung Kim > Cc: Paul Mackerras > Cc: Peter Zijlstra > Cc: Arnaldo Carvalho de Melo > --- > tools/perf/util/evlist.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c > index 0582f67..52bb127 100644 > --- a/tools/perf/util/evlist.c > +++ b/tools/perf/util/evlist.c > @@ -804,7 +804,7 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, > return -1; > > if (perf_target__has_task(target)) > - evlist->cpus = cpu_map__dummy_new(); > + evlist->cpus = cpu_map__new(target->cpu_list); Just a side note, if the target has task, the cpu list should be NULL as task target has a precedence. Please see perf_target__validate(). But I'm fine with the change itself. :) Thanks, Namhyung > else if (!perf_target__has_cpu(target) && !target->uses_mmap) > evlist->cpus = cpu_map__dummy_new(); > else -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless-next 2013-11-04
From: "John W. Linville" Date: Mon, 4 Nov 2013 15:22:42 -0500 > Please accept the following pull request intended for the 3.13 tree... Pulled, thanks John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
Hi Ingo, On Fri, 1 Nov 2013 10:27:59 +0100, Ingo Molnar wrote: > * Namhyung Kim wrote: > >> >> > 2) >> >> > >> >> > Is it possible to configure the default 'report -g' style, so that >> >> > people who'd like to use it all the time don't have to type '-g >> >> > cumulative' all the time? >> >> >> >> Hmm.. maybe I can add support for the 'report.call-graph' config option. >> > >> > If we display your new 'total' field by default then it's not as >> > pressing to me :) >> >> Do you mean -g cumulative without 'self' column? > > So, if by default we display both 'self' and 'total' and sort by > 'total', then I'm personally a happy camper: while it's a change of > the default perf report output, it's also a step forward. > > But some people might complain about it once this hits v3.13 (or > v3.14) and might want to hide individual columns and have different > sorting preferences. > > So out of defensive caution you might want to provide toggles for > such things, maybe even generalize it a bit to allow arbitrary > hiding/display of individual colums in perf report. > > That would probably also make it easier to do minimal tweaks to the > upstream reporting defaults. Okay, so what would the interface look like? I think it'd better to separate the option and pass column and (optional) sort key argument. --cumulative both,total (default) --cumulative both,self --cumulative total --cumulative self (meaningless?) Maybe we need a config option and a single letter option for the default case like --call-graph and -g options do. What do you think? 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/3] omapdss: venc: Add support for bypass and acbias.
Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: > This patches is adding bypass and acbias functionality to omapdss venc driver. > In first patch we export updatin bypass and acbias in devconf1 register. Next > patch > add handling for updating in venc driver and last patch add driver for opa362 > which > is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. > > Marek Belisko (3): > arm: omap2: Export devconf1 bypass and acbias. > video: venc: Add new callback and handling for bypass and acbias > setup. > omapdss: Add OPA362 analog video amplifier driver. > > arch/arm/mach-omap2/Makefile | 2 + > arch/arm/mach-omap2/control.h | 2 + > arch/arm/mach-omap2/omap3-tvout.c | 36 +++ > drivers/video/omap2/displays-new/Kconfig | 6 + > drivers/video/omap2/displays-new/Makefile | 1 + > .../video/omap2/displays-new/amplifier-opa362.c| 294 > + > drivers/video/omap2/dss/venc.c | 21 ++ > include/linux/omap-tvout.h | 14 + > include/video/omap-panel-data.h| 17 ++ > include/video/omapdss.h| 2 + > 10 files changed, 395 insertions(+) > create mode 100644 arch/arm/mach-omap2/omap3-tvout.c > create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c > create mode 100644 include/linux/omap-tvout.h > > -- > 1.8.1.2 > Marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] Generic WorkQueue Engine (GenWQE) device driver (v4)
Am Montag, den 04.11.2013, 14:12 -0800 schrieb Greg KH: > On Mon, Nov 04, 2013 at 06:08:01PM +0100, Frank Haverkamp wrote: > > +if GENWQE > > + > > +config GENWQE_DEVNAME > > +string "Name for sysfs and device nodes" > > + default "genwqe" > > +help > > + Select alternate name for sysfs and device nodes. > > + > > +endif > > Why is this still here? I thought you said you had removed this? > I posted my original v4 version of the code plus the requested changes on top of it. But I think, I should rather follow Ryans suggestion how to split the code into multiple patches. See his last mail. So I will need to spend some time today to get the patch into the form he suggested. Regards Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] BTRFS: fixed a coding style issue
Line 31: Removed spaces before the semicolons.
Signed-off-by: Aldo Iljazi
---
fs/btrfs/print-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index 0088bed..19dd143 100644
--- a/fs/btrfs/print-tree.c
+++ b/fs/btrfs/print-tree.c
@@ -28,7 +28,7 @@ static void print_chunk(struct extent_buffer *eb, struct
btrfs_chunk *chunk)
"num_stripes %d\n",
btrfs_chunk_length(eb, chunk), btrfs_chunk_owner(eb, chunk),
btrfs_chunk_type(eb, chunk), num_stripes);
- for (i = 0 ; i < num_stripes ; i++) {
+ for (i = 0; i < num_stripes; i++) {
printk(KERN_INFO "\t\t\tstripe %d devid %llu offset %llu\n", i,
btrfs_stripe_devid_nr(eb, chunk, i),
btrfs_stripe_offset_nr(eb, chunk, i));
--
1.8.3.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/2] BTRFS: fixed a coding style issue
Line 265: Inserted a space before the open parenthesis. Signed-off-by: Aldo Iljazi --- fs/btrfs/async-thread.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c index 08cc08f..8aec751 100644 --- a/fs/btrfs/async-thread.c +++ b/fs/btrfs/async-thread.c @@ -262,7 +262,7 @@ static struct btrfs_work *get_next_work(struct btrfs_worker_thread *worker, struct btrfs_work *work = NULL; struct list_head *cur = NULL; - if(!list_empty(prio_head)) + if (!list_empty(prio_head)) cur = prio_head->next; smp_mb(); -- 1.8.3.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 RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I wrote: > Hi, > > > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote: >> >> Hi Kishon, >> >>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com] >>> Sent: Monday, November 04, 2013 7:55 AM >>> >>> Hi Vivek, >>> >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. >>> >>> >>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY >>> right? I think that needs to be mentioned here. >> >> >> As far as I know the IP is different. > > > Ok. Sometime back Vivek was mentioning about a single IP for both USB3 and > USB2. Thought it should be this driver. Anyway thanks for the clarification. Right Kishon, I had mentioned that Exynos5's dwc3 controller have a single IP for USB2 and USB3 phy. >From what i see, on exynos5 systems the dwc3 controller uses a combo of usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting 0x1210). Kamil, Tomasz, Please correct me if i am wrong. > > Cheers > Kishon > >> >>> Do you have separate registers that should be used for >>> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? >>> If so, then you should model this driver as a single driver that >>> supports two PHYs similar to what Sylwester has done before? >> >> >> Best wishes, >> Kamil >> >>> Cheers >>> Kishon >>> Signed-off-by: Vivek Gautam --- .../devicetree/bindings/phy/samsung-phy.txt| 20 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 >>> >>> 4 files changed, 590 insertions(+), 0 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..9b5c111 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,23 @@ Required properties: - compatible : should be "samsung,exynos5250-dp-video-phy"; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung Exynos5 SoC seiries USB 3.0 PHY controller +-- + +Required properties: +- compatible : + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC +- reg : Register offset and length array + - first field corresponds to USB 3.0 PHY register set; + - second field corresponds to PHY power isolation register + present in PMU; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock >>> >>> property; + Required clocks: + - first clock is main PHY clock (same as USB 3.0 controller IP >>> >>> clock) + - second clock is reference clock (usually crystal clock) + optional clock: + - third clock is special clock used by PHY for operation +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a344f3d..9a100c6 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO help Support for Display Port PHY found on Samsung EXYNOS SoCs. +config PHY_EXYNOS5_USB3 + tristate "Exynos5 SoC series USB 3.0 PHY driver" + depends on ARCH_EXYNOS5 + select GENERIC_PHY + help + Enable USB 3.0 PHY support for Exynos 5 SoC series + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index d0caae9..9c06a61 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp- >>> >>> video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..b9a2674 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,562 @@ +/* + * Samsung EXYNOS5 SoC
Re: [PATCH 03/14] perf hists: Convert hist entry functions to use struct he_stat
Hi Arnaldo,
On Mon, 4 Nov 2013 20:45:51 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 31, 2013 at 03:56:05PM +0900, Namhyung Kim escreveu:
>
>> -static void hist_entry__add_cpumode_period(struct hist_entry *he,
>> +static void hist_entry__add_cpumode_period(struct he_stat *he_stat,
>> unsigned int cpumode, u64 period)
>
> So it is not anymore a 'struct hist_entry' method, but a 'struct
> he_stat' one, thus these functions need to be renamed accordingly, in
> the above case it should be:
>
> -static void hist_entry__add_cpumode_period(struct hist_entry *he,
> +static void he_stat__add_cpumode_period(struct he_stat *he_stat,
> + unsigned int cpumode, u64 period)
I see your point. Will change the both.
Thanks,
Namhyung
>
>> {
>> switch (cpumode) {
>> case PERF_RECORD_MISC_KERNEL:
>> -he->stat.period_sys += period;
>> +he_stat->period_sys += period;
>> break;
>> case PERF_RECORD_MISC_USER:
>> -he->stat.period_us += period;
>> +he_stat->period_us += period;
>> break;
>> case PERF_RECORD_MISC_GUEST_KERNEL:
>> -he->stat.period_guest_sys += period;
>> +he_stat->period_guest_sys += period;
>> break;
>> case PERF_RECORD_MISC_GUEST_USER:
>> -he->stat.period_guest_us += period;
>> +he_stat->period_guest_us += period;
>> break;
>> default:
>> break;
>> @@ -223,10 +223,10 @@ static void he_stat__add_stat(struct he_stat *dest,
>> struct he_stat *src)
>> dest->weight+= src->weight;
>> }
>>
>> -static void hist_entry__decay(struct hist_entry *he)
>> +static void hist_entry__decay(struct he_stat *he_stat)
>
> Ditto
>
>> {
>> -he->stat.period = (he->stat.period * 7) / 8;
>> -he->stat.nr_events = (he->stat.nr_events * 7) / 8;
>> +he_stat->period = (he_stat->period * 7) / 8;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 5
Hi all, Changes since 20131104: Removed tree: bcon The sound-asoc tree lost its build failure. The device-mapper tree gained a build failure for which I applied a merge fix patch. The modules tree still produced a very large number of warnings so I used the version from next-20131101. The block tree lost its build failure The staging tree gained a conflict against the block tree. The bcon tree gained a build failure due to an interaction with the block tree. Since the maintainer had indicated that the tree may no longer be linux-next material, I removed the tree. The akpm-current tree gained conflicts against the block tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 211 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (18e8a7387340 ARC: [plat-arcfpga] defconfig update) Merging arm-current/fixes (384b38b66947 ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu) Merging m68k-current/for-linus (55490050df0f m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq stack from softirq stack) Merging sparc/master (6d15ee492809 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (84502b5ef984 xfrm: Fix null pointer dereference when decoding sessions) Merging sound-current/for-linus (a4461f41b94c ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM) Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero") Merging wireless/master (8ce9beac4661 drivers: net: wireless: b43: Fix possible NULL ptr dereference) Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6) Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart selection for older products) Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for Z3X Box device) Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6) Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6) Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for model found on Dell XT2) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging audit-current/for-linus (c158a35c8a68 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9b9bb8 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX
Re: [PATCH 02/14] perf tools: Introduce struct add_entry_iter
On Fri, 1 Nov 2013 13:09:09 +0100, Jiri Olsa wrote:
> On Thu, Oct 31, 2013 at 03:56:04PM +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>
> SNIP
>
>> +}
>> +
>> +static int
>> +iter_add_next_nop_entry(struct add_entry_iter *iter __maybe_unused,
>> +struct addr_location *al __maybe_unused)
>> +{
>> +return 0;
>> +}
>> +
>> +static int
>> +iter_prepare_mem_entry(struct add_entry_iter *iter, struct machine *machine,
>> + struct perf_evsel *evsel, struct addr_location *al,
>> + struct perf_sample *sample)
>> +{
>> +union perf_event *event = iter->priv;
>> +struct mem_info *mi;
>> +u8 cpumode;
>> +
>> +BUG_ON(event == NULL);
>
> the priv does not get assigned.. 'perf mem rep' aborts
>
> [jolsa@krava perf]$ ./perf mem rep --stdio
> Aborted
> perf: builtin-report.c:120: iter_prepare_mem_entry: Assertion `!(event ==
> ((void *)0))' failed.
Argh... forgot to set it for mem entries after code refactoring,
sorry. :-/ Will fix in v3.
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] Generic WorkQueue Engine (GenWQE) device driver (v4)
Hi Greg, Am Montag, den 04.11.2013, 14:15 -0800 schrieb Greg KH: > > I am using sysfs_create_group() now, but do I understand you > correctly > > that setting the const struct attribute_group **groups; in my device > > (where in my struct pci_device.dev?) is an even better way to > establish > > my sysfs attributes? Is there a function which I could call rather > than > > trying to find the right pointer? > > Ugh, this is still a problem, I'm trying to work through how to have > individual drivers implement groups and sysfs files in a non-racy way. > The issue is your device was announced to userspace _before_ it was > bound to the driver, so there's no way to get the sysfs files to apply > before then. > > You should just have the attributes on the sysfs device you create > yourself, not your pci device, as that's where they make more sense, > and > there you should be able to use the attribute group easily, right? > The current version works well for me and I did not get any complaints about the possible race-condition you mentioned so far. So I am happy. > thanks, > > greg k-h Greetings Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
On Tue, Nov 5, 2013 at 11:06 AM, Vivek Gautam wrote: > Hi Tomasz, Sorry my mail client had some problem, so forwarding this again. > > On Nov 4, 2013 5:59 PM, "Tomasz Figa" wrote: >> >> Hi Kishon, >> >> On Monday 04 of November 2013 12:24:42 Kishon Vijay Abraham I wrote: >> > Hi Vivek, >> > >> > On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote: >> > > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. >> > > The new driver uses the generic PHY framework and will interact >> > > with DWC3 controller present on Exynos5 series of SoCs. >> > >> > In Exynos, you have a single IP that supports both USB3 and USB2 PHY >> > right? I think that needs to be mentioned here. >> >> Nope. There are two separate, different IPs. > > AFAICS the dwc3 controller (aka usb 3.0 drd controller, as mentioned in > exynos5 UM) uses a combo of usb 2 (utmi+) and usb 3 (pipe 3) phy (with base > address starting 0x1210), thereby giving the driver only freedom to > control them as one. The entire set of registers with base 0x1210 for > exynos5250 and later 0x1250 for exynos5420 are being programmed by this > driver. That's the reason i structured the driver this way, and thereby it > makes the dwc3 controller to just use only single phy. > Please correct me if i am wrong. > >> >> > Do you have separate registers that should be used for >> > initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If >> > so, then you should model this driver as a single driver that supports >> > two PHYs similar to what Sylwester has done before? >> >> Sylwester's MIPI PHY uses such model because it has a single register >> that controls both PHYs. >> >> Best regards, >> Tomasz >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- Best Regards Vivek Gautam Samsung R Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/14] perf tools: Introduce struct add_entry_iter
Hi Jiri,
On Fri, 1 Nov 2013 13:07:35 +0100, Jiri Olsa wrote:
> On Thu, Oct 31, 2013 at 03:56:04PM +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>
> SNIP
>
>> +
>> +static int
>> +perf_evsel__add_entry(struct perf_evsel *evsel, struct addr_location *al,
>> + struct perf_sample *sample, struct machine *machine,
>> + struct add_entry_iter *iter)
>> +{
>> +int err;
>> +
>> +if ((sort__has_parent || symbol_conf.use_callchain) &&
>> sample->callchain) {
>> +err = machine__resolve_callchain(machine, evsel, al->thread,
>> + sample, >parent, al,
>> + iter->rep->max_stack);
>> +if (err)
>> +return err;
>> +}
>> +
>> +err = iter->prepare_entry(iter, machine, evsel, al, sample);
>> +if (err)
>> +return err;
>> +
>> +err = iter->add_single_entry(iter, al);
>> +if (err)
>> +return err;
>> +
>> +while (iter->next_entry(iter, al)) {
>> +err = iter->add_next_entry(iter, al);
>> +if (err)
>> +break;
>> +}
>> +
>> +err = iter->finish_entry(iter, al);
>> +
>> +return err;
>
> return iter->finish_entry(iter, al); ?
Right. Will fix in v3.
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] BTRFS: fixed two coding style issues
Line 26 and 31: Replaced spaces with tabs at the start of the lines.
Signed-off-by: Aldo Iljazi
---
fs/btrfs/struct-funcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/struct-funcs.c b/fs/btrfs/struct-funcs.c
index b976597..09528ec 100644
--- a/fs/btrfs/struct-funcs.c
+++ b/fs/btrfs/struct-funcs.c
@@ -23,12 +23,12 @@
static inline u8 get_unaligned_le8(const void *p)
{
- return *(u8 *)p;
+ return *(u8 *)p;
}
static inline void put_unaligned_le8(u8 val, void *p)
{
- *(u8 *)p = val;
+ *(u8 *)p = val;
}
/*
--
1.8.3.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 -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
* Masami Hiramatsu wrote:
> (2013/11/05 15:09), Ingo Molnar wrote:
> >
> > * Steven Rostedt wrote:
> >
> >> On Fri, 01 Nov 2013 11:25:37 +
> >> Masami Hiramatsu wrote:
> >>
> >>> Prohibit probing on func_ptr_is_kernel_text().
> >>> Since the func_ptr_is_kernel_text() is called from
> >>> notifier_call_chain() which is called from int3 handler,
> >>> probing it may cause double int3 fault and kernel will
> >>> reboot.
> >>>
> >>> This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
> >>>
> >>> Signed-off-by: Masami Hiramatsu
> >>> Cc: Andrew Morton
> >>> Cc: "Uwe Kleine-König"
> >>> Cc: Borislav Petkov
> >>> Cc: Ingo Molnar
> >>> ---
> >>> kernel/extable.c |2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/kernel/extable.c b/kernel/extable.c
> >>> index 832cb28..022fb25 100644
> >>> --- a/kernel/extable.c
> >>> +++ b/kernel/extable.c
> >>> @@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
> >>> * pointer is part of the kernel text, we need to do some
> >>> * special dereferencing first.
> >>> */
> >>> -int func_ptr_is_kernel_text(void *ptr)
> >>> +int nokprobe func_ptr_is_kernel_text(void *ptr)
> >>> {
> >>> unsigned long addr;
> >>> addr = (unsigned long) dereference_function_descriptor(ptr);
> >>>
> >>
> >> One thing I worry about the "nokprobe" annotation, is that it moves the
> >> location of the function out of local. This function no exists in the
> >> section with its users. Same with the debug functions in the other
> >> patch.
> >
> > Well, it's a bit like noinline, that changes the position of the function
> > as well. So it's not true that 'noxyz' attributes don't affect function
> > placement - they often don't, but some do.
> >
> > The more important aspect is that 'noprobe' makes it really, really
> > apparent what the tag is about, at first sight.
> >
> > _How_ the 'non probing' is achived is an implementational detail when
> > kprobes are enabled: right now it puts a function into a separate section,
> > but we could just a much build a list of function names and check against
> > it at probe insertion time.
>
> Actually, kprobes already has it -- kprobes_blacklist. Currently the
> list is manually maintained in kprobes.c separated from the function
> definition. [...]
Yes, I meant a list that is built automatically from the 'noprobe'
annotations.
> [...] I hope to build the list when the kernel build time if possible...
> Would you have any idea to classify some annotated(but no side-effect)
> functions?
The macro magic I can think of would need to change the syntax of the
function definition - for example that is how the SYSCALL_DEFINE*() macros
work.
It would be nice if there was a GCC extension that marked a function
noinline and allowed the emitting of the function's address (and size)
into a special section - but I'm not aware of any such compiler feature
today.
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] Critical ARC Fix for 3.12
On 11/03/2013 03:59 PM, Geert Uytterhoeven wrote: > Added CC stable, so Greg will see it. > Added commit 9c41f4eeb9d51f3ece20428d35a3ea32cf3b5622, so Greg knows > what to cherry-pick. Thanks Geert. While cover-letter was not, the patch itself was CC'ed to stable - this cover letter, with PATCH prefix has caused enough confusion already :-( Greg, I have verified that patch builds fine with 3.10 and 3.11. Please take it. -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/
[PATCH] BTRFS: fixed coding style issues
Line 4989: Inserted a space after the comma.
Lines 7986 and 8274: Inserted a space before the open parenthesis.
Signed-off-by: Aldo Iljazi
---
fs/btrfs/extent-tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d58bef1..3bcd7c0 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4986,7 +4986,7 @@ int btrfs_delalloc_reserve_metadata(struct inode *inode,
u64 num_bytes)
mutex_unlock(_I(inode)->delalloc_mutex);
if (to_reserve)
- trace_btrfs_space_reservation(root->fs_info,"delalloc",
+ trace_btrfs_space_reservation(root->fs_info, "delalloc",
btrfs_ino(inode), to_reserve, 1);
block_rsv_add_bytes(block_rsv, to_reserve, 1);
@@ -7983,7 +7983,7 @@ u64 btrfs_account_ro_block_groups_free_space(struct
btrfs_space_info *sinfo)
spin_lock(>lock);
- for(i = 0; i < BTRFS_NR_RAID_TYPES; i++)
+ for (i = 0; i < BTRFS_NR_RAID_TYPES; i++)
if (!list_empty(>block_groups[i]))
free_bytes += __btrfs_get_ro_block_group_free_space(
>block_groups[i]);
@@ -8271,7 +8271,7 @@ int btrfs_free_block_groups(struct btrfs_fs_info *info)
release_global_block_rsv(info);
- while(!list_empty(>space_info)) {
+ while (!list_empty(>space_info)) {
space_info = list_entry(info->space_info.next,
struct btrfs_space_info,
list);
--
1.8.3.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 -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
(2013/11/05 15:09), Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
>> On Fri, 01 Nov 2013 11:25:37 +
>> Masami Hiramatsu wrote:
>>
>>> Prohibit probing on func_ptr_is_kernel_text().
>>> Since the func_ptr_is_kernel_text() is called from
>>> notifier_call_chain() which is called from int3 handler,
>>> probing it may cause double int3 fault and kernel will
>>> reboot.
>>>
>>> This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
>>>
>>> Signed-off-by: Masami Hiramatsu
>>> Cc: Andrew Morton
>>> Cc: "Uwe Kleine-König"
>>> Cc: Borislav Petkov
>>> Cc: Ingo Molnar
>>> ---
>>> kernel/extable.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/extable.c b/kernel/extable.c
>>> index 832cb28..022fb25 100644
>>> --- a/kernel/extable.c
>>> +++ b/kernel/extable.c
>>> @@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
>>> * pointer is part of the kernel text, we need to do some
>>> * special dereferencing first.
>>> */
>>> -int func_ptr_is_kernel_text(void *ptr)
>>> +int nokprobe func_ptr_is_kernel_text(void *ptr)
>>> {
>>> unsigned long addr;
>>> addr = (unsigned long) dereference_function_descriptor(ptr);
>>>
>>
>> One thing I worry about the "nokprobe" annotation, is that it moves the
>> location of the function out of local. This function no exists in the
>> section with its users. Same with the debug functions in the other
>> patch.
>
> Well, it's a bit like noinline, that changes the position of the function
> as well. So it's not true that 'noxyz' attributes don't affect function
> placement - they often don't, but some do.
>
> The more important aspect is that 'noprobe' makes it really, really
> apparent what the tag is about, at first sight.
>
> _How_ the 'non probing' is achived is an implementational detail when
> kprobes are enabled: right now it puts a function into a separate section,
> but we could just a much build a list of function names and check against
> it at probe insertion time.
Actually, kprobes already has it -- kprobes_blacklist. Currently
the list is manually maintained in kprobes.c separated from the
function definition. I hope to build the list when the kernel
build time if possible... Would you have any idea to classify
some annotated(but no side-effect) functions?
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Documentation/mfd: Fix typos in s2mps11.txt
Fixed trivial typos to improve readability. Signed-off-by: Sachin Kamat --- Documentation/devicetree/bindings/mfd/s2mps11.txt |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index c9332c6..0ff4e65 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,10 +1,10 @@ * Samsung S2MPS11 Voltage and Current Regulator -The Samsung S2MP211 is a multi-function device which includes voltage and +The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is -interfaced to the host controller using a I2C interface. Each sub-block is -addressed by the host system using different I2C slave address. +interfaced to the host controller using an I2C interface. Each sub-block is +addressed by the host system using different I2C slave addresses. Required properties: - compatible: Should be "samsung,s2mps11-pmic". @@ -43,7 +43,8 @@ sub-node should be of the format as listed below. BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly regulator-ramp-delay = <0> can be used for them to disable ramp delay. - In absence of regulator-ramp-delay property, default ramp delay will be used. + In the absence of regulator-ramp-delay property, default ramp delay will + be used. NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set for a particular group of BUCKs. So provide same regulator-ramp-delay. -- 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: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
unsigned long vaddr;
base_addr = instruction_pointer(regs) - tu->offset;
vaddr = base_addr + addr;
return (void __force __user *) vaddr;
}
When I tested it, it was able to fetch global and bss data from both of
executable and library properly. But it still doesn't work for uretprobes
as you said before.
# perf probe -x ./uprobe-test -a "t1=test1 bss=@0x203000:s32
global=@0x201250:s32 str=@0x201254:string"
# perf probe -x ./uprobe-test -a "t2=test2 bss=@0x203000:s32
global=@0x201250:s32 str=@0x201254:string"
# perf probe -x ./uprobe-test -a "t3=test3 bss=@0x203000:s32
global=@0x201250:s32 str=@0x201254:string"
# perf probe -x ./libfoo.so -a "t4=foo1 bar=@0x201258:s32 baz=@0x203000:s32"
# perf probe -x ./libfoo.so -a "t5=foo2 bar=@0x201258:s32 baz=@0x203000:s32"
# perf probe -x ./libfoo.so -a "t6=foo3 bar=@0x201258:s32 baz=@0x203000:s32"
# perf record -e probe_uprobe:* -e probe_libfoo:* -- ./uprobe-test
# perf script | grep -v ^#
uprobe-test 2997 [002] 13108.308952: probe_uprobe:t1: (400660) bss=0
global=1 str="hello uprobe"
uprobe-test 2997 [002] 13108.322479: probe_uprobe:t2: (400666) bss=0
global=2 str="hello uprobe"
uprobe-test 2997 [002] 13108.335552: probe_uprobe:t3: (40066c) bss=1
global=2 str="hello uprobe"
uprobe-test 2997 [002] 13108.342182: probe_libfoo:t4: (7f5eb977b798)
bar=7 baz=0
uprobe-test 2997 [002] 13108.348982: probe_libfoo:t5: (7f5eb977b79e)
bar=8 baz=0
uprobe-test 2997 [002] 13108.356041: probe_libfoo:t6: (7f5eb977b7a4)
bar=8 baz=9
As you can see symbol offset passed to the uprobes now look like 0x203000
since it's the difference to the base mapping address. For a dso, it's same
as the symbol value, but for an executable the symbol value would be larger
value like 0x603000 since the text segment would be mapped to 0x40.
But still the difference is same, and I believe this applies to the
randomization too.
This symbol offset calculation was done in the getsymoff which implemented
like below (I'm sure there's a much simpler way to do this, but ...).
And I revised my toy test program like this:
/* - 8< - test.c - 8< - */
#include
#include
int global = 1;
char str[] = "hello uprobe";
int bss __attribute__((aligned(4096)));
/* this came from libfoo.so */
extern void foo(void);
void test1(void)
{
/* only for adding probe */
}
void test2(void)
{
/* only for adding probe */
}
void test3(void)
{
/* only for adding probe */
}
int main(void)
{
int local = 3;
char buf[128];
test1();
global = 2;
test2();
bss = 1;
test3();
foo();
// snprintf(buf, sizeof(buf), "cat /proc/%d/maps", getpid());
// system(buf);
return 0;
}
/* - 8< - foo.c - 8< - */
int bar = 7;
int baz __attribute__((aligned(4096)));
void foo1(void)
{
/* only for adding probe */
}
void foo2(void)
{
/* only for adding probe */
}
void foo3(void)
{
/* only for adding probe */
}
void foo(void)
{
foo1();
bar = 8;
foo2();
baz = 9;
foo3();
}
/* - 8< - Makefile - 8< - */
PERF=/home/namhyung/project/linux/tools/perf/perf
GETSYMOFF=./getsymoff
define make-args
$(eval ARG1 := $(shell echo "bss=@`${GETSYMOFF} uprobe-test bss`:s32"))
$(eval ARG2 := $(shell echo "global=@`${GETSYMOFF} uprobe-test global`:s32"))
$(eval ARG3 := $(shell echo "str=@`${GETSYMOFF} uprobe-test str`:string"))
$(eval ARG4 := $(shell echo "bar=@`${GETSYMOFF} libfoo.so bar`:s32"))
$(eval ARG5 := $(shell echo "baz=@`${GETSYMOFF} libfoo.so baz`:s32"))
endef
all: uprobe-test
uprobe-test: test.c foo.c
gcc -shared -g -fpic -o libfoo.so foo.c
gcc -g -o $@ test.c -Wl,-rpath,. -L. -lfoo
getsymoff: getsymoff.c
gcc -g -o $@ getsymoff.c -lelf
test: uprobe-test getsymoff
$(call make-args)
${PERF} probe -x ./uprobe-test -a "t1=test1 ${ARG1} ${ARG2} ${ARG3}"
${PERF} probe -x ./uprobe-test -a "t2=test2 ${ARG1} ${ARG2} ${ARG3}"
${PERF} probe -x ./uprobe-test -a "t3=test3 ${ARG1} ${ARG2} ${ARG3}"
${PERF} probe -x ./libfoo.so -a "t4=foo1 ${ARG4} ${ARG5}"
${PERF} probe -x ./libfoo.so -a "t5=foo2 ${ARG4} ${ARG5}"
${PERF} probe -x ./libfoo.so -a "t6=foo3 ${ARG4} ${ARG5}"
${PERF} record -e probe_uprobe:* -e probe_libfoo:* -- ./uprobe-test
${PERF} script | grep -v ^#
${PERF} probe -d probe_uprobe:*
${PERF} probe -d probe_libfoo:*
clean:
rm -f uprobe-test libfoo.so getsymoff *.o *~
# ${PERF} probe -d probe_uprobe:* -d probe_libfoo:*
/* - 8< - getsymoff.c - 8< - */
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
struct sym {
unsigned long addr;
unsigned long size;
char *name;
};
[PATCH] mmc: sdhci: Setting the host->mrq to NULL before executing tuning
In function sdhci_request(), it is possible to do the tuning execution
like below:
sdhci_request() {
spin_lock_irqsave(>lock, flags);
host->mrq = mrq;
...
spin_unlock_irqrestore(>lock, flags);
<=== Here it is possible one pending finish_tasklet get running
and it will operate the original mrq, and notified the mrq
is done, and causes memory corruption.
sdhci_execute_tuning(mmc, tuning_opcode);
spin_lock_irqsave(>lock, flags);
host->mrq = mrq;
...
}
In the above race place, the original mrq should not be finished wrongly,
so here before unlock the spinlock, we need to set the host->mrq to NULL
to avoid this case.
Signed-off-by: Liu, Chuansheng
---
drivers/mmc/host/sdhci.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7a7fb4f..c7a001a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1391,6 +1391,13 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
mmc->card->type == MMC_TYPE_MMC ?
MMC_SEND_TUNING_BLOCK_HS200 :
MMC_SEND_TUNING_BLOCK;
+
+ /* Here we need to set the host->mrq to NULL,
+* in case the penging finish_tasklet
+* operates it wrongly.
+*/
+ host->mrq = NULL;
+
spin_unlock_irqrestore(>lock, flags);
sdhci_execute_tuning(mmc, tuning_opcode);
spin_lock_irqsave(>lock, flags);
--
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: Avoid needless loop in sdhci_irq() for Card Interrupt
Hi Alexey, On Tue, Nov 5, 2013 at 2:43 AM, Alexey Neyman wrote: > [Patch ping #3: anyone interested in making sdhci_irq a bit faster?] > > Hi all, > > I've discovered that the sdhci_irq() function needlessly iterates re-reading > the interrupt status and doing nothing (until it runs out of max_loops) when > it handles the "Card Interrupt" status in the interrupt status register. > > The reason is that the "Card Interrupt" bit is not cleared until the > sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, > re-reading the interrupt status will find this bit set over and over, even if > no other bits are reported. > > The fix: ignore Card Interrupt bits in the interrupt status if we already know > that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). > > Signed-off-by: Alexey Neyman I also noticed this issue. Your fix looks correct to me. But as following community working way, you need send out patches formerly, not attach a diff file. You can refer to 'git send-email' or try with gmail. BTW, please enrich your patch commit message. Regards Dong Aisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 02:16 PM, Joe Perches wrote: > On Tue, 2013-11-05 at 14:04 +0800, Chen Gang wrote: >> On 11/05/2013 01:54 PM, Joe Perches wrote: >>> On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: > If really as what I guess above (some patches no Signed-of-by), is there > a tool to check and find this issue in time? >>> scripts/checkpatch.pl bleats a message on missing sign-offs. >> >> Yeah, the author/maintainer can use it for checking. >> >> But do we have additional tools to let the version tree integrator (e.g. >> sfr) notice about it? > > git pre-commit hooks work. > > btw: there's some development efforts going on > that might help here eventually. > > Read this thread: > https://lkml.org/lkml/2013/10/26/158 > OK, thanks. It seems it is about commit one patch, and it also seems no "git pre-commit" command (my git version is "git version 1.7.7.6"). And do we have a tool to type a command to check all patches whether missing sign-offs? (I guess, the version integrator need not check patch one by one only for whether contents sign-offs). Oh, I forgot one thing, the original "scripts/get_maintainers.pl" (e.g. in next-20130927), it is already smart enough. So can we treat our patch as the fix patch for the latest changes? 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/
Re: [PATCH] x86: Allow NR_CPUS=1024
On 2013/11/5 14:25, Ingo Molnar wrote: > > * H. Peter Anvin wrote: > >> On 11/04/2013 12:11 PM, Ingo Molnar wrote: >>> >>> * H. Peter Anvin wrote: >>> 8192 maybe? >>> >>> Yeah, that makes more sense I guess. >>> >> >> However, I still have serious issues with crap like this because >> randconfig is basically broken. If nothing else we need to get that >> feedback to the kconfig maintainers. > > The problem with that is that there are no kconfig maintainers: > Yes, there is. https://lkml.org/lkml/2013/10/30/124 Though I don't know if the new maintainer will help in this issue. > KCONFIG > ... > S: Odd Fixes > > The kconfig code is still a hard to maintain, scarcely documented mess. It > took us almost a decade to rescue the NTP code from a similar obfuscation > trap and make it maintainable. It had the same author as the original > Kconfig code - and the Kconfig code is 10 times larger than the NTP code. > > Thanks, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On 31 October 2013 21:46, Lee Jones wrote:
> On Thu, 31 Oct 2013, Tushar Behera wrote:
>
>> S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
>> supported by s2mps11-clk driver.
>>
>> Signed-off-by: Tushar Behera
>> CC: Lee Jones
>> ---
>> drivers/mfd/sec-core.c |4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>> index 34c18fb..020b86b 100644
>> --- a/drivers/mfd/sec-core.c
>> +++ b/drivers/mfd/sec-core.c
>> @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
>> .name = "s5m8767-pmic",
>> }, {
>> .name = "s5m-rtc",
>> - },
>> + }, {
>> + .name = "s5m8767-clk",
>> + }
>> };
>>
>> static struct mfd_cell s2mps11_devs[] = {
>
> Acked-by: Lee Jones
>
Thanks.
> I'd prefer to take this patch in via the MFD tree once you have
> support from the other maintainers for the set.
>
Ok. I will let you know once I get the clock patches through.
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/bounce.c between commit 5d1f127c3e0c ("block: Convert
bio_for_each_segment() to bvec_iter") from the block tree and commit
df5494a36263 ("kthread: make kthread_create() killable") from the
akpm-current 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 mm/bounce.c
index d5873f21567d,c9f0a4339a7d..
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@@ -198,14 -201,11 +198,12 @@@ static void __blk_queue_bounce(struct r
{
struct bio *bio;
int rw = bio_data_dir(*bio_orig);
- struct bio_vec *to, *from;
+ struct bio_vec *to, from;
+ struct bvec_iter iter;
unsigned i;
- if (force)
- goto bounce;
- bio_for_each_segment(from, *bio_orig, i)
- if (page_to_pfn(from->bv_page) > queue_bounce_pfn(q))
+ bio_for_each_segment(from, *bio_orig, iter)
+ if (page_to_pfn(from.bv_page) > queue_bounce_pfn(q))
goto bounce;
return;
pgpBUgsYzSzwg.pgp
Description: PGP signature
linux-next: manual merge of the akpm-current tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
fs/bio-integrity.c between commits ed2d2f9a8265 ("block: Abstract out
bvec iterator") and 5d1f127c3e0c ("block: Convert bio_for_each_segment()
to bvec_iter") from the block tree and commit 6952c5b3b2b7
("fs/bio-integrity.c: remove duplicated code") from the akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/bio-integrity.c
index 31f2d5af7b24,8a78830133ab..
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@@ -304,26 -295,37 +300,38 @@@ static int bio_integrity_generate_verif
{
struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
struct blk_integrity_exchg bix;
- struct bio_vec *bv;
+ struct bio_vec bv;
+ struct bvec_iter iter;
- sector_t sector = bio->bi_iter.bi_sector;
- unsigned int sectors, total;
+ sector_t sector;
- unsigned int i, sectors, total, ret;
++ unsigned int sectors, total, ret;
void *prot_buf = bio->bi_integrity->bip_buf;
- total = 0;
+ if (operate)
- sector = bio->bi_sector;
++ sector = bio->bi_iter.bi_sector;
+ else
- sector = bio->bi_integrity->bip_sector;
++ sector = bio->bi_integrity->bip_iter.bi_sector;
+
+ ret = total = 0;
bix.disk_name = bio->bi_bdev->bd_disk->disk_name;
bix.sector_size = bi->sector_size;
- bio_for_each_segment(bv, bio, i) {
- void *kaddr = kmap_atomic(bv->bv_page);
- bix.data_buf = kaddr + bv->bv_offset;
- bix.data_size = bv->bv_len;
+ bio_for_each_segment(bv, bio, iter) {
+ void *kaddr = kmap_atomic(bv.bv_page);
+ bix.data_buf = kaddr + bv.bv_offset;
+ bix.data_size = bv.bv_len;
bix.prot_buf = prot_buf;
bix.sector = sector;
-
- bi->generate_fn();
+ if (operate) {
+ bi->generate_fn();
+ } else {
+ ret = bi->verify_fn();
+ if (ret) {
+ kunmap_atomic(kaddr);
+ return ret;
+ }
+ }
- sectors = bv->bv_len / bi->sector_size;
+ sectors = bv.bv_len / bi->sector_size;
sector += sectors;
prot_buf += sectors * bi->tuple_size;
total += sectors * bi->tuple_size;
pgpVlwVYYcfj0.pgp
Description: PGP signature
Re: [PATCH] x86: Allow NR_CPUS=1024
* H. Peter Anvin wrote: > On 11/04/2013 12:11 PM, Ingo Molnar wrote: > > > > * H. Peter Anvin wrote: > > > >> 8192 maybe? > > > > Yeah, that makes more sense I guess. > > > > However, I still have serious issues with crap like this because > randconfig is basically broken. If nothing else we need to get that > feedback to the kconfig maintainers. The problem with that is that there are no kconfig maintainers: KCONFIG ... S: Odd Fixes The kconfig code is still a hard to maintain, scarcely documented mess. It took us almost a decade to rescue the NTP code from a similar obfuscation trap and make it maintainable. It had the same author as the original Kconfig code - and the Kconfig code is 10 times larger than the NTP code. 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 -next] get_maintainer: Improve "Author:" rolestats
On Tue, 2013-11-05 at 14:04 +0800, Chen Gang wrote: > On 11/05/2013 01:54 PM, Joe Perches wrote: > > On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: > >> > If really as what I guess above (some patches no Signed-of-by), is there > >> > a tool to check and find this issue in time? > > scripts/checkpatch.pl bleats a message on missing sign-offs. > > Yeah, the author/maintainer can use it for checking. > > But do we have additional tools to let the version tree integrator (e.g. > sfr) notice about it? git pre-commit hooks work. btw: there's some development efforts going on that might help here eventually. Read this thread: https://lkml.org/lkml/2013/10/26/158 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
* Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:37 +
> Masami Hiramatsu wrote:
>
> > Prohibit probing on func_ptr_is_kernel_text().
> > Since the func_ptr_is_kernel_text() is called from
> > notifier_call_chain() which is called from int3 handler,
> > probing it may cause double int3 fault and kernel will
> > reboot.
> >
> > This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
> >
> > Signed-off-by: Masami Hiramatsu
> > Cc: Andrew Morton
> > Cc: "Uwe Kleine-König"
> > Cc: Borislav Petkov
> > Cc: Ingo Molnar
> > ---
> > kernel/extable.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/extable.c b/kernel/extable.c
> > index 832cb28..022fb25 100644
> > --- a/kernel/extable.c
> > +++ b/kernel/extable.c
> > @@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
> > * pointer is part of the kernel text, we need to do some
> > * special dereferencing first.
> > */
> > -int func_ptr_is_kernel_text(void *ptr)
> > +int nokprobe func_ptr_is_kernel_text(void *ptr)
> > {
> > unsigned long addr;
> > addr = (unsigned long) dereference_function_descriptor(ptr);
> >
>
> One thing I worry about the "nokprobe" annotation, is that it moves the
> location of the function out of local. This function no exists in the
> section with its users. Same with the debug functions in the other
> patch.
Well, it's a bit like noinline, that changes the position of the function
as well. So it's not true that 'noxyz' attributes don't affect function
placement - they often don't, but some do.
The more important aspect is that 'noprobe' makes it really, really
apparent what the tag is about, at first sight.
_How_ the 'non probing' is achived is an implementational detail when
kprobes are enabled: right now it puts a function into a separate section,
but we could just a much build a list of function names and check against
it at probe insertion time.
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 -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 01:54 PM, Joe Perches wrote: > On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: >> > If really as what I guess above (some patches no Signed-of-by), is there >> > a tool to check and find this issue in time? > scripts/checkpatch.pl bleats a message on missing sign-offs. Yeah, the author/maintainer can use it for checking. But do we have additional tools to let the version tree integrator (e.g. sfr) notice about it? 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/
Re: [PATCH -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 01:50 PM, Joe Perches wrote: > On Tue, 2013-11-05 at 13:42 +0800, Chen Gang wrote: >> On 11/05/2013 01:23 PM, Joe Perches wrote: >>> On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote: > >> (if so, it seems the related >> patch need be re-committed again by the related author). > > No it doesn't mean that. > > Prior to this patch, get_maintainer only used "sign-off-by" > style lines to find interested parties to send patches to > when the MAINTAINERS file did not have a specific section > entry with a matching file pattern to the files that that > the patch modified. > > And there was a defect in the script when no commit history > at all was found for the files modified during the period > selected (1 year of git log history by default) > > Now, using this newly modified get_maintainer.pl script, > the commit authors shown in the git log history as well as > the commit signers are selected. > > If there is no git history, the script defect is also fixed. > Yeah, our "get_maintainer.pl" need be smart enough to bear it (this patch let our "get_maintainer.pl" smart enough). But for this kind of patch, need it re-commit again? (for me, I recommend to re-commit it again by the related author). 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/
Re: [PATCH -next] get_maintainer: Improve "Author:" rolestats
On Tue, 2013-11-05 at 13:45 +0800, Chen Gang wrote: > If really as what I guess above (some patches no Signed-of-by), is there > a tool to check and find this issue in time? scripts/checkpatch.pl bleats a message on missing sign-offs. For instance: $ cat cache.diff include/linux/cache.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/cache.h b/include/linux/cache.h index 4c57065..17e7e82 100644 --- a/include/linux/cache.h +++ b/include/linux/cache.h @@ -1,11 +1,11 @@ #ifndef __LINUX_CACHE_H #define __LINUX_CACHE_H -#include +#include #include #ifndef L1_CACHE_ALIGN -#define L1_CACHE_ALIGN(x) ALIGN(x, L1_CACHE_BYTES) +#define L1_CACHE_ALIGN(x) __ALIGN_KERNEL(x, L1_CACHE_BYTES) #endif #ifndef SMP_CACHE_BYTES $ ./scripts/checkpatch.pl cache.diff ERROR: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 13 lines checked cache.diff has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] get_maintainer: Improve "Author:" rolestats
On Tue, 2013-11-05 at 13:42 +0800, Chen Gang wrote:
> On 11/05/2013 01:23 PM, Joe Perches wrote:
> > On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote:
> >> But after I let it pure next-20131101 ("git reset HEAD^; git stash"), it
> >> still cause this issue.
> >
> > It's also because:
> >
> Also, there's a defect in function vcs_find_signers.
> It should only return the commit count and array references.
>
> If there are no signers in the commit history interval specified,
> then the "authors" array is added to the "signers" array and
> returned as a single array.
>
> OK, thanks. Do you mean: in pure next-20131101 contents an author which
> commit a patch, but not signed himself?
Yes, I mean that.
> (if so, it seems the related
> patch need be re-committed again by the related author).
No it doesn't mean that.
Prior to this patch, get_maintainer only used "sign-off-by"
style lines to find interested parties to send patches to
when the MAINTAINERS file did not have a specific section
entry with a matching file pattern to the files that that
the patch modified.
And there was a defect in the script when no commit history
at all was found for the files modified during the period
selected (1 year of git log history by default)
Now, using this newly modified get_maintainer.pl script,
the commit authors shown in the git log history as well as
the commit signers are selected.
If there is no git history, the script defect is also fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 01:42 PM, Chen Gang wrote:
> On 11/05/2013 01:23 PM, Joe Perches wrote:
>> On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote:
>>> But after I let it pure next-20131101 ("git reset HEAD^; git stash"), it
>>> still cause this issue.
>>
>> It's also because:
>>
> Also, there's a defect in function vcs_find_signers.
> It should only return the commit count and array references.
>
> If there are no signers in the commit history interval specified,
> then the "authors" array is added to the "signers" array and
> returned as a single array.
>>
>>
>>
>>
>
> OK, thanks. Do you mean: in pure next-20131101 contents an author which
> commit a patch, but not signed himself? (if so, it seems the related
> patch need be re-committed again by the related author).
>
If really as what I guess above (some patches no Signed-of-by), is there
a tool to check and find this issue in time?
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/
Re: [PATCH -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 01:23 PM, Joe Perches wrote:
> On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote:
>> But after I let it pure next-20131101 ("git reset HEAD^; git stash"), it
>> still cause this issue.
>
> It's also because:
>
Also, there's a defect in function vcs_find_signers.
It should only return the commit count and array references.
If there are no signers in the commit history interval specified,
then the "authors" array is added to the "signers" array and
returned as a single array.
>
>
>
>
OK, thanks. Do you mean: in pure next-20131101 contents an author which
commit a patch, but not signed himself? (if so, it seems the related
patch need be re-committed again by the related author).
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 bcon tree
Hi Jörn, After merging the bcon tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/block/blockconsole.c: In function 'sync_read': drivers/block/blockconsole.c:184:5: error: 'struct bio' has no member named 'bi_idx' bio.bi_idx = 0; ^ drivers/block/blockconsole.c:185:5: error: 'struct bio' has no member named 'bi_size' bio.bi_size = SECTOR_SIZE; ^ drivers/block/blockconsole.c:187:5: error: 'struct bio' has no member named 'bi_sector' bio.bi_sector = ofs >> SECTOR_SHIFT; ^ drivers/block/blockconsole.c: In function 'bcon_erase_segment': drivers/block/blockconsole.c:215:6: error: 'struct bio' has no member named 'bi_size' bio->bi_size = PAGE_SIZE; ^ drivers/block/blockconsole.c:218:6: error: 'struct bio' has no member named 'bi_idx' bio->bi_idx = 0; ^ drivers/block/blockconsole.c:219:6: error: 'struct bio' has no member named 'bi_sector' bio->bi_sector = (bc->write_bytes + i * PAGE_SIZE) >> 9; ^ drivers/block/blockconsole.c: In function 'bcon_writesector': drivers/block/blockconsole.c:338:5: error: 'struct bio' has no member named 'bi_size' bio->bi_size = SECTOR_SIZE; ^ drivers/block/blockconsole.c:343:5: error: 'struct bio' has no member named 'bi_idx' bio->bi_idx = 0; ^ drivers/block/blockconsole.c:344:5: error: 'struct bio' has no member named 'bi_sector' bio->bi_sector = bc->write_bytes >> 9; ^ Caused by changes in the block tree. Thierry Reding mentioned that you didn't think that the bcon tree was linux-next material any more, so I just dropped your tree. If that is incorrect, please let me know and I will reinstate it and fix this merge conflict. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpvlDXdyWcUe.pgp Description: PGP signature
Attn.......
-- Good day, I am Mr. Cham Tao Soon, Chairman Audit Committee of UOB Bank, Singapore. I have a project for you in the tons of One Hundred & Five Million EUR, after successful transfer, we shall share in the ratio of forty for you and sixty for me. Please reply for specifics. Yours, Mr. Cham Tao Soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] get_maintainer: Improve "Author:" rolestats
On Tue, 2013-11-05 at 10:37 +0800, Chen Gang wrote:
> But after I let it pure next-20131101 ("git reset HEAD^; git stash"), it
> still cause this issue.
It's also because:
> >> Also, there's a defect in function vcs_find_signers.
> >> It should only return the commit count and array references.
> >>
> >> If there are no signers in the commit history interval specified,
> >> then the "authors" array is added to the "signers" array and
> >> returned as a single array.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 staging tree with the block tree
On Tue, Nov 05, 2013 at 04:09:24PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
> ("block: Abstract out bvec iterator") from the block tree and commit
> de40d1209898 ("staging: lustre: fix bug with LL_MRF_RETURN in
> loop_make_request") from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me, 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/
linux-next: manual merge of the staging tree with the block tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
("block: Abstract out bvec iterator") from the block tree and commit
de40d1209898 ("staging: lustre: fix bug with LL_MRF_RETURN in
loop_make_request") from the staging 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/staging/lustre/lustre/llite/lloop.c
index 3488bb6c44a7,e2421ea61352..
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@@ -368,10 -365,9 +367,9 @@@ static void loop_make_request(struct re
goto err;
}
loop_add_bio(lo, old_bio);
- LL_MRF_RETURN(0);
+ return;
err:
- cfs_bio_io_error(old_bio, old_bio->bi_size);
+ cfs_bio_io_error(old_bio, old_bio->bi_iter.bi_size);
- LL_MRF_RETURN(0);
}
pgpdDLQfbmLDS.pgp
Description: PGP signature
Re: Linux 3.12 released .. and 4.0 plans?
Am 04.11.2013 22:46, schrieb Jan Engelhardt: > > On Monday 2013-11-04 01:10, Linus Torvalds wrote: >> >> Onto a totally different topic: we're getting to release numbers where >> I have to take off my socks to count that high again. I'm ok with >> 3. [...] [4.0 "ok, after 3.19 (or whatever),"] > > What would you do when the major number becomes such an unpleasant > highteen number? (That will be in ~64 years if you wrap after x.19.) Changing the counting base and going hex would offer some more years. So after 9.19 he could switch to a.0 instead of 10.0. Or just call it then LinuxNG and start with 1.0 again. But to add something serious to the discussion too, I don't see a reason why to make a bugfix-only version. There should be no need to spend a version number for a bugfix only time. E.g. just insert a bugfix-only time (handled like times at -rc7) before a merge window for a new version. That would give people the possibility to get their bugfix-patches into mainline in order to get them into the stable series without the need to spend a version number. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.12 released .. and 4.0 plans?
Jan Engelhardt wrote: > > On Monday 2013-11-04 01:10, Linus Torvalds wrote: > > > >Onto a totally different topic: we're getting to release numbers where > >I have to take off my socks to count that high again. I'm ok with > >3. [...] [4.0 "ok, after 3.19 (or whatever),"] > > What would you do when the major number becomes such an unpleasant > highteen number? (That will be in ~64 years if you wrap after x.19.) > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I guess renaming the kernel would be an option. (Linus would be ~106 years old by the way.) -- Aldo Iljazi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tools/perf/build: Fix detection of non-core features
ping. did not see this one in your last push to Ingo. On 10/29/13, 10:43 AM, David Ahern wrote: feature_check needs to be invoked through call, and LDFLAGS may not be set so quotes are needed. Thanks to Jiri for spotting the quotes around LDFLAGS; that one was driving me nuts with the upcoming timerfd feature detection. Signed-off-by: David Ahern Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Namhyung Kim Cc: Jiri Olsa --- tools/perf/config/Makefile | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 543aa953bab1..c82772207e6e 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -96,7 +96,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS="$(LDFLAGS)" -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -233,7 +233,7 @@ CFLAGS += -I$(LIB_INCLUDE) CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE ifndef NO_BIONIC - $(feature_check,bionic) + $(call feature_check,bionic) ifeq ($(feature-bionic), 1) BIONIC := 1 EXTLIBS := $(filter-out -lrt,$(EXTLIBS)) @@ -470,15 +470,15 @@ else CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT else ifneq ($(feature-libbfd), 1) - $(feature_check,liberty) + $(call feature_check,liberty) ifeq ($(feature-liberty), 1) EXTLIBS += -lbfd -liberty else -$(feature_check,liberty-z) +$(call feature_check,liberty-z) ifeq ($(feature-liberty-z), 1) EXTLIBS += -lbfd -liberty -lz else - $(feature_check,cplus-demangle) + $(call feature_check,cplus-demangle) ifeq ($(feature-cplus-demangle), 1) EXTLIBS += -liberty CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf kvm: Disable live command if timerfd is not supported
ditto
On 10/29/13, 10:43 AM, David Ahern wrote:
If the OS does not have timerfd support (e.g., older OS'es like RHEL5)
disable perf kvm stat live.
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Namhyung Kim
Cc: Jiri Olsa
---
tools/perf/builtin-kvm.c| 12
tools/perf/config/Makefile | 7 +++
tools/perf/config/feature-checks/Makefile | 6 +-
tools/perf/config/feature-checks/test-all.c | 5 +
tools/perf/config/feature-checks/test-timerfd.c | 18 ++
5 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/config/feature-checks/test-timerfd.c
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index cb05f39d8a77..cd9f92078aba 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -20,7 +20,9 @@
#include "util/data.h"
#include
+#ifdef HAVE_TIMERFD_SUPPORT
#include
+#endif
#include
#include
@@ -337,6 +339,7 @@ static void init_kvm_event_record(struct perf_kvm_stat *kvm)
INIT_LIST_HEAD(>kvm_events_cache[i]);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static void clear_events_cache_stats(struct list_head *kvm_events_cache)
{
struct list_head *head;
@@ -358,6 +361,7 @@ static void clear_events_cache_stats(struct list_head
*kvm_events_cache)
}
}
}
+#endif
static int kvm_events_hash_fn(u64 key)
{
@@ -783,6 +787,7 @@ static void print_result(struct perf_kvm_stat *kvm)
pr_info("\nLost events: %" PRIu64 "\n\n", kvm->lost_events);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static int process_lost_event(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_sample *sample __maybe_unused,
@@ -793,6 +798,7 @@ static int process_lost_event(struct perf_tool *tool,
kvm->lost_events++;
return 0;
}
+#endif
static bool skip_sample(struct perf_kvm_stat *kvm,
struct perf_sample *sample)
@@ -872,6 +878,7 @@ static bool verify_vcpu(int vcpu)
return true;
}
+#ifdef HAVE_TIMERFD_SUPPORT
/* keeping the max events to a modest level to keep
* the processing of samples per mmap smooth.
*/
@@ -1213,6 +1220,7 @@ static int kvm_live_open_events(struct perf_kvm_stat *kvm)
out:
return rc;
}
+#endif
static int read_events(struct perf_kvm_stat *kvm)
{
@@ -1379,6 +1387,7 @@ kvm_events_report(struct perf_kvm_stat *kvm, int argc,
const char **argv)
return kvm_events_report_vcpu(kvm);
}
+#ifdef HAVE_TIMERFD_SUPPORT
static struct perf_evlist *kvm_live_event_list(void)
{
struct perf_evlist *evlist;
@@ -1566,6 +1575,7 @@ out:
return err;
}
+#endif
static void print_kvm_stat_usage(void)
{
@@ -1604,8 +1614,10 @@ static int kvm_cmd_stat(const char *file_name, int argc,
const char **argv)
if (!strncmp(argv[1], "rep", 3))
return kvm_events_report(, argc - 1 , argv + 1);
+#ifdef HAVE_TIMERFD_SUPPORT
if (!strncmp(argv[1], "live", 4))
return kvm_events_live(, argc - 1 , argv + 1);
+#endif
perf_stat:
return cmd_stat(argc, argv, NULL);
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index c82772207e6e..afe4945e3e84 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -395,6 +395,13 @@ else
endif
endif
+$(call feature_check,timerfd)
+ifeq ($(feature-timerfd), 1)
+ CFLAGS += -DHAVE_TIMERFD_SUPPORT
+else
+ msg := $(warning No timerfd support. Disables 'perf kvm stat live');
+endif
+
disable-python = $(eval $(disable-python_code))
define disable-python_code
CFLAGS += -DNO_LIBPYTHON
diff --git a/tools/perf/config/feature-checks/Makefile
b/tools/perf/config/feature-checks/Makefile
index 452b67cc4d7b..a4d4173c576e 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -25,7 +25,8 @@ FILES=\
test-libunwind \
test-on-exit\
test-stackprotector-all \
- test-stackprotector
+ test-stackprotector \
+ test-timerfd
CC := $(CC) -MD
@@ -136,6 +137,9 @@ test-on-exit:
test-backtrace:
$(BUILD)
+test-timerfd:
+ $(BUILD)
+
-include *.d
###
diff --git a/tools/perf/config/feature-checks/test-all.c
b/tools/perf/config/feature-checks/test-all.c
index 50d431892a0c..59e7a705e146 100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@ -81,6 +81,10 @@
# include "test-libnuma.c"
#undef main
+#define main main_test_timerfd
+# include "test-timerfd.c"
+#undef main
+
int main(int argc, char *argv[])
{
main_test_libpython();
@@ -101,6 +105,7 @@ int main(int argc, char *argv[])
main_test_on_exit();
Re: [PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance
Adding shawn in cc list..
On 5 November 2013 08:40, rjying wrote:
> From: Rongjun Ying
>
> Sometime the regulator can't supply appropriate voltages for requestion of
> cpu.
> All voltage tolerance value can't figure out a good voltage.
>
> Signed-off-by: Rongjun Ying
> ---
> drivers/cpufreq/cpufreq-cpu0.c | 17 ++---
> 1 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index c522a95..0c9e6b9 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -23,7 +23,7 @@
> #include
>
> static unsigned int transition_latency;
> -static unsigned int voltage_tolerance; /* in percentage */
> +static unsigned int voltage_max;
>
> static struct device *cpu_dev;
> static struct clk *cpu_clk;
> @@ -45,7 +45,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
> {
> struct cpufreq_freqs freqs;
> struct opp *opp;
> - unsigned long volt = 0, volt_old = 0, tol = 0;
> + unsigned long volt = 0, volt_old = 0;
> long freq_Hz, freq_exact;
> unsigned int index;
> int ret;
> @@ -82,7 +82,6 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
> }
> volt = opp_get_voltage(opp);
> rcu_read_unlock();
> - tol = volt * voltage_tolerance / 100;
> volt_old = regulator_get_voltage(cpu_reg);
> }
>
> @@ -92,7 +91,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
>
> /* scaling up? scale voltage before frequency */
> if (!IS_ERR(cpu_reg) && freqs.new > freqs.old) {
> - ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> + ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
> if (ret) {
> pr_err("failed to scale voltage up: %d\n", ret);
> freqs.new = freqs.old;
> @@ -104,14 +103,14 @@ static int cpu0_set_target(struct cpufreq_policy
> *policy,
> if (ret) {
> pr_err("failed to set clock rate: %d\n", ret);
> if (!IS_ERR(cpu_reg))
> - regulator_set_voltage_tol(cpu_reg, volt_old, tol);
> + regulator_set_voltage(cpu_reg, volt_old, voltage_max);
> freqs.new = freqs.old;
> goto post_notify;
> }
>
> /* scaling down? scale voltage after frequency */
> if (!IS_ERR(cpu_reg) && freqs.new < freqs.old) {
> - ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> + ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
> if (ret) {
> pr_err("failed to scale voltage down: %d\n", ret);
> clk_set_rate(cpu_clk, freqs.old * 1000);
> @@ -224,7 +223,11 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> goto out_put_node;
> }
>
> - of_property_read_u32(np, "voltage-tolerance", _tolerance);
> + ret = of_property_read_u32(np, "voltage-max", _max);
> + if (ret) {
> + pr_err("failed to get max voltage: %d\n", ret);
> + goto out_put_node;
> + }
>
> if (of_property_read_u32(np, "clock-latency", _latency))
> transition_latency = CPUFREQ_ETERNAL;
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/build] x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig
On 11/05/2013 12:03 PM, tip-bot for Chen Gang wrote: > Commit-ID: 7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 > Gitweb: http://git.kernel.org/tip/7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 > Author: Chen Gang > AuthorDate: Tue, 5 Nov 2013 09:46:39 +0800 > Committer: H. Peter Anvin > CommitDate: Mon, 4 Nov 2013 20:01:55 -0800 > > x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig > > The defconfig kernel can not run under neither fedora16 x86_64 laptop > nor fedora17 x86_64 pc. After enable DEVTMPFS* in x86_64_defconfig, it > will be OK. > > DEVTMPFS* is only related with software, so for i386_defconfig may also > need them (at least, it has no negative effect for defconfig). > > Signed-off-by: Chen Gang > Link: http://lkml.kernel.org/r/52784dff.8040...@asianux.com > Signed-off-by: H. Peter Anvin 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/
Re: Disabling in-memory write cache for x86-64 in Linux II
On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote: > > On Oct 25, 2013, at 2:18 AM, Linus Torvalds > wrote: > > On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov > > wrote: > >> > >> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 > >> kernel built for the i686 (with PAE) and x86-64 architectures. What’s > >> really troubling me is that the x86-64 kernel has the following problem: > >> > >> When I copy large files to any storage device, be it my HDD with ext4 > >> partitions or flash drive with FAT32 partitions, the kernel first > >> caches them in memory entirely then flushes them some time later > >> (quite unpredictably though) or immediately upon invoking "sync". > > > > Yeah, I think we default to a 10% "dirty background memory" (and > > allows up to 20% dirty), so on your 16GB machine, we allow up to 1.6GB > > of dirty memory for writeout before we even start writing, and twice > > that before we start *waiting* for it. > > > > On 32-bit x86, we only count the memory in the low 1GB (really > > actually up to about 890MB), so "10% dirty" really means just about > > 90MB of buffering (and a "hard limit" of ~180MB of dirty). > > > > And that "up to 3.2GB of dirty memory" is just crazy. Our defaults > > come from the old days of less memory (and perhaps servers that don't > > much care), and the fact that x86-32 ends up having much lower limits > > even if you end up having more memory. > > I think the “delay writes for a long time” is a holdover from the > days when e.g. /tmp was on a disk and compilers had lousy IO > patterns, then they deleted the file. Today, /tmp is always in > RAM, and IMHO the “write and delete” workload tested by dbench > is not worthwhile optimizing for. > > With Lustre, we’ve long taken the approach that if there is enough > dirty data on a file to make a decent write (which is around 8MB > today even for very fast storage) then there isn’t much point to > hold back for more data before starting the IO. Agreed - write-through caching is much better for high throughput streaming data environments than write back caching that can leave the devices unnecessarily idle. However, most systems are not running in high-throughput streaming data environments... :/ > Any decent allocator will be able to grow allocated extents to > handle following data, or allocate a new extent. At 4-8MB extents, > even very seek-impaired media could do 400-800MB/s (likely much > faster than the underlying storage anyway). True, but this makes the assumption that the filesystem you are using is optimising purely for write throughput and your storage is not seek limited on reads. That's simply not an assumption we can allow the generic writeback code to make. In more detail, if we simply implement "we have 8 MB of dirty pages on a single file, write it" we can maximise write throughput by allocating sequentially on disk for each subsquent write. The problem with this comes when you are writing multiple files at a time, and that leads to this pattern on disk: ABC...ABCABCABC And the result is a) fragmented files b) a large number of seeks during sequential read operations and c) filesystems that age and degrade rapidly under workloads that concurrently write files with different life times (i.e. due to free space fragmention). In some situations this is acceptable, but the performance degradation as the filesystem ages that this sort of allocation causes in most environments is not. I'd say that >90% of filesystems out there would suffer accelerated aging as a result of doing writeback in this manner by default. > This also avoids wasting (tens of?) seconds of idle disk bandwidth. > If the disk is already busy, then the IO will be delayed anyway. > If it is not busy, then why aggregate GB of dirty data in memory > before flushing it? There are plenty of workloads out there where delaying IO for a few seconds can result in writeback that is an order of magnitude faster. Similarly, I've seen other workloads where the writeback delay results in files that can be *read* orders of magnitude faster > Something simple like “start writing at 16MB dirty on a single file” > would probably avoid a lot of complexity at little real-world cost. > That shouldn’t throttle dirtying memory above 16MB, but just start > writeout much earlier than it does today. That doesn't solve the "slow device, large file" problem. We can write data into the page cache at rates of over a GB/s, so it's irrelevant to a device that can write at 5MB/s whether we start writeback immediately or a second later when there is 500MB of dirty pages in memory. AFAIK, the only way to avoid that problem is to use write-through caching for such devices - where they throttle to the IO rate at very low levels of cached data. Realistically, there is no "one right answer" for all combinations of applications, filesystems and hardware, but writeback caching is the best *general
[tip:x86/build] x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig
Commit-ID: 7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Gitweb: http://git.kernel.org/tip/7f71be4c9f9a334e7bd0adc66225db4eb88c3bc4 Author: Chen Gang AuthorDate: Tue, 5 Nov 2013 09:46:39 +0800 Committer: H. Peter Anvin CommitDate: Mon, 4 Nov 2013 20:01:55 -0800 x86, defconfig: Add DEVTMPFS and DEVTMPFS_MOUNT to *86*_defconfig The defconfig kernel can not run under neither fedora16 x86_64 laptop nor fedora17 x86_64 pc. After enable DEVTMPFS* in x86_64_defconfig, it will be OK. DEVTMPFS* is only related with software, so for i386_defconfig may also need them (at least, it has no negative effect for defconfig). Signed-off-by: Chen Gang Link: http://lkml.kernel.org/r/52784dff.8040...@asianux.com Signed-off-by: H. Peter Anvin --- arch/x86/configs/i386_defconfig | 2 ++ arch/x86/configs/x86_64_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 9444708..a7fef26 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -142,6 +142,8 @@ CONFIG_MAC80211=y CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 671524d..c1119d4 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -141,6 +141,8 @@ CONFIG_MAC80211=y CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] toshiba_acpi: Add System Configuration Interface (SCI)
The SCI stands for System Configuration Interface and
it is supposed to be uniform across all their
models.
This patch introduces four new calls, sci_open, sci_close
sci_read and sci_write, along with its definitions and
return codes.
The HCI_ prefix has been removed from all return codes,
since they are shared among the HCI and the SCI.
More information about the SCI can be found at
Jonathan Buzzard's website [1].
[1] http://www.buzzard.me.uk/toshiba/docs.html
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 146 +++-
1 file changed, 112 insertions(+), 34 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index eb3467e..1e580dd 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -71,27 +71,37 @@ MODULE_LICENSE("GPL");
/* Toshiba ACPI method paths */
#define METHOD_VIDEO_OUT "\\_SB_.VALX.DSSX"
-/* Toshiba HCI interface definitions
+/* TCI - Toshiba Configuration Interface definitions
*
- * HCI is Toshiba's "Hardware Control Interface" which is supposed to
- * be uniform across all their models. Ideally we would just call
- * dedicated ACPI methods instead of using this primitive interface.
- * However the ACPI methods seem to be incomplete in some areas (for
- * example they allow setting, but not reading, the LCD brightness value),
+ * This configuration interface is composed by the HCI (Hardware Configuration
+ * Interface) and the SCI (Software Configuration Interface), which are
+ * supposed to be uniform across all their models. Ideally we would just call
+ * dedicated ACPI methods instead of using these primitive interfaces.
+ * However the ACPI methods seem to be incomplete in some areas (for example
+ * they allow setting, but not reading, the LCD brightness value),
* so this is still useful.
*/
#define HCI_WORDS 6
/* operations */
-#define HCI_SET0xff00
+#define SCI_OPEN 0xf100
+#define SCI_CLOSE 0xf200
+#define SCI_GET0xf300
+#define SCI_SET0xf400
#define HCI_GET0xfe00
+#define HCI_SET0xff00
/* return codes */
-#define HCI_SUCCESS0x
-#define HCI_FAILURE0x1000
-#define HCI_NOT_SUPPORTED 0x8000
-#define HCI_EMPTY 0x8c00
+#define SUCCESS0x
+#define OPEN_CLOSE_SUCCESS 0x0044
+#define FAILURE0x1000
+#define NOT_SUPPORTED 0x8000
+#define ALREADY_OPEN 0x8100
+#define NOT_OPENED 0x8200
+#define INPUT_DATA_ERROR 0x8300
+#define NOT_PRESENT0x8600
+#define FIFO_EMPTY 0x8c00
/* registers */
#define HCI_FAN0x0004
@@ -251,7 +261,7 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -262,7 +272,7 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
*out1 = out[2];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -272,7 +282,7 @@ static acpi_status hci_write2(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = hci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
return status;
}
@@ -284,7 +294,75 @@ static acpi_status hci_read2(struct toshiba_acpi_dev *dev,
u32 reg,
acpi_status status = hci_raw(dev, in, out);
*out1 = out[2];
*out2 = out[3];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : FAILURE;
+ return status;
+}
+
+/* common sci tasks
+ */
+
+static int sci_open(struct toshiba_acpi_dev *dev)
+{
+ u32 in[HCI_WORDS] = { SCI_OPEN, 0, 0, 0, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == FAILURE) {
+ pr_err("ACPI call to open SCI failed\n");
+ return 0;
+ }
+
+ if (out[0] == OPEN_CLOSE_SUCCESS) {
+ return 1;
+ } else if (out[0] == ALREADY_OPEN) {
+
[PATCH 0/8] toshiba_acpi: New features added and a fix
Up for review, the following patch series add new features found on newer Toshiba laptops. The first two fix an illumination detection bug, so consider applying those to stable. The rest just add support for touchpad, accelerometer axes, keyboard backlight and ECO led, plus platform support, bumping the version to 0.20. These apply cleanly to Matthew's platform tree and with just some fuzz to next tree. [PATCH 1/8] toshiba_acpi: Add System Configuration Interface (SCI) [PATCH 2/8] toshiba_acpi: Adapt illumination_* code to use the new SCI [PATCH 3/8] toshiba_acpi: Add platform support [PATCH 4/8] toshiba_acpi: Add kbd backlight support and sysfs files [PATCH 5/8] toshiba_acpi: Add ECO led support [PATCH 6/8] toshiba_acpi: Add accelerometer support [PATCH 7/8] toshiba_acpi: Add touchpad enable/disable support [PATCH 8/8] toshiba_acpi: Update version and copyright information Saludos Azael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] toshiba_acpi: Adapt illumination_* code to use the new SCI
Change the toshiba_illumination_* code to use the newly
introduced sci_read and sci_write functions, and in the
process fix toshiba_illumination_available code, since
it was only opening the SCI and the return value was
never checked for errors or actual illumination support.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 91 ++---
1 file changed, 33 insertions(+), 58 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 1e580dd..d7ecef3 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -111,6 +111,7 @@ MODULE_LICENSE("GPL");
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define SCI_ILLUMINATION 0x014e
/* field definitions */
#define HCI_HOTKEY_DISABLE 0x0b
@@ -369,18 +370,23 @@ static acpi_status sci_write(struct toshiba_acpi_dev
*dev, u32 reg,
/* Illumination support */
static int toshiba_illumination_available(struct toshiba_acpi_dev *dev)
{
- u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
+ u32 in[TCI_WORDS] = { SCI_GET, SCI_ILLUMINATION, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status;
- in[0] = 0xf100;
+ if (!sci_open(dev))
+ return 0;
+
status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
+ if (ACPI_FAILURE(status) || out[0] == FAILURE) {
+ pr_err("ACPI call to query Illumination support failed\n");
+ return 0;
+ } else if (out[0] == NOT_SUPPORTED || out[1] != 1) {
pr_info("Illumination device not available\n");
return 0;
}
- in[0] = 0xf400;
- status = hci_raw(dev, in, out);
+ sci_close(dev);
+
return 1;
}
@@ -391,43 +397,23 @@ static void toshiba_illumination_set(struct led_classdev
*cdev,
struct toshiba_acpi_dev, led_dev);
u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
+ u32 state, result;
acpi_status status;
- /* First request : initialize communication. */
- in[0] = 0xf100;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info("Illumination device not available\n");
+ if (!sci_open(dev))
return;
- }
- if (brightness) {
- /* Switch the illumination on */
- in[0] = 0xf400;
- in[1] = 0x14e;
- in[2] = 1;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info("ACPI call for illumination failed\n");
- return;
- }
- } else {
- /* Switch the illumination off */
- in[0] = 0xf400;
- in[1] = 0x14e;
- in[2] = 0;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info("ACPI call for illumination failed.\n");
- return;
- }
+ /* Switch the illumination on/off */
+ state = brightness ? 1 : 0;
+ status = sci_write(dev, SCI_ILLUMINATION, state, );
+ if (ACPI_FAILURE(status)) {
+ pr_err("ACPI call for illumination failed\n");
+ return;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info("Illumination not supported\n");
+ return;
}
-
- /* Last request : close communication. */
- in[0] = 0xf200;
- in[1] = 0;
- in[2] = 0;
- hci_raw(dev, in, out);
+ sci_close(dev);
}
static enum led_brightness toshiba_illumination_get(struct led_classdev *cdev)
@@ -436,35 +422,24 @@ static enum led_brightness
toshiba_illumination_get(struct led_classdev *cdev)
struct toshiba_acpi_dev, led_dev);
u32 in[HCI_WORDS] = { 0, 0, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
+ u32 state, result;
acpi_status status;
- enum led_brightness result;
- /* First request : initialize communication. */
- in[0] = 0xf100;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info("Illumination device not available\n");
+ if (!sci_open(dev))
return LED_OFF;
- }
/* Check the illumination */
- in[0] = 0xf300;
- in[1] = 0x14e;
- status = hci_raw(dev, in, out);
- if (ACPI_FAILURE(status)) {
- pr_info("ACPI call for illumination failed.\n");
+ status = sci_read(dev, SCI_ILLUMINATION, , );
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err("ACPI call for illumination failed\n");
+ return LED_OFF;
+ } else if (result == NOT_SUPPORTED) {
+
[PATCH 4/8] toshiba_acpi: Add kbd backlight support and sysfs files
Toshiba laptops equiped with an illuminated keyboard
can operate in two different modes: Auto and FN-Z.
The Auto mode turns on the led on keystrokes and
automatically turns it off after some (configurable)
time the last key was pressed.
The FN-Z mode is used to toggle the keyboard led on/off
by userspace.
This patch adds support to set the desired KBD mode and
timeout via sysfs, creates and registers toshiba::kbd_backlight
led device whenever the mode is set to FN-Z.
The acceptable values for mode are: 1 (Auto) and 2 (Fn-Z)
The time values range are: 1-60 seconds
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 242
1 file changed, 242 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 226e0b5..f97f942 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -112,7 +112,9 @@ MODULE_LICENSE("GPL");
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define HCI_KBD_ILLUMINATION 0x0095
#define SCI_ILLUMINATION 0x014e
+#define SCI_KBD_ILLUM_STATUS 0x015c
/* field definitions */
#define HCI_HOTKEY_DISABLE 0x0b
@@ -120,6 +122,7 @@ MODULE_LICENSE("GPL");
#define HCI_LCD_BRIGHTNESS_BITS3
#define HCI_LCD_BRIGHTNESS_SHIFT (16-HCI_LCD_BRIGHTNESS_BITS)
#define HCI_LCD_BRIGHTNESS_LEVELS (1 << HCI_LCD_BRIGHTNESS_BITS)
+#define HCI_MISC_SHIFT 0x10
#define HCI_VIDEO_OUT_LCD 0x1
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
@@ -127,6 +130,8 @@ MODULE_LICENSE("GPL");
#define HCI_WIRELESS_BT_PRESENT0x0f
#define HCI_WIRELESS_BT_ATTACH 0x40
#define HCI_WIRELESS_BT_POWER 0x80
+#define SCI_KBD_MODE_FNZ 0x1
+#define SCI_KBD_MODE_AUTO 0x2
struct toshiba_acpi_dev {
struct acpi_device *acpi_dev;
@@ -137,10 +142,13 @@ struct toshiba_acpi_dev {
struct work_struct hotkey_work;
struct backlight_device *backlight_dev;
struct led_classdev led_dev;
+ struct led_classdev kbd_led;
int force_fan;
int last_key_event;
int key_event_valid;
+ int kbd_mode;
+ int kbd_time;
unsigned int illumination_supported:1;
unsigned int video_supported:1;
@@ -149,6 +157,9 @@ struct toshiba_acpi_dev {
unsigned int ntfy_supported:1;
unsigned int info_supported:1;
unsigned int tr_backlight_supported:1;
+ unsigned int kbd_illum_supported:1;
+ unsigned int kbd_led_registered:1;
+ unsigned int sysfs_created:1;
struct mutex mutex;
};
@@ -444,6 +455,89 @@ static enum led_brightness toshiba_illumination_get(struct
led_classdev *cdev)
return state ? LED_FULL : LED_OFF;
}
+/* KBD Illumination */
+static int toshiba_kbd_illum_status_set(struct toshiba_acpi_dev *dev, u32 time)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_write(dev, SCI_KBD_ILLUM_STATUS, time, );
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to set KBD backlight status failed\n");
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info("Keyboard backlight status not supported\n");
+ return -ENODEV;
+ }
+ sci_close(dev);
+
+ return 0;
+}
+
+static int toshiba_kbd_illum_status_get(struct toshiba_acpi_dev *dev, u32
*time)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_read(dev, SCI_KBD_ILLUM_STATUS, time, );
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to get KBD backlight status failed\n");
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info("Keyboard backlight status not supported\n");
+ return -ENODEV;
+ }
+ sci_close(dev);
+
+ return 0;
+}
+
+static enum led_brightness toshiba_kbd_backlight_get(struct led_classdev *cdev)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, kbd_led);
+ u32 state, result;
+ acpi_status status;
+
+ /* Check the keyboard backlight state */
+ status = hci_read1(dev, HCI_KBD_ILLUMINATION, , );
+ if (ACPI_FAILURE(status) || result == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to get the keyboard backlight failed\n");
+ return LED_OFF;
+ } else if (result == NOT_SUPPORTED) {
+ pr_info("Keyboard backlight not supported\n");
+ return LED_OFF;
+ }
+
+ return state ? LED_FULL :
[PATCH 8/8] toshiba_acpi: Update version and copyright information
Add myself to the copyright list and bump version to 0.20 since several new features have been added. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 0e14e9c..22178f2 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -5,6 +5,7 @@ * Copyright (C) 2002-2004 John Belmonte * Copyright (C) 2008 Philip Langdale * Copyright (C) 2010 Pierre Ducroquet + * Copyright (C) 2013 Azael Avalos * * 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 @@ -37,7 +38,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt -#define TOSHIBA_ACPI_VERSION "0.19" +#define TOSHIBA_ACPI_VERSION "0.20" #define PROC_INTERFACE_VERSION 1 #include -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] toshiba_acpi: Add ECO led support
Newer Toshiba laptops now come with a feature called
ECO Mode, where the system is put in low power consupmtion
state and a green (world shaped with leaves) icon illuminates
indicating that the system is in such power state.
This patch adds support to turn on/off the ECO led by
creating and registering the toshiba::eco_mode led.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index f97f942..022c6e6 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -113,6 +113,7 @@ MODULE_LICENSE("GPL");
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
#define HCI_KBD_ILLUMINATION 0x0095
+#define HCI_ECO_MODE 0x0097
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
@@ -143,6 +144,7 @@ struct toshiba_acpi_dev {
struct backlight_device *backlight_dev;
struct led_classdev led_dev;
struct led_classdev kbd_led;
+ struct led_classdev eco_led;
int force_fan;
int last_key_event;
@@ -159,6 +161,7 @@ struct toshiba_acpi_dev {
unsigned int tr_backlight_supported:1;
unsigned int kbd_illum_supported:1;
unsigned int kbd_led_registered:1;
+ unsigned int eco_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -538,6 +541,57 @@ static void toshiba_kbd_backlight_set(struct led_classdev
*cdev,
}
}
+/* Eco Mode support */
+static int toshiba_eco_mode_available(struct toshiba_acpi_dev *dev)
+{
+ acpi_status status;
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_info("ACPI call to get ECO led failed\n");
+ return 0;
+ }
+
+ return 1;
+}
+
+static enum led_brightness toshiba_eco_mode_get_status(struct led_classdev
*cdev)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, eco_led);
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to get ECO led failed\n");
+ return LED_OFF;
+ }
+
+ return out[2] ? LED_FULL : LED_OFF;
+}
+
+static void toshiba_eco_mode_set_status(struct led_classdev *cdev,
+enum led_brightness brightness)
+{
+ struct toshiba_acpi_dev *dev = container_of(cdev,
+ struct toshiba_acpi_dev, eco_led);
+ u32 in[HCI_WORDS] = { HCI_SET, HCI_ECO_MODE, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Switch the Eco Mode led on/off */
+ in[2] = (brightness) ? 1 : 0;
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to set ECO led failed\n");
+ return;
+ }
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1413,6 +1467,9 @@ static int toshiba_acpi_remove(struct acpi_device
*acpi_dev)
if (dev->kbd_led_registered)
led_classdev_unregister(>kbd_led);
+ if (dev->eco_supported)
+ led_classdev_unregister(>eco_led);
+
if (dev->pf_dev)
platform_device_unregister(dev->pf_dev);
@@ -1515,6 +1572,15 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev->illumination_supported = 1;
}
+ if (toshiba_eco_mode_available(dev)) {
+ dev->eco_led.name = "toshiba::eco_mode";
+ dev->eco_led.max_brightness = 1;
+ dev->eco_led.brightness_set = toshiba_eco_mode_set_status;
+ dev->eco_led.brightness_get = toshiba_eco_mode_get_status;
+ if (!led_classdev_register(>pf_dev->dev, >eco_led))
+ dev->eco_supported = 1;
+ }
+
ret = toshiba_kbd_illum_status_get(dev, );
if (!ret) {
dev->kbd_time = dummy >> HCI_MISC_SHIFT;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] toshiba_acpi: Add touchpad enable/disable support
Toshiba laptops have two ways of enabling/disabling the
touchpad, one with a hardwired button on top of the touchpad
that simply emmits scancodes to let userspace know it has changed,
and another with a SCI call that triggers (on Windows drivers)
whenever the user press the Fn-F9 (touchpad toggle) hotkey.
This patch adds support to enable/disable the touchpad
by exposing the _touchpad_ file in sysfs.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 9c718eb..0e14e9c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -120,6 +120,7 @@ MODULE_LICENSE("GPL");
#define HCI_ACCELEROMETER2 0x00a6
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
+#define SCI_TOUCHPAD 0x050e
/* field definitions */
#define HCI_ACCEL_MASK 0x7fff
@@ -168,6 +169,7 @@ struct toshiba_acpi_dev {
unsigned int kbd_led_registered:1;
unsigned int eco_supported:1;
unsigned int accelerometer_supported:1;
+ unsigned int touchpad_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -643,6 +645,47 @@ static int toshiba_accelerometer_get(struct
toshiba_acpi_dev *dev,
return 0;
}
+/* TouchPad support */
+static int toshiba_touchpad_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_write(dev, SCI_TOUCHPAD, state, );
+ sci_close(dev);
+ if (ACPI_FAILURE(status)) {
+ pr_err("ACPI call to set the touchpad failed\n");
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_touchpad_get(struct toshiba_acpi_dev *dev, u32 *state)
+{
+ u32 result;
+ acpi_status status;
+
+ if (!sci_open(dev))
+ return -EIO;
+
+ status = sci_read(dev, SCI_TOUCHPAD, state, );
+ sci_close(dev);
+ if (ACPI_FAILURE(status)) {
+ pr_err("ACPI call to query the touchpad failed\n");
+ return -EIO;
+ } else if (result == NOT_SUPPORTED) {
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1267,16 +1310,49 @@ static ssize_t toshiba_position_show(struct device *dev,
return sprintf(buf, "%d %d %d\n", x, y, z);
}
+static ssize_t toshiba_touchpad_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ int state;
+
+ /* Set the TouchPad on/off, 0 - Disable | 1 - Enable */
+ if (sscanf(buf, "%i", ) == 1 && (state == 0 || state == 1)) {
+ if (toshiba_touchpad_set(toshiba, state) < 0)
+ return -EIO;
+ }
+
+ return count;
+}
+
+static ssize_t toshiba_touchpad_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 state;
+ int ret;
+
+ ret = toshiba_touchpad_get(toshiba, );
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "%i\n", state);
+}
+
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_backlight_timeout, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_timeout_show, toshiba_kbd_bl_timeout_store);
static DEVICE_ATTR(position, S_IRUGO, toshiba_position_show, NULL);
+static DEVICE_ATTR(touchpad, S_IRUGO | S_IWUSR,
+ toshiba_touchpad_show, toshiba_touchpad_store);
static struct attribute *toshiba_attributes[] = {
_attr_kbd_backlight_mode.attr,
_attr_kbd_backlight_timeout.attr,
_attr_position.attr,
+ _attr_touchpad.attr,
NULL,
};
@@ -1294,6 +1370,8 @@ static umode_t toshiba_sysfs_is_visible(struct kobject
*kobj,
exists = (driver->kbd_mode == SCI_KBD_MODE_AUTO) ? true : false;
else if (attr == _attr_position.attr)
exists = (driver->accelerometer_supported) ? true : false;
+ else if (attr == _attr_touchpad.attr)
+ exists = (driver->touchpad_supported) ? true : false;
return exists ? attr->mode : 0;
}
@@ -1679,6 +1757,9 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
ret = toshiba_accelerometer_supported(dev);
dev->accelerometer_supported = !ret;
[PATCH 6/8] toshiba_acpi: Add accelerometer support
Recent Toshiba laptops now come equiped with a built in
accelerometer (TOS620A), but such device does not
expose the axis information, however, HCI calls 0x006d
and 0x00a6 can be used to query such info.
This patch adds support to read the axis values and
exposing them through the _position_ sysfs file.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 022c6e6..9c718eb 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -103,6 +103,8 @@ MODULE_LICENSE("GPL");
#define INPUT_DATA_ERROR 0x8300
#define NOT_PRESENT0x8600
#define FIFO_EMPTY 0x8c00
+#define DATA_NOT_AVAILABLE 0x8d20
+#define NOT_INITIALIZED0x8d50
/* registers */
#define HCI_FAN0x0004
@@ -112,12 +114,15 @@ MODULE_LICENSE("GPL");
#define HCI_HOTKEY_EVENT 0x001e
#define HCI_LCD_BRIGHTNESS 0x002a
#define HCI_WIRELESS 0x0056
+#define HCI_ACCELEROMETER 0x006d
#define HCI_KBD_ILLUMINATION 0x0095
#define HCI_ECO_MODE 0x0097
+#define HCI_ACCELEROMETER2 0x00a6
#define SCI_ILLUMINATION 0x014e
#define SCI_KBD_ILLUM_STATUS 0x015c
/* field definitions */
+#define HCI_ACCEL_MASK 0x7fff
#define HCI_HOTKEY_DISABLE 0x0b
#define HCI_HOTKEY_ENABLE 0x09
#define HCI_LCD_BRIGHTNESS_BITS3
@@ -162,6 +167,7 @@ struct toshiba_acpi_dev {
unsigned int kbd_illum_supported:1;
unsigned int kbd_led_registered:1;
unsigned int eco_supported:1;
+ unsigned int accelerometer_supported:1;
unsigned int sysfs_created:1;
struct mutex mutex;
@@ -592,6 +598,51 @@ static void toshiba_eco_mode_set_status(struct
led_classdev *cdev,
}
}
+/* Accelerometer support */
+static int toshiba_accelerometer_supported(struct toshiba_acpi_dev *dev)
+{
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ACCELEROMETER2, 0, 0, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Check if the accelerometer call exists,
+* this call also serves as initialization
+*/
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to query the accelerometer failed\n");
+ return -EIO;
+ } else if (out[0] == DATA_NOT_AVAILABLE || out[0] == NOT_INITIALIZED) {
+ pr_err("Accelerometer not initialized\n");
+ return -EIO;
+ } else if (out[0] == NOT_SUPPORTED) {
+ pr_info("Accelerometer not supported\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int toshiba_accelerometer_get(struct toshiba_acpi_dev *dev,
+ u32 *xy, u32 *z)
+{
+ u32 in[HCI_WORDS] = { HCI_GET, HCI_ACCELEROMETER, 0, 1, 0, 0 };
+ u32 out[HCI_WORDS];
+ acpi_status status;
+
+ /* Check the Accelerometer status */
+ status = hci_raw(dev, in, out);
+ if (ACPI_FAILURE(status) || out[0] == INPUT_DATA_ERROR) {
+ pr_err("ACPI call to query the accelerometer failed\n");
+ return -EIO;
+ }
+
+ *xy = out[2];
+ *z = out[4];
+
+ return 0;
+}
+
/* Bluetooth rfkill handlers */
static u32 hci_get_bt_present(struct toshiba_acpi_dev *dev, bool *present)
@@ -1195,14 +1246,37 @@ static ssize_t toshiba_kbd_bl_timeout_show(struct
device *dev,
return sprintf(buf, "%i\n", time >> HCI_MISC_SHIFT);
}
+static ssize_t toshiba_position_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
+ u32 xyval, zval, tmp;
+ u16 x, y, z;
+ int ret;
+
+ xyval = zval = 0;
+ ret = toshiba_accelerometer_get(toshiba, , );
+ if (ret < 0)
+ return ret;
+
+ x = xyval & HCI_ACCEL_MASK;
+ tmp = xyval >> HCI_MISC_SHIFT;
+ y = tmp & HCI_ACCEL_MASK;
+ z = zval & HCI_ACCEL_MASK;
+
+ return sprintf(buf, "%d %d %d\n", x, y, z);
+}
+
static DEVICE_ATTR(kbd_backlight_mode, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_mode_show, toshiba_kbd_bl_mode_store);
static DEVICE_ATTR(kbd_backlight_timeout, S_IRUGO | S_IWUSR,
toshiba_kbd_bl_timeout_show, toshiba_kbd_bl_timeout_store);
+static DEVICE_ATTR(position, S_IRUGO, toshiba_position_show, NULL);
static struct attribute *toshiba_attributes[] = {
_attr_kbd_backlight_mode.attr,
_attr_kbd_backlight_timeout.attr,
+ _attr_position.attr,
NULL,
};
@@ -1218,6 +1292,8 @@
[PATCH 3/8] toshiba_acpi: Add platform support
Add platform support and change the backlight
and led devices to register on it instead of the acpi_device.
The use of the platform is to have just one place where to
look for files instead of looking at the current three different
ACPI devices (TOS6200, TOS6208 and TOS1900) and thus making
userspace a bit easier.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index d7ecef3..226e0b5 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
@@ -129,6 +130,7 @@ MODULE_LICENSE("GPL");
struct toshiba_acpi_dev {
struct acpi_device *acpi_dev;
+ struct platform_device *pf_dev;
const char *method_hci;
struct rfkill *bt_rfk;
struct input_dev *hotkey_dev;
@@ -1156,7 +1158,7 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
props.max_brightness++;
dev->backlight_dev = backlight_device_register("toshiba",
- >acpi_dev->dev,
+ >pf_dev->dev,
dev,
_backlight_data,
);
@@ -1198,6 +1200,9 @@ static int toshiba_acpi_remove(struct acpi_device
*acpi_dev)
if (dev->illumination_supported)
led_classdev_unregister(>led_dev);
+ if (dev->pf_dev)
+ platform_device_unregister(dev->pf_dev);
+
if (toshiba_acpi)
toshiba_acpi = NULL;
@@ -1249,6 +1254,15 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev->method_hci = hci_method;
acpi_dev->driver_data = dev;
+ dev->pf_dev = platform_device_register_simple("toshiba", -1, NULL, 0);
+ if (IS_ERR(dev->pf_dev)) {
+ ret = PTR_ERR(dev->pf_dev);
+ pr_err("Unable to register platform device\n");
+ kfree(dev);
+ return ret;
+ }
+ platform_set_drvdata(dev->pf_dev, dev);
+
if (toshiba_acpi_setup_keyboard(dev))
pr_info("Unable to activate hotkeys\n");
@@ -1284,7 +1298,7 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev->led_dev.max_brightness = 1;
dev->led_dev.brightness_set = toshiba_illumination_set;
dev->led_dev.brightness_get = toshiba_illumination_get;
- if (!led_classdev_register(_dev->dev, >led_dev))
+ if (!led_classdev_register(>pf_dev->dev, >led_dev))
dev->illumination_supported = 1;
}
@@ -1388,6 +1402,13 @@ static struct acpi_driver toshiba_acpi_driver = {
.drv.pm = _acpi_pm,
};
+static struct platform_driver platform_driver = {
+ .driver = {
+ .name = "toshiba",
+ .owner = THIS_MODULE,
+ },
+};
+
static int __init toshiba_acpi_init(void)
{
int ret;
@@ -1406,6 +1427,12 @@ static int __init toshiba_acpi_init(void)
return -ENODEV;
}
+ ret = platform_driver_register(_driver);
+ if (ret < 0) {
+ pr_err("Failed to register platform driver: %d\n", ret);
+ return ret;
+ }
+
ret = acpi_bus_register_driver(_acpi_driver);
if (ret) {
pr_err("Failed to register ACPI driver: %d\n", ret);
@@ -1418,6 +1445,7 @@ static int __init toshiba_acpi_init(void)
static void __exit toshiba_acpi_exit(void)
{
acpi_bus_unregister_driver(_acpi_driver);
+ platform_driver_unregister(_driver);
if (toshiba_proc_dir)
remove_proc_entry(PROC_TOSHIBA, acpi_root_dir);
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: samsung: memory leak bugfix in pwm_samsung_free
Hi Sangjung,
On 5 November 2013 08:32, Sangjung Woo wrote:
> There is certainly a kind of memory leak since allocated data (i.e.
> chip_data) is set NULL before freeing it by calling devm_kfree(). This
> patch fixes the memory leak bug by modifying its call order.
>
> Signed-off-by: Sangjung Woo
> Reviewed-by: Jonghwa Lee
> ---
> drivers/pwm/pwm-samsung.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index fcc8b9a..07b2d9d 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -224,8 +224,8 @@ static int pwm_samsung_request(struct pwm_chip *chip,
> struct pwm_device *pwm)
>
> static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> - pwm_set_chip_data(pwm, NULL);
> devm_kfree(chip->dev, pwm_get_chip_data(pwm));
> + pwm_set_chip_data(pwm, NULL);
> }
Similar patch has already been applied by Thierry.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the device-mapper tree
Hi Mike,
On Mon, 4 Nov 2013 22:20:54 -0500 Mike Snitzer wrote:
>
> On Mon, Nov 04 2013 at 9:51pm -0500,
> Stephen Rothwell wrote:
>
> > After merging the device-mapper tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block':
> > drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member
> > named 'bi_size'
> >(bio->bi_size == (cache->sectors_per_block << SECTOR_SHIFT));
> >^
> >
> > Caused by commit 1bd270d800ec ("dm cache: promotion optimisation for
> > writes") interacting with commit ed2d2f9a8265 ("block: Abstract out bvec
> > iterator") from the block tree.
> >
> > I applied this fix up patch and can carry it as necessary:
>
> Yes that is needed, as is this (which begs the question: how should I be
I will add that tomorrow.
> handling the fact that post-merge changes are needed? Especially since
> Linus will need the changes too):
Who ever gets their tree in last has to tell Linus about these extra
merge fix ups as part of their pull request.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpKBFAOR4fez.pgp
Description: PGP signature
Re: [Xen-devel] [PATCH] drivers: xen-selfballoon: consider slab pages
On 11/05/2013 01:22 AM, David Vrabel wrote: > On 04/11/13 12:39, Bob Liu wrote: >> Currently the goal_page in xen-selfballon doesn't consider much about pages >> used >> in kernel space. >> A typical usage is slab pages, without consider slab pages the goal_page >> result >> may be too rough and lead extra memory pressure to guest os. > > Can you provide some real world figures where the calculatation got it > wrong? What was the resultant behavior? Swap death? OOM killer? > Sorry, I didn't run any testing I just think it's unreasonable while reading the source code. vm_memory_committed() only calculate pages which mapped to process address space, but the kernel itself(like block, fs and network subsystem) may occupy some memory. And it's possible that those subsystem may occupy a significant amount of memory in some situation. I'm afraid if we don't consider those kernel memory while calculating goal_pages, guest memory will be set lower than guest really needs. >> Signed-off-by: Bob Liu >> --- >> drivers/xen/xen-selfballoon.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c >> index 21e18c1..4814759 100644 >> --- a/drivers/xen/xen-selfballoon.c >> +++ b/drivers/xen/xen-selfballoon.c >> @@ -191,6 +191,8 @@ static void selfballoon_process(struct work_struct *work) >> tgt_pages = cur_pages; /* default is no change */ >> goal_pages = vm_memory_committed() + >> totalreserve_pages + >> +global_page_state(NR_SLAB_RECLAIMABLE) + > > Does SLAB_RECLAIMABLE want to be included here? Unless I'm > misunderstanding here, SLAB_RECLAIMABLE is effectively free. > SLAB_RECLAIMABLE isn't effectively free, it means the slab page is in used but can be reclaimed(freed) during memory pressure. >> +global_page_state(NR_SLAB_UNRECLAIMABLE) + > > This bit looks fine to me. > >> MB2PAGES(selfballoon_reserved_mb); >> #ifdef CONFIG_FRONTSWAP >> /* allow space for frontswap pages to be repatriated */ > > David > Thanks for your review. -- Regards, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 warnings after merge of the modules tree
Stephen Rothwell writes:
> Hi Rusty,
>
> After merging the modules tree, today's linux-next build (x86_64
> allmodconfig) produced these warning:
>
> WARNING: vmlinux: 'pci_restore_msi_state' exported twice. Previous export was
> in vmlinux
> WARNING: vmlinux: '__mod_zone_page_state' exported twice. Previous export was
> in vmlinux
> WARNING: vmlinux: 'scsi_prep_return' exported twice. Previous export was in
> vmlinux
> WARNING: vmlinux: 'hvc_poll' exported twice. Previous export was in vmlinux
> WARNING: vmlinux: 'nfs_clear_inode' exported twice. Previous export was in
> vmlinux
>
> (just some samples ... it scrolled off my scrollback :-()
>
> Presumably caused by commit e0f244c63fc9 ("asmlinkage, module: Make
> ksymtab and kcrctab symbols and __this_module __visible"). (reverting
> that commit makes the warnings go away.)
This works for me feedback please!
Cheers,
Rusty.
modpost: fix bogus 'exported twice' warnings.
Andi's change in e0f244c63fc9 ("asmlinkage, module: Make ksymtab and
kcrctab symbols and __this_module __visible") make the crc appear
first in the symbol table.
modpost creates an entry when it sees the CRC, then when it sees the
actual symbol, it complains that it's seen it before. The preloaded
flag already exists for the equivalent case where we loaded from
Module.symvers, so use that.
Signed-off-by: Rusty Russell
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 9b873ac6ed7b..5c677a3e7487 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -164,7 +164,7 @@ struct symbol {
unsigned int vmlinux:1;/* 1 if symbol is defined in vmlinux */
unsigned int kernel:1; /* 1 if symbol is from kernel
* (only for external modules) **/
- unsigned int preloaded:1; /* 1 if symbol from Module.symvers */
+ unsigned int preloaded:1; /* 1 if symbol from Module.symvers, or crc */
enum export export; /* Type of export */
char name[0];
};
@@ -332,8 +332,11 @@ static void sym_update_crc(const char *name, struct module
*mod,
{
struct symbol *s = find_symbol(name);
- if (!s)
+ if (!s) {
s = new_symbol(name, mod, export);
+ /* Don't complain when we find it later. */
+ s->preloaded = 1;
+ }
s->crc = crc;
s->crc_valid = 1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the device-mapper tree
On Mon, Nov 04 2013 at 9:51pm -0500,
Stephen Rothwell wrote:
> Hi all,
>
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block':
> drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member named
> 'bi_size'
>(bio->bi_size == (cache->sectors_per_block << SECTOR_SHIFT));
>^
>
> Caused by commit 1bd270d800ec ("dm cache: promotion optimisation for
> writes") interacting with commit ed2d2f9a8265 ("block: Abstract out bvec
> iterator") from the block tree.
>
> I applied this fix up patch and can carry it as necessary:
Hi Stephen,
Yes that is needed, as is this (which begs the question: how should I be
handling the fact that post-merge changes are needed? Especially since
Linus will need the changes too):
drivers/md/dm-cache-target.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index a977d5c..52d7d75 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -85,6 +85,12 @@ static void dm_unhook_bio(struct dm_hook_info *h, struct bio
*bio)
{
bio->bi_end_io = h->bi_end_io;
bio->bi_private = h->bi_private;
+
+ /*
+* Must bump bi_remaining to allow bio to complete with
+* restored bi_end_io.
+*/
+ atomic_inc(>bi_remaining);
}
/**/
@@ -746,12 +752,6 @@ static void writethrough_endio(struct bio *bio, int err)
dm_unhook_bio(>hook_info, bio);
- /*
-* Must bump bi_remaining to allow bio to complete with
-* restored bi_end_io.
-*/
- atomic_inc(>bi_remaining);
-
if (err) {
bio_endio(bio, err);
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
(2013/11/05 11:00), Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:37 +
> Masami Hiramatsu wrote:
>
>> Prohibit probing on func_ptr_is_kernel_text().
>> Since the func_ptr_is_kernel_text() is called from
>> notifier_call_chain() which is called from int3 handler,
>> probing it may cause double int3 fault and kernel will
>> reboot.
>>
>> This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
>>
>> Signed-off-by: Masami Hiramatsu
>> Cc: Andrew Morton
>> Cc: "Uwe Kleine-König"
>> Cc: Borislav Petkov
>> Cc: Ingo Molnar
>> ---
>> kernel/extable.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/extable.c b/kernel/extable.c
>> index 832cb28..022fb25 100644
>> --- a/kernel/extable.c
>> +++ b/kernel/extable.c
>> @@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
>> * pointer is part of the kernel text, we need to do some
>> * special dereferencing first.
>> */
>> -int func_ptr_is_kernel_text(void *ptr)
>> +int nokprobe func_ptr_is_kernel_text(void *ptr)
>> {
>> unsigned long addr;
>> addr = (unsigned long) dereference_function_descriptor(ptr);
>>
>
> One thing I worry about the "nokprobe" annotation, is that it moves the
> location of the function out of local. This function no exists in
> the section with its users. Same with the debug functions in the
> other patch.
>
> Now these may be a slow path where we really don't care, but if the
> nokprobe expands this can cause issues.
>
> The "nokprobe" works differently than "notrace" as "notrace" is just an
> attribute that tells gcc not to add mcount to it. The "nokprobe"
> actually moves the function into a different section.
Well, in that case, I can put it in the opt-out type
blacklist(kprobe_blacklist). :)
Hmm, I think if I can list nokprobe functions up at build time, we can almost
remove the .kprobes.text (Note that some of entry functions in asm still
require it.)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cpufreq: cpufreq-cpu0: use the max voltage instead of voltage-tolerance
From: Rongjun Ying
Sometime the regulator can't supply appropriate voltages for requestion of cpu.
All voltage tolerance value can't figure out a good voltage.
Signed-off-by: Rongjun Ying
---
drivers/cpufreq/cpufreq-cpu0.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index c522a95..0c9e6b9 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -23,7 +23,7 @@
#include
static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
+static unsigned int voltage_max;
static struct device *cpu_dev;
static struct clk *cpu_clk;
@@ -45,7 +45,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
{
struct cpufreq_freqs freqs;
struct opp *opp;
- unsigned long volt = 0, volt_old = 0, tol = 0;
+ unsigned long volt = 0, volt_old = 0;
long freq_Hz, freq_exact;
unsigned int index;
int ret;
@@ -82,7 +82,6 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
}
volt = opp_get_voltage(opp);
rcu_read_unlock();
- tol = volt * voltage_tolerance / 100;
volt_old = regulator_get_voltage(cpu_reg);
}
@@ -92,7 +91,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (!IS_ERR(cpu_reg) && freqs.new > freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err("failed to scale voltage up: %d\n", ret);
freqs.new = freqs.old;
@@ -104,14 +103,14 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
if (ret) {
pr_err("failed to set clock rate: %d\n", ret);
if (!IS_ERR(cpu_reg))
- regulator_set_voltage_tol(cpu_reg, volt_old, tol);
+ regulator_set_voltage(cpu_reg, volt_old, voltage_max);
freqs.new = freqs.old;
goto post_notify;
}
/* scaling down? scale voltage after frequency */
if (!IS_ERR(cpu_reg) && freqs.new < freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ ret = regulator_set_voltage(cpu_reg, volt, voltage_max);
if (ret) {
pr_err("failed to scale voltage down: %d\n", ret);
clk_set_rate(cpu_clk, freqs.old * 1000);
@@ -224,7 +223,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_put_node;
}
- of_property_read_u32(np, "voltage-tolerance", _tolerance);
+ ret = of_property_read_u32(np, "voltage-max", _max);
+ if (ret) {
+ pr_err("failed to get max voltage: %d\n", ret);
+ goto out_put_node;
+ }
if (of_property_read_u32(np, "clock-latency", _latency))
transition_latency = CPUFREQ_ETERNAL;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Mon, Nov 04, 2013 at 05:44:00PM -0800, Tim Chen wrote: > On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote: > > On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote: > > > On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote: > > > > On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote: > > > > > > > > > > * Yuanhan Liu wrote: > > > > > > > > > > > > Btw., another _really_ interesting comparison would be against > > > > > > > the latest rwsem patches. Mind doing such a comparison? > > > > > > > > > > > > Sure. Where can I get it? Are they on some git tree? > > > > > > > > > > I've Cc:-ed Tim Chen who might be able to point you to the latest > > > > > version. > > > > > > > > > > The last on-lkml submission was in this thread: > > > > > > > > > > Subject: [PATCH v8 0/9] rwsem performance optimizations > > > > > > > > > > > > > Thanks. > > > > > > > > I queued bunchs of tests about one hour ago, and already got some > > > > results(If necessary, I can add more data tomorrow when those tests are > > > > finished): > > > > > > What kind of system are you using to run these workloads on? > > > > I queued jobs on 5 testboxes: > > - brickland1: 120 core Ivybridge server > > - lkp-ib03: 48 core Ivybridge server > > - lkp-sb03: 32 core Sandybridge server > > - lkp-nex04: 64 core NHM server > > - lkp-a04:Atom server > > > > > > > > > > > > > > >v3.12-rc7 fe001e3de090e179f95d > > > > > > > > -9.3% > > > > brickland1/micro/aim7/shared > > > > +4.3% > > > > lkp-ib03/micro/aim7/fork_test > > > > +2.2% > > > > lkp-ib03/micro/aim7/shared > > > > -2.6% TOTAL > > > > aim7.2000.jobs-per-min > > > > > > > > > > Sorry if I'm missing something, but could you elaborate more on what > > > these percentages represent? > > > >v3.12-rc7 fe001e3de090e179f95d > > > > -9.3% > > brickland1/micro/aim7/shared > > > > > > -2.6% TOTAL > > aim7.2000.jobs-per-min > > > > The comparation base is v3.12-rc7, and we got 9.3 performance regression > > at commit fe001e3de090e179f95d, which is the head of rwsem performance > > optimizations patch set. > > Yunahan, thanks for the data. This I assume is with the entire rwsem > v8 patchset. Yes, it is; 9 patches in total. > Any idea of the run variation on the workload? Your concern is right. The variation is quite big on the brickland1/micro/aim7/shared testcase. * - v3.12-rc7 O - fe001e3de090e179f95d brickland1/micro/aim7/shared: aim7.2000.jobs-per-min 32 +++ | | 31 ++ .*. | | ...| 30 ++ ... | |... .. | 29 ++ ...| | * 28 ++... | | | 27 ++| *.O 26 O+| |O| 25 +++ --yliu > > > > "brickland1/micro/aim7/shared" tells the testbox(brickland1) and testcase: > > shared workfile of aim7. > > > > The last line tell what field we are comparing, and it's > > "aim7.2000.jobs-per-min" in this case. 2000 means 2000 users in aim7. > > > > > Are they anon vma rwsem + optimistic > > > spinning patches vs anon vma rwlock? > > > > I tested "[PATCH v8 0/9] rwsem performance optimizations" only. > > > > > > > > Also, I see your running aim7, you might be interested in some of the > > > results I found when trying out Ingo's rwlock conversion patch on a > > > largish 80 core system: https://lkml.org/lkml/2013/9/29/280 > > > > Besides aim7, I also tested dbench, hackbench, netperf, pigz. And as you > > can image and see from the data, aim7 benifit most from the anon_vma > > optimization stuff due to high contention of anon_vma lock. > >
[PATCH] pwm: samsung: memory leak bugfix in pwm_samsung_free
There is certainly a kind of memory leak since allocated data (i.e.
chip_data) is set NULL before freeing it by calling devm_kfree(). This
patch fixes the memory leak bug by modifying its call order.
Signed-off-by: Sangjung Woo
Reviewed-by: Jonghwa Lee
---
drivers/pwm/pwm-samsung.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index fcc8b9a..07b2d9d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -224,8 +224,8 @@ static int pwm_samsung_request(struct pwm_chip *chip,
struct pwm_device *pwm)
static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- pwm_set_chip_data(pwm, NULL);
devm_kfree(chip->dev, pwm_get_chip_data(pwm));
+ pwm_set_chip_data(pwm, NULL);
}
static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
--
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: converting unicore32 to gate_vma as done for arm (was Re: [PATCH] mm: cache largest vma)
The patch is ok for unicore32. Thanks Al.
While testing this patch, a bug is found in
arch/unicore32/include/asm/pgtable.h:
@@ -96,7 +96,7 @@ extern pgprot_t pgprot_kernel;
| PTE_EXEC)
#define PAGE_READONLY __pgprot(pgprot_val(pgprot_user | PTE_READ)
#define PAGE_READONLY_EXEC __pgprot(pgprot_val(pgprot_user | PTE_READ \
- | PTE_EXEC)
+ | PTE_EXEC))
In fact, all similar macros are wrong. I'll post an bug-fix patch for this
obvious error.
Xuetao
- Al Viro 写道：
> On Sun, Nov 03, 2013 at 08:20:10PM -0800, Davidlohr Bueso wrote:
> > > > diff --git a/arch/unicore32/include/asm/mmu_context.h
> > > > b/arch/unicore32/include/asm/mmu_context.h
> > > > index fb5e4c6..38cc7fc 100644
> > > > --- a/arch/unicore32/include/asm/mmu_context.h
> > > > +++ b/arch/unicore32/include/asm/mmu_context.h
> > > > @@ -73,7 +73,7 @@ do { \
> > > > else \
> > > > mm->mmap = NULL; \
> > > > rb_erase(_vma->vm_rb, >mm_rb); \
> > > > - mm->mmap_cache = NULL; \
> > > > + vma_clear_caches(mm); \
> > > > mm->map_count--; \
> > > > remove_vma(high_vma); \
> > > > } \
>
> BTW, this one needs an analog of
> commit f9d4861fc32b995b1616775614459b8f266c803c
> Author: Will Deacon
> Date: Fri Jan 20 12:01:13 2012 +0100
>
> ARM: 7294/1: vectors: use gate_vma for vectors user mapping
>
> This code is a copy of older arm logics rewritten in that commit; unicore32
> never got its counterpart. I have a [completely untested] variant sitting
> in vfs.git#vm^; it's probably worth testing - if it works, we'll get rid
> of one more place that needs to be aware of MM guts and unicore32 folks
> will have fewer potential headache sources...
>
> FWIW, after porting to the current tree it becomes the following; I'm not
> sure whether we want VM_DONTEXPAND | VM_DONTDUMP set for this one, though...
>
> Signed-off-by: Al Viro
> ---
> diff --git a/arch/unicore32/include/asm/elf.h
> b/arch/unicore32/include/asm/elf.h
> index 829042d..eeba258 100644
> --- a/arch/unicore32/include/asm/elf.h
> +++ b/arch/unicore32/include/asm/elf.h
> @@ -87,8 +87,4 @@ struct mm_struct;
> extern unsigned long arch_randomize_brk(struct mm_struct *mm);
> #define arch_randomize_brk arch_randomize_brk
>
> -extern int vectors_user_mapping(void);
> -#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
> -#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
> -
> #endif
> diff --git a/arch/unicore32/include/asm/mmu_context.h
> b/arch/unicore32/include/asm/mmu_context.h
> index fb5e4c6..600b1b8 100644
> --- a/arch/unicore32/include/asm/mmu_context.h
> +++ b/arch/unicore32/include/asm/mmu_context.h
> @@ -18,6 +18,7 @@
>
> #include
> #include
> +#include
>
> #define init_new_context(tsk, mm)0
>
> @@ -56,32 +57,4 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
> #define deactivate_mm(tsk, mm) do { } while (0)
> #define activate_mm(prev, next) switch_mm(prev, next, NULL)
>
> -/*
> - * We are inserting a "fake" vma for the user-accessible vector page so
> - * gdb and friends can get to it through ptrace and /proc//mem.
> - * But we also want to remove it before the generic code gets to see it
> - * during process exit or the unmapping of it would cause total havoc.
> - * (the macro is used as remove_vma() is static to mm/mmap.c)
> - */
> -#define arch_exit_mmap(mm) \
> -do { \
> - struct vm_area_struct *high_vma = find_vma(mm, 0x); \
> - if (high_vma) { \
> - BUG_ON(high_vma->vm_next); /* it should be last */ \
> - if (high_vma->vm_prev) \
> - high_vma->vm_prev->vm_next = NULL; \
> - else \
> - mm->mmap = NULL; \
> - rb_erase(_vma->vm_rb, >mm_rb); \
> - mm->mmap_cache = NULL; \
> - mm->map_count--; \
> - remove_vma(high_vma); \
> - } \
> -} while (0)
> -
> -static inline void arch_dup_mmap(struct mm_struct *oldmm,
> - struct mm_struct *mm)
> -{
> -}
> -
> #endif
> diff --git a/arch/unicore32/include/asm/page.h
> b/arch/unicore32/include/asm/page.h
> index 594b322..e79da8b 100644
> --- a/arch/unicore32/include/asm/page.h
> +++ b/arch/unicore32/include/asm/page.h
> @@ -28,6 +28,8 @@ extern void copy_page(void *to, const void *from);
> #define clear_user_page(page, vaddr, pg) clear_page(page)
> #define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
>
> +#define __HAVE_ARCH_GATE_AREA 1
> +
> #undef STRICT_MM_TYPECHECKS
>
> #ifdef STRICT_MM_TYPECHECKS
> diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
> index 778ebba..51d129e 100644
> ---
Re: [PATCH] [RFC] vfs: don't revalidate dentries that serve as mountpoints
For a similar issue in cifs vfs (samba bugzilla 8950), I was going to try
unset the bit DCACHE_OP_REVALIDATE of d_flags of the
dentry. Would something like work for the mountpoint dentry?
On Mon, Nov 4, 2013 at 7:16 PM, Jeff Layton wrote:
> We had a couple of reports of people that are mounting NFS filesystems,
> and then bind mounting certain local files onto dentries in that nfs
> mount (sort of like a poor-man's unionmount).
>
> This all works well until the dentry serving as the mountpoint fails
> d_revalidate. The dentry will end up being invalidated which makes the
> bind mount unreachable via pathwalk.
>
> It doesn't make much sense to me to allow dentries to serve as
> mountpoints to end up invalidated, so there's no real point in
> attempting to d_revalidate them at all.
>
> Reported-by: Patrick McLean
> Reported-by: Guang Cheng Li
> Signed-off-by: Jeff Layton
> ---
> fs/namei.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index caa2805..5b10ad0 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -585,6 +585,9 @@ drop_root_mnt:
>
> static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
> {
> + /* dentries that serve as mountpoints are always considered valid */
> + if (d_mountpoint(dentry))
> + return 1;
> return dentry->d_op->d_revalidate(dentry, flags);
> }
>
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
> On 11/04, Oleg Nesterov wrote:
>>
>> On 11/04, Oleg Nesterov wrote:
>> >
>> > On 11/04, Oleg Nesterov wrote:
>> > >
>> > > But in any case, I strongly believe that it doesn't make any sense to
>> > > rely on tu->inode in get_user_vaddr().
>> >
>> > Hmm. But I forgot about the case when you probe the function in libc
>> > and want to dump the variable in libc...
>> >
>> > So probably I was wrong and this all needs more thinking. Damn.
>> > Perhaps we really need to pass @file/offset, but it is not clear what
>> > we can do with bss/anon-mapping.
>>
>> Or. Not that I really like this, but just for discussion...
>>
>> How about
>>
>> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
>> addr)
>> {
>> return (void __force __user *)addr + instruction_pointer(regs);
>> }
>>
>> ?
>>
>> This should solve the problems with relocations/randomization/bss.
>>
>> The obvious disadvantage is that it is not easy to calculate the
>> offset we need to pass as an argument, it depends on the probed
>> function.
>
> forgot to mention... and instruction_pointer() can't work in ret-probe,
> we need to pass the "unsigned long func" arg somehow...
Hmm.. what's the value of tu->offset in this case? Does it have the
offset of the return address or the start of the function?
Anyway, what we really need is the base address of the text mapping
IMHO.
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/
linux-next: build failure after merge of the device-mapper tree
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-cache-target.c: In function 'bio_writes_complete_block':
drivers/md/dm-cache-target.c:1020:7: error: 'struct bio' has no member named
'bi_size'
(bio->bi_size == (cache->sectors_per_block << SECTOR_SHIFT));
^
Caused by commit 1bd270d800ec ("dm cache: promotion optimisation for
writes") interacting with commit ed2d2f9a8265 ("block: Abstract out bvec
iterator") from the block tree.
I applied this fix up patch and can carry it as necessary:
From: Stephen Rothwell
Date: Tue, 5 Nov 2013 13:49:25 +1100
Subject: [PATCH] dm_cache: fix up for bvec iterator abstraction
Signed-off-by: Stephen Rothwell
---
drivers/md/dm-cache-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index a977d5c6d544..5ce0f5ec6d74 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -1017,7 +1017,7 @@ static void issue_overwrite(struct dm_cache_migration
*mg, struct bio *bio)
static bool bio_writes_complete_block(struct cache *cache, struct bio *bio)
{
return (bio_data_dir(bio) == WRITE) &&
- (bio->bi_size == (cache->sectors_per_block << SECTOR_SHIFT));
+ (bio->bi_iter.bi_size == (cache->sectors_per_block <<
SECTOR_SHIFT));
}
static void avoid_copy(struct dm_cache_migration *mg)
--
1.8.4.rc3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpv9OhCKl6a4.pgp
Description: PGP signature
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 19:47:41 +0100, Oleg Nesterov wrote:
> On 11/04, Oleg Nesterov wrote:
>>
>> On 11/04, Oleg Nesterov wrote:
>> >
>> > But in any case, I strongly believe that it doesn't make any sense to
>> > rely on tu->inode in get_user_vaddr().
>>
>> Hmm. But I forgot about the case when you probe the function in libc
>> and want to dump the variable in libc...
>>
>> So probably I was wrong and this all needs more thinking. Damn.
>> Perhaps we really need to pass @file/offset, but it is not clear what
>> we can do with bss/anon-mapping.
>
> Or. Not that I really like this, but just for discussion...
>
> How about
>
> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> addr)
> {
> return (void __force __user *)addr + instruction_pointer(regs);
> }
>
> ?
>
> This should solve the problems with relocations/randomization/bss.
Right. I think this approach is more reliable than playing with vma.
>
> The obvious disadvantage is that it is not easy to calculate the
> offset we need to pass as an argument, it depends on the probed
> function.
Well, maybe it's not that hard if we use symbol address in elf image
rather than file offset for the data.
IOW we can get the base mapping address by subtracting tu->offset from
instruction pointer. And then adding symbol address of the data should
give us the final virtual address, yay!
I'll try to play with it after lunch.
>
> And this still doesn't allow to, say, probe the executable but read
> the data from libc. Unless, again, we attach to the running process
> or randomize_va_space = 0, so we can know it in advance. But otherwise
> I do not think there is any solution.
Yes, cross-fetching is hard, let's go lunch. :)
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 2/2] libata: avoid waking disk to check power
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:39 PM, Aaron Lu wrote: > If the disk entered sleep mode due to runtime PM, then udisks can > easily tell by checking the device's runtime status and not send > out the query. > > But if the disk entered sleep mode due to other reason, the patch > may be necessary. So what's your scenario? I am planning on patching udisks to do that as well, but if you have a current udsisk or manually run hdparm -C, or some other program is doing something similar, then this patch takes care of that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFvFAAoJEJrBOlT6nu75hcYH/0YsYcs3u9Dmuqq9z5kFXL3k C4xYQtvOxw2z+B/vEFzdym5J3ZfVyT4+ZdcHMvRgbbPH+R8/rzNC+F3OjdGtDIRA 5EUo0BUT2IfY0Yp2SzP44+8aRC4iF5jLLcH9XJKQx7WHedJQ7puCgJXXHAgUhpwW 52gJ0UEHnjlBgjwxY9RKqppnJs57x2VwgwR2BeFns6Hcry0S0HN0U4gwROmb1GZR kjpOUUYHb3MH/gfzCaY97t0duAAp7jzZeOIuu+XHfkyV3APwsnbasLOOoRYtpbvQ M++xmYQdNAh2DcZLEmAo6H6HLB/Z5d9K0+SKUFnsKHFaUCH0GPHm8SZ7E/NN7ig= =7c7v -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] libata: use sleep instead of standby command
On 11/05/2013 10:39 AM, Phillip Susi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 11/04/2013 09:23 PM, Aaron Lu wrote: >> I suppose this is mainly for runtime PM? Since for system >> suspend/hibernation, the disk and its controller will be powered >> off anyway. > > Yes, or the second patch also helps when one manually issues hdparm > - -Y, which otherwise will cause the drive to be woken up to answer the > CHECK POWER command, which udisks issues to decide if it should skip > polling the SMART status of the drive. OK, I see. I wish udidks can do both of these(polling smart status and put the disk into sleep mode), so that it knows when the disk is in sleep mode and it will not send out the needless poll... -Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vfs: don't revalidate dentries that serve as mountpoints
On Mon, 4 Nov 2013 20:16:26 -0500 Jeff Layton wrote:
> We had a couple of reports of people that are mounting NFS filesystems,
> and then bind mounting certain local files onto dentries in that nfs
> mount (sort of like a poor-man's unionmount).
>
> This all works well until the dentry serving as the mountpoint fails
> d_revalidate. The dentry will end up being invalidated which makes the
> bind mount unreachable via pathwalk.
>
> It doesn't make much sense to me to allow dentries to serve as
> mountpoints to end up invalidated, so there's no real point in
> attempting to d_revalidate them at all.
>
> Reported-by: Patrick McLean
> Reported-by: Guang Cheng Li
> Signed-off-by: Jeff Layton
> ---
> fs/namei.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index caa2805..5b10ad0 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -585,6 +585,9 @@ drop_root_mnt:
>
> static inline int d_revalidate(struct dentry *dentry, unsigned int flags)
> {
> + /* dentries that serve as mountpoints are always considered valid */
> + if (d_mountpoint(dentry))
> + return 1;
> return dentry->d_op->d_revalidate(dentry, flags);
> }
>
Makes sense to me. But what about the parent or grandparent of the mountpoint?
Presumably we don't want to invalidate them either, and I don't think
d_mountpoint() returns true for those, does it?
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 1/2] libata: use sleep instead of standby command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:23 PM, Aaron Lu wrote: > I suppose this is mainly for runtime PM? Since for system > suspend/hibernation, the disk and its controller will be powered > off anyway. Yes, or the second patch also helps when one manually issues hdparm - -Y, which otherwise will cause the drive to be woken up to answer the CHECK POWER command, which udisks issues to decide if it should skip polling the SMART status of the drive. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFpOAAoJEJrBOlT6nu75JdwIALFvwncNyf1ENxnIho2Y3CXC N6BpHQ7CzD1tap/5ybSFPBvUvJfyC/UPAY69bjldOtbwnArDIWRFqEWW7JWm6G0z J1C5MMCIRHSuRo4RbN/rnsPQFsaFJy0Z5kJ0uXX+aOrZwEov5vo2MEuj/DEdCBDC SKpYkogDlSHTNhFsaEF5iJiJlLU9FF5pEM6S6P0/+Z+SrZ5PVCDOm9rK+oeqrn0U TBX5tKPxWRSjJ/2F094DYia5l8ODNgzl1gPDXA50a+A4M0CZi3d5Liz5Ctfnv88A ac5cG8Ae8MDss0kJmSMCuRwkKVIROM3qMxf1wDWjBwm3eCTAJV1gxRYSN0adOvc= =Rfny -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 10:22 AM, Chen Gang wrote:
> On 11/05/2013 05:54 AM, Joe Perches wrote:
>> Add this to "try this"...
>>
>> Chen Gang's defect is because his git repository branch
>> had a commit he authored but where did not add his signature.
>>
Hmm... in fact, when I make a patch, I really let "git log" contents a
commit I author but where do not add my signature.
But after I let it pure next-20131101 ("git reset HEAD^; git stash"), it
still cause this issue.
>
> Hmm... for pure next-20131101 tree in my git directory and the demo
> patches in attachment, it will cause this issue.
>
> And excuse me, I am not quite familiar with git, could you provide more
> details (e.g. where the special difference of the demo patches or the
> pure next-20131101 tree in my git directory)? thanks.
>
>> Also, there's a defect in function vcs_find_signers.
>> It should only return the commit count and array references.
>>
>> If there are no signers in the commit history interval specified,
>> then the "authors" array is added to the "signers" array and
>> returned as a single array.
>>
>> Use references instead.
>>
>> Make sure that references are defined in the places
>> that vcs_find_signers is called.
>>
>
> After apply the patch below, it can work well.
>
> Tested-by Chen Gang
>
>
>
>> Signed-off-by: Joe Perches
>> ---
>> scripts/get_maintainer.pl | 21 +++--
>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
>> index ee9adb8..9c3986f 100755
>> --- a/scripts/get_maintainer.pl
>> +++ b/scripts/get_maintainer.pl
>> @@ -128,7 +128,7 @@ my %VCS_cmds_git = (
>> "blame_commit_pattern" => "^([0-9a-f]+) ",
>> "author_pattern" => "^GitAuthor: (.*)",
>> "subject_pattern" => "^GitSubject: (.*)",
>> -"stat_pattern" => "(\\d+)\\t(\\d+)\\t\$file",
>> +"stat_pattern" => "^(\\d+)\\t(\\d+)\\t\$file\$",
>> );
>>
>> my %VCS_cmds_hg = (
>> @@ -156,7 +156,7 @@ my %VCS_cmds_hg = (
>> "blame_commit_pattern" => "^([ 0-9a-f]+):",
>> "author_pattern" => "^HgAuthor: (.*)",
>> "subject_pattern" => "^HgSubject: (.*)",
>> -"stat_pattern" => "(\\d+)\t(\\d+)\t\$file",
>> +"stat_pattern" => "^(\\d+)\t(\\d+)\t\$file\$",
>> );
>>
>> my $conf = which_conf(".get_maintainer.conf");
>> @@ -1297,7 +1297,7 @@ sub vcs_find_signers {
>>
>> #print("stats: <@stats>\n");
>>
>> -return (0, @signatures, @authors) if !@signatures;
>> +return (0, \@signatures, \@authors, \@stats) if !@signatures;
>>
>> save_commits_by_author(@lines) if ($interactive);
>> save_commits_by_signer(@lines) if ($interactive);
>> @@ -1880,9 +1880,10 @@ sub vcs_file_signoffs {
>> $cmd =~ s/(\$\w+)/$1/eeg; # interpolate $cmd
>>
>> ($commits, $signers_ref, $authors_ref, $stats_ref) =
>> vcs_find_signers($cmd, $file);
>> -@signers = @{$signers_ref};
>> -@authors = @{$authors_ref};
>> -@stats = @{$stats_ref};
>> +
>> +@signers = @{$signers_ref} if defined $signers_ref;
>> +@authors = @{$authors_ref} if defined $authors_ref;
>> +@stats = @{$stats_ref} if defined $stats_ref;
>>
>> #print("commits: <$commits>\nsigners:<@signers>\nauthors:
>> <@authors>\nstats: <@stats>\n");
>>
>> @@ -1965,8 +1966,8 @@ sub vcs_file_blame {
>> $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
>>
>> ($commit_count, $commit_signers_ref, $commit_authors_ref,
>> $stats_ref) = vcs_find_signers($cmd, $file);
>> -@commit_authors = @{$commit_authors_ref};
>> -@commit_signers = @{$commit_signers_ref};
>> +@commit_authors = @{$commit_authors_ref} if defined
>> $commit_authors_ref;
>> +@commit_signers = @{$commit_signers_ref} if defined
>> $commit_signers_ref;
>>
>> push(@signers, @commit_signers);
>> } else {
>> @@ -1983,8 +1984,8 @@ sub vcs_file_blame {
>> $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
>>
>> ($commit_count, $commit_signers_ref, $commit_authors_ref,
>> $stats_ref) = vcs_find_signers($cmd, $file);
>> -@commit_authors = @{$commit_authors_ref};
>> -@commit_signers = @{$commit_signers_ref};
>> +@commit_authors = @{$commit_authors_ref} if defined
>> $commit_authors_ref;
>> +@commit_signers = @{$commit_signers_ref} if defined
>> $commit_signers_ref;
>>
>> push(@signers, @commit_signers);
>> }
>>
>>
>>
>>
>
>
--
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/
Re: [PATCH 2/2] libata: avoid waking disk to check power
+linux-ide
On 11/05/2013 08:53 AM, Phillip Susi wrote:
> When a disk is in SLEEP mode it can not respond to commands,
> including the CHECK POWER command. Instead of waking up the
> sleeping disk, fake the reply to the CHECK POWER command to
> indicate the disk is in standby mode. This prevents udisks
> from waking up sleeping disks when it polls to see if they
> are awake or not before trying to read their smart status.
If the disk entered sleep mode due to runtime PM, then udisks can easily
tell by checking the device's runtime status and not send out the query.
But if the disk entered sleep mode due to other reason, the patch may be
necessary. So what's your scenario?
Best regards,
Aaron
>
> Signed-off-by: Phillip Susi
> ---
> drivers/ata/libata-core.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 83b1a9f..573d151 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -5084,6 +5084,13 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
>
> /* if device is sleeping, schedule reset and abort the link */
> if (unlikely(qc->dev->flags & ATA_DFLAG_SLEEPING)) {
> + if (unlikely(qc->tf.command == ATA_CMD_CHK_POWER))
> + {
> + /* fake reply to avoid waking drive */
> + qc->result_tf.nsect = 0;
> + ata_qc_complete(qc);
> + return;
> + }
> link->eh_info.action |= ATA_EH_RESET;
> ata_ehi_push_desc(>eh_info, "waking up from sleep");
> ata_link_abort(link);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][ext2] XIP does not work on ext2
Hi Jan,
On Mon, Nov 4, 2013 at 4:37 PM, Jan Kara wrote:
> Hello,
>
> On Mon 04-11-13 14:31:34, Andiry Xu wrote:
>> When I'm trying XIP on ext2, I find that xip does not work on ext2
>> with latest kernel.
>>
>> Reproduce steps:
>> Compile kernel with following configs:
>> CONFIG_BLK_DEV_XIP=y
>> CONFIG_EXT2_FS_XIP=y
>>
>> And run following commands:
>> # mke2fs -b 4096 /dev/ram0
>> # mount -t ext2 -o xip /dev/ram0 /mnt/ramdisk/
>> # dd if=/dev/zero of=/mnt/ramdisk/test1 bs=1M count=16
>>
>> And it shows:
>> dd: writing `/mnt/ramdisk/test1': No space left on device
>>
>> df also shows /mnt/ramdisk is 100% full. Its default size is 64MB so a
>> 16MB write should only occupy 1/4 capacity.
>>
>> Criminal commit:
>> After git bisect, it points to the following commit:
>> 8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b
>> Ext2: mark inode dirty after the function dquot_free_block_nodirty is called
> Thanks for report and the bisection!
>
>> Particularly, the following code:
>> @@ -1412,9 +1415,11 @@ allocated:
>> *errp = 0;
>> brelse(bitmap_bh);
>> -dquot_free_block_nodirty(inode, *count-num);
>> -mark_inode_dirty(inode);
>> -*count = num;
>> +if (num < *count) {
>> +dquot_free_block_nodirty(inode, *count-num);
>> +mark_inode_dirty(inode);
>> +*count = num;
>> +}
>> return ret_block;
>>
>> Not mark_inode_dirty() is called only when num is less than *count.
>> However, I've seen
>> with the dd command, there is case where num >= *count.
>>
>> Fix:
>> I've verified that the following patch fixes the issue:
>> diff --git a/fs/ext2/balloc.c b/fs/ext2/balloc.c
>> index 9f9992b..5446a52 100644
>> --- a/fs/ext2/balloc.c
>> +++ b/fs/ext2/balloc.c
>> @@ -1406,11 +1406,10 @@ allocated:
>>
>> *errp = 0;
>> brelse(bitmap_bh);
>> - if (num < *count) {
>> + if (num <= *count)
>> dquot_free_block_nodirty(inode, *count-num);
>> - mark_inode_dirty(inode);
>> - *count = num;
>> - }
>> + mark_inode_dirty(inode);
>> + *count = num;
>> return ret_block;
>>
>> io_error:
>>
>> However, I'm not familiar with ext2 source code and cannot tell if
>> this is the correct fix. At least it fixes my issue.
> With this, you have essentially reverted a hunk from commit
> 8e3dffc651cb668e1ff4d8b89cc1c3dde7540d3b. But I don't see a reason why it
> should be reverted. num should never ever be greater than *count and when
> num == count, we the code inside if doesn't do anything useful.
>
> I've looked into the code and I think I see the problem. It is a long
> standing bug in __ext2_get_block() in fs/ext2/xip.c. It calls
> ext2_get_block() asking for 0 blocks to map (while we really want 1 block).
> ext2_get_block() just passes that request and ext2_get_blocks() actually
> allocates 1 block. And that's were the commit you have identified makes a
> difference because previously we returned that 1 block was allocated while
> now we return that 0 blocks were allocated and thus allocation is repeated
> until all free blocks are exhaused.
>
> Attached patch should fix the problem.
>
Thanks for the reply. I've verified that your patch fixes my issue.
And it's absolutely better than my solution.
Tested-by: Andiry Xu
I have another question about ext2 XIP performance, although it's not
quite related to this thread.
I'm testing xip with ext2 on a ram disk drive, the driver is brd.c.
The RAM disk size is 2GB and I pre-fill it to guarantee that all pages
reside in main memory.
Then I use two different applications to write to the ram disk. One is
open() with O_DIRECT flag, and writing with Posix write(). Another is
open() with O_DIRECT, mmap() it to user space, then use memcpy() to
write data. I use different request size to write data, from 512 bytes
to 64MB.
In my understanding, the mmap version bypasses the file system and
does not go to kernel space, hence it should have better performance
than the Posix-write version. However, my test result shows it's not
always true: when the request size is between 8KB and 1MB, the
Posix-write() version has bandwidth about 7GB/s and mmap version only
has 5GB/s. The test is performed on a i7-3770K machine with 8GB
memory, kernel 3.12. Also I have tested on kernel 3.2, in which mmap
has really bad performance, only 2GB/s for all request sizes.
Do you know the reason why write() outperforms mmap() in some cases? I
know it's not related the thread but I really appreciate if you can
answer my question.
Thanks,
Andiry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
Hi Vinod Koul and Dan Williams,
Ping?
On 10/17/2013 01:56 PM, Hongbo Zhang wrote:
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver
works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
-tristate "Freescale Elo and Elo Plus DMA support"
+tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA
controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and
the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx
parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3
is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
-chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct
platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+{ .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
-pr_info("Freescale Elo / Elo Plus DMA driver\n");
+pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs;/* DGSR register base */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] get_maintainer: Improve "Author:" rolestats
On 11/05/2013 05:54 AM, Joe Perches wrote:
> Add this to "try this"...
>
> Chen Gang's defect is because his git repository branch
> had a commit he authored but where did not add his signature.
>
Hmm... for pure next-20131101 tree in my git directory and the demo
patches in attachment, it will cause this issue.
And excuse me, I am not quite familiar with git, could you provide more
details (e.g. where the special difference of the demo patches or the
pure next-20131101 tree in my git directory)? thanks.
> Also, there's a defect in function vcs_find_signers.
> It should only return the commit count and array references.
>
> If there are no signers in the commit history interval specified,
> then the "authors" array is added to the "signers" array and
> returned as a single array.
>
> Use references instead.
>
> Make sure that references are defined in the places
> that vcs_find_signers is called.
>
After apply the patch below, it can work well.
Tested-by Chen Gang
> Signed-off-by: Joe Perches
> ---
> scripts/get_maintainer.pl | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index ee9adb8..9c3986f 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -128,7 +128,7 @@ my %VCS_cmds_git = (
> "blame_commit_pattern" => "^([0-9a-f]+) ",
> "author_pattern" => "^GitAuthor: (.*)",
> "subject_pattern" => "^GitSubject: (.*)",
> -"stat_pattern" => "(\\d+)\\t(\\d+)\\t\$file",
> +"stat_pattern" => "^(\\d+)\\t(\\d+)\\t\$file\$",
> );
>
> my %VCS_cmds_hg = (
> @@ -156,7 +156,7 @@ my %VCS_cmds_hg = (
> "blame_commit_pattern" => "^([ 0-9a-f]+):",
> "author_pattern" => "^HgAuthor: (.*)",
> "subject_pattern" => "^HgSubject: (.*)",
> -"stat_pattern" => "(\\d+)\t(\\d+)\t\$file",
> +"stat_pattern" => "^(\\d+)\t(\\d+)\t\$file\$",
> );
>
> my $conf = which_conf(".get_maintainer.conf");
> @@ -1297,7 +1297,7 @@ sub vcs_find_signers {
>
> #print("stats: <@stats>\n");
>
> -return (0, @signatures, @authors) if !@signatures;
> +return (0, \@signatures, \@authors, \@stats) if !@signatures;
>
> save_commits_by_author(@lines) if ($interactive);
> save_commits_by_signer(@lines) if ($interactive);
> @@ -1880,9 +1880,10 @@ sub vcs_file_signoffs {
> $cmd =~ s/(\$\w+)/$1/eeg;# interpolate $cmd
>
> ($commits, $signers_ref, $authors_ref, $stats_ref) =
> vcs_find_signers($cmd, $file);
> -@signers = @{$signers_ref};
> -@authors = @{$authors_ref};
> -@stats = @{$stats_ref};
> +
> +@signers = @{$signers_ref} if defined $signers_ref;
> +@authors = @{$authors_ref} if defined $authors_ref;
> +@stats = @{$stats_ref} if defined $stats_ref;
>
> #print("commits: <$commits>\nsigners:<@signers>\nauthors:
> <@authors>\nstats: <@stats>\n");
>
> @@ -1965,8 +1966,8 @@ sub vcs_file_blame {
> $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
>
> ($commit_count, $commit_signers_ref, $commit_authors_ref,
> $stats_ref) = vcs_find_signers($cmd, $file);
> - @commit_authors = @{$commit_authors_ref};
> - @commit_signers = @{$commit_signers_ref};
> + @commit_authors = @{$commit_authors_ref} if defined
> $commit_authors_ref;
> + @commit_signers = @{$commit_signers_ref} if defined
> $commit_signers_ref;
>
> push(@signers, @commit_signers);
> } else {
> @@ -1983,8 +1984,8 @@ sub vcs_file_blame {
> $cmd =~ s/(\$\w+)/$1/eeg; #substitute variables in $cmd
>
> ($commit_count, $commit_signers_ref, $commit_authors_ref,
> $stats_ref) = vcs_find_signers($cmd, $file);
> - @commit_authors = @{$commit_authors_ref};
> - @commit_signers = @{$commit_signers_ref};
> + @commit_authors = @{$commit_authors_ref} if defined
> $commit_authors_ref;
> + @commit_signers = @{$commit_signers_ref} if defined
> $commit_signers_ref;
>
> push(@signers, @commit_signers);
> }
>
>
>
>
--
Chen Gang
Subject: [PATCH] hexagon: kernel: remove useless variables 'dn', 'r' and 'err' in time_init_deferred() in "time.c"
Date: Fri, 01 Nov 2013 19:07:48 +0800
From: Chen Gang
Remove them, since they are useless. The related warnings (with
allmodconfig for v4):
CC arch/hexagon/kernel/time.o
arch/hexagon/kernel/time.c: In function 'time_init_deferred':
arch/hexagon/kernel/time.c:196: warning: unused variable 'err'
arch/hexagon/kernel/time.c:195: warning: unused variable 'r'
arch/hexagon/kernel/time.c:194: warning: unused variable 'dn'
Signed-off-by: Chen Gang
---
arch/hexagon/kernel/time.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index 9903fad..d0c4f5a 100644
--- a/arch/hexagon/kernel/time.c
+++
Re: [PATCH 1/2] libata: use sleep instead of standby command
+linux-ide On 11/05/2013 08:52 AM, Phillip Susi wrote: > The ATA SLEEP mode saves some more power than SUSPEND, and > has basically the same recovery time, so use it instead. I suppose this is mainly for runtime PM? Since for system suspend/hibernation, the disk and its controller will be powered off anyway. Best regards, Aaron > > Signed-off-by: Phillip Susi > --- > drivers/ata/libata-scsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c > index 97a0cef..79b75fd 100644 > --- a/drivers/ata/libata-scsi.c > +++ b/drivers/ata/libata-scsi.c > @@ -1362,8 +1362,8 @@ static unsigned int ata_scsi_start_stop_xlat(struct > ata_queued_cmd *qc) >system_entering_hibernation()) > goto skip; > > - /* Issue ATA STANDBY IMMEDIATE command */ > - tf->command = ATA_CMD_STANDBYNOW1; > + /* Issue ATA SLEEP command */ > + tf->command = ATA_CMD_SLEEP; > } > > /* > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/13] tracing/uprobes: Add more fetch functions
Hi Steve,
On Mon, 4 Nov 2013 12:17:06 -0500, Steven Rostedt wrote:
> On Mon, 4 Nov 2013 17:44:31 +0100
> Oleg Nesterov wrote:
>
>> On 11/04, Namhyung Kim wrote:
>> >
>> > On Thu, 31 Oct 2013 19:22:18 +0100, Oleg Nesterov wrote:
>> > > On 10/29, Namhyung Kim wrote:
>> > >>
>> > >> +static void __user *get_user_vaddr(unsigned long addr, struct
>> > >> trace_uprobe *tu)
>> > >> +{
>> > >> + unsigned long pgoff = addr >> PAGE_SHIFT;
>> > >> + struct vm_area_struct *vma;
>> > >> + struct address_space *mapping;
>> > >> + unsigned long vaddr = 0;
>> > >> +
>> > >> + if (tu == NULL) {
>> > >> + /* A NULL tu means that we already got the vaddr */
>> > >> + return (void __force __user *) addr;
>> > >> + }
>> > >> +
>> > >> + mapping = tu->inode->i_mapping;
>> > >> +
>> > >> + mutex_lock(>i_mmap_mutex);
>> > >> + vma_interval_tree_foreach(vma, >i_mmap, pgoff, pgoff) {
>> > >> + if (vma->vm_mm != current->mm)
>> > >> + continue;
>> > >> + if (!(vma->vm_flags & VM_READ))
>> > >> + continue;
>> > >> +
>> > >> + vaddr = offset_to_vaddr(vma, addr);
>> > >> + break;
>> > >> + }
>> > >> + mutex_unlock(>i_mmap_mutex);
>> > >> +
>> > >> + WARN_ON_ONCE(vaddr == 0);
>> > >
>> > > Hmm. But unless I missed something this "addr" passed as an argument can
>> > > be wrong? And if nothing else this or another thread can unmap the vma?
>> >
>> > You mean WARN_ON_ONCE here is superfluous? I admit that it should
>> > protect concurrent vma [un]mappings. Please see my reply in other
>> > thread for a new approach.
>>
>> Whatever we do this address can be unmapped. For example, just because of
>> @invalid_address passed to trace_uprobe.c.
>>
>> We do not really care, copy_from_user() should fail. But we should not
>> WARN() in this case.
>>
>
> I agree, the WARN_ON_ONCE() above looks like it's uncalled for.
> WARN()ings should only be used when an anomaly in the kernel logic is
> detected. Can this trigger on bad input from user space, or something
> else that userspace does? (a race with unmapping memory?). If so, error
> out to the user process, but do not call any of the WARN() functions.
Will do. Thanks for the explanation.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/13] tracing/uprobes: Add more fetch functions
On Mon, 4 Nov 2013 17:44:31 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Thu, 31 Oct 2013 19:22:18 +0100, Oleg Nesterov wrote:
>> > On 10/29, Namhyung Kim wrote:
>> >>
>> >> +static void __user *get_user_vaddr(unsigned long addr, struct
>> >> trace_uprobe *tu)
>> >> +{
>> >> + unsigned long pgoff = addr >> PAGE_SHIFT;
>> >> + struct vm_area_struct *vma;
>> >> + struct address_space *mapping;
>> >> + unsigned long vaddr = 0;
>> >> +
>> >> + if (tu == NULL) {
>> >> + /* A NULL tu means that we already got the vaddr */
>> >> + return (void __force __user *) addr;
>> >> + }
>> >> +
>> >> + mapping = tu->inode->i_mapping;
>> >> +
>> >> + mutex_lock(>i_mmap_mutex);
>> >> + vma_interval_tree_foreach(vma, >i_mmap, pgoff, pgoff) {
>> >> + if (vma->vm_mm != current->mm)
>> >> + continue;
>> >> + if (!(vma->vm_flags & VM_READ))
>> >> + continue;
>> >> +
>> >> + vaddr = offset_to_vaddr(vma, addr);
>> >> + break;
>> >> + }
>> >> + mutex_unlock(>i_mmap_mutex);
>> >> +
>> >> + WARN_ON_ONCE(vaddr == 0);
>> >
>> > Hmm. But unless I missed something this "addr" passed as an argument can
>> > be wrong? And if nothing else this or another thread can unmap the vma?
>>
>> You mean WARN_ON_ONCE here is superfluous? I admit that it should
>> protect concurrent vma [un]mappings. Please see my reply in other
>> thread for a new approach.
>
> Whatever we do this address can be unmapped. For example, just because of
> @invalid_address passed to trace_uprobe.c.
>
> We do not really care, copy_from_user() should fail. But we should not
> WARN() in this case.
Okay, I see. Will remove it in the next spin.
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 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote: > On 11/04, Oleg Nesterov wrote: >> >> But in any case, I strongly believe that it doesn't make any sense to >> rely on tu->inode in get_user_vaddr(). > > Hmm. But I forgot about the case when you probe the function in libc > and want to dump the variable in libc... Right. Actually that's what I really wanted. > > So probably I was wrong and this all needs more thinking. Damn. :) > Perhaps we really need to pass @file/offset, but it is not clear what > we can do with bss/anon-mapping. The @file/offset should work with bss since data in bss is accessed via an offset in the program, but still anon-mapping has nothing to do with it. Hmm... 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 11/13] tracing/kprobes: Add priv argument to fetch functions
On Mon, 4 Nov 2013 17:09:14 +0100, Oleg Nesterov wrote:
> See my replies to 0/13. Lets assume that you agree that get_user_vaddr()
> doesn't need tu->inode.
Okay.
>
> On 10/29, Namhyung Kim wrote:
>>
>> This argument is for passing private data structure to each fetch
>> function and will be used by uprobes.
>
> In this case, why do we need this "void *priv"? It actually becomes
> "bool need_addr_translation".
Right. I added it because the deref method is used for both of kprobes
and uprobes and it only needed for uprobes. And I thought if we need
something for kprobes later, it can be reused so make it general.
>
> Can't we avoid it? Can't we just add FETCH_MTD_memory_notranslate ?
> kprobes should use the same methods for FETCH_MTD_memory*, uprobes
> should obviously adjust the addr in FETCH_MTD_memory.
>
> Then (afaics) we need a single change in parse_probe_arg(),
>
> - dprm->fetch = t->fetch[FETCH_MTD_memory];
> + dprm->fetch = t->fetch[FETCH_MTD_memory_notranslate];
>
> Yes, this will blow *probes_fetch_type_table[], but looks simpler.
Looks good to me too, thanks! :)
>
> And. This way it would be simple to teach parse_probe_arg('@') to use
> _notranslate, say, "@=addr" or whatever.
Yeah, it'll be useful at least for fetching data in anon pages.
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/2] kernfs: update sysfs_init_inode_attrs()
sysfs_init_inode_attrs() is a bit clumsy to use requiring the caller
to check whether @sd->s_iattr is already set or not. Rename it to
sysfs_inode_attrs(), update it to check whether @sd->s_iattr is
already initialized before trying to initialize it and return
@sd->s_iattr. This simplifies the callers.
While at it,
* Rename struct sysfs_inode_attrs pointer variables to "attrs". As
kernfs no longer deals with "struct attribute", this isn't confusing
and makes it easier to distinguish from struct iattr pointers.
* A new field will be added to sysfs_inode_attrs. Reindent in
preparation.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo
---
fs/kernfs/inode.c | 60 -
fs/kernfs/kernfs-internal.h | 6 ++---
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index b4cae6f..a1f8382 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -43,15 +43,17 @@ void __init sysfs_inode_init(void)
panic("failed to init sysfs_backing_dev_info");
}
-static struct sysfs_inode_attrs *sysfs_init_inode_attrs(struct sysfs_dirent
*sd)
+static struct sysfs_inode_attrs *sysfs_inode_attrs(struct sysfs_dirent *sd)
{
- struct sysfs_inode_attrs *attrs;
struct iattr *iattrs;
- attrs = kzalloc(sizeof(struct sysfs_inode_attrs), GFP_KERNEL);
- if (!attrs)
+ if (sd->s_iattr)
+ return sd->s_iattr;
+
+ sd->s_iattr = kzalloc(sizeof(struct sysfs_inode_attrs), GFP_KERNEL);
+ if (!sd->s_iattr)
return NULL;
- iattrs = >ia_iattr;
+ iattrs = >s_iattr->ia_iattr;
/* assign default attributes */
iattrs->ia_mode = sd->s_mode;
@@ -59,26 +61,20 @@ static struct sysfs_inode_attrs
*sysfs_init_inode_attrs(struct sysfs_dirent *sd)
iattrs->ia_gid = GLOBAL_ROOT_GID;
iattrs->ia_atime = iattrs->ia_mtime = iattrs->ia_ctime = CURRENT_TIME;
- return attrs;
+ return sd->s_iattr;
}
static int __kernfs_setattr(struct sysfs_dirent *sd, const struct iattr *iattr)
{
- struct sysfs_inode_attrs *sd_attrs;
+ struct sysfs_inode_attrs *attrs;
struct iattr *iattrs;
unsigned int ia_valid = iattr->ia_valid;
- sd_attrs = sd->s_iattr;
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
- if (!sd_attrs) {
- /* setting attributes for the first time, allocate now */
- sd_attrs = sysfs_init_inode_attrs(sd);
- if (!sd_attrs)
- return -ENOMEM;
- sd->s_iattr = sd_attrs;
- }
- /* attributes were changed at least once in past */
- iattrs = _attrs->ia_iattr;
+ iattrs = >ia_iattr;
if (ia_valid & ATTR_UID)
iattrs->ia_uid = iattr->ia_uid;
@@ -143,22 +139,19 @@ out:
static int sysfs_sd_setsecdata(struct sysfs_dirent *sd, void **secdata,
u32 *secdata_len)
{
- struct sysfs_inode_attrs *iattrs;
+ struct sysfs_inode_attrs *attrs;
void *old_secdata;
size_t old_secdata_len;
- if (!sd->s_iattr) {
- sd->s_iattr = sysfs_init_inode_attrs(sd);
- if (!sd->s_iattr)
- return -ENOMEM;
- }
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
- iattrs = sd->s_iattr;
- old_secdata = iattrs->ia_secdata;
- old_secdata_len = iattrs->ia_secdata_len;
+ old_secdata = attrs->ia_secdata;
+ old_secdata_len = attrs->ia_secdata_len;
- iattrs->ia_secdata = *secdata;
- iattrs->ia_secdata_len = *secdata_len;
+ attrs->ia_secdata = *secdata;
+ attrs->ia_secdata_len = *secdata_len;
*secdata = old_secdata;
*secdata_len = old_secdata_len;
@@ -216,17 +209,16 @@ static inline void set_inode_attr(struct inode *inode,
struct iattr *iattr)
static void sysfs_refresh_inode(struct sysfs_dirent *sd, struct inode *inode)
{
- struct sysfs_inode_attrs *iattrs = sd->s_iattr;
+ struct sysfs_inode_attrs *attrs = sd->s_iattr;
inode->i_mode = sd->s_mode;
- if (iattrs) {
+ if (attrs) {
/* sysfs_dirent has non-default attributes
* get them from persistent copy in sysfs_dirent
*/
- set_inode_attr(inode, >ia_iattr);
- security_inode_notifysecctx(inode,
- iattrs->ia_secdata,
- iattrs->ia_secdata_len);
+ set_inode_attr(inode, >ia_iattr);
+ security_inode_notifysecctx(inode, attrs->ia_secdata,
+ attrs->ia_secdata_len);
}
if (sysfs_type(sd) == SYSFS_DIR)
diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs-internal.h
[PATCH 2/2] kernfs: implement "trusted.*" xattr support
kernfs inherited "security.*" xattr support from sysfs. This patch
extends xattr support to "trusted.*" using simple_xattr_*(). As
trusted xattrs are restricted to CAP_SYS_ADMIN, simple_xattr_*() which
uses kernel memory for storage shouldn't be problematic.
Note that the existing "security.*" support doesn't implement
get/remove/list and the this patch only implements those ops for
"trusted.*". We probably want to extend those ops to include support
for "security.*".
This patch will allow using kernfs from cgroup which requires
"trusted.*" xattr support.
Signed-off-by: Tejun Heo
Cc: David P. Quigley
---
fs/kernfs/dir.c | 12 ++---
fs/kernfs/inode.c | 63 +++--
fs/kernfs/kernfs-internal.h | 7 +
fs/kernfs/symlink.c | 3 +++
4 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 6db5ed3..d5b33fe 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -255,9 +255,12 @@ void kernfs_put(struct sysfs_dirent *sd)
kernfs_put(sd->s_symlink.target_sd);
if (sysfs_type(sd) & SYSFS_COPY_NAME)
kfree(sd->s_name);
- if (sd->s_iattr && sd->s_iattr->ia_secdata)
- security_release_secctx(sd->s_iattr->ia_secdata,
- sd->s_iattr->ia_secdata_len);
+ if (sd->s_iattr) {
+ if (sd->s_iattr->ia_secdata)
+ security_release_secctx(sd->s_iattr->ia_secdata,
+ sd->s_iattr->ia_secdata_len);
+ simple_xattrs_free(>s_iattr->xattrs);
+ }
kfree(sd->s_iattr);
ida_simple_remove(>ino_ida, sd->s_ino);
kmem_cache_free(sysfs_dir_cachep, sd);
@@ -711,6 +714,9 @@ const struct inode_operations sysfs_dir_inode_operations = {
.setattr= sysfs_setattr,
.getattr= sysfs_getattr,
.setxattr = sysfs_setxattr,
+ .removexattr= sysfs_removexattr,
+ .getxattr = sysfs_getxattr,
+ .listxattr = sysfs_listxattr,
};
static struct sysfs_dirent *sysfs_leftmost_descendant(struct sysfs_dirent *pos)
diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c
index a1f8382..18ad431 100644
--- a/fs/kernfs/inode.c
+++ b/fs/kernfs/inode.c
@@ -35,6 +35,9 @@ static const struct inode_operations sysfs_inode_operations =
{
.setattr= sysfs_setattr,
.getattr= sysfs_getattr,
.setxattr = sysfs_setxattr,
+ .removexattr= sysfs_removexattr,
+ .getxattr = sysfs_getxattr,
+ .listxattr = sysfs_listxattr,
};
void __init sysfs_inode_init(void)
@@ -61,6 +64,8 @@ static struct sysfs_inode_attrs *sysfs_inode_attrs(struct
sysfs_dirent *sd)
iattrs->ia_gid = GLOBAL_ROOT_GID;
iattrs->ia_atime = iattrs->ia_mtime = iattrs->ia_ctime = CURRENT_TIME;
+ simple_xattrs_init(>s_iattr->xattrs);
+
return sd->s_iattr;
}
@@ -162,23 +167,25 @@ int sysfs_setxattr(struct dentry *dentry, const char
*name, const void *value,
size_t size, int flags)
{
struct sysfs_dirent *sd = dentry->d_fsdata;
+ struct sysfs_inode_attrs *attrs;
void *secdata;
int error;
u32 secdata_len = 0;
- if (!sd)
- return -EINVAL;
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
if (!strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN)) {
const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
error = security_inode_setsecurity(dentry->d_inode, suffix,
value, size, flags);
if (error)
- goto out;
+ return error;
error = security_inode_getsecctx(dentry->d_inode,
, _len);
if (error)
- goto out;
+ return error;
mutex_lock(_mutex);
error = sysfs_sd_setsecdata(sd, , _len);
@@ -186,10 +193,50 @@ int sysfs_setxattr(struct dentry *dentry, const char
*name, const void *value,
if (secdata)
security_release_secctx(secdata, secdata_len);
- } else
- return -EINVAL;
-out:
- return error;
+ return error;
+ } else if (!strncmp(name, XATTR_TRUSTED_PREFIX,
XATTR_TRUSTED_PREFIX_LEN)) {
+ return simple_xattr_set(>xattrs, name, value, size,
+ flags);
+ }
+
+ return -EINVAL;
+}
+
+int sysfs_removexattr(struct dentry *dentry, const char *name)
+{
+ struct sysfs_dirent *sd = dentry->d_fsdata;
+ struct sysfs_inode_attrs *attrs;
+
+ attrs = sysfs_inode_attrs(sd);
+ if (!attrs)
+ return -ENOMEM;
+
+
[PATCHSET driver-core-next] kernfs: implement trusted.* xattr support
Hello,
(This is for 3.14-rc1. Posting early for review. Will refresh and
repost once the next driver-core-next opens.)
kernfs inherited "security.*" xattr support from sysfs but for it to
be useable for cgroupfs, it needs to support "trusted.*" too. This
patchset adds "trusted.*" xattr support using simple_xattr*().
Note that the existing "security.*" support is gimped in that it
doesn't include remove/get/list. This patchset implements all
operations for "trusted.*" but doesn't change "security.*" support.
David P. Quigley, can you please comment on this? It doesn't seem
like adding it would be too difficult. Why don't we have it yet? Are
they unnecessary?
This patchset contains the following two patches.
0001-kernfs-update-sysfs_init_inode_attrs.patch
0002-kernfs-implement-trusted.-xattr-support.patch
0001 preps and 0002 implements.
This patchset is on top of
driver-core-next 0cae60f91494 ("sysfs: rename sysfs_assoc_lock and explain
what it's about")
+ [1] [PATCHSET] sysfs: separate out kernfs, take #2
and available in the following git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-kernfs-xattr
diffstat follows. Thanks.
fs/kernfs/dir.c | 12 +++-
fs/kernfs/inode.c | 123
fs/kernfs/kernfs-internal.h | 13 +++-
fs/kernfs/symlink.c |3 +
4 files changed, 103 insertions(+), 48 deletions(-)
--
tejun
[1] https://lkml.kernel.org/g/1383472398-17812-1-git-send-email...@kernel.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Disabling in-memory write cache for x86-64 in Linux II
On Tue, 5 Nov 2013 09:40:55 +0800 "Figo.zhang" wrote: > > > > > > Of course, if you don't use Linux on the desktop you don't really care - > > well, I do. Also > > > not everyone in this world has an UPS - which means such a huge buffer > > can lead to a > > > serious data loss in case of a power blackout. > > > > I don't have a desk (just a lap), but I use Linux on all my computers and > > I've never really noticed the problem. Maybe I'm just very patient, or > > maybe > > I don't work with large data sets and slow devices. > > > > However I don't think data-loss is really a related issue. Any process > > that > > cares about data safety *must* use fsync at appropriate places. This has > > always been true. > > > > =>May i ask question that, some like ext4 filesystem, if some app motify > the files, it create some dirty data. if some meta-data writing to the > journal disk when a power backout, > it will be lose some serious data and the the file will damage? If you modify a file, then you must take care that you can recover from a crash at any point in the process. If the file is small, the usual approach is to create a copy of the file with the appropriate changes made, then 'fsync' the file and rename the new file over the old file. If the file is large you might need some sort of update log (in a small file) so you can replay recent updates after a crash. The journalling that the filesystem provides only protects the filesystem metadata. It does not protect the consistency of the data in your file. I hope that helps. NeilBrown signature.asc Description: PGP signature
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Mon, 2013-11-04 at 17:44 -0800, Tim Chen wrote: > On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote: > > On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote: > > > On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote: > > > > On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote: > > > > > > > > > > * Yuanhan Liu wrote: > > > > > > > > > > > > Btw., another _really_ interesting comparison would be against > > > > > > > the latest rwsem patches. Mind doing such a comparison? > > > > > > > > > > > > Sure. Where can I get it? Are they on some git tree? > > > > > > > > > > I've Cc:-ed Tim Chen who might be able to point you to the latest > > > > > version. > > > > > > > > > > The last on-lkml submission was in this thread: > > > > > > > > > > Subject: [PATCH v8 0/9] rwsem performance optimizations > > > > > > > > > > > > > Thanks. > > > > > > > > I queued bunchs of tests about one hour ago, and already got some > > > > results(If necessary, I can add more data tomorrow when those tests are > > > > finished): > > > > > > What kind of system are you using to run these workloads on? > > > > I queued jobs on 5 testboxes: > > - brickland1: 120 core Ivybridge server > > - lkp-ib03: 48 core Ivybridge server > > - lkp-sb03: 32 core Sandybridge server > > - lkp-nex04: 64 core NHM server > > - lkp-a04:Atom server > > > > > > > > > > > > > > >v3.12-rc7 fe001e3de090e179f95d > > > > > > > > -9.3% > > > > brickland1/micro/aim7/shared > > > > +4.3% > > > > lkp-ib03/micro/aim7/fork_test > > > > +2.2% > > > > lkp-ib03/micro/aim7/shared > > > > -2.6% TOTAL > > > > aim7.2000.jobs-per-min > > > > > > > > > > Sorry if I'm missing something, but could you elaborate more on what > > > these percentages represent? > > > >v3.12-rc7 fe001e3de090e179f95d > > > > -9.3% > > brickland1/micro/aim7/shared > > > > > > -2.6% TOTAL > > aim7.2000.jobs-per-min > > > > The comparation base is v3.12-rc7, and we got 9.3 performance regression > > at commit fe001e3de090e179f95d, which is the head of rwsem performance > > optimizations patch set. > > Yunahan, thanks for the data. This I assume is with the entire rwsem > v8 patchset. Any idea of the run variation on the workload? Yunhan, I haven't got a chance to make multiple runs to check the standard deviation. From the few runs I did, I got a 5.1% increase in performance for aim7 shared workload for the complete rwsem patchset on a similar machine that you are using. The patches are applied to the 3.12-rc7 and compared to the vanilla kernel. Thanks. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
