Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch. The change below on top of
> -next makes these ARM boards happy again.
Oops, it should've fixed __devres_alloc() also. Updated patch below.
Kevin
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()
commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory. However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.
To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.
Signed-off-by: Kevin Hilman
---
drivers/base/devres.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t
size, gfp_t gfp,
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(>node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
return dr->data;
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions
On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
[]
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch. The change below on top of
> -next makes these ARM boards happy again.
[]
> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
> the default behavior of alloc_dr() to no longer zero the allocated
> memory. However,
> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
> which leaves
> any users of devres_alloc() or __devres_alloc() with potentially wrong
> assumptions
> about memory being zero'd upon allocation.
>
> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
> behavior of zero'ing memory upon allocation.
[]
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
[]
> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
> size, gfp_t gfp)
> {
> struct devres *dr;
>
> - dr = alloc_dr(release, size, gfp);
> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
> if (unlikely(!dr))
> return NULL;
> return dr->data;
Wouldn't the __devres_alloc need that too?
#ifdef CONFIG_DEBUG_DEVRES
void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
const char *name)
{
struct devres *dr;
dr = alloc_dr(release, size, gfp);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(>node, name, size);
return dr->data;
}
EXPORT_SYMBOL_GPL(__devres_alloc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Run checksumming in parallel accross multiple alu's
If implemented properly adcx/adox should give additional speedup... that is the whole reason for their existence. Neil Horman wrote: >On Sat, Oct 12, 2013 at 03:29:24PM -0700, H. Peter Anvin wrote: >> On 10/11/2013 09:51 AM, Neil Horman wrote: >> > Sébastien Dugué reported to me that devices implementing ipoib >(which don't have >> > checksum offload hardware were spending a significant amount of >time computing >> > checksums. We found that by splitting the checksum computation >into two >> > separate streams, each skipping successive elements of the buffer >being summed, >> > we could parallelize the checksum operation accros multiple alus. >Since neither >> > chain is dependent on the result of the other, we get a speedup in >execution (on >> > hardware that has multiple alu's available, which is almost >ubiquitous on x86), >> > and only a negligible decrease on hardware that has only a single >alu (an extra >> > addition is introduced). Since addition in commutative, the result >is the same, >> > only faster >> >> On hardware that implement ADCX/ADOX then you should also be able to >> have additional streams interleaved since those instructions allow >for >> dual carry chains. >> >> -hpa >> >I've been looking into this a bit more, and I'm a bit confused. >According to >this: >http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/ia-large-integer-arithmetic-paper.html > >by my read, this pair of instructions simply supports 2 carry bit >chains, >allowing for two parallel execution paths through the cpu that won't >block on >one another. Its exactly the same as whats being done with the >universally >available addcq instruction, so theres no real speedup (that I can >see). Since >we'd either have to use the alternatives macro to support adcx/adox >here or the >old instruction set, it seems not overly worth the effort to support >the >extension. > >Or am I missing something? > >Neil -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] device: Add kernel standard devm_k.alloc functions
On Fri, Oct 18, 2013 at 10:06 AM, Joe Perches wrote:
> On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
> []
>> A handful of boot panics on ARM platforms were bisected to point at
>> the version of this commit that's in linux-next (commit
>> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
>> makes things happy again.
>>
>> Upon further digging, it seems that users of devres_alloc() are
>> relying on the previous behavior of having the memory zero'd which is
>> no longer the case after $SUBJECT patch. The change below on top of
>> -next makes these ARM boards happy again.
> []
>> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
>> the default behavior of alloc_dr() to no longer zero the allocated
>> memory. However,
>> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
>> which leaves
>> any users of devres_alloc() or __devres_alloc() with potentially wrong
>> assumptions
>> about memory being zero'd upon allocation.
>>
>> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
>> behavior of zero'ing memory upon allocation.
> []
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> []
>> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
>> size, gfp_t gfp)
>> {
>> struct devres *dr;
>>
>> - dr = alloc_dr(release, size, gfp);
>> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>> if (unlikely(!dr))
>> return NULL;
>> return dr->data;
>
> Wouldn't the __devres_alloc need that too?
Yeah, I had mentioned __devres_alloc() in the changelog, but missed
it in the actual patch. :(
Anyways, I had quickly sent an updated patch, but our mails must've
crossed paths.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] perf-report: add --max-stack option to limit callchain stack scan
Em Fri, Oct 18, 2013 at 10:38:48AM -0400, Waiman Long escreveu:
> When callgraph data was included in the perf data file, it may take a
> long time to scan all those data and merge them together especially
> if the stored callchains are long and the perf data file itself is
> large, like a Gbyte or so.
>
> The callchain stack is currently limited to PERF_MAX_STACK_DEPTH (127).
> This is a large value. Usually the callgraph data that developers are
> most interested in are the first few levels, the rests are usually
> not looked at.
>
> This patch adds a new --max-stack option to perf-report to limit the
> depth of callchain stack data to look at to reduce the time it takes
> for perf-report to finish its processing. It trades the presence of
> trailing stack information with faster speed.
>
> The following table shows the elapsed time of doing perf-report on a
> perf.data file of size 985,531,828 bytes.
>
> --max_stack Elapsed TimeOutput data size
> ---
Please prefix lines like this (--) with a space, otherwise 'git am'
will chop off everything from that line onwards. Fixing it up now.
- Arnaldo
> not set 88.0s124,422,651
> 64 87.5s116,303,213
> 32 87.2s112,023,804
> 16 86.6s 94,326,380
> 859.9s 33,697,248
> 440.7s 10,116,637
> -g none 27.1s 2,555,810
>
> Signed-off-by: Waiman Long
> ---
> tools/perf/Documentation/perf-report.txt |8
> tools/perf/builtin-report.c | 22 +-
> tools/perf/builtin-top.c |3 ++-
> tools/perf/util/machine.c| 14 +-
> tools/perf/util/machine.h|3 ++-
> tools/perf/util/session.c|3 ++-
> 6 files changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf-report.txt
> b/tools/perf/Documentation/perf-report.txt
> index 2b8097e..be3f196 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -135,6 +135,14 @@ OPTIONS
>
> Default: fractal,0.5,callee,function.
>
> +--max-stack::
> + Set the stack depth limit when parsing the callchain, anything
> + beyond the specified depth will be ignored. This is a trade-off
> + between information loss and faster processing especially for
> + workloads that can have a very long callchain stack.
> +
> + Default: 127
> +
> -G::
> --inverted::
> alias for inverted caller based call graph.
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 72eae74..d0c9504 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -47,6 +47,7 @@ struct perf_report {
> boolshow_threads;
> boolinverted_callchain;
> boolmem_mode;
> + int max_stack;
> struct perf_read_values show_threads_values;
> const char *pretty_printing_style;
> const char *cpu_list;
> @@ -88,7 +89,8 @@ static int perf_report__add_mem_hist_entry(struct perf_tool
> *tool,
> if ((sort__has_parent || symbol_conf.use_callchain) &&
> sample->callchain) {
> err = machine__resolve_callchain(machine, evsel, al->thread,
> - sample, , al);
> + sample, , al,
> + rep->max_stack);
> if (err)
> return err;
> }
> @@ -179,7 +181,8 @@ static int perf_report__add_branch_hist_entry(struct
> perf_tool *tool,
> if ((sort__has_parent || symbol_conf.use_callchain)
> && sample->callchain) {
> err = machine__resolve_callchain(machine, evsel, al->thread,
> - sample, , al);
> + sample, , al,
> + rep->max_stack);
> if (err)
> return err;
> }
> @@ -242,18 +245,21 @@ out:
> return err;
> }
>
> -static int perf_evsel__add_hist_entry(struct perf_evsel *evsel,
> +static int perf_evsel__add_hist_entry(struct perf_tool *tool,
> + struct perf_evsel *evsel,
> struct addr_location *al,
> struct perf_sample *sample,
> struct machine *machine)
> {
> + struct perf_report *rep = container_of(tool, struct perf_report, tool);
> struct symbol *parent = NULL;
> int err = 0;
> struct hist_entry *he;
>
> if ((sort__has_parent || symbol_conf.use_callchain) &&
> sample->callchain) {
Re: [PATCH] netfilter: fix ordering of jumpstack allocation and table update
On Fri, 2013-10-18 at 17:57 +0100, Will Deacon wrote: > Hi Pablo, > > > We also need fixes for net/ipv6/netfilter/ip6_tables.c and > > net/ipv4/netfilter/arp_tables.c as well. Could you extend this patch > > and resend? > > Sure, I can try, but that's going to require a bit of time to sit down and > look at the shared data, access order, dependencies etc. I'm currently > preparing for Edinburgh, so it might be a while before I get a chance to > extend this. That's basically same code copy/pasted, so it should be relatively easy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Run checksumming in parallel accross multiple alu's
On Fri, 2013-10-18 at 12:50 -0400, Neil Horman wrote:
> >
> for(i=0;i<10;i++) {
> sum = csum_partial(buf+offset, PAGE_SIZE, sum);
> offset = (offset < BUFSIZ-PAGE_SIZE) ? offset+PAGE_SIZE : 0;
> }
Please replace this by random accesses, and use the more standard 1500
length.
offset = prandom_u32() % (BUFSIZ - 1500);
offset &= ~1U;
sum = csum_partial(buf + offset, 1500, sum);
You are basically doing sequential accesses, so prefetch should
be automatically done by cpu itself.
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 RESEND 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
This has been committed. Thanks --Rich commit e64190f8440286a815060524777b435e06a7b364 Author: Namjae Jeon Date: Sun Oct 6 20:13:38 2013 + [RESEND, 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: kirkwood: remove lagacy clk workarounds
On 10/18/2013 06:17 PM, Ezequiel Garcia wrote: On Fri, Oct 18, 2013 at 10:47:41AM -0400, Jason Cooper wrote: On Fri, Oct 18, 2013 at 01:54:13PM +0200, Sebastian Hesselbarth wrote: With legacy devices converted to DT and a proper ethernet MAC workaround, we can now remove the clk workarounds for legacy devices. While at it, also cleanup the list of includes. Signed-off-by: Sebastian Hesselbarth --- As a follow-up patch for latest mvebu PRs, this patch is based on git://git.infradead.org/linux-mvebu.git tags/soc-3.13-2 Cc: Jason Cooper Cc: Andrew Lunn Cc: Russell King Cc: Kevin Hilman Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/mach-kirkwood/board-dt.c | 42 ++-- 1 files changed, 3 insertions(+), 39 deletions(-) Applied to mvebu/soc Weird: I've tried to do this clean-up myself and my usual tests with network built as a module failed somehow. Maybe I missed something and did something stupid? Ezequiel, you need commits b5d82db net: mv643xx_eth: fix missing device_node for port devices f564412 net: mv643xx_eth: fix orphaned statistics timer crash 041b4dd net: mv643xx_eth: update statistics timer from timer context only from git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master Those are the three net driver fixes and have not yet been pulled into mainline linux. Can you re-test with those three applied (or you can just merge in above master)? I am compiling right now and will report. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv1 5/8] ASoC: sgtl5000: Revise the bugs about the sgt15000 codec.
On Thu, Oct 17, 2013 at 05:01:14PM +0800, Xiubo Li wrote:
> @@ -883,14 +883,19 @@ static int ldo_regulator_register(struct snd_soc_codec
> *codec,
> struct regulator_init_data *init_data,
> int voltage)
> {
> +#ifdef CONFIG_SND_SOC_FSL_SGTL5000
> + return 0;
> +#else
> dev_err(codec->dev, "this setup needs regulator support in the
> kernel\n");
> return -EINVAL;
> +#endif
> }
If these systems don't actually need the internal regulator then should
they not be trying to enable it? Alternatively if it's OK to ignore
this then why is this conditional in the board?
If this is something that it's safe to ignore then it should either be
ignored all the time or should be controlled by platform data not by a
compile time #define.
signature.asc
Description: Digital signature
Re: [PATCH V2 Resend 31/34] cpufreq: sparc: Convert to light weight ->target_index() routine
From: Viresh Kumar Date: Fri, 18 Oct 2013 19:29:54 +0530 > This patch converts existing .target() to newly defined light weight > .target_index() routine for this driver. > > CPUFreq core will call cpufreq_frequency_table_target() before calling this > routine and will pass index to it. > > Cc: David S. Miller > Cc: sparcli...@vger.kernel.org > Signed-off-by: Viresh Kumar Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] perf-report: add --max-stack option to limit callchain stack scan
On 10/18/13 8:38 AM, Waiman Long wrote: When callgraph data was included in the perf data file, it may take a long time to scan all those data and merge them together especially if the stored callchains are long and the perf data file itself is large, like a Gbyte or so. The callchain stack is currently limited to PERF_MAX_STACK_DEPTH (127). This is a large value. Usually the callgraph data that developers are most interested in are the first few levels, the rests are usually not looked at. This patch adds a new --max-stack option to perf-report to limit the depth of callchain stack data to look at to reduce the time it takes for perf-report to finish its processing. It trades the presence of trailing stack information with faster speed. The following table shows the elapsed time of doing perf-report on a perf.data file of size 985,531,828 bytes. --max_stack Elapsed TimeOutput data size --- not set88.0s124,422,651 64 87.5s116,303,213 32 87.2s112,023,804 16 86.6s 94,326,380 8 59.9s 33,697,248 4 40.7s 10,116,637 -g none27.1s 2,555,810 Signed-off-by: Waiman Long --- tools/perf/Documentation/perf-report.txt |8 tools/perf/builtin-report.c | 22 +- tools/perf/builtin-top.c |3 ++- tools/perf/util/machine.c| 14 +- tools/perf/util/machine.h|3 ++- tools/perf/util/session.c|3 ++- 6 files changed, 40 insertions(+), 13 deletions(-) Looks good to me. Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] perf-top: add --max-stack option to limit callchain stack scan
On 10/18/13 8:38 AM, Waiman Long wrote: When the callgraph function is enabled (-G), it may take a long time to scan all the stack data and merge them accordingly. This patch adds a new --max-stack option to perf-top to limit the depth of callchain stack data to look at to reduce the time it takes for perf-top to finish its processing. It reduces the amount of information provided to the user in exchange for faster speed. Signed-off-by: Waiman Long --- tools/perf/Documentation/perf-top.txt |8 tools/perf/builtin-top.c |8 ++-- tools/perf/util/top.h |1 + 3 files changed, 15 insertions(+), 2 deletions(-) Looks good to me. Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv1 8/8] Documentation: Add device tree bindings for Freescale VF610 sound.
On Thu, Oct 17, 2013 at 05:01:17PM +0800, Xiubo Li wrote: > + -- Power supplies: > + * Mic Bias > + > + -- SGTL5000 pins: > + * MIC_IN > + * LINE_IN > + * HP_OUT > + * LINE_OUT Things that are part of the CODEC should be part of the CODEC binding and this binding should reference that - this way the information doesn't have to be replicated by all boards using the CODEC and if new devices are supported by the CODEC driver then only that needs updating hopefully. signature.asc Description: Digital signature
Re: [PATCHv1 6/8] ASoC: fsl: add SGT15000 based audio machine driver.
On Thu, Oct 17, 2013 at 05:01:15PM +0800, Xiubo Li wrote:
> + ret = snd_soc_register_card(_sgt1500_card);
> + if (ret) {
> + dev_err(>dev, "register soc sound card failed :%d\n",
> + ret);
> + return ret;
> + }
Use the newly added devm_snd_soc_register_card() (in -next).
signature.asc
Description: Digital signature
[PATCH v2 03/13] dmaengine: prepare for generic 'unmap' data
From: Dan Williams
Add a hook for a common dma unmap implementation to enable removal of
the per driver custom unmap code. (A reworked version of Bartlomiej
Zolnierkiewicz's patches to remove the custom callbacks and the size
increase of dma_async_tx_descriptor for drivers that don't care about
raid).
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Signed-off-by: Dan Williams
[bzolnier: prepare pl330 driver for adding missing unmap while at it]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/dma/amba-pl08x.c | 1 +
drivers/dma/at_hdmac.c| 1 +
drivers/dma/dw/core.c | 1 +
drivers/dma/ep93xx_dma.c | 1 +
drivers/dma/fsldma.c | 1 +
drivers/dma/ioat/dma.c| 1 +
drivers/dma/ioat/dma_v2.c | 1 +
drivers/dma/ioat/dma_v3.c | 1 +
drivers/dma/iop-adma.c| 1 +
drivers/dma/mv_xor.c | 1 +
drivers/dma/pl330.c | 2 ++
drivers/dma/ppc4xx/adma.c | 1 +
drivers/dma/timb_dma.c| 1 +
drivers/dma/txx9dmac.c| 1 +
include/linux/dmaengine.h | 26 ++
15 files changed, 41 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index e2c06e6..bbc01c1 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1197,6 +1197,7 @@ static void pl08x_desc_free(struct virt_dma_desc *vd)
struct pl08x_txd *txd = to_pl08x_txd(>tx);
struct pl08x_dma_chan *plchan = to_pl08x_chan(vd->tx.chan);
+ dma_descriptor_unmap(txd);
if (!plchan->slave)
pl08x_unmap_buffers(txd);
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index c787f38..cc7098d 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -345,6 +345,7 @@ atc_chain_complete(struct at_dma_chan *atchan, struct
at_desc *desc)
list_move(>desc_node, >free_list);
/* unmap dma addresses (not on slave channels) */
+ dma_descriptor_unmap(txd);
if (!atchan->chan_common.private) {
struct device *parent = chan2parent(>chan_common);
if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 89eb89f..e3fe1b1 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -311,6 +311,7 @@ dwc_descriptor_complete(struct dw_dma_chan *dwc, struct
dw_desc *desc,
list_splice_init(>tx_list, >free_list);
list_move(>desc_node, >free_list);
+ dma_descriptor_unmap(txd);
if (!is_slave_direction(dwc->direction)) {
struct device *parent = chan2parent(>chan);
if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index 591cd8c..dcd6bf5 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -791,6 +791,7 @@ static void ep93xx_dma_tasklet(unsigned long data)
* For the memcpy channels the API requires us to unmap the
* buffers unless requested otherwise.
*/
+ dma_descriptor_unmap(>txd);
if (!edmac->chan.private)
ep93xx_dma_unmap_buffers(desc);
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 61517dd..3752b2a9 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -870,6 +870,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
/* Run any dependencies */
dma_run_dependencies(txd);
+ dma_descriptor_unmap(txd);
/* Unmap the dst buffer, if requested */
if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
if (txd->flags & DMA_COMPL_DEST_UNMAP_SINGLE)
diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index 5ff6fc1..26f8cfd 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -602,6 +602,7 @@ static void __cleanup(struct ioat_dma_chan *ioat,
dma_addr_t phys_complete)
dump_desc_dbg(ioat, desc);
if (tx->cookie) {
dma_cookie_complete(tx);
+ dma_descriptor_unmap(tx);
ioat_dma_unmap(chan, tx->flags, desc->len, desc->hw);
ioat->active -= desc->hw->tx_cnt;
if (tx->callback) {
diff --git a/drivers/dma/ioat/dma_v2.c b/drivers/dma/ioat/dma_v2.c
index b925e1b..fc7b50a 100644
--- a/drivers/dma/ioat/dma_v2.c
+++ b/drivers/dma/ioat/dma_v2.c
@@ -148,6 +148,7 @@ static void __cleanup(struct ioat2_dma_chan *ioat,
dma_addr_t phys_complete)
tx = >txd;
dump_desc_dbg(ioat, desc);
if (tx->cookie) {
+ dma_descriptor_unmap(tx);
ioat_dma_unmap(chan, tx->flags, desc->len, desc->hw);
dma_cookie_complete(tx);
if (tx->callback) {
diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
index d8ececa..57a2901 100644
--- a/drivers/dma/ioat/dma_v3.c
[PATCH v2 00/13] dmaengine: introduce dmaengine_unmap_data
[ Original patch series description by Dan. ]
dmaengine from the beginning has placed the burden of unmapping dma
buffers on the individual drivers. The thought being that since the dma
driver already has the descriptor it can use that information for
unmapping. This results in a lot of cruft to read back data from
descriptors, places a burden on channels that need to break up an
operation internally into multiple descriptors, and makes it difficult
to have dma mappings with different lifetimes than the current
operation.
For example an xor->copy->xor chain wants to leave all buffers
mapped until completion, async_tx currently performs invalid overlapping
mappings. With dmaengine_unmap_data map once and take a reference for
descriptor that uses the mapping.
Reference to v1:
https://lkml.org/lkml/2012/12/6/71
Changes since v1:
- synced patch series with next-20131016
- removed no longer needed "async_memset: convert to dmaengine_unmap_data"
patch (patch #5 in v1)
- added patch #1 ("dmatest: make driver unmap also source buffers by itself")
- added patch #11 ("NTB: convert to dmaengine_unmap_data")
- prepared pl330 driver for adding missing unmap in patch #3
- in patch #4:
- fixed IS_ENABLED() check
- fixed release ordering in dmaengine_destroy_unmap_pool()
- fixed check for success in dmaengine_init_unmap_pool()
- replaced kmem_cache_free() by mempool_free()
- added missing unmap->len initializations
- added __init tag to dmaengine_init_unmap_pool()
- in patch #5:
- added missing unmap->len initialization
- fixed whitespace damage
- did minor cleanups in patches #6 & #7
- added temporary dma_dest array in patches #8 & #9
Tested on Exynos4412-based Trats2 board containing PL330 DMA engine, with
additional patches doing memory copying tests using DMA memcpy API.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (4):
dmatest: make driver unmap also source buffers by itself
NTB: convert to dmaengine_unmap_data
dmaengine: remove DMA unmap from drivers
dmaengine: remove DMA unmap flags
Dan Williams (9):
dmaengine: consolidate memcpy apis
dmaengine: prepare for generic 'unmap' data
dmaengine: reference counted unmap data
async_memcpy: convert to dmaengine_unmap_data
async_xor: convert to dmaengine_unmap_data
async_xor_val: convert to dmaengine_unmap_data
async_raid6_recov: convert to dmaengine_unmap_data
async_pq: convert to dmaengine_unmap_data
async_pq_val: convert to dmaengine_unmap_data
arch/arm/include/asm/hardware/iop3xx-adma.h | 30
arch/arm/include/asm/hardware/iop_adma.h| 4 -
arch/arm/mach-iop13xx/include/mach/adma.h | 26 ---
crypto/async_tx/async_memcpy.c | 37 ++--
crypto/async_tx/async_pq.c | 174 ++
crypto/async_tx/async_raid6_recov.c | 61 +--
crypto/async_tx/async_xor.c | 123 +++--
drivers/ata/pata_arasan_cf.c| 3 +-
drivers/dma/amba-pl08x.c| 32 +---
drivers/dma/at_hdmac.c | 26 +--
drivers/dma/dmaengine.c | 262 ++-
drivers/dma/dmatest.c | 9 +-
drivers/dma/dw/core.c | 21 +--
drivers/dma/ep93xx_dma.c| 30 +---
drivers/dma/fsldma.c| 17 +-
drivers/dma/ioat/dma.c | 20 +--
drivers/dma/ioat/dma.h | 12 --
drivers/dma/ioat/dma_v2.c | 2 +-
drivers/dma/ioat/dma_v3.c | 179 +-
drivers/dma/iop-adma.c | 97 +-
drivers/dma/mv_xor.c| 45 +
drivers/dma/pl330.c | 2 +
drivers/dma/ppc4xx/adma.c | 270 +---
drivers/dma/timb_dma.c | 37 +---
drivers/dma/txx9dmac.c | 25 +--
drivers/media/platform/m2m-deinterlace.c| 3 +-
drivers/media/platform/timblogiw.c | 2 +-
drivers/misc/carma/carma-fpga.c | 3 +-
drivers/mtd/nand/atmel_nand.c | 3 +-
drivers/mtd/nand/fsmc_nand.c| 2 -
drivers/net/ethernet/micrel/ks8842.c| 6 +-
drivers/ntb/ntb_transport.c | 64 +--
drivers/spi/spi-dw-mid.c| 4 +-
include/linux/dmaengine.h | 64 +--
34 files changed, 538 insertions(+), 1157 deletions(-)
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/13] dmaengine: reference counted unmap data
From: Dan Williams
Hang a common 'unmap' object off of dma descriptors for the purpose of
providing a unified unmapping interface. The lifetime of a mapping may
span multiple descriptors, so these unmap objects are reference counted
by related descriptor.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Signed-off-by: Dan Williams
[bzolnier: fix IS_ENABLED() check]
[bzolnier: fix release ordering in dmaengine_destroy_unmap_pool()]
[bzolnier: fix check for success in dmaengine_init_unmap_pool()]
[bzolnier: use mempool_free() instead of kmem_cache_free()]
[bzolnier: add missing unmap->len initializations]
[bzolnier: add __init tag to dmaengine_init_unmap_pool()]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/dma/dmaengine.c | 156 +++---
include/linux/dmaengine.h | 3 +
2 files changed, 150 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index bbc89df..e721a1c 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
static DEFINE_MUTEX(dma_list_mutex);
static DEFINE_IDR(dma_idr);
@@ -901,6 +902,129 @@ void dma_async_device_unregister(struct dma_device
*device)
}
EXPORT_SYMBOL(dma_async_device_unregister);
+struct dmaengine_unmap_pool {
+ struct kmem_cache *cache;
+ const char *name;
+ mempool_t *pool;
+ size_t size;
+};
+
+#define __UNMAP_POOL(x) { .size = x, .name = "dmaengine-unmap-" __stringify(x)
}
+static struct dmaengine_unmap_pool unmap_pool[] = {
+ __UNMAP_POOL(2),
+ #if IS_ENABLED(CONFIG_ASYNC_TX_DMA)
+ __UNMAP_POOL(16),
+ __UNMAP_POOL(128),
+ __UNMAP_POOL(256),
+ #endif
+};
+
+static struct dmaengine_unmap_pool *__get_unmap_pool(int nr)
+{
+ int order = get_count_order(nr);
+
+ switch (order) {
+ case 0 ... 1:
+ return _pool[0];
+ case 2 ... 4:
+ return _pool[1];
+ case 5 ... 7:
+ return _pool[2];
+ case 8:
+ return _pool[3];
+ default:
+ BUG();
+ return NULL;
+ }
+}
+
+static void dmaengine_unmap(struct kref *kref)
+{
+ struct dmaengine_unmap_data *unmap = container_of(kref, typeof(*unmap),
kref);
+ struct device *dev = unmap->dev;
+ int cnt, i;
+
+ cnt = unmap->to_cnt;
+ for (i = 0; i < cnt; i++)
+ dma_unmap_page(dev, unmap->addr[i], unmap->len,
+ DMA_TO_DEVICE);
+ cnt += unmap->from_cnt;
+ for (; i < cnt; i++)
+ dma_unmap_page(dev, unmap->addr[i], unmap->len,
+ DMA_FROM_DEVICE);
+ cnt += unmap->bidi_cnt;
+ for (; i < cnt; i++)
+ dma_unmap_page(dev, unmap->addr[i], unmap->len,
+ DMA_BIDIRECTIONAL);
+ mempool_free(unmap, __get_unmap_pool(cnt)->pool);
+}
+
+void dmaengine_unmap_put(struct dmaengine_unmap_data *unmap)
+{
+ if (unmap)
+ kref_put(>kref, dmaengine_unmap);
+}
+EXPORT_SYMBOL_GPL(dmaengine_unmap_put);
+
+static void dmaengine_destroy_unmap_pool(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(unmap_pool); i++) {
+ struct dmaengine_unmap_pool *p = _pool[i];
+
+ if (p->pool)
+ mempool_destroy(p->pool);
+ p->pool = NULL;
+ if (p->cache)
+ kmem_cache_destroy(p->cache);
+ p->cache = NULL;
+ }
+}
+
+static int __init dmaengine_init_unmap_pool(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(unmap_pool); i++) {
+ struct dmaengine_unmap_pool *p = _pool[i];
+ size_t size;
+
+ size = sizeof(struct dmaengine_unmap_data) +
+ sizeof(dma_addr_t) * p->size;
+
+ p->cache = kmem_cache_create(p->name, size, 0,
+SLAB_HWCACHE_ALIGN, NULL);
+ if (!p->cache)
+ break;
+ p->pool = mempool_create_slab_pool(1, p->cache);
+ if (!p->pool)
+ break;
+ }
+
+ if (i == ARRAY_SIZE(unmap_pool))
+ return 0;
+
+ dmaengine_destroy_unmap_pool();
+ return -ENOMEM;
+}
+
+static struct dmaengine_unmap_data *
+dmaengine_get_unmap_data(struct device *dev, int nr, gfp_t flags)
+{
+ struct dmaengine_unmap_data *unmap;
+
+ unmap = mempool_alloc(__get_unmap_pool(nr)->pool, flags);
+ if (!unmap)
+ return NULL;
+
+ memset(unmap, 0, sizeof(*unmap));
+ kref_init(>kref);
+ unmap->dev = dev;
+
+ return unmap;
+}
+
/**
* dma_async_memcpy_pg_to_pg - offloaded copy from page to page
* @chan: DMA channel to offload copy to
@@ -922,24 +1046,34 @@ dma_async_memcpy_pg_to_pg(struct dma_chan *chan,
[PATCH v2 10/13] async_pq_val: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_pq.c | 58 --
1 file changed, 35 insertions(+), 23 deletions(-)
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 8cdbf33..4126b56 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -290,50 +290,60 @@ async_syndrome_val(struct page **blocks, unsigned int
offset, int disks,
struct dma_async_tx_descriptor *tx;
unsigned char coefs[disks-2];
enum dma_ctrl_flags dma_flags = submit->cb_fn ? DMA_PREP_INTERRUPT : 0;
- dma_addr_t *dma_src = NULL;
- int src_cnt = 0;
+ struct dmaengine_unmap_data *unmap = NULL;
BUG_ON(disks < 4);
- if (submit->scribble)
- dma_src = submit->scribble;
- else if (sizeof(dma_addr_t) <= sizeof(struct page *))
- dma_src = (dma_addr_t *) blocks;
+ if (device)
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
- if (dma_src && device && disks <= dma_maxpq(device, 0) &&
+ if (unmap && disks <= dma_maxpq(device, 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
struct device *dev = device->dev;
- dma_addr_t *pq = _src[disks-2];
- int i;
+ dma_addr_t pq[2];
+ int i, j = 0, src_cnt = 0;
pr_debug("%s: (async) disks: %d len: %zu\n",
__func__, disks, len);
- if (!P(blocks, disks))
+
+ unmap->len = len;
+ for (i = 0; i < disks-2; i++)
+ if (likely(blocks[i])) {
+ unmap->addr[j] = dma_map_page(dev, blocks[i],
+ offset, len,
+ DMA_TO_DEVICE);
+ coefs[j] = raid6_gfexp[i];
+ unmap->to_cnt++;
+ src_cnt++;
+ j++;
+ }
+
+ if (!P(blocks, disks)) {
+ pq[0] = 0;
dma_flags |= DMA_PREP_PQ_DISABLE_P;
- else
+ } else {
pq[0] = dma_map_page(dev, P(blocks, disks),
offset, len,
DMA_TO_DEVICE);
- if (!Q(blocks, disks))
+ unmap->addr[j++] = pq[0];
+ unmap->to_cnt++;
+ }
+ if (!Q(blocks, disks)) {
+ pq[1] = 0;
dma_flags |= DMA_PREP_PQ_DISABLE_Q;
- else
+ } else {
pq[1] = dma_map_page(dev, Q(blocks, disks),
offset, len,
DMA_TO_DEVICE);
+ unmap->addr[j++] = pq[1];
+ unmap->to_cnt++;
+ }
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
- for (i = 0; i < disks-2; i++)
- if (likely(blocks[i])) {
- dma_src[src_cnt] = dma_map_page(dev, blocks[i],
- offset, len,
- DMA_TO_DEVICE);
- coefs[src_cnt] = raid6_gfexp[i];
- src_cnt++;
- }
-
for (;;) {
- tx = device->device_prep_dma_pq_val(chan, pq, dma_src,
+ tx = device->device_prep_dma_pq_val(chan, pq,
+ unmap->addr,
src_cnt,
coefs,
len, pqres,
@@ -343,6 +353,8 @@ async_syndrome_val(struct page **blocks, unsigned int
offset, int disks,
async_tx_quiesce(>depend_tx);
dma_async_issue_pending(chan);
}
+
+ dma_set_unmap(tx, unmap);
async_tx_submit(chan, tx, submit);
return tx;
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/13] async_xor_val: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
[bzolnier: minor cleanups]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_xor.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index f092fa1..d2cc77d 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -275,18 +275,17 @@ async_xor_val(struct page *dest, struct page **src_list,
unsigned int offset,
struct dma_chan *chan = xor_val_chan(submit, dest, src_list, src_cnt,
len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
- dma_addr_t *dma_src = NULL;
+ struct dmaengine_unmap_data *unmap = NULL;
BUG_ON(src_cnt <= 1);
- if (submit->scribble)
- dma_src = submit->scribble;
- else if (sizeof(dma_addr_t) <= sizeof(struct page *))
- dma_src = (dma_addr_t *) src_list;
+ if (device)
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt,
GFP_NOIO);
- if (dma_src && device && src_cnt <= device->max_xor &&
+ if (unmap && src_cnt <= device->max_xor &&
is_dma_xor_aligned(device, offset, 0, len)) {
- unsigned long dma_prep_flags = 0;
+ unsigned long dma_prep_flags = DMA_COMPL_SKIP_SRC_UNMAP |
+ DMA_COMPL_SKIP_DEST_UNMAP;
int i;
pr_debug("%s: (async) len: %zu\n", __func__, len);
@@ -295,11 +294,15 @@ async_xor_val(struct page *dest, struct page **src_list,
unsigned int offset,
dma_prep_flags |= DMA_PREP_INTERRUPT;
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- for (i = 0; i < src_cnt; i++)
- dma_src[i] = dma_map_page(device->dev, src_list[i],
- offset, len, DMA_TO_DEVICE);
- tx = device->device_prep_dma_xor_val(chan, dma_src, src_cnt,
+ for (i = 0; i < src_cnt; i++) {
+ unmap->addr[i] = dma_map_page(device->dev, src_list[i],
+ offset, len,
DMA_TO_DEVICE);
+ unmap->to_cnt++;
+ }
+ unmap->len = len;
+
+ tx = device->device_prep_dma_xor_val(chan, unmap->addr, src_cnt,
len, result,
dma_prep_flags);
if (unlikely(!tx)) {
@@ -308,11 +311,11 @@ async_xor_val(struct page *dest, struct page **src_list,
unsigned int offset,
while (!tx) {
dma_async_issue_pending(chan);
tx = device->device_prep_dma_xor_val(chan,
- dma_src, src_cnt, len, result,
+ unmap->addr, src_cnt, len, result,
dma_prep_flags);
}
}
-
+ dma_set_unmap(tx, unmap);
async_tx_submit(chan, tx, submit);
} else {
enum async_tx_flags flags_orig = submit->flags;
@@ -334,6 +337,7 @@ async_xor_val(struct page *dest, struct page **src_list,
unsigned int offset,
async_tx_sync_epilog(submit);
submit->flags = flags_orig;
}
+ dmaengine_unmap_put(unmap);
return tx;
}
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/13] dmaengine: remove DMA unmap from drivers
Remove support for DMA unmapping from drivers as it is no longer
needed (DMA core code is now handling it).
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Dan Williams
---
arch/arm/include/asm/hardware/iop3xx-adma.h | 30
arch/arm/include/asm/hardware/iop_adma.h| 4 -
arch/arm/mach-iop13xx/include/mach/adma.h | 26 ---
drivers/dma/amba-pl08x.c| 31
drivers/dma/at_hdmac.c | 25 ---
drivers/dma/dw/core.c | 20 ---
drivers/dma/ep93xx_dma.c| 29 ---
drivers/dma/fsldma.c| 16 --
drivers/dma/ioat/dma.c | 16 --
drivers/dma/ioat/dma.h | 12 --
drivers/dma/ioat/dma_v2.c | 1 -
drivers/dma/ioat/dma_v3.c | 166 -
drivers/dma/iop-adma.c | 96 +-
drivers/dma/mv_xor.c| 44 +
drivers/dma/ppc4xx/adma.c | 269
drivers/dma/timb_dma.c | 36
drivers/dma/txx9dmac.c | 24 ---
17 files changed, 3 insertions(+), 842 deletions(-)
diff --git a/arch/arm/include/asm/hardware/iop3xx-adma.h
b/arch/arm/include/asm/hardware/iop3xx-adma.h
index 9b28f12..240b29e 100644
--- a/arch/arm/include/asm/hardware/iop3xx-adma.h
+++ b/arch/arm/include/asm/hardware/iop3xx-adma.h
@@ -393,36 +393,6 @@ static inline int iop_chan_zero_sum_slot_count(size_t len,
int src_cnt,
return slot_cnt;
}
-static inline int iop_desc_is_pq(struct iop_adma_desc_slot *desc)
-{
- return 0;
-}
-
-static inline u32 iop_desc_get_dest_addr(struct iop_adma_desc_slot *desc,
- struct iop_adma_chan *chan)
-{
- union iop3xx_desc hw_desc = { .ptr = desc->hw_desc, };
-
- switch (chan->device->id) {
- case DMA0_ID:
- case DMA1_ID:
- return hw_desc.dma->dest_addr;
- case AAU_ID:
- return hw_desc.aau->dest_addr;
- default:
- BUG();
- }
- return 0;
-}
-
-
-static inline u32 iop_desc_get_qdest_addr(struct iop_adma_desc_slot *desc,
- struct iop_adma_chan *chan)
-{
- BUG();
- return 0;
-}
-
static inline u32 iop_desc_get_byte_count(struct iop_adma_desc_slot *desc,
struct iop_adma_chan *chan)
{
diff --git a/arch/arm/include/asm/hardware/iop_adma.h
b/arch/arm/include/asm/hardware/iop_adma.h
index 122f86d..250760e 100644
--- a/arch/arm/include/asm/hardware/iop_adma.h
+++ b/arch/arm/include/asm/hardware/iop_adma.h
@@ -82,8 +82,6 @@ struct iop_adma_chan {
* @slot_cnt: total slots used in an transaction (group of operations)
* @slots_per_op: number of slots per operation
* @idx: pool index
- * @unmap_src_cnt: number of xor sources
- * @unmap_len: transaction bytecount
* @tx_list: list of descriptors that are associated with one operation
* @async_tx: support for the async_tx api
* @group_list: list of slots that make up a multi-descriptor transaction
@@ -99,8 +97,6 @@ struct iop_adma_desc_slot {
u16 slot_cnt;
u16 slots_per_op;
u16 idx;
- u16 unmap_src_cnt;
- size_t unmap_len;
struct list_head tx_list;
struct dma_async_tx_descriptor async_tx;
union {
diff --git a/arch/arm/mach-iop13xx/include/mach/adma.h
b/arch/arm/mach-iop13xx/include/mach/adma.h
index 6d3782d..a86fd0e 100644
--- a/arch/arm/mach-iop13xx/include/mach/adma.h
+++ b/arch/arm/mach-iop13xx/include/mach/adma.h
@@ -218,20 +218,6 @@ iop_chan_xor_slot_count(size_t len, int src_cnt, int
*slots_per_op)
#define iop_chan_pq_slot_count iop_chan_xor_slot_count
#define iop_chan_pq_zero_sum_slot_count iop_chan_xor_slot_count
-static inline u32 iop_desc_get_dest_addr(struct iop_adma_desc_slot *desc,
- struct iop_adma_chan *chan)
-{
- struct iop13xx_adma_desc_hw *hw_desc = desc->hw_desc;
- return hw_desc->dest_addr;
-}
-
-static inline u32 iop_desc_get_qdest_addr(struct iop_adma_desc_slot *desc,
- struct iop_adma_chan *chan)
-{
- struct iop13xx_adma_desc_hw *hw_desc = desc->hw_desc;
- return hw_desc->q_dest_addr;
-}
-
static inline u32 iop_desc_get_byte_count(struct iop_adma_desc_slot *desc,
struct iop_adma_chan *chan)
{
@@ -350,18 +336,6 @@ iop_desc_init_pq(struct iop_adma_desc_slot *desc, int
src_cnt,
hw_desc->desc_ctrl = u_desc_ctrl.value;
}
-static inline int iop_desc_is_pq(struct iop_adma_desc_slot *desc)
-{
- struct iop13xx_adma_desc_hw *hw_desc = desc->hw_desc;
- union {
- u32 value;
- struct iop13xx_adma_desc_ctrl field;
- } u_desc_ctrl;
-
-
[PATCH v2 11/13] NTB: convert to dmaengine_unmap_data
Use the generic unmap object to unmap dma buffers. As NTB can be compiled without DMA_ENGINE support add stub functions to for dma_set_unmap(), dmaengine_get_unmap_data() and dmaengine_unmap_put(). Cc: Dan Williams Cc: Vinod Koul Cc: Tomasz Figa Cc: Dave Jiang Cc: Jon Mason Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park --- drivers/ntb/ntb_transport.c | 63 + include/linux/dmaengine.h | 15 +++ 2 files changed, 61 insertions(+), 17 deletions(-) diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c index 12a9e83..fc6bbf1 100644 --- a/drivers/ntb/ntb_transport.c +++ b/drivers/ntb/ntb_transport.c @@ -1034,7 +1034,7 @@ static void ntb_async_rx(struct ntb_queue_entry *entry, void *offset, struct dma_chan *chan = qp->dma_chan; struct dma_device *device; size_t pay_off, buff_off; - dma_addr_t src, dest; + struct dmaengine_unmap_data *unmap; dma_cookie_t cookie; void *buf = entry->buf; unsigned long flags; @@ -1054,27 +1054,41 @@ static void ntb_async_rx(struct ntb_queue_entry *entry, void *offset, if (!is_dma_copy_aligned(device, pay_off, buff_off, len)) goto err1; - dest = dma_map_single(device->dev, buf, len, DMA_FROM_DEVICE); - if (dma_mapping_error(device->dev, dest)) + unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO); + if (!unmap) goto err1; - src = dma_map_single(device->dev, offset, len, DMA_TO_DEVICE); - if (dma_mapping_error(device->dev, src)) + unmap->addr[0] = dma_map_page(device->dev, virt_to_page(offset), + pay_off, len, DMA_TO_DEVICE); + if (dma_mapping_error(device->dev, unmap->addr[0])) goto err2; - flags = DMA_COMPL_DEST_UNMAP_SINGLE | DMA_COMPL_SRC_UNMAP_SINGLE | + unmap->to_cnt = 1; + + unmap->addr[1] = dma_map_page(device->dev, virt_to_page(buf), + buff_off, len, DMA_FROM_DEVICE); + if (dma_mapping_error(device->dev, unmap->addr[1])) + goto err2; + + unmap->from_cnt = 1; + + flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP | DMA_PREP_INTERRUPT; - txd = device->device_prep_dma_memcpy(chan, dest, src, len, flags); + txd = device->device_prep_dma_memcpy(chan, unmap->addr[1], +unmap->addr[0], len, flags); if (!txd) - goto err3; + goto err2; txd->callback = ntb_rx_copy_callback; txd->callback_param = entry; + dma_set_unmap(txd, unmap); cookie = dmaengine_submit(txd); if (dma_submit_error(cookie)) goto err3; + dmaengine_unmap_put(unmap); + qp->last_cookie = cookie; qp->rx_async++; @@ -1082,9 +1096,9 @@ static void ntb_async_rx(struct ntb_queue_entry *entry, void *offset, return; err3: - dma_unmap_single(device->dev, src, len, DMA_TO_DEVICE); + dmaengine_unmap_put(unmap); err2: - dma_unmap_single(device->dev, dest, len, DMA_FROM_DEVICE); + dmaengine_unmap_put(unmap); err1: /* If the callbacks come out of order, the writing of the index to the * last completed will be out of order. This may result in the @@ -1245,7 +1259,8 @@ static void ntb_async_tx(struct ntb_transport_qp *qp, struct dma_chan *chan = qp->dma_chan; struct dma_device *device; size_t dest_off, buff_off; - dma_addr_t src, dest; + struct dmaengine_unmap_data *unmap; + dma_addr_t dest; dma_cookie_t cookie; void __iomem *offset; size_t len = entry->len; @@ -1273,28 +1288,42 @@ static void ntb_async_tx(struct ntb_transport_qp *qp, if (!is_dma_copy_aligned(device, buff_off, dest_off, len)) goto err; - src = dma_map_single(device->dev, buf, len, DMA_TO_DEVICE); - if (dma_mapping_error(device->dev, src)) + unmap = dmaengine_get_unmap_data(device->dev, 1, GFP_NOIO); + if (!unmap) goto err; - flags = DMA_COMPL_SRC_UNMAP_SINGLE | DMA_PREP_INTERRUPT; - txd = device->device_prep_dma_memcpy(chan, dest, src, len, flags); + unmap->addr[0] = dma_map_page(device->dev, virt_to_page(buf), + buff_off, len, DMA_TO_DEVICE); + if (dma_mapping_error(device->dev, unmap->addr[0])) + goto err1; + + unmap->to_cnt = 1; + + flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP | + DMA_PREP_INTERRUPT; + txd = device->device_prep_dma_memcpy(chan, dest, unmap->addr[0], len, + flags); if (!txd) goto err1; txd->callback = ntb_tx_copy_callback; txd->callback_param = entry; +
[PATCH v2 13/13] dmaengine: remove DMA unmap flags
Remove no longer needed DMA unmap flags:
- DMA_COMPL_SKIP_SRC_UNMAP
- DMA_COMPL_SKIP_DEST_UNMAP
- DMA_COMPL_SRC_UNMAP_SINGLE
- DMA_COMPL_DEST_UNMAP_SINGLE
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Dan Williams
---
crypto/async_tx/async_memcpy.c | 3 +--
crypto/async_tx/async_pq.c | 1 -
crypto/async_tx/async_raid6_recov.c | 8 ++--
crypto/async_tx/async_xor.c | 6 ++
drivers/ata/pata_arasan_cf.c | 3 +--
drivers/dma/dmaengine.c | 3 +--
drivers/dma/dmatest.c| 3 +--
drivers/dma/ioat/dma.c | 3 +--
drivers/dma/ioat/dma_v3.c| 12 +++-
drivers/media/platform/m2m-deinterlace.c | 3 +--
drivers/media/platform/timblogiw.c | 2 +-
drivers/misc/carma/carma-fpga.c | 3 +--
drivers/mtd/nand/atmel_nand.c| 3 +--
drivers/mtd/nand/fsmc_nand.c | 2 --
drivers/net/ethernet/micrel/ks8842.c | 6 ++
drivers/ntb/ntb_transport.c | 3 +--
drivers/spi/spi-dw-mid.c | 4 ++--
include/linux/dmaengine.h| 18 --
18 files changed, 25 insertions(+), 61 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index 7275021..f8c0b8d 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -56,8 +56,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len))
{
- unsigned long dma_prep_flags = DMA_COMPL_SKIP_SRC_UNMAP |
- DMA_COMPL_SKIP_DEST_UNMAP;
+ unsigned long dma_prep_flags = 0;
if (submit->cb_fn)
dma_prep_flags |= DMA_PREP_INTERRUPT;
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 4126b56..d05327c 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,7 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
- dma_flags |= DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
diff --git a/crypto/async_tx/async_raid6_recov.c
b/crypto/async_tx/async_raid6_recov.c
index a3a72a7..934a849 100644
--- a/crypto/async_tx/async_raid6_recov.c
+++ b/crypto/async_tx/async_raid6_recov.c
@@ -47,9 +47,7 @@ async_sum_product(struct page *dest, struct page **srcs,
unsigned char *coef,
struct device *dev = dma->dev;
dma_addr_t pq[2];
struct dma_async_tx_descriptor *tx;
- enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
- DMA_COMPL_SKIP_DEST_UNMAP |
- DMA_PREP_PQ_DISABLE_P;
+ enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
@@ -113,9 +111,7 @@ async_mult(struct page *dest, struct page *src, u8 coef,
size_t len,
dma_addr_t dma_dest[2];
struct device *dev = dma->dev;
struct dma_async_tx_descriptor *tx;
- enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
- DMA_COMPL_SKIP_DEST_UNMAP |
- DMA_PREP_PQ_DISABLE_P;
+ enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index d2cc77d..3c562f5 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -41,7 +41,7 @@ do_async_xor(struct dma_chan *chan, struct
dmaengine_unmap_data *unmap,
dma_async_tx_callback cb_fn_orig = submit->cb_fn;
void *cb_param_orig = submit->cb_param;
enum async_tx_flags flags_orig = submit->flags;
- enum dma_ctrl_flags dma_flags;
+ enum dma_ctrl_flags dma_flags = 0;
int src_cnt = unmap->to_cnt;
int xor_src_cnt;
dma_addr_t dma_dest = unmap->addr[unmap->to_cnt];
@@ -55,7 +55,6 @@ do_async_xor(struct dma_chan *chan, struct
dmaengine_unmap_data *unmap,
/* if we are submitting additional xors, leave the chain open
* and clear the callback parameters
*/
- dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
DMA_COMPL_SKIP_DEST_UNMAP;
if (src_cnt > xor_src_cnt) {
submit->flags &=
Re: [PATCH v3 0/3] New descriptor-based GPIO interface
On Fri, Oct 18, 2013 at 4:23 AM, Linus Walleij wrote: > On Thu, Oct 17, 2013 at 7:21 PM, Alexandre Courbot > wrote: > >> Hi Linus, >> >> This version should merge as-is in your tree (I hope!). A patch for >> documentation will follow soon. >> >> Changes since v2: >> - rebased on top of Linus' for-next branch >> - exported new gpiod_(un)lock_as_irq() functions in driver.h >> - squashed a fix for a compilation error > > Thanks, let's see if I can get this into v3.13, right now it's > unclear if I'll dare to do this. These do not apply right off > as it requires the late fixes to the gpiod code which currently > are in Torvalds' tree and on my fixes branch, so I'll merge in > v3.12-rc6 as it arrives, and then attempt to apply this on > top, but I don't know if I dare to do this so late. > > The outage of linux-next also contributes to this situation. > > We might have to take this as the first thing after the merge > window and targeted for v3.14. No particular pressure from my side to get this in 3.13. Do for the best, and don't hesitate to delay them to 3.14 if you feel they are not tested enough. I'll already feel better once I know they are under your tree. ;) Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/13] async_pq: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
[bzolnier: keep temporary dma_dest array in do_async_gen_syndrome()]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_pq.c | 117 +
drivers/dma/dmaengine.c| 5 +-
2 files changed, 69 insertions(+), 53 deletions(-)
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 91d5d38..8cdbf33 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -46,49 +46,25 @@ static struct page *pq_scribble_page;
* do_async_gen_syndrome - asynchronously calculate P and/or Q
*/
static __async_inline struct dma_async_tx_descriptor *
-do_async_gen_syndrome(struct dma_chan *chan, struct page **blocks,
- const unsigned char *scfs, unsigned int offset, int disks,
- size_t len, dma_addr_t *dma_src,
+do_async_gen_syndrome(struct dma_chan *chan,
+ const unsigned char *scfs, int disks,
+ struct dmaengine_unmap_data *unmap,
+ enum dma_ctrl_flags dma_flags,
struct async_submit_ctl *submit)
{
struct dma_async_tx_descriptor *tx = NULL;
struct dma_device *dma = chan->device;
- enum dma_ctrl_flags dma_flags = 0;
enum async_tx_flags flags_orig = submit->flags;
dma_async_tx_callback cb_fn_orig = submit->cb_fn;
dma_async_tx_callback cb_param_orig = submit->cb_param;
int src_cnt = disks - 2;
- unsigned char coefs[src_cnt];
unsigned short pq_src_cnt;
dma_addr_t dma_dest[2];
int src_off = 0;
- int idx;
- int i;
- /* DMAs use destinations as sources, so use BIDIRECTIONAL mapping */
- if (P(blocks, disks))
- dma_dest[0] = dma_map_page(dma->dev, P(blocks, disks), offset,
- len, DMA_BIDIRECTIONAL);
- else
- dma_flags |= DMA_PREP_PQ_DISABLE_P;
- if (Q(blocks, disks))
- dma_dest[1] = dma_map_page(dma->dev, Q(blocks, disks), offset,
- len, DMA_BIDIRECTIONAL);
- else
- dma_flags |= DMA_PREP_PQ_DISABLE_Q;
-
- /* convert source addresses being careful to collapse 'empty'
-* sources and update the coefficients accordingly
-*/
- for (i = 0, idx = 0; i < src_cnt; i++) {
- if (blocks[i] == NULL)
- continue;
- dma_src[idx] = dma_map_page(dma->dev, blocks[i], offset, len,
- DMA_TO_DEVICE);
- coefs[idx] = scfs[i];
- idx++;
- }
- src_cnt = idx;
+ dma_flags |= DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
+ if (submit->flags & ASYNC_TX_FENCE)
+ dma_flags |= DMA_PREP_FENCE;
while (src_cnt > 0) {
submit->flags = flags_orig;
@@ -100,28 +76,25 @@ do_async_gen_syndrome(struct dma_chan *chan, struct page
**blocks,
if (src_cnt > pq_src_cnt) {
submit->flags &= ~ASYNC_TX_ACK;
submit->flags |= ASYNC_TX_FENCE;
- dma_flags |= DMA_COMPL_SKIP_DEST_UNMAP;
submit->cb_fn = NULL;
submit->cb_param = NULL;
} else {
- dma_flags &= ~DMA_COMPL_SKIP_DEST_UNMAP;
submit->cb_fn = cb_fn_orig;
submit->cb_param = cb_param_orig;
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
- if (submit->flags & ASYNC_TX_FENCE)
- dma_flags |= DMA_PREP_FENCE;
- /* Since we have clobbered the src_list we are committed
-* to doing this asynchronously. Drivers force forward
-* progress in case they can not provide a descriptor
+ /* Drivers force forward progress in case they can not provide
+* a descriptor
*/
for (;;) {
+ dma_dest[0] = unmap->addr[disks - 2];
+ dma_dest[1] = unmap->addr[disks - 1];
tx = dma->device_prep_dma_pq(chan, dma_dest,
-_src[src_off],
+>addr[src_off],
pq_src_cnt,
-[src_off], len,
+[src_off], unmap->len,
dma_flags);
if
Re: [PATCH v2 2/2] x86, apic: Disable BSP if boot cpu is AP
On Wed, Oct 16, 2013 at 10:26:44AM +0900, HATAYAMA Daisuke wrote:
[..]
> >I am wondering if there is any attribute of cpu which we can pass to
> >second kernel on command line. And tell second kernel not to bring up
> >that specific cpu. (Say exclude_cpu=)? If this works, then
> >if ACPI or other mechanism don't report BSP, we could possibly assume
> >that cpu 0 is BSP and ask second kernel to not try to boot it.
> >
>
> I've come up with similar idea. If there's such kernel option, rest of
> the processing can be implemented in user-land, i.e., get apicid of
> BSP from /proc/cpuid and set it in kernel command line of 2nd kernel.
> What kexec-tools should do on fedora/RHEL? Also, this idea covers SFI
> and device tree.
>
> The reason why I didn't choose such idea was first passing the value
> via command-line seems rather ad-hoc.
We do so many things using command line. So telling kernel not to boot
certain cpus seems ok to me.
> The second reason is that in any
> case it's compromised design. Rigorously, we cannot get correct mapping
> of apicid to {BSP, APIC} at the 1st kernel. That is, there's a class of
> the bugs that affect BSP flag of each processor. For example, on
> catastrophic state, all the cpus can have BSP flag on the 2nd kernel due
> to wrmsr instructions generated by the bug causing crash. In this sense,
> current implementation is less reliable than max_cpus=1 case.
>
> If addressing this rigorously, for example, we need to check status of
> BSP flag between 1st kernel and 2nd kernel to keep processor with BSP
> flag unique, exclude cpus in catastrophic state that are not checked,
> and to tell the 2nd kernel which cpu can be wake up.
Ok, for the time being let us not do any comparision with maxcpus=1 or
nr_cpus=1 because we know that's the most robust thing to do.
For the case where we want to bring up more than one cpu in second kernel,
there seems to be two problems.
- ACPI tables or other tables might not report which is BSP. In that
case we might try to bring up BSP and crash the system.
- Due to malicious wrmsr, more than one cpu might claim being BSP. In that
case the cpu we are crashing on will think it is BSP and it can safely
bring up other cpus.
If we start sending a mask of cpus which should not be brought up in
second kernel, then it would not matter whether BSP flag in MSR is set
or not. Isn't it? And that will solve the second issue.
And if ACPI tables don't report which one is BSP, user space can first
try to look at BSP flags of processors (may be this can be reported
in /proc/cpuinfo?) and if no one has BSP flag set, then assume cpu 0
is BSP.
So to me it looks like passing which cpus to not bring up to second kernel
is more resilient approach. Isn't it?
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/13] async_raid6_recov: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
[bzolnier: keep temporary dma_dest array in async_mult()]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_raid6_recov.c | 69 ++---
1 file changed, 49 insertions(+), 20 deletions(-)
diff --git a/crypto/async_tx/async_raid6_recov.c
b/crypto/async_tx/async_raid6_recov.c
index a9f08a6..a3a72a7 100644
--- a/crypto/async_tx/async_raid6_recov.c
+++ b/crypto/async_tx/async_raid6_recov.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
static struct dma_async_tx_descriptor *
async_sum_product(struct page *dest, struct page **srcs, unsigned char *coef,
@@ -34,35 +35,47 @@ async_sum_product(struct page *dest, struct page **srcs,
unsigned char *coef,
struct dma_chan *chan = async_tx_find_channel(submit, DMA_PQ,
, 1, srcs, 2, len);
struct dma_device *dma = chan ? chan->device : NULL;
+ struct dmaengine_unmap_data *unmap = NULL;
const u8 *amul, *bmul;
u8 ax, bx;
u8 *a, *b, *c;
- if (dma) {
- dma_addr_t dma_dest[2];
- dma_addr_t dma_src[2];
+ if (dma)
+ unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOIO);
+
+ if (unmap) {
struct device *dev = dma->dev;
+ dma_addr_t pq[2];
struct dma_async_tx_descriptor *tx;
- enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
+ enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
+ DMA_COMPL_SKIP_DEST_UNMAP |
+ DMA_PREP_PQ_DISABLE_P;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
- dma_dest[1] = dma_map_page(dev, dest, 0, len,
DMA_BIDIRECTIONAL);
- dma_src[0] = dma_map_page(dev, srcs[0], 0, len, DMA_TO_DEVICE);
- dma_src[1] = dma_map_page(dev, srcs[1], 0, len, DMA_TO_DEVICE);
- tx = dma->device_prep_dma_pq(chan, dma_dest, dma_src, 2, coef,
+ unmap->addr[0] = dma_map_page(dev, srcs[0], 0, len,
DMA_TO_DEVICE);
+ unmap->addr[1] = dma_map_page(dev, srcs[1], 0, len,
DMA_TO_DEVICE);
+ unmap->to_cnt = 2;
+
+ unmap->addr[2] = dma_map_page(dev, dest, 0, len,
DMA_BIDIRECTIONAL);
+ unmap->bidi_cnt = 1;
+ /* engine only looks at Q, but expects it to follow P */
+ pq[1] = unmap->addr[2];
+
+ unmap->len = len;
+ tx = dma->device_prep_dma_pq(chan, pq, unmap->addr, 2, coef,
len, dma_flags);
if (tx) {
+ dma_set_unmap(tx, unmap);
async_tx_submit(chan, tx, submit);
+ dmaengine_unmap_put(unmap);
return tx;
}
/* could not get a descriptor, unmap and fall through to
* the synchronous path
*/
- dma_unmap_page(dev, dma_dest[1], len, DMA_BIDIRECTIONAL);
- dma_unmap_page(dev, dma_src[0], len, DMA_TO_DEVICE);
- dma_unmap_page(dev, dma_src[1], len, DMA_TO_DEVICE);
+ dmaengine_unmap_put(unmap);
}
/* run the operation synchronously */
@@ -89,23 +102,40 @@ async_mult(struct page *dest, struct page *src, u8 coef,
size_t len,
struct dma_chan *chan = async_tx_find_channel(submit, DMA_PQ,
, 1, , 1, len);
struct dma_device *dma = chan ? chan->device : NULL;
+ struct dmaengine_unmap_data *unmap = NULL;
const u8 *qmul; /* Q multiplier table */
u8 *d, *s;
- if (dma) {
+ if (dma)
+ unmap = dmaengine_get_unmap_data(dma->dev, 3, GFP_NOIO);
+
+ if (unmap) {
dma_addr_t dma_dest[2];
- dma_addr_t dma_src[1];
struct device *dev = dma->dev;
struct dma_async_tx_descriptor *tx;
- enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
+ enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
+ DMA_COMPL_SKIP_DEST_UNMAP |
+ DMA_PREP_PQ_DISABLE_P;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
- dma_dest[1] = dma_map_page(dev, dest, 0, len,
DMA_BIDIRECTIONAL);
- dma_src[0] = dma_map_page(dev, src, 0, len, DMA_TO_DEVICE);
- tx = dma->device_prep_dma_pq(chan, dma_dest, dma_src,
[PATCH v2 06/13] async_xor: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Later we can push this unmap object up to the raid layer and get rid of
the 'scribble' parameter.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
[bzolnier: minor cleanups]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_xor.c | 95 -
1 file changed, 51 insertions(+), 44 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 8ade0a0..f092fa1 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -33,48 +33,32 @@
/* do_async_xor - dma map the pages and perform the xor with an engine */
static __async_inline struct dma_async_tx_descriptor *
-do_async_xor(struct dma_chan *chan, struct page *dest, struct page **src_list,
-unsigned int offset, int src_cnt, size_t len, dma_addr_t *dma_src,
+do_async_xor(struct dma_chan *chan, struct dmaengine_unmap_data *unmap,
struct async_submit_ctl *submit)
{
struct dma_device *dma = chan->device;
struct dma_async_tx_descriptor *tx = NULL;
- int src_off = 0;
- int i;
dma_async_tx_callback cb_fn_orig = submit->cb_fn;
void *cb_param_orig = submit->cb_param;
enum async_tx_flags flags_orig = submit->flags;
enum dma_ctrl_flags dma_flags;
- int xor_src_cnt = 0;
- dma_addr_t dma_dest;
-
- /* map the dest bidrectional in case it is re-used as a source */
- dma_dest = dma_map_page(dma->dev, dest, offset, len, DMA_BIDIRECTIONAL);
- for (i = 0; i < src_cnt; i++) {
- /* only map the dest once */
- if (!src_list[i])
- continue;
- if (unlikely(src_list[i] == dest)) {
- dma_src[xor_src_cnt++] = dma_dest;
- continue;
- }
- dma_src[xor_src_cnt++] = dma_map_page(dma->dev, src_list[i],
offset,
- len, DMA_TO_DEVICE);
- }
- src_cnt = xor_src_cnt;
+ int src_cnt = unmap->to_cnt;
+ int xor_src_cnt;
+ dma_addr_t dma_dest = unmap->addr[unmap->to_cnt];
+ dma_addr_t *src_list = unmap->addr;
while (src_cnt) {
+ dma_addr_t tmp;
+
submit->flags = flags_orig;
- dma_flags = 0;
xor_src_cnt = min(src_cnt, (int)dma->max_xor);
- /* if we are submitting additional xors, leave the chain open,
-* clear the callback parameters, and leave the destination
-* buffer mapped
+ /* if we are submitting additional xors, leave the chain open
+* and clear the callback parameters
*/
+ dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
DMA_COMPL_SKIP_DEST_UNMAP;
if (src_cnt > xor_src_cnt) {
submit->flags &= ~ASYNC_TX_ACK;
submit->flags |= ASYNC_TX_FENCE;
- dma_flags = DMA_COMPL_SKIP_DEST_UNMAP;
submit->cb_fn = NULL;
submit->cb_param = NULL;
} else {
@@ -85,12 +69,18 @@ do_async_xor(struct dma_chan *chan, struct page *dest,
struct page **src_list,
dma_flags |= DMA_PREP_INTERRUPT;
if (submit->flags & ASYNC_TX_FENCE)
dma_flags |= DMA_PREP_FENCE;
- /* Since we have clobbered the src_list we are committed
-* to doing this asynchronously. Drivers force forward progress
-* in case they can not provide a descriptor
+
+ /* Drivers force forward progress in case they can not provide a
+* descriptor
*/
- tx = dma->device_prep_dma_xor(chan, dma_dest, _src[src_off],
- xor_src_cnt, len, dma_flags);
+ tmp = src_list[0];
+ if (src_list > unmap->addr)
+ src_list[0] = dma_dest;
+ tx = dma->device_prep_dma_xor(chan, dma_dest, src_list,
+ xor_src_cnt, unmap->len,
+ dma_flags);
+ src_list[0] = tmp;
+
if (unlikely(!tx))
async_tx_quiesce(>depend_tx);
@@ -99,22 +89,21 @@ do_async_xor(struct dma_chan *chan, struct page *dest,
struct page **src_list,
while (unlikely(!tx)) {
dma_async_issue_pending(chan);
tx = dma->device_prep_dma_xor(chan, dma_dest,
- _src[src_off],
- xor_src_cnt, len,
+
[PATCH v2 05/13] async_memcpy: convert to dmaengine_unmap_data
From: Dan Williams
Use the generic unmap object to unmap dma buffers.
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Reported-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Dan Williams
[bzolnier: add missing unmap->len initialization]
[bzolnier: fix whitespace damage]
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
crypto/async_tx/async_memcpy.c | 40 +++-
drivers/dma/dmaengine.c| 3 ++-
include/linux/dmaengine.h | 2 ++
3 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index 9e62fef..7275021 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -50,33 +50,37 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
, 1, , 1, len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
+ struct dmaengine_unmap_data *unmap = NULL;
- if (device && is_dma_copy_aligned(device, src_offset, dest_offset,
len)) {
- dma_addr_t dma_dest, dma_src;
- unsigned long dma_prep_flags = 0;
+ if (device)
+ unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
+
+ if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len))
{
+ unsigned long dma_prep_flags = DMA_COMPL_SKIP_SRC_UNMAP |
+ DMA_COMPL_SKIP_DEST_UNMAP;
if (submit->cb_fn)
dma_prep_flags |= DMA_PREP_INTERRUPT;
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- dma_dest = dma_map_page(device->dev, dest, dest_offset, len,
- DMA_FROM_DEVICE);
-
- dma_src = dma_map_page(device->dev, src, src_offset, len,
- DMA_TO_DEVICE);
-
- tx = device->device_prep_dma_memcpy(chan, dma_dest, dma_src,
- len, dma_prep_flags);
- if (!tx) {
- dma_unmap_page(device->dev, dma_dest, len,
- DMA_FROM_DEVICE);
- dma_unmap_page(device->dev, dma_src, len,
- DMA_TO_DEVICE);
- }
+
+ unmap->to_cnt = 1;
+ unmap->addr[0] = dma_map_page(device->dev, src, src_offset, len,
+ DMA_TO_DEVICE);
+ unmap->from_cnt = 1;
+ unmap->addr[1] = dma_map_page(device->dev, dest, dest_offset,
len,
+ DMA_FROM_DEVICE);
+ unmap->len = len;
+
+ tx = device->device_prep_dma_memcpy(chan, unmap->addr[1],
+ unmap->addr[0], len,
+ dma_prep_flags);
}
if (tx) {
pr_debug("%s: (async) len: %zu\n", __func__, len);
+
+ dma_set_unmap(tx, unmap);
async_tx_submit(chan, tx, submit);
} else {
void *dest_buf, *src_buf;
@@ -96,6 +100,8 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
async_tx_sync_epilog(submit);
}
+ dmaengine_unmap_put(unmap);
+
return tx;
}
EXPORT_SYMBOL_GPL(async_memcpy);
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index e721a1c..54138b5 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1009,7 +1009,7 @@ static int __init dmaengine_init_unmap_pool(void)
return -ENOMEM;
}
-static struct dmaengine_unmap_data *
+struct dmaengine_unmap_data *
dmaengine_get_unmap_data(struct device *dev, int nr, gfp_t flags)
{
struct dmaengine_unmap_data *unmap;
@@ -1024,6 +1024,7 @@ dmaengine_get_unmap_data(struct device *dev, int nr,
gfp_t flags)
return unmap;
}
+EXPORT_SYMBOL(dmaengine_get_unmap_data);
/**
* dma_async_memcpy_pg_to_pg - offloaded copy from page to page
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 2fe855a..dc98bc5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -464,6 +464,8 @@ static inline void dma_set_unmap(struct
dma_async_tx_descriptor *tx,
tx->unmap = unmap;
}
+struct dmaengine_unmap_data *
+dmaengine_get_unmap_data(struct device *dev, int nr, gfp_t flags);
void dmaengine_unmap_put(struct dmaengine_unmap_data *unmap);
static inline void dma_descriptor_unmap(struct dma_async_tx_descriptor *tx)
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v2 02/13] dmaengine: consolidate memcpy apis
From: Dan Williams
Copying from page to page (dma_async_memcpy_pg_to_pg) is the superset,
make the other two apis use that one in preparation for providing a
common dma unmap implementation. The common implementation just wants
to assume all buffers are mapped with dma_map_page().
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Signed-off-by: Dan Williams
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/dma/dmaengine.c | 137
1 file changed, 45 insertions(+), 92 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 9162ac8..bbc89df 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -902,20 +902,23 @@ void dma_async_device_unregister(struct dma_device
*device)
EXPORT_SYMBOL(dma_async_device_unregister);
/**
- * dma_async_memcpy_buf_to_buf - offloaded copy between virtual addresses
+ * dma_async_memcpy_pg_to_pg - offloaded copy from page to page
* @chan: DMA channel to offload copy to
- * @dest: destination address (virtual)
- * @src: source address (virtual)
+ * @dest_pg: destination page
+ * @dest_off: offset in page to copy to
+ * @src_pg: source page
+ * @src_off: offset in page to copy from
* @len: length
*
- * Both @dest and @src must be mappable to a bus address according to the
- * DMA mapping API rules for streaming mappings.
- * Both @dest and @src must stay memory resident (kernel memory or locked
- * user space pages).
+ * Both @dest_page/@dest_off and @src_page/@src_off must be mappable to a bus
+ * address according to the DMA mapping API rules for streaming mappings.
+ * Both @dest_page/@dest_off and @src_page/@src_off must stay memory resident
+ * (kernel memory or locked user space pages).
*/
dma_cookie_t
-dma_async_memcpy_buf_to_buf(struct dma_chan *chan, void *dest,
- void *src, size_t len)
+dma_async_memcpy_pg_to_pg(struct dma_chan *chan, struct page *dest_pg,
+ unsigned int dest_off, struct page *src_pg, unsigned int src_off,
+ size_t len)
{
struct dma_device *dev = chan->device;
struct dma_async_tx_descriptor *tx;
@@ -923,16 +926,15 @@ dma_async_memcpy_buf_to_buf(struct dma_chan *chan, void
*dest,
dma_cookie_t cookie;
unsigned long flags;
- dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE);
- dma_dest = dma_map_single(dev->dev, dest, len, DMA_FROM_DEVICE);
- flags = DMA_CTRL_ACK |
- DMA_COMPL_SRC_UNMAP_SINGLE |
- DMA_COMPL_DEST_UNMAP_SINGLE;
+ dma_src = dma_map_page(dev->dev, src_pg, src_off, len, DMA_TO_DEVICE);
+ dma_dest = dma_map_page(dev->dev, dest_pg, dest_off, len,
+ DMA_FROM_DEVICE);
+ flags = DMA_CTRL_ACK;
tx = dev->device_prep_dma_memcpy(chan, dma_dest, dma_src, len, flags);
if (!tx) {
- dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE);
- dma_unmap_single(dev->dev, dma_dest, len, DMA_FROM_DEVICE);
+ dma_unmap_page(dev->dev, dma_src, len, DMA_TO_DEVICE);
+ dma_unmap_page(dev->dev, dma_dest, len, DMA_FROM_DEVICE);
return -ENOMEM;
}
@@ -946,6 +948,29 @@ dma_async_memcpy_buf_to_buf(struct dma_chan *chan, void
*dest,
return cookie;
}
+EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
+
+/**
+ * dma_async_memcpy_buf_to_buf - offloaded copy between virtual addresses
+ * @chan: DMA channel to offload copy to
+ * @dest: destination address (virtual)
+ * @src: source address (virtual)
+ * @len: length
+ *
+ * Both @dest and @src must be mappable to a bus address according to the
+ * DMA mapping API rules for streaming mappings.
+ * Both @dest and @src must stay memory resident (kernel memory or locked
+ * user space pages).
+ */
+dma_cookie_t
+dma_async_memcpy_buf_to_buf(struct dma_chan *chan, void *dest,
+ void *src, size_t len)
+{
+ return dma_async_memcpy_pg_to_pg(chan, virt_to_page(dest),
+(unsigned long) dest & ~PAGE_MASK,
+virt_to_page(src),
+(unsigned long) src & ~PAGE_MASK, len);
+}
EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
/**
@@ -963,86 +988,14 @@ EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
*/
dma_cookie_t
dma_async_memcpy_buf_to_pg(struct dma_chan *chan, struct page *page,
- unsigned int offset, void *kdata, size_t len)
+ unsigned int offset, void *kdata, size_t len)
{
- struct dma_device *dev = chan->device;
- struct dma_async_tx_descriptor *tx;
- dma_addr_t dma_dest, dma_src;
- dma_cookie_t cookie;
- unsigned long flags;
-
- dma_src = dma_map_single(dev->dev, kdata, len, DMA_TO_DEVICE);
- dma_dest = dma_map_page(dev->dev, page, offset, len, DMA_FROM_DEVICE);
- flags = DMA_CTRL_ACK |
[PATCH v2 01/13] dmatest: make driver unmap also source buffers by itself
Make the driver DMA unmap also source buffers by itself
(currently it DMA unmaps only destination buffers) as
a preparation for introducing generic 'ummap' data.
Cc: Dan Williams
Cc: Vinod Koul
Cc: Tomasz Figa
Cc: Dave Jiang
Cc: Andy Shevchenko
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
drivers/dma/dmatest.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index 92f796c..f4a2a25 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -597,11 +597,10 @@ static int dmatest_func(void *data)
set_user_nice(current, 10);
/*
-* src buffers are freed by the DMAEngine code with dma_unmap_single()
-* dst buffers are freed by ourselves below
+* src and dst buffers are freed by ourselves below
*/
- flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT
- | DMA_COMPL_SKIP_DEST_UNMAP | DMA_COMPL_SRC_UNMAP_SINGLE;
+ flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT |
+ DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
while (!kthread_should_stop()
&& !(params->iterations && total_tests >= params->iterations)) {
@@ -750,7 +749,8 @@ static int dmatest_func(void *data)
continue;
}
- /* Unmap by myself (see DMA_COMPL_SKIP_DEST_UNMAP above) */
+ /* Unmap by myself */
+ unmap_src(dev->dev, dma_srcs, len, src_cnt);
unmap_dst(dev->dev, dma_dsts, params->buf_size, dst_cnt);
error_count = 0;
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI/Power: Check physical device's runtime pm status before requesting to resume it
On Friday, October 18, 2013 09:05:13 PM Lan Tianyu wrote: > On 10/17/2013 07:38 PM, Rafael J. Wysocki wrote: > >>> Unfortunately, I don't see how we can fix this race in a > >>> satisfactory way and I'm starting to think that the whole > >>> resuming of dependent devices may be a bad idea. > >>> > >>> IIRC, the original concern was that devices may end up in > >>> D0-uninitialized if we don't do that, but then whoever > >>> turned the power resource on will probably turn if off at > >>> one point anyway, so they will be in that state > >>> temporarily. In other words, in addition to the fact > >>> that this is racy, there even is no reason to do it. > >>> > >>> I'll send a patch to rip off that stuff later today. > >>> > >>> Currently, dropping it should be the better choice but I think we > >>> still need to resolve the D0-uninitialized problem, right? > > Why do you think it is a problem in the first place? Those devices > > will not be accessed while in that state (unless there's a bug > > somewhere). > > > > Yes, those devices will not be accessed but they will continue to stay > D0-uninitiallized without any users before next resume and suspend. PM > core and device driver still think they are in the lower power state. > > At this point, it seems these devices should be put into lower power > state(E.G D3hot) than D0-uninitiallized. > > E.G, two devices share one power resource. After they are suspended and > power resource turns off, one device is resumed and power resource turns > on. The other device will remain D0-uninitallized until there are resume > and suspend for it. That's not correct. If the device that has been resumed is now suspended again, that will cause the power resource to go off again and the other device will not stay in D0-uninitialized. > It may consume more power than lowest power state it can reach at that point. I don't see a compelling case for that. The only situation of interest is if A and B share a power resource, they both are suspended to start with, so the power resource is off, and then A is resumed and not suspended again for a relatively long time. In that case B *may* be in D0-uninitialized although it could go into D3hot if it were resumed and suspended. Now there's a question of timing, because the resume and suspend of B is only beneficial if it would stay in D0-uninitialized long enough and we can't say in advance when A is going to be suspended again. Moreover, we don't really know what state B is in, because "power restored" need not automatically mean "clock enabled" etc. for various kinds of devices. I think the whole problem is highly theoretical and really only affects PCI where "power restored" pretty much means "reset". And I am yet to see a system where it actually matters. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: kirkwood: remove lagacy clk workarounds
On 10/18/2013 07:27 PM, Sebastian Hesselbarth wrote: On 10/18/2013 06:17 PM, Ezequiel Garcia wrote: On Fri, Oct 18, 2013 at 10:47:41AM -0400, Jason Cooper wrote: On Fri, Oct 18, 2013 at 01:54:13PM +0200, Sebastian Hesselbarth wrote: With legacy devices converted to DT and a proper ethernet MAC workaround, we can now remove the clk workarounds for legacy devices. While at it, also cleanup the list of includes. Signed-off-by: Sebastian Hesselbarth --- As a follow-up patch for latest mvebu PRs, this patch is based on git://git.infradead.org/linux-mvebu.git tags/soc-3.13-2 Cc: Jason Cooper Cc: Andrew Lunn Cc: Russell King Cc: Kevin Hilman Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/mach-kirkwood/board-dt.c | 42 ++-- 1 files changed, 3 insertions(+), 39 deletions(-) Applied to mvebu/soc Weird: I've tried to do this clean-up myself and my usual tests with network built as a module failed somehow. Maybe I missed something and did something stupid? Ezequiel, you need commits b5d82db net: mv643xx_eth: fix missing device_node for port devices f564412 net: mv643xx_eth: fix orphaned statistics timer crash 041b4dd net: mv643xx_eth: update statistics timer from timer context only from git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master Those are the three net driver fixes and have not yet been pulled into mainline linux. Can you re-test with those three applied (or you can just merge in above master)? I am compiling right now and will report. With mvebu/for-next and net/master merged in, modular mvmdio and mv643xx_eth on Kirkwood Dockstar: Tested-by: Sebastian Hesselbarth IOW, works. I hope you can confirm this, too. Sebastian Log follows: --- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-rc3-00388-g863cf23 (hesselba@nijin) (gcc version 4.3.5 (Debian 4.3.5-4) ) #26 PREEMPT Fri Oct 18 19:30:40 CEST 2013 [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Marvell Kirkwood (Flattened Device Tree), model: Seagate FreeAgent Dockstar ... [0.165779] [Firmware Info]: /ocp@f100/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set ... root@cosmo:~# insmod mvmdio.ko [ 206.994283] libphy: orion_mdio_bus: probed root@cosmo:~# insmod mv643xx_eth.ko [ 210.725345] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4 [ 211.748687] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 02:50:43:19:fd:e2 [ 214.599588] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled ... root@cosmo:~# dhclient eth0 ... RTNETLINK answers: File exists root@cosmo:~# ifconfig eth0 Link encap:Ethernet HWaddr 02:50:43:19:fd:e2 inet addr:192.168.1.54 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2822 (2.7 KiB) TX bytes:4049 (3.9 KiB) Interrupt:29 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: kirkwood: remove lagacy clk workarounds
On Fri, Oct 18, 2013 at 07:43:54PM +0200, Sebastian Hesselbarth wrote: > On 10/18/2013 07:27 PM, Sebastian Hesselbarth wrote: > >On 10/18/2013 06:17 PM, Ezequiel Garcia wrote: > >>On Fri, Oct 18, 2013 at 10:47:41AM -0400, Jason Cooper wrote: > >>>On Fri, Oct 18, 2013 at 01:54:13PM +0200, Sebastian Hesselbarth wrote: > With legacy devices converted to DT and a proper ethernet MAC > workaround, we can now remove the clk workarounds for legacy > devices. While at it, also cleanup the list of includes. > > Signed-off-by: Sebastian Hesselbarth > --- > As a follow-up patch for latest mvebu PRs, this patch is based on > git://git.infradead.org/linux-mvebu.git tags/soc-3.13-2 > > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Russell King > Cc: Kevin Hilman > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/mach-kirkwood/board-dt.c | 42 > ++-- > 1 files changed, 3 insertions(+), 39 deletions(-) > >>> > >>>Applied to mvebu/soc > >>> > >> > >>Weird: I've tried to do this clean-up myself and my usual tests with > >>network > >>built as a module failed somehow. Maybe I missed something and did > >>something > >>stupid? > > > >Ezequiel, > > > >you need commits > >b5d82db net: mv643xx_eth: fix missing device_node for port devices > >f564412 net: mv643xx_eth: fix orphaned statistics timer crash > >041b4dd net: mv643xx_eth: update statistics timer from timer context only > > > >from git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master > > > >Those are the three net driver fixes and have not yet been pulled into > >mainline linux. > > > >Can you re-test with those three applied (or you can just merge in > >above master)? I am compiling right now and will report. > > With mvebu/for-next and net/master merged in, > modular mvmdio and mv643xx_eth on Kirkwood Dockstar: > > Tested-by: Sebastian Hesselbarth > > IOW, works. I hope you can confirm this, too. Nice! Thanks for testing. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next] fib_trie: remove duplicated rcu lock
From: baker.ker...@gmail.com Date: Sun, 13 Oct 2013 19:50:09 +0800 > From: "baker.zhang" > > fib_table_lookup has included the rcu lock protection. > > Signed-off-by: baker.zhang Applied, 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/
Linux 3.10.17
I'm announcing the release of the 3.10.17 kernel. All users of the 3.10 kernel series must upgrade. The updated 3.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.10.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/include/asm/delay.h|5 arch/arc/include/asm/sections.h |1 arch/arc/include/asm/spinlock.h |9 arch/arc/include/asm/uaccess.h |4 arch/arc/kernel/head.S |7 arch/arc/kernel/irq.c |3 arch/arc/kernel/ptrace.c|2 arch/arc/kernel/setup.c |3 arch/arc/kernel/signal.c| 25 - arch/arc/kernel/unaligned.c |6 arch/arm/include/asm/jump_label.h |2 arch/arm/kernel/process.c |2 arch/mips/include/asm/jump_label.h |2 arch/parisc/kernel/traps.c |6 arch/powerpc/include/asm/jump_label.h |2 arch/powerpc/kvm/book3s_hv_rmhandlers.S |2 arch/s390/include/asm/jump_label.h |2 arch/sparc/include/asm/jump_label.h |2 arch/x86/include/asm/cpufeature.h |2 arch/x86/include/asm/e820.h |2 arch/x86/include/asm/jump_label.h |2 arch/x86/kernel/e820.c |5 arch/x86/kernel/setup.c | 19 drivers/char/random.c |3 drivers/gpu/drm/i915/intel_display.c|8 drivers/gpu/drm/radeon/evergreen.c |2 drivers/gpu/drm/radeon/evergreend.h |4 drivers/gpu/drm/radeon/r600d.h |2 drivers/gpu/drm/radeon/radeon_test.c|4 drivers/gpu/drm/radeon/sid.h|4 drivers/hwmon/applesmc.c| 13 drivers/i2c/busses/i2c-omap.c |3 drivers/watchdog/ts72xx_wdt.c |3 fs/btrfs/inode.c|2 fs/dcache.c | 11 fs/ext4/xattr.c |2 fs/hugetlbfs/inode.c|8 fs/statfs.c |2 include/linux/compiler-gcc4.h | 15 include/linux/dcache.h |1 include/linux/ipc_namespace.h |2 include/linux/random.h |1 include/linux/sem.h |6 init/main.c |2 ipc/msg.c | 281 - ipc/namespace.c |7 ipc/sem.c | 660 +--- ipc/shm.c | 288 - ipc/util.c | 140 ++ ipc/util.h | 34 + mm/shmem.c |8 sound/pci/hda/patch_hdmi.c | 18 sound/pci/hda/patch_realtek.c | 37 + sound/usb/usx2y/usbusx2yaudio.c | 22 - sound/usb/usx2y/usx2yhwdeppcm.c |7 56 files changed, 1061 insertions(+), 656 deletions(-) Al Viro (1): cope with potentially long ->d_dname() output for shmem/hugetlb Alex Deucher (1): drm/radeon: fix typo in CP DMA register headers Anssi Hannula (1): ALSA: hda - hdmi: Fix channel map switch not taking effect Chris Wilson (1): drm/i915: Only apply DPMS to the encoder if enabled Christian Ruppert (1): ARC: Fix signal frame management for SA_SIGINFO Dan Carpenter (2): watchdog: ts72xx_wdt: locking bug in ioctl drm/radeon: forever loop on error in radeon_do_test_moves() Daniel Mack (1): ALSA: snd-usb-usx2y: remove bogus frame checks Dave Jones (1): ext4: fix memory leak in xattr David Henningsson (2): ALSA: hda - Fix microphone for Sony VAIO Pro 13 (Haswell model) ALSA: hda - Fix mono speakers and headset mic on Dell Vostro 5470 Davidlohr Bueso (28): ipc: move rcu lock out of ipc_addid ipc: introduce ipc object locking helpers ipc: close open coded spin lock calls ipc: move locking out of ipcctl_pre_down_nolock ipc,msg: shorten critical region in msgctl_down ipc,msg: introduce msgctl_nolock ipc,msg: introduce lockless functions to obtain the ipc object ipc,msg: make msgctl_nolock lockless ipc,msg: shorten critical region in msgsnd ipc,msg: shorten critical region in msgrcv ipc: remove unused functions ipc,shm: introduce lockless functions to obtain the ipc object ipc,shm: shorten critical region in shmctl_down ipc: drop ipcctl_pre_down ipc,shm: introduce shmctl_nolock ipc,shm: make shmctl_nolock lockless ipc,shm: shorten critical region for shmctl ipc,shm: cleanup do_shmat pasta ipc,shm:
Re: linux-next: Tree for Oct 17
On Fri, Oct 18, 2013 at 9:22 AM, Kevin Hilman wrote: > On Fri, Oct 18, 2013 at 1:22 AM, Thierry Reding > wrote: >> On Fri, Oct 18, 2013 at 12:45:26AM -0700, Olof Johansson wrote: >>> On Fri, Oct 18, 2013 at 01:38:47AM +0100, Mark Brown wrote: >>> > Hi all, >>> > >>> > I've uploaded today's linux-next tree to the master branch of the >>> > repository below: >>> > >>> > git://gitorious.org/thierryreding/linux-next.git > >>> > A next-20131017 tag is also provided for convenience. >>> > >>> > One new conflict today but otherwise uneventful. x86_64 allmodconfigs >>> > build after each merge but no other build tests were done. >>> >>> Hi, >>> >>> I'm seeing a fairly large fallout on boot testing. See >>> http://lists.linaro.org/pipermail/kernel-build-reports/2013-October/000719.html >>> for full list (I need to start providing longer backlogs for failures, the >>> top >>> of the oopses is lost in the email). >>> >>> For example, on dove (SolidRun Cubox) I see: >>> >>> [0.707248] Unable to handle kernel NULL pointer dereference at virtual >>> address 0054 >>> [0.715297] pgd = c0004000 >>> [0.717984] [0054] *pgd= >>> [0.721548] Internal error: Oops: 5 [#1] ARM >>> [0.725794] Modules linked in: >>> [0.728841] CPU: 0 PID: 1 Comm: swapper Not tainted >>> 3.12.0-rc5-next-20131017 #1 >>> [0.736114] task: ef035c00 ti: ef036000 task.ti: ef036000 >>> [0.741497] PC is at kfree+0x54/0xc4 >>> [0.745063] LR is at ata_host_register+0x3c/0x290 >>> [0.749741] pc : []lr : []psr: 4193 >>> [0.749741] sp : ef037da8 ip : 0034 fp : >>> [0.761159] r10: r9 : ef061810 r8 : c0519fc8 >>> [0.766353] r7 : c0519fc8 r6 : a113 r5 : r4 : ef1c9dd0 >>> [0.772850] r3 : c0fc8fe0 r2 : c07c9000 r1 : 4000 r0 : >>> [0.779349] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM >>> Segment kernel >>> [0.786708] Control: 10c5387d Table: 4019 DAC: 0015 >>> [0.792428] Process swapper (pid: 1, stack limit = 0xef036248) >>> [0.798234] Stack: (0xef037da8 to 0xef038000) >>> [0.957218] [] (kfree+0x54/0xc4) from [] >>> (ata_host_register+0x3c/0x290) >>> [0.965542] [] (ata_host_register+0x3c/0x290) from >>> [] (ata_host_activate+0xdc/0x118) >>> [0.974992] [] (ata_host_activate+0xdc/0x118) from >>> [] (mv_platform_probe+0x2dc/0x36c) >>> [0.984527] [] (mv_platform_probe+0x2dc/0x36c) from >>> [] (platform_drv_probe+0x18/0x48) >>> [0.994051] [] (platform_drv_probe+0x18/0x48) from >>> [] (really_probe+0x74/0x1fc) >>> [1.003062] [] (really_probe+0x74/0x1fc) from [] >>> (__driver_attach+0x98/0x9c) >>> [1.011804] [] (__driver_attach+0x98/0x9c) from [] >>> (bus_for_each_dev+0x60/0x94) >>> [1.020808] [] (bus_for_each_dev+0x60/0x94) from [] >>> (bus_add_driver+0x148/0x1f0) >>> [1.029898] [] (bus_add_driver+0x148/0x1f0) from [] >>> (driver_register+0x78/0xf8) >>> [1.038911] [] (driver_register+0x78/0xf8) from [] >>> (mv_init+0x30/0x50) >>> [1.047144] [] (mv_init+0x30/0x50) from [] >>> (do_one_initcall+0x100/0x14c) >>> [1.07] [] (do_one_initcall+0x100/0x14c) from [] >>> (kernel_init_freeable+0x120/0x1c0) >>> [1.065259] [] (kernel_init_freeable+0x120/0x1c0) from >>> [] (kernel_init+0x8/0x158) >>> [1.074441] [] (kernel_init+0x8/0x158) from [] >>> (ret_from_fork+0x14/0x3c) >>> [1.082841] Code: e0823283 e3110902 1593301c e593001c (e5904054) >>> >>> >>> I bisected it down to commit 55acc602faae7c10e53acdca0c70f4936c2539c6, which >>> is really weird. That is: >>> >>> commit 55acc602faae7c10e53acdca0c70f4936c2539c6 >>> Merge: e32face ba6857b >>> Author: Mark Brown >>> AuthorDate: Thu Oct 17 23:55:55 2013 +0100 >>> Commit: Mark Brown >>> CommitDate: Thu Oct 17 23:55:55 2013 +0100 >>> >>> Merge remote-tracking branch 'driver-core/driver-core-next' >>> >>> Conflicts: >>> include/linux/netdevice.h >>> >>> >>> But there isn't anything controversial in the merge commit. >>> >>> I tried checking out either side of that merge, and they both boot >>> fine. I redid the merge myself, and I get no delta compared to your >>> merge and I still get the same failure. >>> >>> I've got more failures than dove, I'll try bisecting a few of the others >>> in the morning (it's late here), hopefully they will help indicate what's >>> actually going wrong. I'm guessing something just happens to move around >>> enough to expose a different problem once the two branches are merged. >> >> Looking at that oops it seems like host is actually NULL when kfree() is >> called in ata_host_register(). That seems to only happen when freeing up >> any of the unused ports, which is strange in itself because Cubox seems >> to only register a single one. Also if host is indeed NULL, then things >> should go haywire much sooner. >> >> Looks like you won't easily find out what's going on here unless you get >> into it somewhat deeper and
[PATCH V9.1 17/33] loop: use aio to perform io on the underlying file
[I made a mistake with my last change to this patch. I misunderstood
what bdev_io_min() was all about. I needed to stick with
logical_block_size.]
This uses the new kernel aio interface to process loopback IO by
submitting concurrent direct aio. Previously loop's IO was serialized
by synchronous processing in a thread.
The aio operations specify the memory for the IO with the bio_vec arrays
directly instead of mappings of the pages.
The use of aio operations is enabled when the backing file supports the
read_iter, write_iter and direct_IO methods.
Signed-off-by: Zach Brown
Signed-off-by: Dave Kleikamp
Tested-by: Sedat Dilek
---
drivers/block/loop.c | 158 ++
include/uapi/linux/loop.h | 1 +
2 files changed, 119 insertions(+), 40 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 40e7155..e564769 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include "loop.h"
#include
@@ -218,6 +219,48 @@ lo_do_transfer(struct loop_device *lo, int cmd,
return lo->transfer(lo, cmd, rpage, roffs, lpage, loffs, size, rblock);
}
+#ifdef CONFIG_AIO
+static void lo_rw_aio_complete(u64 data, long res)
+{
+ struct bio *bio = (struct bio *)(uintptr_t)data;
+
+ if (res > 0)
+ res = 0;
+ else if (res < 0)
+ res = -EIO;
+
+ bio_endio(bio, res);
+}
+
+static int lo_rw_aio(struct loop_device *lo, struct bio *bio)
+{
+ struct file *file = lo->lo_backing_file;
+ struct kiocb *iocb;
+ unsigned int op;
+ struct iov_iter iter;
+ struct bio_vec *bvec;
+ size_t nr_segs;
+ loff_t pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
+
+ iocb = aio_kernel_alloc(GFP_NOIO);
+ if (!iocb)
+ return -ENOMEM;
+
+ if (bio_rw(bio) & WRITE)
+ op = IOCB_CMD_WRITE_ITER;
+ else
+ op = IOCB_CMD_READ_ITER;
+
+ bvec = bio_iovec_idx(bio, bio->bi_idx);
+ nr_segs = bio_segments(bio);
+ iov_iter_init_bvec(, bvec, nr_segs, bvec_length(bvec, nr_segs), 0);
+ aio_kernel_init_rw(iocb, file, iov_iter_count(), pos);
+ aio_kernel_init_callback(iocb, lo_rw_aio_complete, (u64)(uintptr_t)bio);
+
+ return aio_kernel_submit(iocb, op, );
+}
+#endif /* CONFIG_AIO */
+
/**
* __do_lo_send_write - helper for writing data to a loop device
*
@@ -418,50 +461,33 @@ static int do_bio_filebacked(struct loop_device *lo,
struct bio *bio)
pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
if (bio_rw(bio) == WRITE) {
- struct file *file = lo->lo_backing_file;
-
- if (bio->bi_rw & REQ_FLUSH) {
- ret = vfs_fsync(file, 0);
- if (unlikely(ret && ret != -EINVAL)) {
- ret = -EIO;
- goto out;
- }
- }
+ ret = lo_send(lo, bio, pos);
+ } else
+ ret = lo_receive(lo, bio, lo->lo_blocksize, pos);
- /*
-* We use punch hole to reclaim the free space used by the
-* image a.k.a. discard. However we do not support discard if
-* encryption is enabled, because it may give an attacker
-* useful information.
-*/
- if (bio->bi_rw & REQ_DISCARD) {
- struct file *file = lo->lo_backing_file;
- int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE;
+ return ret;
+}
- if ((!file->f_op->fallocate) ||
- lo->lo_encrypt_key_size) {
- ret = -EOPNOTSUPP;
- goto out;
- }
- ret = file->f_op->fallocate(file, mode, pos,
- bio->bi_size);
- if (unlikely(ret && ret != -EINVAL &&
-ret != -EOPNOTSUPP))
- ret = -EIO;
- goto out;
- }
+static int lo_discard(struct loop_device *lo, struct bio *bio)
+{
+ struct file *file = lo->lo_backing_file;
+ int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE;
+ loff_t pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
+ int ret;
- ret = lo_send(lo, bio, pos);
+ /*
+* We use punch hole to reclaim the free space used by the
+* image a.k.a. discard. However we do not support discard if
+* encryption is enabled, because it may give an attacker
+* useful information.
+*/
- if ((bio->bi_rw & REQ_FUA) && !ret) {
- ret = vfs_fsync(file, 0);
- if (unlikely(ret && ret != -EINVAL))
-
[PATCH v2 2/4] ARM: dts: MSM8974: Add restart node
Add the restart node so we can reboot the device.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 2ebb4f0..df18637 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -29,5 +29,10 @@
<1 1 0xf08>;
clock-frequency = <1920>;
};
+
+ restart@fc4ab000 {
+ compatible = "qcom,pshold";
+ reg = <0xfc4ab000 0x4>;
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] ARM: msm: Simplify ARCH_MSM_DT config
This doesn't need to be a def_bool y. Instead we can have every DT supported platform select ARCH_MSM_DT and we achieve the same thing with less chance of conflicts. Signed-off-by: Stephen Boyd --- arch/arm/mach-msm/Kconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index 5e5782d..702553b 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -44,6 +44,7 @@ endchoice config ARCH_MSM8X60 bool "MSM8X60" + select ARCH_MSM_DT select ARM_GIC select CPU_V7 select GPIO_MSM_V2 @@ -52,6 +53,7 @@ config ARCH_MSM8X60 config ARCH_MSM8960 bool "MSM8960" + select ARCH_MSM_DT select ARM_GIC select CPU_V7 select HAVE_SMP @@ -60,6 +62,7 @@ config ARCH_MSM8960 config ARCH_MSM8974 bool "MSM8974" + select ARCH_MSM_DT select ARM_GIC select CPU_V7 select HAVE_ARM_ARCH_TIMER @@ -68,8 +71,7 @@ config ARCH_MSM8974 select USE_OF config ARCH_MSM_DT - def_bool y - depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974) + bool select SPARSE_IRQ select USE_OF -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] ARM: dts: MSM8974: Add MMIO architected timer node
Add the mmio architected timer node.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 59 +
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index df18637..6ac9496 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -30,6 +30,65 @@
clock-frequency = <1920>;
};
+ timer@f902 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "arm,armv7-timer-mem";
+ reg = <0xf902 0x1000>;
+ clock-frequency = <1920>;
+
+ frame@f9021000 {
+ frame-number = <0>;
+ interrupts = <0 8 0x4>,
+<0 7 0x4>;
+ reg = <0xf9021000 0x1000>,
+ <0xf9022000 0x1000>;
+ };
+
+ frame@f9023000 {
+ frame-number = <1>;
+ interrupts = <0 9 0x4>;
+ reg = <0xf9023000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9024000 {
+ frame-number = <2>;
+ interrupts = <0 10 0x4>;
+ reg = <0xf9024000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9025000 {
+ frame-number = <3>;
+ interrupts = <0 11 0x4>;
+ reg = <0xf9025000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9026000 {
+ frame-number = <4>;
+ interrupts = <0 12 0x4>;
+ reg = <0xf9026000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9027000 {
+ frame-number = <5>;
+ interrupts = <0 13 0x4>;
+ reg = <0xf9027000 0x1000>;
+ status = "disabled";
+ };
+
+ frame@f9028000 {
+ frame-number = <6>;
+ interrupts = <0 14 0x4>;
+ reg = <0xf9028000 0x1000>;
+ status = "disabled";
+ };
+ };
+
restart@fc4ab000 {
compatible = "qcom,pshold";
reg = <0xfc4ab000 0x4>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] APQ8074 updates
This patchset simplifies the ARCH_MSM_DT config and adds some more nodes for devices that have drivers merged in the upstream kernel. Changes since v1: * Moved nodes into soc node * Enabled restart driver in defconfig Stephen Boyd (4): ARM: msm: Simplify ARCH_MSM_DT config ARM: dts: MSM8974: Add restart node ARM: dts: MSM8974: Add MMIO architected timer node ARM: msm_defconfig: Enable restart driver arch/arm/boot/dts/qcom-msm8974.dtsi | 64 + arch/arm/configs/msm_defconfig | 2 ++ arch/arm/mach-msm/Kconfig | 6 ++-- 3 files changed, 70 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] ARM: msm_defconfig: Enable restart driver
Signed-off-by: Stephen Boyd --- arch/arm/configs/msm_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig index 0ed32e5..c5698b7 100644 --- a/arch/arm/configs/msm_defconfig +++ b/arch/arm/configs/msm_defconfig @@ -89,6 +89,8 @@ CONFIG_SSBI=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_MSM=y CONFIG_THERMAL=y CONFIG_REGULATOR=y CONFIG_MEDIA_SUPPORT=y -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2013-10-14
On Mon, Oct 14, 2013 at 08:52:18PM -0300, Gustavo Padovan wrote: > Hi John, > > More patches for 3.12, busy times for Bluetooth. More than a 100 commits since > the last pull. The bulk of work comes from Johan and Marcel, they are doing > fixes and improvements all over the Bluetooth subsystem, as the diffstat can > show. > > Please pull or let me know of any problems! Thanks. > > Gustavo > -- > The following changes since commit 4f3e219d95a3c31b916dcd5e2631c4e440736f79: > > Bluetooth: Only one command per L2CAP LE signalling is supported > (2013-10-03 16:09:59 +0300) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next > for-upstream > > for you to fetch changes up to 4b836f393bd8ed111857a6ee1865e44627266ec6: > > Bluetooth: Read current IAC LAP on controller setup (2013-10-14 19:31:18 > -0300) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/13] dmatest: make driver unmap also source buffers by itself
On Fri, 2013-10-18 at 19:35 +0200, Bartlomiej Zolnierkiewicz wrote:
> Make the driver DMA unmap also source buffers by itself
> (currently it DMA unmaps only destination buffers) as
> a preparation for introducing generic 'ummap' data.
>
> Cc: Dan Williams
I think you may update Dan's address.
I assume you run exactly this module to test your DMA drivers.
If so, please take my
Acked-by: Andy Shevchenko
> Cc: Vinod Koul
> Cc: Tomasz Figa
> Cc: Dave Jiang
> Cc: Andy Shevchenko
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
> ---
> drivers/dma/dmatest.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index 92f796c..f4a2a25 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -597,11 +597,10 @@ static int dmatest_func(void *data)
> set_user_nice(current, 10);
>
> /*
> - * src buffers are freed by the DMAEngine code with dma_unmap_single()
> - * dst buffers are freed by ourselves below
> + * src and dst buffers are freed by ourselves below
>*/
> - flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT
> - | DMA_COMPL_SKIP_DEST_UNMAP | DMA_COMPL_SRC_UNMAP_SINGLE;
> + flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT |
> + DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
>
> while (!kthread_should_stop()
> && !(params->iterations && total_tests >= params->iterations)) {
> @@ -750,7 +749,8 @@ static int dmatest_func(void *data)
> continue;
> }
>
> - /* Unmap by myself (see DMA_COMPL_SKIP_DEST_UNMAP above) */
> + /* Unmap by myself */
> + unmap_src(dev->dev, dma_srcs, len, src_cnt);
> unmap_dst(dev->dev, dma_dsts, params->buf_size, dst_cnt);
>
> error_count = 0;
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] udf: fix for pathetic mount times in case of invalid file system
From: Peter A. Felvegi The UDF driver was not strict enough about checking the IDs in the VSDs when mounting, which resulted in reading through all the sectors of the block device in some unfortunate cases. Eg, trying to mount my uninitialized 200G SSD partition (all 0xFF bytes) took ~350 minutes to fail, because the code expected some of the valid IDs or a zero byte. During this, the mount couldn't be killed, sync from the cmdline blocked, and the machine froze into the shutdown. Valid filesystems (extX, btrfs, ntfs) were rejected by the mere accident of having a zero byte at just the right place in some of their sectors, close enough to the beginning not to generate excess I/O. The fix adds a hard limit on the VSD sector offset, adds the two missing VSD IDs, and stops scanning when encountering an invalid ID. Also replaced the magic number 32768 with a more meaningful #define, and supressed the bogus message about failing to read the first sector if no UDF fs was detected. Signed-off-by: Peter A. Felvegi --- The fix was developed for 3.9.4, and applies to 3.12-rc3, too. patch v2: edited the code so that added/changed lines are not longer than 80 chars. sending the patch as an attachment, as gmail messes it up otherwise. udf.patch Description: Binary data
[RFC] ARM: tty: Move HVC DCC assembly to arch/arm
Put architecture-specific assembly code where it belongs,
allowing for support of additional architectures such as arm64 in
the future.
Signed-off-by: Christopher Covington
---
arch/arm/include/asm/dcc.h | 45 +++
drivers/tty/hvc/hvc_dcc.c | 48 ++
2 files changed, 47 insertions(+), 46 deletions(-)
create mode 100644 arch/arm/include/asm/dcc.h
diff --git a/arch/arm/include/asm/dcc.h b/arch/arm/include/asm/dcc.h
new file mode 100644
index 000..306d1fc
--- /dev/null
+++ b/arch/arm/include/asm/dcc.h
@@ -0,0 +1,45 @@
+/* Copyright (c) 2010, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+/* DCC Status Bits */
+#define DCC_STATUS_RX (1 << 30)
+#define DCC_STATUS_TX (1 << 29)
+
+static inline u32 __dcc_getstatus(void)
+{
+ u32 __ret;
+ asm volatile("mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg"
+ : "=r" (__ret) : : "cc");
+
+ return __ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm volatile("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
+ : "=r" (__c));
+ isb();
+
+ return __c;
+}
+
+static inline void __dcc_putchar(char c)
+{
+ asm volatile("mcr p14, 0, %0, c0, c5, 0 @ write a char"
+ : /* no output register */
+ : "r" (c));
+ isb();
+}
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..e9f0191 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+/* Copyright (c) 2010, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -8,57 +8,13 @@
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
*/
-#include
-#include
-#include
-#include
-#include
-#include
-
+#include
#include
#include "hvc_console.h"
-/* DCC Status Bits */
-#define DCC_STATUS_RX (1 << 30)
-#define DCC_STATUS_TX (1 << 29)
-
-static inline u32 __dcc_getstatus(void)
-{
- u32 __ret;
- asm volatile("mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg"
- : "=r" (__ret) : : "cc");
-
- return __ret;
-}
-
-
-static inline char __dcc_getchar(void)
-{
- char __c;
-
- asm volatile("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
- : "=r" (__c));
- isb();
-
- return __c;
-}
-
-static inline void __dcc_putchar(char c)
-{
- asm volatile("mcr p14, 0, %0, c0, c5, 0 @ write a char"
- : /* no output register */
- : "r" (c));
- isb();
-}
-
static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
{
int i;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/19] perf script: print addr by default for BTS
On 10/18/13 6:29 AM, Adrian Hunter wrote:
addr is not displayed by default for hardware events,
however for branch events it is the target of the branch
so for BTS display it by default if it was recorded.
Signed-off-by: Adrian Hunter
---
tools/perf/builtin-script.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 3f9a9bf..1a91621 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -413,7 +413,9 @@ static void print_sample_bts(union perf_event *event,
printf(" => ");
/* print branch_to information */
- if (PRINT_FIELD(ADDR))
+ if (PRINT_FIELD(ADDR) ||
+ ((evsel->attr.sample_type & PERF_SAMPLE_ADDR) &&
+!output[attr->type].user_set))
print_sample_addr(event, sample, machine, thread, attr);
printf("\n");
Looks ok to me. Acked-by: David Ahern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/12] mm, thp, tmpfs: enable thp page cache in tmpfs
I guess this is the last review I have for this around, but not sure what's the best solution right now. Kirill, do you think it's OK to just split the huge page when it will be moved. Will look into how thp anon handle this situation. Then after this, I probably will post v2. Thanks! Best wishes, -- Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066 On Tue, Oct 15, 2013 at 11:42 AM, Ning Qu wrote: > I agree with this. It has been like this just for a quick proof, but I > need to address this problem as soon as possible. > > Thanks! > Best wishes, > -- > Ning Qu (曲宁) | Software Engineer | qun...@google.com | +1-408-418-6066 > > > On Tue, Oct 15, 2013 at 4:09 AM, Kirill A. Shutemov > wrote: >> Ning Qu wrote: >>> Signed-off-by: Ning Qu >>> --- >>> mm/Kconfig | 4 ++-- >>> mm/shmem.c | 5 + >>> 2 files changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/mm/Kconfig b/mm/Kconfig >>> index 562f12f..4d2f90f 100644 >>> --- a/mm/Kconfig >>> +++ b/mm/Kconfig >>> @@ -428,8 +428,8 @@ config TRANSPARENT_HUGEPAGE_PAGECACHE >>> help >>> Enabling the option adds support hugepages for file-backed >>> mappings. It requires transparent hugepage support from >>> - filesystem side. For now, the only filesystem which supports >>> - hugepages is ramfs. >>> + filesystem side. For now, the filesystems which support >>> + hugepages are: ramfs and tmpfs. >>> >>> config CROSS_MEMORY_ATTACH >>> bool "Cross Memory Support" >>> diff --git a/mm/shmem.c b/mm/shmem.c >>> index 75c0ac6..50a3335 100644 >>> --- a/mm/shmem.c >>> +++ b/mm/shmem.c >>> @@ -1672,6 +1672,11 @@ static struct inode *shmem_get_inode(struct >>> super_block *sb, const struct inode >>> break; >>> case S_IFREG: >>> inode->i_mapping->a_ops = _aops; >>> + /* >>> + * TODO: make tmpfs pages movable >>> + */ >>> + mapping_set_gfp_mask(inode->i_mapping, >>> + GFP_TRANSHUGE & ~__GFP_MOVABLE); >> >> Unlike ramfs, tmpfs pages are movable before transparent page cache >> patchset. >> Making tmpfs pages non-movable looks like a big regression to me. It need >> to be fixed before proposing it upstream. >> >> -- >> Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/29] score: Use get_signal() signal_setup_done()
It's fine for Score. Pass the compiling and other tests.
Thank you.
Acked-by: Lennox Wu
於 2013/10/8 下午 07:34, Richard Weinberger 提到:
> Use the more generic functions get_signal() signal_setup_done()
> for signal delivery.
>
> Signed-off-by: Richard Weinberger
> ---
> arch/score/kernel/signal.c | 43 ++-
> 1 file changed, 18 insertions(+), 25 deletions(-)
>
> diff --git a/arch/score/kernel/signal.c b/arch/score/kernel/signal.c
> index a00fba3..1651807 100644
> --- a/arch/score/kernel/signal.c
> +++ b/arch/score/kernel/signal.c
> @@ -173,15 +173,15 @@ badframe:
> return 0;
> }
>
> -static int setup_rt_frame(struct k_sigaction *ka, struct pt_regs *regs,
> - int signr, sigset_t *set, siginfo_t *info)
> +static int setup_rt_frame(struct ksignal *ksig, struct pt_regs *regs,
> + sigset_t *set)
> {
> struct rt_sigframe __user *frame;
> int err = 0;
>
> - frame = get_sigframe(ka, regs, sizeof(*frame));
> + frame = get_sigframe(>ka, regs, sizeof(*frame));
> if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
> - goto give_sigsegv;
> + return -EFAULT;
>
> /*
>* Set up the return code ...
> @@ -194,7 +194,7 @@ static int setup_rt_frame(struct k_sigaction *ka, struct
> pt_regs *regs,
> err |= __put_user(0x80008002, frame->rs_code + 1);
> flush_cache_sigtramp((unsigned long) frame->rs_code);
>
> - err |= copy_siginfo_to_user(>rs_info, info);
> + err |= copy_siginfo_to_user(>rs_info, >info);
> err |= __put_user(0, >rs_uc.uc_flags);
> err |= __put_user(NULL, >rs_uc.uc_link);
> err |= __save_altstack(>rs_uc.uc_stack, regs->regs[0]);
> @@ -202,26 +202,23 @@ static int setup_rt_frame(struct k_sigaction *ka,
> struct pt_regs *regs,
> err |= __copy_to_user(>rs_uc.uc_sigmask, set, sizeof(*set));
>
> if (err)
> - goto give_sigsegv;
> + return -EFAULT;
>
> regs->regs[0] = (unsigned long) frame;
> regs->regs[3] = (unsigned long) frame->rs_code;
> - regs->regs[4] = signr;
> + regs->regs[4] = ksig->sig;
> regs->regs[5] = (unsigned long) >rs_info;
> regs->regs[6] = (unsigned long) >rs_uc;
> - regs->regs[29] = (unsigned long) ka->sa.sa_handler;
> - regs->cp0_epc = (unsigned long) ka->sa.sa_handler;
> + regs->regs[29] = (unsigned long) ksig->ka.sa.sa_handler;
> + regs->cp0_epc = (unsigned long) ksig->ka.sa.sa_handler;
>
> return 0;
> -
> -give_sigsegv:
> - force_sigsegv(signr, current);
> - return -EFAULT;
> }
>
> -static void handle_signal(unsigned long sig, siginfo_t *info,
> - struct k_sigaction *ka, struct pt_regs *regs)
> +static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
> {
> + int ret;
> +
> if (regs->is_syscall) {
> switch (regs->regs[4]) {
> case ERESTART_RESTARTBLOCK:
> @@ -229,7 +226,7 @@ static void handle_signal(unsigned long sig, siginfo_t
> *info,
> regs->regs[4] = EINTR;
> break;
> case ERESTARTSYS:
> - if (!(ka->sa.sa_flags & SA_RESTART)) {
> + if (!(ksig->ka.sa.sa_flags & SA_RESTART)) {
> regs->regs[4] = EINTR;
> break;
> }
> @@ -245,17 +242,14 @@ static void handle_signal(unsigned long sig, siginfo_t
> *info,
> /*
>* Set up the stack frame
>*/
> - if (setup_rt_frame(ka, regs, sig, sigmask_to_save(), info) < 0)
> - return;
> + ret = setup_rt_frame(ksig, regs, sigmask_to_save());
>
> - signal_delivered(sig, info, ka, regs, 0);
> + signal_setup_done(ret, ksig, 0);
> }
>
> static void do_signal(struct pt_regs *regs)
> {
> - struct k_sigaction ka;
> - siginfo_t info;
> - int signr;
> + struct ksignal ksig;
>
> /*
>* We want the common case to go fast, which is why we may in certain
> @@ -265,10 +259,9 @@ static void do_signal(struct pt_regs *regs)
> if (!user_mode(regs))
> return;
>
> - signr = get_signal_to_deliver(, , regs, NULL);
> - if (signr > 0) {
> + if (get_signal()) {
> /* Actually deliver the signal. */
> - handle_signal(signr, , , regs);
> + handle_signal(, regs);
> return;
> }
>
signature.asc
Description: OpenPGP digital signature
Re: [RFC] ARM: tty: Move HVC DCC assembly to arch/arm
On 10/18/13 11:14, Christopher Covington wrote: > Put architecture-specific assembly code where it belongs, > allowing for support of additional architectures such as arm64 in > the future. Do you have that patch too? There was also a patch a year ago to add armv5/v4 support to this driver. Maybe we can resurrect that too. > diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c > index 44fbeba..e9f0191 100644 > --- a/drivers/tty/hvc/hvc_dcc.c > +++ b/drivers/tty/hvc/hvc_dcc.c > @@ -8,57 +8,13 @@ > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > - * 02110-1301, USA. > */ > > -#include > -#include > -#include > -#include We still need init.h > -#include > -#include > - > +#include > #include > > #include "hvc_console.h" > > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] ARM: DT: msm: Add Qualcomm's PRNG driver binding document
On 10/15/13 07:11, Stanimir Varbanov wrote: > This adds Qualcomm PRNG driver device tree binding documentation > to use as an example in dts trees. > > Signed-off-by: Stanimir Varbanov > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] hwrng: msm: Add PRNG support for MSM SoC's
On 10/15/13 07:11, Stanimir Varbanov wrote: > This adds a driver for hardware random number generator present > on Qualcomm MSM SoC's. > > Signed-off-by: Stanimir Varbanov > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of/lib: Export fdt routines to modules
Hi all, Guenter, thanks for adding devicetree to Cc. On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote: > On 10/17/2013 04:51 PM, Michael Bohan wrote: > > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote: > >> On 10/16/2013 05:27 PM, Michael Bohan wrote: > >>> My motivation is actually to use the fdt format as a firmware. > >>> I have a requirement to express driver metadata that's loadable > >> >from the filesystem. This data is not reasonable to place in the > >>> system Device Tree, since it's application specific and does not > >>> actually describe hardware. The fact that the format chosen is > >>> 'flattened device tree' is merely just a coincidence. Michael, could you elaborate on using the fdt format "as a firmware" and what driver metadata you need to be loadable from the filesystem? How are you intending to pass the DT to the kernel from userspace? Given that you mention this is application-specific configuration, why is using sysfs attributes or some other sort of filesystem interaction not appropriate? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.11.6
I'm announcing the release of the 3.11.6 kernel. All users of the 3.11 kernel series must upgrade. The updated 3.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.11.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arc/include/asm/delay.h|5 arch/arc/include/asm/spinlock.h |9 + arch/arc/include/asm/uaccess.h |4 arch/arc/kernel/ptrace.c|2 arch/arc/kernel/signal.c| 25 +-- arch/arc/kernel/unaligned.c |6 arch/arm/include/asm/jump_label.h |2 arch/mips/include/asm/jump_label.h |2 arch/mips/kernel/octeon_switch.S|2 arch/mips/kernel/r2300_switch.S |2 arch/mips/kernel/r4k_switch.S |2 arch/parisc/kernel/traps.c |6 arch/powerpc/include/asm/jump_label.h |2 arch/powerpc/kvm/book3s_hv_rmhandlers.S |2 arch/s390/include/asm/jump_label.h |2 arch/sparc/include/asm/jump_label.h |2 arch/x86/include/asm/cpufeature.h |6 arch/x86/include/asm/e820.h |2 arch/x86/include/asm/jump_label.h |2 arch/x86/kernel/e820.c |5 arch/x86/kernel/setup.c | 19 +- drivers/char/random.c |3 drivers/gpu/drm/i915/i915_reg.h |6 drivers/gpu/drm/i915/intel_display.c|8 - drivers/gpu/drm/i915/intel_pm.c |9 - drivers/gpu/drm/radeon/btc_dpm.c|6 drivers/gpu/drm/radeon/evergreen.c |2 drivers/gpu/drm/radeon/evergreend.h |4 drivers/gpu/drm/radeon/r600d.h |2 drivers/gpu/drm/radeon/radeon_test.c|4 drivers/gpu/drm/radeon/si_dpm.c |6 drivers/gpu/drm/radeon/sid.h|4 drivers/hwmon/applesmc.c| 13 + drivers/i2c/busses/i2c-omap.c |3 drivers/watchdog/kempld_wdt.c |2 drivers/watchdog/ts72xx_wdt.c |3 fs/btrfs/inode.c|2 fs/ext4/xattr.c |2 fs/statfs.c |2 include/linux/compiler-gcc4.h | 15 + include/linux/ipc_namespace.h |2 include/linux/random.h |1 init/main.c |2 ipc/msg.c | 25 +-- ipc/namespace.c |7 ipc/sem.c | 82 +++--- ipc/shm.c | 255 ++-- ipc/util.c | 82 +++--- ipc/util.h | 14 - sound/pci/hda/patch_hdmi.c | 18 +- sound/pci/hda/patch_realtek.c | 37 sound/usb/usx2y/usbusx2yaudio.c | 22 -- sound/usb/usx2y/usx2yhwdeppcm.c |7 54 files changed, 436 insertions(+), 325 deletions(-) Alex Deucher (1): drm/radeon: fix typo in CP DMA register headers Anssi Hannula (1): ALSA: hda - hdmi: Fix channel map switch not taking effect Chris Wilson (1): drm/i915: Only apply DPMS to the encoder if enabled Christian Ruppert (1): ARC: Fix signal frame management for SA_SIGINFO Dan Carpenter (4): watchdog: ts72xx_wdt: locking bug in ioctl drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers() drm/radeon/dpm: off by one in si_set_mc_special_registers() drm/radeon: forever loop on error in radeon_do_test_moves() Daniel Mack (1): ALSA: snd-usb-usx2y: remove bogus frame checks Dave Jones (1): ext4: fix memory leak in xattr David Henningsson (2): ALSA: hda - Fix microphone for Sony VAIO Pro 13 (Haswell model) ALSA: hda - Fix mono speakers and headset mic on Dell Vostro 5470 Davidlohr Bueso (15): ipc,shm: introduce lockless functions to obtain the ipc object ipc,shm: shorten critical region in shmctl_down ipc: drop ipcctl_pre_down ipc,shm: introduce shmctl_nolock ipc,shm: make shmctl_nolock lockless ipc,shm: shorten critical region for shmctl ipc,shm: cleanup do_shmat pasta ipc,shm: shorten critical region for shmat ipc: rename ids->rw_mutex ipc,msg: drop msg_unlock ipc: document general ipc locking scheme ipc, shm: guard against non-existant vma in shmdt(2) ipc: drop ipc_lock_by_ptr ipc, shm: drop shm_lock_check ipc: drop ipc_lock_check Francisco Jerez (1): drm/i915/hsw: Disable L3 caching of atomic memory operations. Greg Kroah-Hartman (1): Linux 3.11.6 Helge Deller (1): parisc: fix interruption handler to respect pagefault_disable() Henrik Rydberg (1): hwmon:
[PATCH 0/3] : KGDB/KDB/UV updates.
* Change the fix for KDB not defined build problem by changing the kgdb_nmicallin() interface to include the KDB specific reason code. This removes a dependency on KDB in the debug core. Also requires a change the call in from UV NMI handler. * Fix some problems found by the kbuild test robot. * Fix UV call into kgdb to depend only on whether KGDB is defined and not both KGDB and KDB. This allows the power nmi command to use the gdb remote connection if enabled. Note new action of 'kgdb' needs to be set as well to indicate user wants to wait for gdb to be connected. If it's set to 'kdb' then an error message is displayed if KDB is not configured. -- -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] PATCH: UV/NMI Fix tip/bot/kbuild test robot problems
Fix some problems found by the kbuild test robot.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86/include/asm/uv/uv.h |2 --
arch/x86/kernel/apic/x2apic_uv_x.c |1 -
arch/x86/platform/uv/uv_nmi.c |9 -
3 files changed, 4 insertions(+), 8 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -12,7 +12,6 @@ extern enum uv_system_type get_uv_system
extern int is_uv_system(void);
extern void uv_cpu_init(void);
extern void uv_nmi_init(void);
-extern void uv_register_nmi_notifier(void);
extern void uv_system_init(void);
extern void (*uv_trace_nmi_func)(unsigned int reason, struct pt_regs *regs);
extern void (*uv_trace_func)(const char *f, const int l, const char *fmt, ...);
@@ -34,7 +33,6 @@ static inline int is_uv_system(void) { r
static inline void uv_cpu_init(void) { }
static inline void uv_system_init(void){ }
static inline void uv_trace(void *fmt, ...){ }
-static inline void uv_register_nmi_notifier(void) { }
static inline const struct cpumask *
uv_flush_tlb_others(const struct cpumask *cpumask, struct mm_struct *mm,
unsigned long start, unsigned long end, unsigned int cpu)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -980,7 +980,6 @@ void __init uv_system_init(void)
uv_nmi_setup();
uv_cpu_init();
uv_scir_register_cpu_notifier();
- uv_register_nmi_notifier();
proc_mkdir("sgi_uv", NULL);
/* register Legacy VGA I/O redirection handler */
--- linux.orig/arch/x86/platform/uv/uv_nmi.c
+++ linux/arch/x86/platform/uv/uv_nmi.c
@@ -81,7 +81,6 @@ static atomic_t uv_in_nmi;
static atomic_t uv_nmi_cpu = ATOMIC_INIT(-1);
static atomic_t uv_nmi_cpus_in_nmi = ATOMIC_INIT(-1);
static atomic_t uv_nmi_slave_continue;
-static atomic_t uv_nmi_kexec_failed;
static cpumask_var_t uv_nmi_cpu_mask;
/* Values for uv_nmi_slave_continue */
@@ -511,6 +510,7 @@ static void uv_nmi_touch_watchdogs(void)
}
#if defined(CONFIG_KEXEC)
+static atomic_t uv_nmi_kexec_failed;
static void uv_nmi_kdump(int cpu, int master, struct pt_regs *regs)
{
/* Call crash to dump system state */
@@ -645,7 +645,7 @@ int uv_handle_nmi(unsigned int reason, s
/*
* NMI handler for pulling in CPUs when perf events are grabbing our NMI
*/
-int uv_handle_nmi_ping(unsigned int reason, struct pt_regs *regs)
+static int uv_handle_nmi_ping(unsigned int reason, struct pt_regs *regs)
{
int ret;
@@ -662,7 +662,7 @@ int uv_handle_nmi_ping(unsigned int reas
return ret;
}
-void uv_register_nmi_notifier(void)
+static void uv_register_nmi_notifier(void)
{
if (register_nmi_handler(NMI_UNKNOWN, uv_handle_nmi, 0, "uv"))
pr_warn("UV: NMI handler failed to register\n");
@@ -706,6 +706,5 @@ void uv_nmi_setup(void)
uv_hub_nmi_per(cpu) = uv_hub_nmi_list[nid];
}
BUG_ON(!alloc_cpumask_var(_nmi_cpu_mask, GFP_KERNEL));
+ uv_register_nmi_notifier();
}
-
-
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] PATCH: KGDB/KDB Fix no KDB config problem.
Some code added to the debug_core module had KDB dependencies that it
shouldn't have. Move the KDB dependent REASON back to the caller to
remove the dependence in KGDB code.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86/platform/uv/uv_nmi.c |2 +-
include/linux/kgdb.h |3 ++-
kernel/debug/debug_core.c |5 +++--
kernel/debug/debug_core.h |2 --
4 files changed, 6 insertions(+), 6 deletions(-)
--- linux.orig/arch/x86/platform/uv/uv_nmi.c
+++ linux/arch/x86/platform/uv/uv_nmi.c
@@ -553,7 +553,7 @@ static void uv_call_kdb(int cpu, struct
if (master) {
/* call KGDB NMI handler as MASTER */
ret = kgdb_nmicallin(cpu, X86_TRAP_NMI, regs,
- _nmi_slave_continue);
+ KDB_REASON_SYSTEM_NMI, _nmi_slave_continue);
if (ret) {
pr_alert("KDB returned error, is kgdboc set?\n");
atomic_set(_nmi_slave_continue, SLAVE_EXIT);
--- linux.orig/include/linux/kgdb.h
+++ linux/include/linux/kgdb.h
@@ -310,7 +310,8 @@ extern int
kgdb_handle_exception(int ex_vector, int signo, int err_code,
struct pt_regs *regs);
extern int kgdb_nmicallback(int cpu, void *regs);
-extern int kgdb_nmicallin(int cpu, int trapnr, void *regs, atomic_t *snd_rdy);
+extern int kgdb_nmicallin(int cpu, int trapnr, void *regs, int err_code,
+ atomic_t *snd_rdy);
extern void gdbstub_exit(int status);
extern int kgdb_single_step;
--- linux.orig/kernel/debug/debug_core.c
+++ linux/kernel/debug/debug_core.c
@@ -736,7 +736,8 @@ int kgdb_nmicallback(int cpu, void *regs
return 1;
}
-int kgdb_nmicallin(int cpu, int trapnr, void *regs, atomic_t *send_ready)
+int kgdb_nmicallin(int cpu, int trapnr, void *regs, int err_code,
+ atomic_t *send_ready)
{
#ifdef CONFIG_SMP
if (!kgdb_io_ready(0) || !send_ready)
@@ -750,7 +751,7 @@ int kgdb_nmicallin(int cpu, int trapnr,
ks->cpu = cpu;
ks->ex_vector = trapnr;
ks->signo = SIGTRAP;
- ks->err_code= KGDB_KDB_REASON_SYSTEM_NMI;
+ ks->err_code= err_code;
ks->linux_regs = regs;
ks->send_ready = send_ready;
kgdb_cpu_enter(ks, regs, DCPU_WANT_MASTER);
--- linux.orig/kernel/debug/debug_core.h
+++ linux/kernel/debug/debug_core.h
@@ -75,13 +75,11 @@ extern int kdb_stub(struct kgdb_state *k
extern int kdb_parse(const char *cmdstr);
extern int kdb_common_init_state(struct kgdb_state *ks);
extern int kdb_common_deinit_state(void);
-#define KGDB_KDB_REASON_SYSTEM_NMI KDB_REASON_SYSTEM_NMI
#else /* ! CONFIG_KGDB_KDB */
static inline int kdb_stub(struct kgdb_state *ks)
{
return DBG_PASS_EVENT;
}
-#define KGDB_KDB_REASON_SYSTEM_NMI 0
#endif /* CONFIG_KGDB_KDB */
#endif /* _DEBUG_CORE_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/
[PATCH 3/3] PATCH: UV/NMI/KGDB/KDB Fix UV NMI handler when KDB not configed.
Fix UV call into kgdb to depend only on whether KGDB is defined and not
both KGDB and KDB. This allows the power nmi command to use the gdb
remote connection if enabled. Note new action of 'kgdb' needs to be set
as well to indicate user wants to wait for gdb to be connected. If it's
set to 'kdb' then an error message is displayed if KDB is not configured.
Note that if both KGDB and KDB are enabled, then the action of 'kgdb' or
'kdb' has no affect on which is used. See the KGDB documention for further
information.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86/platform/uv/uv_nmi.c | 57 +++---
1 file changed, 43 insertions(+), 14 deletions(-)
--- linux.orig/arch/x86/platform/uv/uv_nmi.c
+++ linux/arch/x86/platform/uv/uv_nmi.c
@@ -155,7 +155,8 @@ module_param_named(retry_count, uv_nmi_r
* "dump" - dump process stack for each cpu
* "ips" - dump IP info for each cpu
* "kdump"- do crash dump
- * "kdb" - enter KDB/KGDB (default)
+ * "kdb" - enter KDB (default)
+ * "kgdb" - enter KGDB
*/
static char uv_nmi_action[8] = "kdb";
module_param_string(action, uv_nmi_action, sizeof(uv_nmi_action), 0644);
@@ -544,18 +545,46 @@ static inline void uv_nmi_kdump(int cpu,
}
#endif /* !CONFIG_KEXEC */
+#ifdef CONFIG_KGDB
#ifdef CONFIG_KGDB_KDB
-/* Call KDB from NMI handler */
-static void uv_call_kdb(int cpu, struct pt_regs *regs, int master)
+static inline int uv_nmi_kgdb_reason(void)
{
- int ret;
+ if (uv_nmi_action_is("kdb"))
+ return KDB_REASON_SYSTEM_NMI;
+ return 0;
+}
+#else /* !CONFIG_KGDB_KDB */
+static inline int uv_nmi_kgdb_reason(void)
+{
+ if (uv_nmi_action_is("kgdb"))
+ return 0;
+ pr_err("UV: NMI error: KDB is not enabled in this kernel\n");
+ return -1;
+}
+#endif /* CONFIG_KGDB_KDB */
+
+/*
+ * Call KGDB/KDB from NMI handler
+ *
+ * Note that if both KGDB and KDB are configured, then the action of 'kgdb' or
+ * 'kdb' has no affect on which is used. See the KGDB documention for further
+ * information.
+ */
+static void uv_call_kgdb_kdb(int cpu, struct pt_regs *regs, int master)
+{
if (master) {
+ int reason = uv_nmi_kgdb_reason();
+ int ret;
+
+ if (reason < 0)
+ return;
+
/* call KGDB NMI handler as MASTER */
- ret = kgdb_nmicallin(cpu, X86_TRAP_NMI, regs,
- KDB_REASON_SYSTEM_NMI, _nmi_slave_continue);
+ ret = kgdb_nmicallin(cpu, X86_TRAP_NMI, regs, reason,
+ _nmi_slave_continue);
if (ret) {
- pr_alert("KDB returned error, is kgdboc set?\n");
+ pr_alert("KGDB returned error, is kgdboc set?\n");
atomic_set(_nmi_slave_continue, SLAVE_EXIT);
}
} else {
@@ -574,12 +603,12 @@ static void uv_call_kdb(int cpu, struct
uv_nmi_sync_exit(master);
}
-#else /* !CONFIG_KGDB_KDB */
-static inline void uv_call_kdb(int cpu, struct pt_regs *regs, int master)
+#else /* !CONFIG_KGDB */
+static inline void uv_call_kgdb_kdb(int cpu, struct pt_regs *regs, int master)
{
- pr_err("UV: NMI error: KGDB/KDB is not enabled in this kernel\n");
+ pr_err("UV: NMI error: KGDB is not enabled in this kernel\n");
}
-#endif /* !CONFIG_KGDB_KDB */
+#endif /* !CONFIG_KGDB */
/*
* UV NMI handler
@@ -617,9 +646,9 @@ int uv_handle_nmi(unsigned int reason, s
if (uv_nmi_action_is("ips") || uv_nmi_action_is("dump"))
uv_nmi_dump_state(cpu, regs, master);
- /* Call KDB if enabled */
- else if (uv_nmi_action_is("kdb"))
- uv_call_kdb(cpu, regs, master);
+ /* Call KGDB/KDB if enabled */
+ else if (uv_nmi_action_is("kdb") || uv_nmi_action_is("kgdb"))
+ uv_call_kgdb_kdb(cpu, regs, master);
/* Clear per_cpu "in nmi" flag */
atomic_set(_cpu_nmi.state, UV_NMI_STATE_OUT);
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] NVMe: Convert to blk-mq
On 10/18/2013 05:13 PM, Keith Busch wrote:
On Fri, 18 Oct 2013, Matias Bjorling wrote:
The nvme driver implements itself as a bio-based driver. This primarily
because of high lock congestion for high-performance nvm devices. To
remove the congestion within the traditional block layer, a multi-queue
block layer is being implemented.
This patch converts the current bio-based approach to work with the
request-based approach found in the multi-queue block layer. This means
that bio responsibility is moved from the driver, into the block layer.
In return the block layer packs request structures and submit them to
the nvme according to the features/limits of nvme hardware.
The patch consists of:
* Initialization of multi-queue data structures
* Conversion of bio function call into request function calls.
* Separate cmdid patchs for admin and normal queues.
* Bio splits according to NOT_VIRT_MERGEABLE are assumed to be handled
by blk-mq.
* Uses the timeout framework blk-mq where possible.
Signed-off-by: Matias Bjorling
---
drivers/block/nvme-core.c | 765
+++---
drivers/block/nvme-scsi.c | 39 +--
include/linux/nvme.h | 7 +-
3 files changed, 385 insertions(+), 426 deletions(-)
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index e99a30a..36bf45c 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
[snip]
-static void nvme_start_io_acct(struct bio *bio)
+static void nvme_start_io_acct(struct request *rq)
{
-struct gendisk *disk = bio->bi_bdev->bd_disk;
-const int rw = bio_data_dir(bio);
+struct gendisk *disk = rq->rq_disk;
+const int rw = rq_data_dir(rq);
int cpu = part_stat_lock();
part_round_stats(cpu, >part0);
part_stat_inc(cpu, >part0, ios[rw]);
-part_stat_add(cpu, >part0, sectors[rw], bio_sectors(bio));
+part_stat_add(cpu, >part0, sectors[rw], blk_rq_sectors(rq));
part_inc_in_flight(>part0, rw);
part_stat_unlock();
}
-static void nvme_end_io_acct(struct bio *bio, unsigned long start_time)
+static void nvme_end_io_acct(struct request *rq, unsigned long
start_time)
{
-struct gendisk *disk = bio->bi_bdev->bd_disk;
-const int rw = bio_data_dir(bio);
+struct gendisk *disk = rq->rq_disk;
+const int rw = rq_data_dir(rq);
unsigned long duration = jiffies - start_time;
int cpu = part_stat_lock();
part_stat_add(cpu, >part0, ticks[rw], duration);
@@ -342,23 +370,26 @@ static void nvme_end_io_acct(struct bio *bio,
unsigned long start_time)
part_stat_unlock();
}
I think you can remove the io accounting, right? These were added here
because the diskstats are not updated in the block layer for bio-based
block drivers.
Yeap, I'll make a patch for the next version that removes them.
@@ -715,32 +606,47 @@ static int nvme_submit_bio_queue(struct
nvme_queue *nvmeq, struct nvme_ns *ns,
dma_dir = DMA_FROM_DEVICE;
}
-result = nvme_map_bio(nvmeq, iod, bio, dma_dir, psegs);
-if (result <= 0)
+if (nvme_map_rq(nvmeq, iod, rq, dma_dir))
goto free_cmdid;
-length = result;
-cmnd->rw.command_id = cmdid;
+length = blk_rq_bytes(rq);
+
+cmnd->rw.command_id = rq->tag;
The command ids have to be unique on a submission queue. Since each
namespace's blk-mq has its own 'tags' used as command ids here but share
submission queues, what's stopping the tags for commands sent to namespace
1 from clashing with tags for namespace 2?
I think this would work better if one blk-mq was created per device
rather than namespace. It would fix the tag problem above and save a
lot of memory potentially wasted on millions of requests allocated that
can't be used.
You're right. I didn't see the connection. In v3 I'll push struct
request_queue to nvme_dev and map the queues appropriately. It will also
fix the command id issues.
Do you know how/if this is planned to work with scsi? Will there be one
blk-mq per LUN or per host controller?
Christoph Hellwig and Nicholas Bellinger are working on scsi-mq.
https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/log/?h=scsi-mq
I think they will map it out per controller. That'll be the most natural.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Potential out-of-bounds in ftrace_regex_release
On Mon, 14 Oct 2013 12:29:13 +0400
Andrey Konovalov wrote:
> Testing now with your patch.
> I've seen this report only twice, so it will be difficult to say if
> it's not happening any more or just not triggered.
Can I assume that this is fixed? I'll put it in for 3.12 and mark it
for stable too.
-- Steve
>
> On Thu, Oct 10, 2013 at 6:23 AM, Steven Rostedt wrote:
> > On Wed, 9 Oct 2013 14:05:26 +0400
> > Andrey Konovalov wrote:
> >time cat trace > /tmp/trace
> >> So I still think that the bug is in 'trage_get_user()':
> >> Checking that 'parser->idx < parser->size - 1' is not performed in 'if
> >> (isspace(ch))' section, so 'parser->idx' becomes equal to
> >> 'parser->size' after 'parser->buffer[parser->idx++] = ch;'.
> >> (However in 'while (cnt && !isspace(ch))' loop checking is performed.)
> >
> > Yep, you are correct. I put in some printk's and did same writing to
> > the set_events file and was able to prove that I could get that "0"
> > written into the +1 overflow boundary.
> >
> > Can you try this patch to see if it fixes it for you.
> >
> > Thanks,
> >
> > -- Steve
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index d5f7c4d..063a92b 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -843,9 +843,12 @@ int trace_get_user(struct trace_parser *parser, const
> > char __user *ubuf,
> > if (isspace(ch)) {
> > parser->buffer[parser->idx] = 0;
> > parser->cont = false;
> > - } else {
> > + } else if (parser->idx < parser->size - 1) {
> > parser->cont = true;
> > parser->buffer[parser->idx++] = ch;
> > + } else {
> > + ret = -EINVAL;
> > + goto out;
> > }
> >
> > *ppos += read;
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Convert from bio-based to blk-mq v2
On 10/18/2013 05:48 PM, Matthew Wilcox wrote: On Fri, Oct 18, 2013 at 03:14:19PM +0200, Matias Bjorling wrote: Performance study: System: HGST Research NVMe prototype, Haswell i7-4770 3.4Ghz, 32GB 1333Mhz I don't have one of these. Can you provide more details about it, such as: - How many I/O queues does it have? - Are the interrupts correctly bound to the CPUs (for both sets of tests)? The driver isn't allowed to set the irq affinity correctly itself; it can only set a hint and userspace (eg irqbalance) has to set the affinity correctly - Does it support interrupt coalescing? If so, have you managed to do any testing using that feature? Current impletation is an PCI-e Gen2x4 interface, two I/O queues. One for admin and one for all other I/Os. I'll check up on IRQ affinity when multiple queues are available. I haven't yet tested interrupt coalescing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] x86 fixes
Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: dd3c9c4b603c664fedc12facf180db0f1794aafe x86: Update UV3 hub revision ID Two fixlets: - fix a (rare-config) build bug - fix a next-gen SGI/UV hw/firmware enumeration bug Thanks, Ingo --> Borislav Petkov (1): x86/microcode: Correct Kconfig dependencies Russ Anderson (1): x86: Update UV3 hub revision ID arch/x86/Kconfig | 1 + arch/x86/kernel/apic/x2apic_uv_x.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 145d703..f67e839 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1033,6 +1033,7 @@ config X86_REBOOTFIXUPS config MICROCODE tristate "CPU microcode loading support" + depends on CPU_SUP_AMD || CPU_SUP_INTEL select FW_LOADER ---help--- diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c index 1191ac1..a419814 100644 --- a/arch/x86/kernel/apic/x2apic_uv_x.c +++ b/arch/x86/kernel/apic/x2apic_uv_x.c @@ -113,7 +113,7 @@ static int __init early_get_pnodeid(void) break; case UV3_HUB_PART_NUMBER: case UV3_HUB_PART_NUMBER_X: - uv_min_hub_revision_id += UV3_HUB_REVISION_BASE - 1; + uv_min_hub_revision_id += UV3_HUB_REVISION_BASE; break; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Convert from bio-based to blk-mq v2
On 10/18/2013 05:48 PM, Matthew Wilcox wrote: On Fri, Oct 18, 2013 at 03:14:19PM +0200, Matias Bjorling wrote: Performance study: System: HGST Research NVMe prototype, Haswell i7-4770 3.4Ghz, 32GB 1333Mhz I don't have one of these. Can you provide more details about it, such as: - How many I/O queues does it have? - Are the interrupts correctly bound to the CPUs (for both sets of tests)? The driver isn't allowed to set the irq affinity correctly itself; it can only set a hint and userspace (eg irqbalance) has to set the affinity correctly - Does it support interrupt coalescing? If so, have you managed to do any testing using that feature? Current implementation is a driven using a PCI-e Gen2x4 interface, two I/O queues. One for admin and one for all other I/Os. I'll check up on IRQ affinity when multiple queues are available. I haven't yet tested interrupt coalescing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?
On 10/17/2013 11:07 PM, Myklebust, Trond wrote: > On Thu, 2013-10-17 at 22:42 퍭, Helge Deller wrote: >> I'm seeing a regression with current kernel git head when using NFS-mounts. >> Architecture in my case is parisc, although I don't think that this is >> relevant. >> At least kernel 3.10 (and I think 3.11) didn't showed that problem. >> >> The symtom is, that "top" shows high usage of either kswapd0 or kswapd1. >> Here is an output with kswapd1: >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>37 root 20 0 000 R 91.8 0.0 63:00.40 kswapd1 >> 28448 root 20 0 3252 1428 1060 R 15.3 0.0 0:00.09 top >> 1 root 20 0 2784 988 852 S 0.0 0.0 0:09.95 init >> >> This is what ps shows: >> ls:~# ps -ef | grep mount >> root 1181 1 0 14:51 ?00:00:18 /usr/sbin/automount >> --pid-file /var/run/autofs.pid >> root 25331 1181 0 21:25 ?00:00:00 /bin/mount -n -t nfs -s -o >> nolock,rw,hard,intr homes:/unixhome1 /net/home1 >> root 25332 25331 0 21:25 ?00:00:00 /sbin/mount.nfs >> homes:/unixhome1 /net/home1 -s -n -o rw,nolock,hard,intr >> >> And using sysrq to show the blocked tasks I get in syslog: >> SysRq : Show Blocked State >> mount.nfs D 401040c0 0 25332 25331 0x0010 >> Backtrace: >> [<40113a68>] __schedule팞瓓ﴱ >> >> I know it's not a problem of the NFS server, since the same mount is still >> ok on other machines. >> The NFS directory was already mounted and in use when this mount happened >> again (called by cron-job). >> >> Any ideas? > > If the NFS directory is already mounted, then why is the automounter > trying to mount it a second time? I was wrong in this. The directory wasn't mounted yet (or at least it was unmounted in the meantime before the new mount.nfs was called). I'm now not even sure, that the high kswapd is really triggered by the NFS problem, because I now have another machine with the blocked NFS-mount, but without the high kswapd usage. Nevertheless, the blocked nfs mount tasks really make me wonder. There is clearly some kind of regression since it doesn't happen with older kernels. Helge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] USB: ehci-atmel: add usb_clk for transition to CCF
Hello Nicolas,
This patch should fix the bug you were seeing with USB device
enumaration after moving to CCF.
Tell me if this solves the issue (it worked for me).
Best Regards,
Boris
On 18/10/2013 21:26, Boris BREZILLON wrote:
The AT91 PMC (Power Management Controller) provides a USB clock used by
the different USB controllers (ehci, ohci and udc).
The atmel-ehci driver must configure the usb clock rate to 48Mhz in order
to get a fully functionnal USB host controller.
This configuration was formely done in mach-at91/clock.c, but will be
bypassed when moving to common clk framework.
This patch adds support for usb clock retrieval and configuration only if
CCF is enabled (CONFIG_COMMON_CLK).
Signed-off-by: Boris BREZILLON
---
drivers/usb/host/ehci-atmel.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..f417526 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -30,13 +30,17 @@ static const char hcd_name[] = "ehci-atmel";
static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
-static struct clk *iclk, *fclk;
+static struct clk *iclk, *fclk, *uclk;
static int clocked;
/*-*/
static void atmel_start_clock(void)
{
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ clk_set_rate(uclk, 4800);
+ clk_prepare_enable(uclk);
+ }
clk_prepare_enable(iclk);
clk_prepare_enable(fclk);
clocked = 1;
@@ -46,6 +50,8 @@ static void atmel_stop_clock(void)
{
clk_disable_unprepare(fclk);
clk_disable_unprepare(iclk);
+ if (IS_ENABLED(CONFIG_COMMON_CLK))
+ clk_disable_unprepare(uclk);
clocked = 0;
}
@@ -130,6 +136,14 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
retval = -ENOENT;
goto fail_request_resource;
}
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ uclk = devm_clk_get(>dev, "usb_clk");
+ if (IS_ERR(uclk)) {
+ dev_err(>dev, "failed to get uclk\n");
+ retval = PTR_ERR(uclk);
+ goto fail_request_resource;
+ }
+ }
ehci = hcd_to_ehci(hcd);
/* registers start at offset 0x0 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of/lib: Export fdt routines to modules
On Fri, Oct 18, 2013 at 09:30:32AM -0700, David Daney wrote: > On 10/18/2013 08:57 AM, Rob Herring wrote: > [...] > > > >Unflattening is definitely the right > >direction to go here. > > > > I wonder if that is really true. > > The device tree in question is very short lived, and used to control > the configuration of some hardware device when loading the driver. > > The use of it is completely contained within a single driver (at > least that is my understanding), it is not information that needs to > be shared system wide. That's correct. > Given that it is a driver implementation issue, rather than making > things work nicely system wide, I don't think it really matters what > is done. > > It may be that the overhead of unflattening the tree and then > freeing it, is much greater than just extracting a few things from > the FDT. Yes, this was my original thought as well. On the other hand, having libfdt in the kernel does add a little extra bloat, and so it seems a tradeoff from one-time runtime overhead to footprint. > That said, I don't really have a preference for what is done. My > original questions were targeted at understanding this particular > use case. My preference is probably straight libfdt calls, but if others think that unpacking is a better solution, I'm able to go that route as well. My only concern there is that we provide a means to detect invalid dtb image (ex. handle error codes) and also free the device_node allocations once the device is released. Thanks, Mike -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: ehci-atmel: add usb_clk for transition to CCF
The AT91 PMC (Power Management Controller) provides a USB clock used by
the different USB controllers (ehci, ohci and udc).
The atmel-ehci driver must configure the usb clock rate to 48Mhz in order
to get a fully functionnal USB host controller.
This configuration was formely done in mach-at91/clock.c, but will be
bypassed when moving to common clk framework.
This patch adds support for usb clock retrieval and configuration only if
CCF is enabled (CONFIG_COMMON_CLK).
Signed-off-by: Boris BREZILLON
---
drivers/usb/host/ehci-atmel.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..f417526 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -30,13 +30,17 @@ static const char hcd_name[] = "ehci-atmel";
static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
-static struct clk *iclk, *fclk;
+static struct clk *iclk, *fclk, *uclk;
static int clocked;
/*-*/
static void atmel_start_clock(void)
{
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ clk_set_rate(uclk, 4800);
+ clk_prepare_enable(uclk);
+ }
clk_prepare_enable(iclk);
clk_prepare_enable(fclk);
clocked = 1;
@@ -46,6 +50,8 @@ static void atmel_stop_clock(void)
{
clk_disable_unprepare(fclk);
clk_disable_unprepare(iclk);
+ if (IS_ENABLED(CONFIG_COMMON_CLK))
+ clk_disable_unprepare(uclk);
clocked = 0;
}
@@ -130,6 +136,14 @@ static int ehci_atmel_drv_probe(struct platform_device
*pdev)
retval = -ENOENT;
goto fail_request_resource;
}
+ if (IS_ENABLED(CONFIG_COMMON_CLK)) {
+ uclk = devm_clk_get(>dev, "usb_clk");
+ if (IS_ERR(uclk)) {
+ dev_err(>dev, "failed to get uclk\n");
+ retval = PTR_ERR(uclk);
+ goto fail_request_resource;
+ }
+ }
ehci = hcd_to_ehci(hcd);
/* registers start at offset 0x0 */
--
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: 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?
On Fri, 2013-10-18 at 21:26 +0200, Helge Deller wrote: > On 10/17/2013 11:07 PM, Myklebust, Trond wrote: > > On Thu, 2013-10-17 at 22:42 퍭, Helge Deller wrote: > >> I'm seeing a regression with current kernel git head when using NFS-mounts. > >> Architecture in my case is parisc, although I don't think that this is > >> relevant. > >> At least kernel 3.10 (and I think 3.11) didn't showed that problem. > >> > >> The symtom is, that "top" shows high usage of either kswapd0 or kswapd1. > >> Here is an output with kswapd1: > >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND > >>37 root 20 0 000 R 91.8 0.0 63:00.40 kswapd1 > >> 28448 root 20 0 3252 1428 1060 R 15.3 0.0 0:00.09 top > >> 1 root 20 0 2784 988 852 S 0.0 0.0 0:09.95 init > >> > >> This is what ps shows: > >> ls:~# ps -ef | grep mount > >> root 1181 1 0 14:51 ?00:00:18 /usr/sbin/automount > >> --pid-file /var/run/autofs.pid > >> root 25331 1181 0 21:25 ?00:00:00 /bin/mount -n -t nfs -s -o > >> nolock,rw,hard,intr homes:/unixhome1 /net/home1 > >> root 25332 25331 0 21:25 ?00:00:00 /sbin/mount.nfs > >> homes:/unixhome1 /net/home1 -s -n -o rw,nolock,hard,intr > >> > >> And using sysrq to show the blocked tasks I get in syslog: > >> SysRq : Show Blocked State > >> mount.nfs D 401040c0 0 25332 25331 0x0010 > >> Backtrace: > >> [<40113a68>] __schedule팞瓓ﴱ > >> > >> I know it's not a problem of the NFS server, since the same mount is still > >> ok on other machines. > >> The NFS directory was already mounted and in use when this mount happened > >> again (called by cron-job). > >> > >> Any ideas? > > > > If the NFS directory is already mounted, then why is the automounter > > trying to mount it a second time? > > I was wrong in this. > The directory wasn't mounted yet (or at least it was unmounted in the > meantime before the new > mount.nfs was called). > > I'm now not even sure, that the high kswapd is really triggered by the NFS > problem, > because I now have another machine with the blocked NFS-mount, but without > the high kswapd usage. > > Nevertheless, the blocked nfs mount tasks really make me wonder. There is > clearly > some kind of regression since it doesn't happen with older kernels. Have you ever reproduced it without the automounter? Also, could you please try a sysRQ-t the next time it happens, so that we can get a trace of where the mount program is hanging. Knowing that the mount is stuck in "__schedule()" is not really interesting unless we know from where that was called. -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.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/
[GIT PULL] ACPI and power management fixes for v3.12-rc6
Hi Linus, Please pull from the git repository at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm+acpi-3.12-rc6 to receive ACPI and power management fixes for v3.12-rc6 with top-most commit 981984cbd09e41c05b4ec6260e3f68591354cd54 Merge branch Merge branch 'acpi-fixes' on top of commit 35f9162d67c3e20a82b4bd6ec538f3e9c14fb055 Merge tag 'pm+acpi-3.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm These fix a bug related to system suspend/resume in intel_pstate and fix it up after a recent change, make a forgotten structure field change in one of cpufreq drivers, remove a leftover reference to /proc/acpi/event in Kconfig help, add a missing mutex unlock to an error code path in ACPI power resources code and drop a pile of unuseful code related to power resources that causes problems to happen on real systems. Specifics: - intel_pstate fix for misbehavior after system resume if sysfs attributes are set in a specific way before the corresponding suspend from Dirk Brandewie. - A recent intel_pstate fix has no effect if unsigned long is 32-bit, so fix it up to cover that case as well. - The s3c64xx cpufreq driver was not updated when the index field of struct cpufreq_frequency_table was replaced with driver_data, so update it now. From Charles Keepax. - The Kconfig help text for ACPI_BUTTON still refers to /proc/acpi/event that has been dropped recently, so modify it to remove that reference. From Krzysztof Mazur. - A Lan Tianyu's change adds a missing mutex unlock to an error code path in acpi_resume_power_resources(). - Some code related to ACPI power resources, whose very purpose is questionable to put it lightly, turns out to cause problems to happen during testing on real systems, so remove it completely (we may revisit that in the future if there's a compelling enough reason). From yours truly and Aaron Lu. Thanks! --- Aaron Lu (1): ATA / ACPI: remove power dependent device handling Charles Keepax (1): cpufreq: s3c64xx: Rename index to driver_data Dirk Brandewie (1): cpufreq / intel_pstate: Fix max_perf_pct on resume Krzysztof Mazur (1): ACPI: remove /proc/acpi/event from ACPI_BUTTON help Lan Tianyu (1): ACPI / power: Release resource_lock after acpi_power_get_state() return error Rafael J. Wysocki (3): intel_pstate: Fix type mismatch warning ACPI / power: Drop automaitc resume of power resource dependent devices ACPI / PM: Drop two functions that are not used any more --- drivers/acpi/Kconfig |6 +-- drivers/acpi/device_pm.c | 56 drivers/acpi/power.c | 104 ++--- drivers/acpi/scan.c |1 - drivers/ata/libata-acpi.c | 14 - drivers/ata/libata-scsi.c |3 -- drivers/ata/libata.h |4 -- drivers/cpufreq/intel_pstate.c| 14 ++--- drivers/cpufreq/s3c64xx-cpufreq.c |2 +- include/acpi/acpi_bus.h |7 --- 10 files changed, 15 insertions(+), 196 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 17 (pinctrl-single.c)
On Fri, Oct 18, 2013 at 8:08 PM, Randy Dunlap wrote: > On 10/17/13 17:38, Mark Brown wrote: >> Hi all, >> >> I've uploaded today's linux-next tree to the master branch of the >> repository below: >> >> git://gitorious.org/thierryreding/linux-next.git >> >> A next-20131017 tag is also provided for convenience. >> >> One new conflict today but otherwise uneventful. x86_64 allmodconfigs >> build after each merge but no other build tests were done. > > on i386: > > drivers/pinctrl/pinctrl-single.c: In function 'pcs_irqdomain_map': > drivers/pinctrl/pinctrl-single.c:1750:2: error: implicit declaration of > function 'set_irq_flags' [-Werror=implicit-function-declaration] > drivers/pinctrl/pinctrl-single.c:1750:21: error: 'IRQF_VALID' undeclared > (first use in this function) > drivers/pinctrl/pinctrl-single.c:1750:34: error: 'IRQF_PROBE' undeclared > (first use in this function) H this looks like Tony's baby and the offending patch is not in the pinctrl tree, I bet he'll have a fix for it in no time. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 0/7] 3.0.101-stable review
NOTE: This is the LAST 3.0.x stable kernel release that I will be doing. After this release, 3.0.x is End-Of-Life, please move to the 3.10.x, or if you must, 3.4.x series. For more information about longterm stable releases and how long they will be maintained, please see https://www.kernel.org/category/releases.html This is the start of the stable review cycle for the 3.0.101 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 20 19:50:26 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.0.101-rc1 Eric Dumazet ipv6: tcp: fix panic in SYN processing wojciech kapuscinski drm/radeon: fix hw contexts for SUMO2 asics Dan Carpenter watchdog: ts72xx_wdt: locking bug in ioctl Helge Deller parisc: fix interruption handler to respect pagefault_disable() Dave Jones ext4: fix memory leak in xattr Linus Torvalds vfs: allow O_PATH file descriptors for fstatfs() Theodore Ts'o random: run random_int_secret_init() run after all late_initcalls - Diffstat: Makefile | 4 ++-- arch/parisc/kernel/traps.c | 6 +++--- drivers/char/random.c | 3 +-- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/watchdog/ts72xx_wdt.c | 3 ++- fs/ext4/xattr.c| 2 ++ fs/statfs.c| 2 +- include/linux/random.h | 1 + init/main.c| 2 ++ net/ipv6/inet6_connection_sock.c | 2 +- 10 files changed, 16 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 00/11] 3.4.67-stable review
This is the start of the stable review cycle for the 3.4.67 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Oct 20 19:50:39 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.67-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.4.67-rc1 Linus Torvalds mm: do not grow the stack vma just because of an overrun on preceding vma Cyril Hrubis mm/mmap: check for RLIMIT_AS before unmapping wojciech kapuscinski drm/radeon: fix hw contexts for SUMO2 asics Dan Carpenter watchdog: ts72xx_wdt: locking bug in ioctl Helge Deller parisc: fix interruption handler to respect pagefault_disable() Paul Mackerras KVM: PPC: Book3S HV: Fix typo in saving DSCR Dave Jones ext4: fix memory leak in xattr Linus Torvalds vfs: allow O_PATH file descriptors for fstatfs() Theodore Ts'o random: run random_int_secret_init() run after all late_initcalls Takashi Iwai ALSA: hda - Add fixup for ASUS N56VZ Daniel Mack ALSA: snd-usb-usx2y: remove bogus frame checks - Diffstat: Makefile| 4 +- arch/parisc/kernel/traps.c | 6 +-- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- drivers/char/random.c | 3 +- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/watchdog/ts72xx_wdt.c | 3 +- fs/ext4/xattr.c | 2 + fs/statfs.c | 2 +- include/linux/random.h | 1 + init/main.c | 2 + mm/mmap.c | 77 +++-- sound/pci/hda/patch_realtek.c | 1 + sound/usb/usx2y/usbusx2yaudio.c | 22 ++ sound/usb/usx2y/usx2yhwdeppcm.c | 7 +-- 14 files changed, 94 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 7/7] ipv6: tcp: fix panic in SYN processing
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit c16a98ed91597b40b22b540c6517103497ef8e74 upstream.
commit 72a3effaf633bc ([NET]: Size listen hash tables using backlog
hint) added a bug allowing inet6_synq_hash() to return an out of bound
array index, because of u16 overflow.
Bug can happen if system admins set net.core.somaxconn &
net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Cc: Willy Tarreau
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/inet6_connection_sock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -85,7 +85,7 @@ struct dst_entry *inet6_csk_route_req(st
* request_sock (formerly open request) hash tables.
*/
static u32 inet6_synq_hash(const struct in6_addr *raddr, const __be16 rport,
- const u32 rnd, const u16 synq_hsize)
+ const u32 rnd, const u32 synq_hsize)
{
u32 c;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 4/7] parisc: fix interruption handler to respect pagefault_disable()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
probe_kernel_read(, >current_pwq, sizeof(pwq));
probe_kernel_read(, >wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);
The problem here is, that the first probe_kernel_read() might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.
With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0). Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.
Signed-off-by: Helge Deller
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
---
arch/parisc/kernel/traps.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -811,14 +811,14 @@ void notrace handle_interruption(int cod
else {
/*
-* The kernel should never fault on its own address space.
+* The kernel should never fault on its own address space,
+* unless pagefault_disable() was called before.
*/
- if (fault_space == 0)
+ if (fault_space == 0 && !in_atomic())
{
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
parisc_terminate("Kernel Fault", regs, code, fault_address);
-
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 09/11] drm/radeon: fix hw contexts for SUMO2 asics
3.4-stable review patch. If anyone has any objections, please let me know. -- From: wojciech kapuscinski commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream. They have 4 rather than 8. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=63599 Signed-off-by: wojciech kapuscinski Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/evergreen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -1912,7 +1912,7 @@ static void evergreen_gpu_init(struct ra rdev->config.evergreen.sx_max_export_size = 256; rdev->config.evergreen.sx_max_export_pos_size = 64; rdev->config.evergreen.sx_max_export_smx_size = 192; - rdev->config.evergreen.max_hw_contexts = 8; + rdev->config.evergreen.max_hw_contexts = 4; rdev->config.evergreen.sq_num_cf_insts = 2; rdev->config.evergreen.sc_prim_fifo_size = 0x40; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 08/11] watchdog: ts72xx_wdt: locking bug in ioctl
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Dan Carpenter commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream. Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a interruptible deadlock. Signed-off-by: Dan Carpenter Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman --- drivers/watchdog/ts72xx_wdt.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/watchdog/ts72xx_wdt.c +++ b/drivers/watchdog/ts72xx_wdt.c @@ -310,7 +310,8 @@ static long ts72xx_wdt_ioctl(struct file case WDIOC_GETSTATUS: case WDIOC_GETBOOTSTATUS: - return put_user(0, p); + error = put_user(0, p); + break; case WDIOC_KEEPALIVE: ts72xx_wdt_kick(wdt); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 10/11] mm/mmap: check for RLIMIT_AS before unmapping
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Cyril Hrubis
commit e8420a8ece80b3fe810415ecf061d54ca7fab266 upstream.
Fix a corner case for MAP_FIXED when requested mapping length is larger
than rlimit for virtual memory. In such case any overlapping mappings
are unmapped before we check for the limit and return ENOMEM.
The check is moved before the loop that unmaps overlapping parts of
existing mappings. When we are about to hit the limit (currently mapped
pages + len > limit) we scan for overlapping pages and check again
accounting for them.
This fixes situation when userspace program expects that the previous
mappings are preserved after the mmap() syscall has returned with error.
(POSIX clearly states that successfull mapping shall replace any
previous mappings.)
This corner case was found and can be tested with LTP testcase:
testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c
In this case the mmap, which is clearly over current limit, unmaps
dynamic libraries and the testcase segfaults right after returning into
userspace.
I've also looked at the second instance of the unmapping loop in the
do_brk(). The do_brk() is called from brk() syscall and from vm_brk().
The brk() syscall checks for overlapping mappings and bails out when
there are any (so it can't be triggered from the brk syscall). The
vm_brk() is called only from binmft handlers so it shouldn't be
triggered unless binmft handler created overlapping mappings.
Signed-off-by: Cyril Hrubis
Reviewed-by: Mel Gorman
Reviewed-by: Wanpeng Li
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Xishi Qiu
Signed-off-by: Greg Kroah-Hartman
---
mm/mmap.c | 50 ++
1 file changed, 46 insertions(+), 4 deletions(-)
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -6,6 +6,7 @@
* Address space accounting code
*/
+#include
#include
#include
#include
@@ -392,6 +393,34 @@ find_vma_prepare(struct mm_struct *mm, u
return vma;
}
+static unsigned long count_vma_pages_range(struct mm_struct *mm,
+ unsigned long addr, unsigned long end)
+{
+ unsigned long nr_pages = 0;
+ struct vm_area_struct *vma;
+
+ /* Find first overlaping mapping */
+ vma = find_vma_intersection(mm, addr, end);
+ if (!vma)
+ return 0;
+
+ nr_pages = (min(end, vma->vm_end) -
+ max(addr, vma->vm_start)) >> PAGE_SHIFT;
+
+ /* Iterate over the rest of the overlaps */
+ for (vma = vma->vm_next; vma; vma = vma->vm_next) {
+ unsigned long overlap_len;
+
+ if (vma->vm_start > end)
+ break;
+
+ overlap_len = min(end, vma->vm_end) - vma->vm_start;
+ nr_pages += overlap_len >> PAGE_SHIFT;
+ }
+
+ return nr_pages;
+}
+
void __vma_link_rb(struct mm_struct *mm, struct vm_area_struct *vma,
struct rb_node **rb_link, struct rb_node *rb_parent)
{
@@ -1245,6 +1274,23 @@ unsigned long mmap_region(struct file *f
unsigned long charged = 0;
struct inode *inode = file ? file->f_path.dentry->d_inode : NULL;
+ /* Check against address space limit. */
+ if (!may_expand_vm(mm, len >> PAGE_SHIFT)) {
+ unsigned long nr_pages;
+
+ /*
+* MAP_FIXED may remove pages of mappings that intersects with
+* requested mapping. Account for the pages it would unmap.
+*/
+ if (!(vm_flags & MAP_FIXED))
+ return -ENOMEM;
+
+ nr_pages = count_vma_pages_range(mm, addr, addr + len);
+
+ if (!may_expand_vm(mm, (len >> PAGE_SHIFT) - nr_pages))
+ return -ENOMEM;
+ }
+
/* Clear old maps */
error = -ENOMEM;
munmap_back:
@@ -1255,10 +1301,6 @@ munmap_back:
goto munmap_back;
}
- /* Check against address space limit. */
- if (!may_expand_vm(mm, len >> PAGE_SHIFT))
- return -ENOMEM;
-
/*
* Set 'VM_NORESERVE' if we should not account for the
* memory use of this mapping.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 07/11] parisc: fix interruption handler to respect pagefault_disable()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
probe_kernel_read(, >current_pwq, sizeof(pwq));
probe_kernel_read(, >wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);
The problem here is, that the first probe_kernel_read() might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.
With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0). Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.
Signed-off-by: Helge Deller
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
---
arch/parisc/kernel/traps.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -810,14 +810,14 @@ void notrace handle_interruption(int cod
else {
/*
-* The kernel should never fault on its own address space.
+* The kernel should never fault on its own address space,
+* unless pagefault_disable() was called before.
*/
- if (fault_space == 0)
+ if (fault_space == 0 && !in_atomic())
{
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
parisc_terminate("Kernel Fault", regs, code, fault_address);
-
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 01/11] ALSA: snd-usb-usx2y: remove bogus frame checks
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
commit a9d14bc0b188a822e42787d01e56c06fe9750162 upstream.
The frame check in i_usX2Y_urb_complete() and
i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as
described in this LAU thread:
http://linuxaudio.org/mailarchive/lau/2013/5/20/200177
This patch removes the check code entirely.
Cc: f...@wemgehoertderstaat.de
Reported-by: Dr Nicholas J Bailey
Suggested-by: Takashi Iwai
Signed-off-by: Daniel Mack
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/usx2y/usbusx2yaudio.c | 22 +++---
sound/usb/usx2y/usx2yhwdeppcm.c |7 +--
2 files changed, 4 insertions(+), 25 deletions(-)
--- a/sound/usb/usx2y/usbusx2yaudio.c
+++ b/sound/usb/usx2y/usbusx2yaudio.c
@@ -295,19 +295,6 @@ static void usX2Y_error_urb_status(struc
usX2Y_clients_stop(usX2Y);
}
-static void usX2Y_error_sequence(struct usX2Ydev *usX2Y,
-struct snd_usX2Y_substream *subs, struct urb
*urb)
-{
- snd_printk(KERN_ERR
-"Sequence Error!(hcd_frame=%i ep=%i%s;wait=%i,frame=%i).\n"
-"Most probably some urb of usb-frame %i is still missing.\n"
-"Cause could be too long delays in usb-hcd interrupt handling.\n",
- usb_get_current_frame_number(usX2Y->dev),
- subs->endpoint, usb_pipein(urb->pipe) ? "in" : "out",
- usX2Y->wait_iso_frame, urb->start_frame,
usX2Y->wait_iso_frame);
- usX2Y_clients_stop(usX2Y);
-}
-
static void i_usX2Y_urb_complete(struct urb *urb)
{
struct snd_usX2Y_substream *subs = urb->context;
@@ -324,12 +311,9 @@ static void i_usX2Y_urb_complete(struct
usX2Y_error_urb_status(usX2Y, subs, urb);
return;
}
- if (likely((urb->start_frame & 0x) == (usX2Y->wait_iso_frame &
0x)))
- subs->completed_urb = urb;
- else {
- usX2Y_error_sequence(usX2Y, subs, urb);
- return;
- }
+
+ subs->completed_urb = urb;
+
{
struct snd_usX2Y_substream *capsubs =
usX2Y->subs[SNDRV_PCM_STREAM_CAPTURE],
*playbacksubs = usX2Y->subs[SNDRV_PCM_STREAM_PLAYBACK];
--- a/sound/usb/usx2y/usx2yhwdeppcm.c
+++ b/sound/usb/usx2y/usx2yhwdeppcm.c
@@ -244,13 +244,8 @@ static void i_usX2Y_usbpcm_urb_complete(
usX2Y_error_urb_status(usX2Y, subs, urb);
return;
}
- if (likely((urb->start_frame & 0x) == (usX2Y->wait_iso_frame &
0x)))
- subs->completed_urb = urb;
- else {
- usX2Y_error_sequence(usX2Y, subs, urb);
- return;
- }
+ subs->completed_urb = urb;
capsubs = usX2Y->subs[SNDRV_PCM_STREAM_CAPTURE];
capsubs2 = usX2Y->subs[SNDRV_PCM_STREAM_CAPTURE + 2];
playbacksubs = usX2Y->subs[SNDRV_PCM_STREAM_PLAYBACK];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
On 10/18/2013 12:46 AM, Thierry Reding wrote: > On Sun, Sep 22, 2013 at 09:59:56AM -0700, Mike Dunn wrote: >> Currently the driver assumes that the values specified in the >> brightness-levels device tree property increase as they are parsed from >> left to right. But boards that invert the signal between the PWM output >> and the backlight will need to specify decreasing brightness-levels. >> This patch removes the assumption that the last element of the array is >> the maximum value, and instead searches the array for the maximum value >> and uses that in the duty cycle calculation. >> >> Signed-off-by: Mike Dunn >> --- >> Changelog: >> v2: >> - commit message reworded; correct line wrap used >> - 'max_level' variable renamed to 'scale' >> - loop counter variable type changed to unsigned int >> - value held in scale changed from array index to actual maximum level >> - blank lines added around loop for readability >> >> drivers/video/backlight/pwm_bl.c | 12 ++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) > > Hey Mike, > > I've pushed a slightly different version of this patch which gets rid of > the intermediate max variable and uses the new scale field exclusively > to pass the same information around. Could you look at the patch from my > for-next branch in the PWM tree and see whether that still works for the > specific hardware that you need this for? Yes looks good. I also tested the current HEAD of for-next on the Palm Treo 680, including the enable-gpios DT node property. I will have to do more work and investigation before I will be able to try the power-supply property, though. Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 06/11] KVM: PPC: Book3S HV: Fix typo in saving DSCR
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Paul Mackerras commit cfc860253abd73e1681696c08ea268d33285a2c4 upstream. This fixes a typo in the code that saves the guest DSCR (Data Stream Control Register) into the kvm_vcpu_arch struct on guest exit. The effect of the typo was that the DSCR value was saved in the wrong place, so changes to the DSCR by the guest didn't persist across guest exit and entry, and some host kernel memory got corrupted. Signed-off-by: Paul Mackerras Acked-by: Alexander Graf Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kvm/book3s_hv_rmhandlers.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -935,7 +935,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206) BEGIN_FTR_SECTION mfspr r8, SPRN_DSCR ld r7, HSTATE_DSCR(r13) - std r8, VCPU_DSCR(r7) + std r8, VCPU_DSCR(r9) mtspr SPRN_DSCR, r7 END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 05/11] ext4: fix memory leak in xattr
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Jones
commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations. If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.
Spotted with Coverity.
[ Fixed by tytso to set is and bs to NULL after freeing these
pointers, in case in the retry loop we later end up triggering an
error causing a jump to cleanup, at which point we could have a double
free bug. -- Ted ]
Signed-off-by: Dave Jones
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Eric Sandeen
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/xattr.c |2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1268,6 +1268,8 @@ retry:
s_min_extra_isize) {
tried_min_extra_isize++;
new_extra_isize = s_min_extra_isize;
+ kfree(is); is = NULL;
+ kfree(bs); bs = NULL;
goto retry;
}
error = -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/
[ 11/11] mm: do not grow the stack vma just because of an overrun on preceding vma
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 09884964335e85e897876d17783c2ad33cf8a2e0 upstream.
The stack vma is designed to grow automatically (marked with VM_GROWSUP
or VM_GROWSDOWN depending on architecture) when an access is made beyond
the existing boundary. However, particularly if you have not limited
your stack at all ("ulimit -s unlimited"), this can cause the stack to
grow even if the access was really just one past *another* segment.
And that's wrong, especially since we first grow the segment, but then
immediately later enforce the stack guard page on the last page of the
segment. So _despite_ first growing the stack segment as a result of
the access, the kernel will then make the access cause a SIGSEGV anyway!
So do the same logic as the guard page check does, and consider an
access to within one page of the next segment to be a bad access, rather
than growing the stack to abut the next segment.
Reported-and-tested-by: Heiko Carstens
Signed-off-by: Linus Torvalds
Cc: Xishi Qiu
Signed-off-by: Greg Kroah-Hartman
---
mm/mmap.c | 27 +++
1 file changed, 27 insertions(+)
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1875,9 +1875,28 @@ int expand_downwards(struct vm_area_stru
return error;
}
+/*
+ * Note how expand_stack() refuses to expand the stack all the way to
+ * abut the next virtual mapping, *unless* that mapping itself is also
+ * a stack mapping. We want to leave room for a guard page, after all
+ * (the guard page itself is not added here, that is done by the
+ * actual page faulting logic)
+ *
+ * This matches the behavior of the guard page logic (see mm/memory.c:
+ * check_stack_guard_page()), which only allows the guard page to be
+ * removed under these circumstances.
+ */
#ifdef CONFIG_STACK_GROWSUP
int expand_stack(struct vm_area_struct *vma, unsigned long address)
{
+ struct vm_area_struct *next;
+
+ address &= PAGE_MASK;
+ next = vma->vm_next;
+ if (next && next->vm_start == address + PAGE_SIZE) {
+ if (!(next->vm_flags & VM_GROWSUP))
+ return -ENOMEM;
+ }
return expand_upwards(vma, address);
}
@@ -1900,6 +1919,14 @@ find_extend_vma(struct mm_struct *mm, un
#else
int expand_stack(struct vm_area_struct *vma, unsigned long address)
{
+ struct vm_area_struct *prev;
+
+ address &= PAGE_MASK;
+ prev = vma->vm_prev;
+ if (prev && prev->vm_end == address) {
+ if (!(prev->vm_flags & VM_GROWSDOWN))
+ return -ENOMEM;
+ }
return expand_downwards(vma, address);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 04/11] vfs: allow O_PATH file descriptors for fstatfs()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.
There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()". See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.
Reported-and-tested-by: ольга крыжановская
Acked-by: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/statfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -87,7 +87,7 @@ int user_statfs(const char __user *pathn
int fd_statfs(int fd, struct kstatfs *st)
{
- struct file *file = fget(fd);
+ struct file *file = fget_raw(fd);
int error = -EBADF;
if (file) {
error = vfs_statfs(>f_path, st);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 02/11] ALSA: hda - Add fixup for ASUS N56VZ
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit c6cc3d58b4042f5cadae653ff8d3df26af1a0169 upstream. ASUS N56VZ needs a fixup for the bass speaker pin, which was already provided via model=asus-mode4. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=841645 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_realtek.c |1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6832,6 +6832,7 @@ static const struct snd_pci_quirk alc662 SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x1025, 0x038b, "Acer Aspire 8943G", ALC662_FIXUP_ASPIRE), SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800), + SND_PCI_QUIRK(0x1043, 0x1477, "ASUS N56VZ", ALC662_FIXUP_ASUS_MODE4), SND_PCI_QUIRK(0x1043, 0x8469, "ASUS mobo", ALC662_FIXUP_NO_JACK_DETECT), SND_PCI_QUIRK(0x105b, 0x0cd6, "Foxconn", ALC662_FIXUP_ASUS_MODE2), SND_PCI_QUIRK(0x144d, 0xc051, "Samsung R720", ALC662_FIXUP_IDEAPAD), -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 03/11] random: run random_int_secret_init() run after all late_initcalls
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
drivers/char/random.c |3 +--
include/linux/random.h |1 +
init/main.c|2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1435,12 +1435,11 @@ ctl_table random_table[] = {
static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] cacheline_aligned;
-static int __init random_int_secret_init(void)
+int random_int_secret_init(void)
{
get_random_bytes(random_int_secret, sizeof(random_int_secret));
return 0;
}
-late_initcall(random_int_secret_init);
/*
* Get a random word for internal kernel use only. Similar to urandom but
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -56,6 +56,7 @@ extern void add_interrupt_randomness(int
extern void get_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern int random_int_secret_init(void);
#ifndef MODULE
extern const struct file_operations random_fops, urandom_fops;
--- a/init/main.c
+++ b/init/main.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#include
#include
@@ -779,6 +780,7 @@ static void __init do_basic_setup(void)
do_ctors();
usermodehelper_enable();
do_initcalls();
+ random_int_secret_init();
}
static void __init do_pre_smp_initcalls(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 5/7] watchdog: ts72xx_wdt: locking bug in ioctl
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Dan Carpenter commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream. Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a interruptible deadlock. Signed-off-by: Dan Carpenter Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman --- drivers/watchdog/ts72xx_wdt.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/watchdog/ts72xx_wdt.c +++ b/drivers/watchdog/ts72xx_wdt.c @@ -310,7 +310,8 @@ static long ts72xx_wdt_ioctl(struct file case WDIOC_GETSTATUS: case WDIOC_GETBOOTSTATUS: - return put_user(0, p); + error = put_user(0, p); + break; case WDIOC_KEEPALIVE: ts72xx_wdt_kick(wdt); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 3/7] ext4: fix memory leak in xattr
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Jones
commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations. If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.
Spotted with Coverity.
[ Fixed by tytso to set is and bs to NULL after freeing these
pointers, in case in the retry loop we later end up triggering an
error causing a jump to cleanup, at which point we could have a double
free bug. -- Ted ]
Signed-off-by: Dave Jones
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Eric Sandeen
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/xattr.c |2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1271,6 +1271,8 @@ retry:
s_min_extra_isize) {
tried_min_extra_isize++;
new_extra_isize = s_min_extra_isize;
+ kfree(is); is = NULL;
+ kfree(bs); bs = NULL;
goto retry;
}
error = -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/
[ 6/7] drm/radeon: fix hw contexts for SUMO2 asics
3.0-stable review patch. If anyone has any objections, please let me know. -- From: wojciech kapuscinski commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream. They have 4 rather than 8. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=63599 Signed-off-by: wojciech kapuscinski Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/evergreen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -1749,7 +1749,7 @@ static void evergreen_gpu_init(struct ra rdev->config.evergreen.sx_max_export_size = 256; rdev->config.evergreen.sx_max_export_pos_size = 64; rdev->config.evergreen.sx_max_export_smx_size = 192; - rdev->config.evergreen.max_hw_contexts = 8; + rdev->config.evergreen.max_hw_contexts = 4; rdev->config.evergreen.sq_num_cf_insts = 2; rdev->config.evergreen.sc_prim_fifo_size = 0x40; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 2/7] vfs: allow O_PATH file descriptors for fstatfs()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.
There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()". See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.
Reported-and-tested-by: ольга крыжановская
Acked-by: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/statfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -86,7 +86,7 @@ int user_statfs(const char __user *pathn
int fd_statfs(int fd, struct kstatfs *st)
{
- struct file *file = fget(fd);
+ struct file *file = fget_raw(fd);
int error = -EBADF;
if (file) {
error = vfs_statfs(>f_path, st);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 1/7] random: run random_int_secret_init() run after all late_initcalls
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
drivers/char/random.c |3 +--
include/linux/random.h |1 +
init/main.c|2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1435,12 +1435,11 @@ ctl_table random_table[] = {
static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] cacheline_aligned;
-static int __init random_int_secret_init(void)
+int random_int_secret_init(void)
{
get_random_bytes(random_int_secret, sizeof(random_int_secret));
return 0;
}
-late_initcall(random_int_secret_init);
/*
* Get a random word for internal kernel use only. Similar to urandom but
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -56,6 +56,7 @@ extern void add_interrupt_randomness(int
extern void get_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern int random_int_secret_init(void);
#ifndef MODULE
extern const struct file_operations random_fops, urandom_fops;
--- a/init/main.c
+++ b/init/main.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#include
#include
@@ -717,6 +718,7 @@ static void __init do_basic_setup(void)
init_irq_proc();
do_ctors();
do_initcalls();
+ random_int_secret_init();
}
static void __init do_pre_smp_initcalls(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?
On 10/18/2013 09:36 PM, Myklebust, Trond wrote: > On Fri, 2013-10-18 at 21:26 퍭, Helge Deller wrote: >> On 10/17/2013 11:07 PM, Myklebust, Trond wrote: >>> On Thu, 2013-10-17 at 22:42 m, Helge Deller wrote: I'm seeing a regression with current kernel git head when using NFS-mounts. Architecture in my case is parisc, although I don't think that this is relevant. At least kernel 3.10 (and I think 3.11) didn't showed that problem. The symtom is, that "top" shows high usage of either kswapd0 or kswapd1. Here is an output with kswapd1: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 37 root 20 0 000 R 91.8 0.0 63:00.40 kswapd1 28448 root 20 0 3252 1428 1060 R 15.3 0.0 0:00.09 top 1 root 20 0 2784 988 852 S 0.0 0.0 0:09.95 init This is what ps shows: ls:~# ps -ef | grep mount root 1181 1 0 14:51 ?00:00:18 /usr/sbin/automount --pid-file /var/run/autofs.pid root 25331 1181 0 21:25 ?00:00:00 /bin/mount -n -t nfs -s -o nolock,rw,hard,intr homes:/unixhome1 /net/home1 root 25332 25331 0 21:25 ?00:00:00 /sbin/mount.nfs homes:/unixhome1 /net/home1 -s -n -o rw,nolock,hard,intr And using sysrq to show the blocked tasks I get in syslog: SysRq : Show Blocked State mount.nfs D 401040c0 0 25332 25331 0x0010 Backtrace: [<40113a68>] __schedule I know it's not a problem of the NFS server, since the same mount is still ok on other machines. The NFS directory was already mounted and in use when this mount happened again (called by cron-job). Any ideas? >>> >>> If the NFS directory is already mounted, then why is the automounter >>> trying to mount it a second time? >> >> I was wrong in this. >> The directory wasn't mounted yet (or at least it was unmounted in the >> meantime before the new >> mount.nfs was called). >> >> I'm now not even sure, that the high kswapd is really triggered by the NFS >> problem, >> because I now have another machine with the blocked NFS-mount, but without >> the high kswapd usage. >> >> Nevertheless, the blocked nfs mount tasks really make me wonder. There is >> clearly >> some kind of regression since it doesn't happen with older kernels. > > Have you ever reproduced it without the automounter? No, because it happens only after quite some time (>12h) and only if I have it under pressure (load is >9 on a 4-way box). I'll try it as soon as possible. > Also, could you please try a sysRQ-t the next time it happens, so that > we can get a trace of where the mount program is hanging. Knowing that > the mount is stuck in "__schedule()" is not really interesting unless we > know from where that was called. Actually, the machine was still running in this state. Here is sysrq-t: [112009.084000] mount S 401040c0 0 25331 1 0x0010 [112009.084000] Backtrace: [112009.084000] [<40113a68>] __schedule팞瓓ﴱ [112009.232000] [112009.232000] mount.nfs D 401040c0 0 25332 25331 0x0010 [112009.232000] Backtrace: [112009.232000] [<40113a68>] __schedule팞瓓ﴱ Helge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
Jaehoon,
On Fri, Oct 18, 2013 at 2:42 AM, Jaehoon Chung wrote:
>> - clk_en_a = mci_readl(host, CLKENA);
>> + /*
>> + * Low power mode will stop the card clock when idle. According to the
>> + * description of the CLKENA register we should disable low power mode
>> + * for SDIO cards if we need SDIO interrupts to work.
>> + */
>> + if (mmc->caps | MMC_CAP_SDIO_IRQ) {
> mmc->caps & MMC_CAP_SDIO_IRQ?
Wow, that was an embarrassing one. Thanks.
>> + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
>> + u32 clk_en_a_old;
>> + u32 clk_en_a;
>>
>> - if (clk_en_a & clken_low_pwr) {
>> - mci_writel(host, CLKENA, clk_en_a & ~clken_low_pwr);
>> - mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
>> - SDMMC_CMD_PRV_DAT_WAIT, 0);
>> + clk_en_a_old = mci_readl(host, CLKENA);
>> +
>> + if (card->type == MMC_TYPE_SDIO ||
>> + card->type == MMC_TYPE_SD_COMBO) {
>> + set_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> + clk_en_a = clk_en_a_old & ~clken_low_pwr;
>> + } else {
>> + clear_bit(DW_MMC_CARD_NO_LOW_PWR, >flags);
>> + clk_en_a = clk_en_a_old | clken_low_pwr;
> When this condition is entered? card->type is always MMC_TYPE_SDIO or
> MMC_TYPE_SD_COMBO, isn't?
Ugh, that's not intuitive. This callback is only called for SDIO
cards and not MMC/SD cards? That means if you plug in an SDIO card
and then eject it and plug in an SD card you won't get to low power.
Hrm.
I dug around a bit and couldn't find a better way to do this and then
I realized that the other user of the init_card() callback has the
same bug, so for the next version of the series I'm proposing a fix
for mmc core to add this for all types. If you have a better
suggestion, I'm all ears.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock
Jaehoon / James On Fri, Oct 18, 2013 at 2:51 AM, Jaehoon Chung wrote: >> In this case it'd only be a space and code complexity thing I think. I >> suppose in some cases the benefit of finer-grained locking is probably >> pretty marginal, but there's a good case for it here. It might be >> worth renaming the lock to irq_lock or something like that so it's >> clear it doesn't have to protect only for INTMASK in the future - up >> to you. > It seems good that use the irq_lock than intmask_lock. (It's just naming) Done in v2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Run checksumming in parallel accross multiple alu's
On Fri, Oct 18, 2013 at 10:20:35AM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-18 at 12:50 -0400, Neil Horman wrote:
> > >
>
> > for(i=0;i<10;i++) {
> > sum = csum_partial(buf+offset, PAGE_SIZE, sum);
> > offset = (offset < BUFSIZ-PAGE_SIZE) ? offset+PAGE_SIZE : 0;
> > }
>
> Please replace this by random accesses, and use the more standard 1500
> length.
>
> offset = prandom_u32() % (BUFSIZ - 1500);
> offset &= ~1U;
>
> sum = csum_partial(buf + offset, 1500, sum);
>
> You are basically doing sequential accesses, so prefetch should
> be automatically done by cpu itself.
>
> Thanks !
>
>
>
Sure, you got it! Results below. However, they continue to bear out that
parallel execution beats prefetch only execution, and both is better than either
one.
base results:
53156647
59670931
62839770
44842780
39297190
44905905
53300688
53287805
39436951
43021730
AVG=493 ns
prefetch-only results:
40337434
51986404
43509199
53128857
52973171
53520649
53536338
50325466
44864664
47908398
AVG=492 ns
parallel-only results:
52157183
44496511
36180011
38298368
36258099
43263531
45365519
54116344
62529241
63118224
AVG = 475 ns
both prefetch and parallel:
44317078
44526464
45761272
44477906
34868814
44637904
49478309
49718417
58681403
58304972
AVG = 474 ns
Heres the code I was using
#include
#include
#include
#include
#include
#include
#include
#include
#include
static char *buf;
#define BUFSIZ_ORDER 4
#define BUFSIZ ((2 << BUFSIZ_ORDER) * (1024*1024*2))
static int __init csum_init_module(void)
{
int i;
__wsum sum = 0;
struct timespec start, end;
u64 time;
struct page *page;
u32 offset = 0;
page = alloc_pages((GFP_TRANSHUGE & ~__GFP_MOVABLE), BUFSIZ_ORDER);
if (!page) {
printk(KERN_CRIT "NO MEMORY FOR ALLOCATION");
return -ENOMEM;
}
buf = page_address(page);
printk(KERN_CRIT "INITALIZING BUFFER\n");
preempt_disable();
printk(KERN_CRIT "STARTING ITERATIONS\n");
getnstimeofday();
for(i=0;i<10;i++) {
sum = csum_partial(buf+offset, 1500, sum);
offset = prandom_u32() % (BUFSIZ - 1500);
offset &= ~1U;
}
getnstimeofday();
preempt_enable();
if ((unsigned long)start.tv_nsec > (unsigned long)end.tv_nsec)
time = (ULONG_MAX - (unsigned long)end.tv_nsec) + (unsigned
long)start.tv_nsec;
else
time = (unsigned long)end.tv_nsec - (unsigned
long)start.tv_nsec;
printk(KERN_CRIT "COMPLETED 10 iterations of csum in %llu
nanosec\n", time);
__free_pages(page, BUFSIZ_ORDER);
return 0;
}
static void __exit csum_cleanup_module(void)
{
return;
}
module_init(csum_init_module);
module_exit(csum_cleanup_module);
MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.12-rcX - NFS regression - kswapd0 / kswapd1 stays using 100% CPU?
On Fri, 2013-10-18 at 22:03 +0200, Helge Deller wrote: > On 10/18/2013 09:36 PM, Myklebust, Trond wrote: > > Also, could you please try a sysRQ-t the next time it happens, so that > > we can get a trace of where the mount program is hanging. Knowing that > > the mount is stuck in "__schedule()" is not really interesting unless we > > know from where that was called. > > Actually, the machine was still running in this state. > Here is sysrq-t: > [112009.084000] mount S 401040c0 0 25331 1 > 0x0010 > [112009.084000] Backtrace: > [112009.084000] [<40113a68>] __schedule팞瓓ﴱ > [112009.232000] > [112009.232000] mount.nfs D 401040c0 0 25332 25331 > 0x0010 > [112009.232000] Backtrace: > [112009.232000] [<40113a68>] __schedule팞瓓ﴱ That makes no sense unless sysrq-t works differently on parisc than on other platforms. I'd expect the backtrace to at least include a system call. Parisc experts? -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.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 net-next] em_ipset: use dev_net() accessor
From: Stephen Hemminger Date: Wed, 16 Oct 2013 17:29:34 -0700 > Randy found that if network namespace not enabled then > nd_net does not exist and would cause compilation failure. > > This is handled correctly by using the dev_net() macro. > > Signed-off-by: Stephen Hemminger > Acked-by: Randy Dunlap Applied, thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 5/6] ARM: dts: Specify clocks for timer on bcm11351
On Thu, Oct 17, 2013 at 7:06 AM, Mark Rutland wrote: >> diff --git a/arch/arm/boot/dts/bcm11351.dtsi >> b/arch/arm/boot/dts/bcm11351.dtsi >> index 193659c..39c1395 100644 >> --- a/arch/arm/boot/dts/bcm11351.dtsi >> +++ b/arch/arm/boot/dts/bcm11351.dtsi >> @@ -95,7 +95,7 @@ >> compatible = "brcm,kona-timer"; >> reg = <0x35006000 0x1000>; >> interrupts = ; >> - clock-frequency = <32768>; >> + clocks = <_timer_clk>; > > This should probably be after the code change that enables support for a > clocks property. > > Thanks, > Mark. This is already the case. The driver change is patch 4 and this dts change is patch 5 of the series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 0/9] Introduce support to lazy initialize mostly static keys
From: Hannes Frederic Sowa Date: Thu, 17 Oct 2013 07:31:54 +0200 > This series implements support for delaying the initialization of secret > keys, e.g. used for hashing, for as long as possible. This functionality > is implemented by a new macro, net_get_random_bytes. > > I already used it to protect the socket hashes, the syncookie secret > (most important) and the tcp_fastopen secrets. I generally have no problem with this series and like how it improves the secret being input on the ipv6 side. Please address the commit message feedback and respin this series. 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/
