Re: [PATCH 01/16] mac80211: fix TX device statistics for monitor interfaces
Pali Rohár writes: > From: David Gnedt > > Count TX packets and bytes also for monitor interfaces. > > Signed-of-by: David Gnedt You should send mac80211 patches separately, not inside a wl1251 patchset. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 rebase] perf/ui/tui: don't force a refresh during progress update
Hi Patrick, On Fri, 25 Oct 2013 20:25:49 -0400, Patrick Palka wrote: > Each call to tui_progress__update() would forcibly refresh the entire > screen. This is somewhat inefficient and causes noticable flickering > during the startup of perf-report, especially on large/slow terminals. > > It looks like the force-refresh in tui_progress__update() serves no > purpose other than to clear the screen so that the progress bar of a > previous operation does not subsume that of a subsequent operation. > But we can do just that in a much more efficient manner by clearing only > the region that a previous progress bar may have occupied before > repainting the new progress bar. Then the force-refresh could be > removed with no change in visuals. > > This patch disables the slow force-refresh in tui_progress__update() and > instead calls SLsmg_fill_region() on the entire area that the progress > bar may occupy before repainting it. This change makes the startup of > perf-report much faster and appear much "smoother". > > It turns out that this was a big bottleneck in the startup speed of > perf-report -- with this patch, perf-report starts up ~2x faster (1.1s > vs 0.55s) on my machines. (These numbers were measured by running > "time perf report" on an 8MB perf.data and pressing 'q' immediately.) Acked-by: Namhyung Kim Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
On 10/28/13 at 01:49pm, Dave Young wrote: > > without Cong's patch, kernel will fail to reserve, and user would dig > > s/Chao/Cong ;) s/Cong/Chao in fact :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel/kallsyms.c: only show legal kernel symbol
Ming Lei writes:
> On Mon, 28 Oct 2013 13:44:30 +1030
> Rusty Russell wrote:
>
>> Ming Lei writes:
>>
>> I don't know... It would be your job, as the person making the change,
>> to find all the users of kallsyms and prove that.
>>
>> This is why it is easier not to include incorrect values in the kernel's
>> kallsyms in the first place.
>
> OK, thanks for your comment, and I figured out one way to do it in
> scripts/kallsyms.c, could you comment on below patch?
Looks great! Seems like we spent more time arguing than it took you to
code that up.
Acked-by: Rusty Russell
Russell, this seems logical for you to take along with the changes which
caused the problem?
Thanks,
Rusty.
> --
> From 4327534dedfa60d208ac3e23db7556c243e1c7dc Mon Sep 17 00:00:00 2001
> From: Ming Lei
> Date: Mon, 28 Oct 2013 13:04:49 +0800
> Subject: [PATCH] scripts/kallsyms: filter symbols not in kernel address space
>
> This patch uses CONFIG_PAGE_OFFSET to filter symbols which
> are not in kernel address space because these symbols are
> generally for generating code purpose and can't be run at
> kernel mode, so we needn't keep them in /proc/kallsyms.
>
> For example, on ARM there are some symbols which may be
> linked in relocatable code section, then perf can't parse
> symbols any more from /proc/kallsyms, this patch fixes the
> problem.
>
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Rusty Russell
> Cc: Michal Marek
> Signed-off-by: Ming Lei
> ---
> scripts/kallsyms.c | 12 +++-
> scripts/link-vmlinux.sh |2 ++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> index 487ac6f..9a11f9f 100644
> --- a/scripts/kallsyms.c
> +++ b/scripts/kallsyms.c
> @@ -55,6 +55,7 @@ static struct sym_entry *table;
> static unsigned int table_size, table_cnt;
> static int all_symbols = 0;
> static char symbol_prefix_char = '\0';
> +static unsigned long long kernel_start_addr = 0;
>
> int token_profit[0x1];
>
> @@ -65,7 +66,10 @@ unsigned char best_table_len[256];
>
> static void usage(void)
> {
> - fprintf(stderr, "Usage: kallsyms [--all-symbols]
> [--symbol-prefix=] < in.map > out.S\n");
> + fprintf(stderr, "Usage: kallsyms [--all-symbols] "
> + "[--symbol-prefix=] "
> + "[--page-offset=] "
> + "< in.map > out.S\n");
> exit(1);
> }
>
> @@ -194,6 +198,9 @@ static int symbol_valid(struct sym_entry *s)
> int i;
> int offset = 1;
>
> + if (s->addr < kernel_start_addr)
> + return 0;
> +
> /* skip prefix char */
> if (symbol_prefix_char && *(s->sym + 1) == symbol_prefix_char)
> offset++;
> @@ -646,6 +653,9 @@ int main(int argc, char **argv)
> if ((*p == '"' && *(p+2) == '"') || (*p == '\''
> && *(p+2) == '\''))
> p++;
> symbol_prefix_char = *p;
> + } else if (strncmp(argv[i], "--page-offset=", 14) == 0)
> {
> + const char *p = [i][14];
> + kernel_start_addr = strtoull(p, NULL, 16);
> } else
> usage();
> }
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 0149949..32b10f5 100644
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -82,6 +82,8 @@ kallsyms()
> kallsymopt="${kallsymopt} --all-symbols"
> fi
>
> + kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
> +
> local aflags="${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} \
> ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS}"
>
> --
> 1.7.9.5
>
>
>
>
> Thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts/tags.sh: remove obsolete __devinit[const|data]
This removes the use of __devinitconst and __devinitdata in scripts/tags.sh,
which were removed in 3.8.
Signed-off-by: Michael Opdenacker
---
scripts/tags.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 74f02e4..72035c7 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -149,8 +149,8 @@ dogtags()
exuberant()
{
all_target_sources | xargs $1 -a\
- -I __initdata,__exitdata,__initconst,__devinitdata \
- -I __devinitconst,__cpuinitdata,__initdata_memblock \
+ -I __initdata,__exitdata,__initconst\
+ -I __cpuinitdata,__initdata_memblock\
-I __refdata,__attribute\
-I __acquires,__releases,__deprecated \
-I __read_mostly,__aligned,cacheline_aligned\
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
> Again, for distribution, when new kernel is added, new kernel will all > have ",high" > and new kexec-tools get installed. > > Even we want to extend crashkernel=XM, then i would like to have > it identical to crashkernel=XM,high instead. My points: I can accept the approach of extending crashkernel=XM to use high mem firstly if we could remove the extra 72M in low mem, but apparently it's not doable now. So I would vote for Chao's patch. Also newer kernel use more complex ",high" then older kernel looks not good. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: ktap inclusion in drivers/staging/?
(2013/10/25 19:15), Ingo Molnar wrote: > > * Jovi Zhangwei wrote: > >> Hi Ingo, >> >> On Thu, Oct 24, 2013 at 3:58 PM, Ingo Molnar wrote: >>> >>> Greg, >>> >>> I was surprised to see 'ktap' appear in the staging tree silently, >>> via these commits that are visible in today's staging-next: >>> >>> 2c856b9e3e06 staging: ktap: remove unused header file >>> 687b63a3bfd5 staging: ktap: update email name in MAINTAINERS >>> c63a164271f8 staging: ktap: add to the kernel tree >>> >>> ktap is pretty fresh instrumentation code, announced on lkml a >>> couple of months ago, and so far I haven't seen much technical >>> discussion of integrating ktap upstream, mostly I suspect because >>> not a _single_ patch was sent to linux-kernel for review. (!) >>> >> I accept Greg revert this in staging-next tree, It's entirely my fault, >> sorry. > > Thanks! > >>> An announcement of a Git tree was made (which Git tree is not very >>> structured), and some very minimal discussion ensued, but no actual >>> patches were sent with an intent to merge, no technical arguments >>> were made in favor of merging and nothing conclusive was achieved. >>> >>> A couple of very quick (and incomplete) technical objections: >>> >>> - The Git commits in staging an absolutely unstructured, >>>unreviewable mess, due to a single commit adding 16 KLOCs (!) of >>>code: >>> >>> 80 files changed, 16376 insertions(+) >>> >>>(I looked at the ktap Git tree as well, it's not much better.) >>> >>> - Most of the kernel code comes with near zero explanations in the >>>code itself. I looked at the kernel code in >>>drivers/staging/ktap/interpreter/. I have not found a _single_ >>>substantial in-code comment about design details and >>>implementational considerations. (!!) >>> >> I will add more comments for it, also will draft a design detail in >> doc/ directory. >> >>> - From the little I've been able to decode I get the impression >>>that the design should be much more integrated into the rest of >>>instrumentation: the in-kernel Lua bytecode interpreter looks >>>interesting, it could be an intelligent upgrade (or even outright >>>replacement) for the current 'filter' interpreter concept we have >>>for tracepoints - instead of putting a parallel interpreter >>>implementation into the kernel. Hmm, IMHO, the current simple filter itself is not needed to be merged at least ftrace side, since the ktap filter requires userspace compiler on the other hand ftrace does it directly by debugfs. Perhaps, after the bytecode generator and JIT compiler is introduced, we can pass filter rules to the generator via debugfs. >>> - In a similar fashion, it would be nice to see it integrated with >>>'perf probe' or 'perf ktap', so that users can create probes from >>>a single place, with coherent syntax and integrated analysis >>>capabilities. I.e. there's no reason to not make this a >>>relatively pain-less yet very useful transition. >> >> Yes, I also mentioned this in my RFC email post before, that's the >> reason why I use perf-like interface in ktap as much as I can, >> like perf-tracepoints and perf-probe, also ktap can reuse perf >> debuginfo handling code in future, we are on the same page at this >> technical point. > > Okay, cool! I've also Cc:-ed Masami, who was also very receptive in > person of the idea to merge this kind of scripting into perf probe. Yeah, that is what I recommend him. If ktap uses directly perf tools, it will simplify its design (compared with systemtap...) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 0cc4b69960f3 ("drm/i915:
Mask LPSP to get PSR working even with Power Well in use by audio") from
Linus' tree and commit 52e1e223456e ("drm/i915/dp: workaround BIOS eDP
bpp clamping issue") from the drm-intel-fixes tree and commits
18442d087864 ("drm/i915: Fix port_clock and adjusted_mode.clock readout
all over") and 18b5992c3756 ("drm/i915: Calculate PSR register offsets
from base + gen") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_dp.c
index 1a431377d83b,1e3d2720d811..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1402,31 -1469,20 +1469,40 @@@ static void intel_dp_get_config(struct
pipe_config->port_clock = 27;
}
+ if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
+ pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
+ /*
+ * This is a big fat ugly hack.
+ *
+ * Some machines in UEFI boot mode provide us a VBT that has 18
+ * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+ * unknown we fail to light up. Yet the same BIOS boots up with
+ * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+ * max, not what it tells us to use.
+ *
+ * Note: This will still be broken if the eDP panel is not lit
+ * up by the BIOS, and thus we can't get the mode at module
+ * load.
+ */
+ DRM_DEBUG_KMS("pipe has %d bpp for eDP panel, overriding
BIOS-provided max %d bpp\n",
+pipe_config->pipe_bpp, dev_priv->vbt.edp_bpp);
+ dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
+ }
++
+ dotclock = intel_dotclock_calculate(pipe_config->port_clock,
+ _config->dp_m_n);
+
+ if (HAS_PCH_SPLIT(dev_priv->dev) && port != PORT_A)
+ ironlake_check_encoder_dotclock(pipe_config, dotclock);
+
+ pipe_config->adjusted_mode.crtc_clock = dotclock;
}
- static bool is_edp_psr(struct intel_dp *intel_dp)
+ static bool is_edp_psr(struct drm_device *dev)
{
- return is_edp(intel_dp) &&
- intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ return dev_priv->psr.sink_support;
}
static bool intel_edp_is_psr_enabled(struct drm_device *dev)
@@@ -1486,8 -1542,8 +1562,8 @@@ static void intel_edp_psr_setup(struct
intel_edp_psr_write_vsc(intel_dp, _vsc);
/* Avoid continuous PSR exit by masking memup and hpd */
- I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
+ I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
+ EDP_PSR_DEBUG_MASK_HPD);
intel_dp->psr_setup_done = true;
}
pgpOr_Wo6QGTk.pgp
Description: PGP signature
Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616
On 10/24/2013 07:20 AM, Fengguang Wu wrote: > Yes it reduces the sleeping function bug: > > /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/7c4ed2767afb813493b0a8fb18d666cd44550963 > > ++---+--+--+ > | >| v3.12-rc3 | 3ab098df35f8 | 7c4ed2767afb | > ++---+--+--+ > | good_boots >| 30| 0| 93 | > | has_kernel_error_warning >| 0 | 20 | 7| > | BUG:sleeping_function_called_from_invalid_context_at_kernel/mutex.c >| 0 | 20 | | > | INFO:rcu_sched_self-detected_stall_on_CPU(t=jiffies_g=c=q=) >| 0 | 0| 1| > | INFO:task_blocked_for_more_than_seconds >| 0 | 0| 2| > | > INFO:NMI_handler(arch_trigger_all_cpu_backtrace_handler)took_too_long_to_run:msecs > | 0 | 0| 1| > | Kernel_panic-not_syncing:hung_task:blocked_tasks >| 0 | 0| 1| > | BUG:kernel_test_crashed >| 0 | 0| 3| > | BUG:kernel_test_hang >| 0 | 0| 1| > ++---+--+--+ > > However I'll need to increase tests on v3.12-rc3 to make sure it's not > the patch that added the other error messages. > > Thanks, > Fengguang Thanks, any more update on the result of v3.12-rc3 for this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] iio: exynos_adc: use wait_for_completion_timeout instead of interruptible
1. The irq routine is so simple (just one register read) shouldn't be long
Hence, reduce the timeout to 100milli secs,
2. With 100ms of wait time, interruptible is very much unnecessary.
Hence, use wait_for_completion_timeout instead of
wait_for_completion_interruptible_timeout
3. Reset software if a timeout happens.
4. Add INIT_COMPLETION before the wait_for_completion_timeout in raw_read()
Note: submitted for review at https://patchwork.kernel.org/patch/2279591/
Signed-off-by: Naveen Krishna Chatradhi
Cc: Doug Anderson
Cc: Lars-Peter Clausen
Reviewed-on: https://chromium-review.googlesource.com/172724
Reviewed-by: Doug Anderson
---
Changes since v1:
As per discussion at
http://marc.info/?l=linux-kernel=136517637228869=3
Changes since v2:
None.
Rebased and reposting.
Changes since v3:
1. commit message change and
2. removed an unncessary assignment
Changes since v4:
Moved INIT_COMPLETION call to the starting of the function
drivers/iio/adc/exynos_adc.c | 69
1 file changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 0f2ca60..a675751 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -81,7 +81,7 @@ enum adc_version {
#define ADC_CON_EN_START (1u << 0)
#define ADC_DATX_MASK 0xFFF
-#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
+#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
void __iomem*regs;
@@ -111,6 +111,30 @@ static inline unsigned int exynos_adc_get_version(struct
platform_device *pdev)
return (unsigned int)match->data;
}
+static void exynos_adc_hw_init(struct exynos_adc *info)
+{
+ u32 con1, con2;
+
+ if (info->version == ADC_V2) {
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info->regs));
+
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info->regs));
+
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info->regs));
+ } else {
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info->regs));
+ }
+}
+
static int exynos_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
@@ -120,11 +144,13 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
u32 con1, con2;
+ int ret;
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
mutex_lock(_dev->mlock);
+ INIT_COMPLETION(info->completion);
/* Select the channel to be used and Trigger conversion */
if (info->version == ADC_V2) {
@@ -144,16 +170,21 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ADC_V1_CON(info->regs));
}
- timeout = wait_for_completion_interruptible_timeout
+ timeout = wait_for_completion_timeout
(>completion, EXYNOS_ADC_TIMEOUT);
- *val = info->value;
+ if (timeout == 0) {
+ dev_warn(_dev->dev, "Conversion timed out! Resetting\n");
+ exynos_adc_hw_init(info);
+ ret = -ETIMEDOUT;
+ } else {
+ *val = info->value;
+ *val2 = 0;
+ ret = IIO_VAL_INT;
+ }
mutex_unlock(_dev->mlock);
- if (timeout == 0)
- return -ETIMEDOUT;
-
- return IIO_VAL_INT;
+ return ret;
}
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
@@ -225,30 +256,6 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
-{
- u32 con1, con2;
-
- if (info->version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info->regs));
-
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info->regs));
-
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info->regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
-
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info->regs));
- }
-}
-
static int exynos_adc_probe(struct
Re: [PATCH 6/8] perf tools: Add new comm infrastructure
Hi David, On Fri, 25 Oct 2013 12:19:07 -0600, David Ahern wrote: > On 10/25/13 12:12 PM, Frederic Weisbecker wrote: >> Oh I see. It's possible that my massive conversion to use the comm >> accessor got blind at some point and left over a few things. I >> remember that I only lightly tested that new comm infrastructure. I >> mean I tested a lot of "perf report -s foo,bar" combinations for >> performance comparisons but I haven't tested the perf script and all >> the other perf tools. >> >> I'll rebase these patches and test that wider before resending. > > specifically, I see stuff like perf forking ls and comm still shows as > perf even though there is COMM record with the rename to ls. I believe > the test case was something like: > > perf sched record -- ls > perf script Hmm.. did you try my latest v5 patchset? I couldn't reproduce the case at least for the command lines above. $ perf script perf 24810 [007] 1546517.815809: sched:sched_stat_runtime: comm=perf pid=24810 ru perf 24810 [007] 1546517.815909: sched:sched_wakeup: comm=perf pid=24811 prio=120 swapper 0 [008] 1546517.815913: sched:sched_switch: prev_comm=swapper/8 prev_pid perf 24810 [007] 1546517.815953: sched:sched_stat_runtime: comm=perf pid=24810 ru perf 24810 [007] 1546517.815957: sched:sched_switch: prev_comm=perf prev_pid=2481 perf 24811 [008] 1546517.815992: sched:sched_wakeup: comm=migration/8 pid=48 prio perf 24811 [008] 1546517.815993: sched:sched_stat_runtime: comm=perf pid=24811 ru perf 24811 [008] 1546517.815993: sched:sched_switch: prev_comm=perf prev_pid=2481 migration/848 [008] 1546517.815996: sched:sched_migrate_task: comm=perf pid=24811 pr migration/848 [008] 1546517.816000: sched:sched_switch: prev_comm=migration/8 prev_p swapper 0 [009] 1546517.816002: sched:sched_switch: prev_comm=swapper/9 prev_pid ls 24811 [009] 1546517.816808: sched:sched_stat_runtime: comm=ls pid=24811 runt Here, the process 24811 has only 3 samples before COMM event $ perf report -D | grep 24811 | grep -v MMAP | head 0 0 0x629b0 [0x38]: PERF_RECORD_COMM: perf:24811 8 1546517815992058 0x65f50 [0x68]: PERF_RECORD_SAMPLE(IP, 1): 24811/24811: 0x81091512 period: 1 addr: 0 ... thread: perf:24811 8 1546517815993189 0x65fb8 [0x70]: PERF_RECORD_SAMPLE(IP, 1): 24811/24811: 0x81099d25 period: 83314 addr: 0 ... thread: perf:24811 8 1546517815993975 0x66028 [0x80]: PERF_RECORD_SAMPLE(IP, 1): 24811/24811: 0x81659d60 period: 1 addr: 0 ... thread: perf:24811 9 1546517816224342 0x66378 [0x38]: PERF_RECORD_COMM: ls:24811 9 1546517816808637 0x667f0 [0x70]: PERF_RECORD_SAMPLE(IP, 1): 24811/24811: 0x81099d25 period: 810663 addr: 0 ... thread: ls:24811 $ perf version perf version 3.11.ge9eb20 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_drv.c between commit 828c79087cec ("drm/i915:
Disable GGTT PTEs on GEN6+ suspend") from Linus' tree and commit
9d49c0ef4089 ("drm/i915: move more code to __i915_drm_thaw") from the drm
tree.
I fixed it up (the section of code added to i915_drm_thaw by the first
patch looks as though it could not do anything, so I just used the latter
patch) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpvDDBQf0rki.pgp
Description: PGP signature
[PATCH 1/1] tty: Add NULL check to return value of kzalloc()
Function kzalloc() may return a NULL pointer, it should be checked against NULL
before used.
This bug is found by a static analysis tool developed by RUC_SoftSec, supported
by China.X.Orion.
Signed-off-by: RUC_SoftSec
---
drivers/tty/vt/vt.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 9a8e8c5..fcba3ce 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2887,12 +2887,14 @@ static int __init con_init(void)
for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
GFP_NOWAIT);
- INIT_WORK(_cons[currcons].SAK_work, vc_SAK);
- tty_port_init(>port);
- visual_init(vc, currcons, 1);
- vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
- vc_init(vc, vc->vc_rows, vc->vc_cols,
- currcons || !vc->vc_sw->con_save_screen);
+ if (vc) {
+ INIT_WORK(_cons[currcons].SAK_work, vc_SAK);
+ tty_port_init(>port);
+ visual_init(vc, currcons, 1);
+ vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size,
GFP_NOWAIT);
+ vc_init(vc, vc->vc_rows, vc->vc_cols,
+ currcons ||
!vc->vc_sw->con_save_screen);
+ }
}
currcons = fg_console = 0;
master_display_fg = vc = vc_cons[currcons].d;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] squashfs: enhance parallel I/O
Now squashfs have used for only one stream buffer for decompression
so it hurts parallel read performance so this patch supports
multiple decompressor to enhance performance parallel I/O.
Four 1G file dd read on KVM machine which has 2 CPU and 4G memory.
dd if=test/test1.dat of=/dev/null &
dd if=test/test2.dat of=/dev/null &
dd if=test/test3.dat of=/dev/null &
dd if=test/test4.dat of=/dev/null &
old : 1m39s -> new : 9s
* From v1
* Change comp_strm with decomp_strm - Phillip
* Change/add comments - Phillip
Signed-off-by: Minchan Kim
---
fs/squashfs/Kconfig | 13 +++
fs/squashfs/Makefile |9 +-
fs/squashfs/decompressor_multi.c | 200 ++
3 files changed, 221 insertions(+), 1 deletion(-)
create mode 100644 fs/squashfs/decompressor_multi.c
diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index c70111e..1c6d340 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -63,6 +63,19 @@ config SQUASHFS_LZO
If unsure, say N.
+config SQUASHFS_MULTI_DECOMPRESSOR
+ bool "Use multiple decompressors for handling parallel I/O"
+ depends on SQUASHFS
+ help
+ By default Squashfs uses a single decompressor but it gives
+ poor performance on parallel I/O workloads when using multiple CPU
+ machines due to waiting on decompressor availability.
+
+ If you have a parallel I/O workload and your system has enough memory,
+ using this option may improve overall I/O performance.
+
+ If unsure, say N.
+
config SQUASHFS_XZ
bool "Include support for XZ compressed file systems"
depends on SQUASHFS
diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
index c223c84..dfebc3b 100644
--- a/fs/squashfs/Makefile
+++ b/fs/squashfs/Makefile
@@ -4,8 +4,15 @@
obj-$(CONFIG_SQUASHFS) += squashfs.o
squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
-squashfs-y += namei.o super.o symlink.o decompressor.o decompressor_single.o
+squashfs-y += namei.o super.o symlink.o decompressor.o
+
squashfs-$(CONFIG_SQUASHFS_XATTR) += xattr.o xattr_id.o
squashfs-$(CONFIG_SQUASHFS_LZO) += lzo_wrapper.o
squashfs-$(CONFIG_SQUASHFS_XZ) += xz_wrapper.o
squashfs-$(CONFIG_SQUASHFS_ZLIB) += zlib_wrapper.o
+
+ifdef CONFIG_SQUASHFS_MULTI_DECOMPRESSOR
+ squashfs-y += decompressor_multi.o
+else
+ squashfs-y += decompressor_single.o
+endif
diff --git a/fs/squashfs/decompressor_multi.c b/fs/squashfs/decompressor_multi.c
new file mode 100644
index 000..462731d
--- /dev/null
+++ b/fs/squashfs/decompressor_multi.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (c) 2013
+ * Minchan Kim
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "squashfs_fs.h"
+#include "squashfs_fs_sb.h"
+#include "decompressor.h"
+#include "squashfs.h"
+
+/*
+ * This file implements multi-threaded decompression in the
+ * decompressor framework
+ */
+
+
+/*
+ * The reason that multiply two is that a CPU can request new I/O
+ * while it is waiting previous request.
+ */
+#define MAX_DECOMPRESSOR (num_online_cpus() * 2)
+
+
+int squashfs_max_decompressors(void)
+{
+ return MAX_DECOMPRESSOR;
+}
+
+
+struct squashfs_stream {
+ void*comp_opts;
+ struct list_headstrm_list;
+ struct mutexmutex;
+ int avail_decomp;
+ wait_queue_head_t wait;
+};
+
+
+struct decomp_stream {
+ void *stream;
+ struct list_head list;
+};
+
+
+static void put_decomp_stream(struct decomp_stream *decomp_strm,
+ struct squashfs_stream *stream)
+{
+ mutex_lock(>mutex);
+ list_add(_strm->list, >strm_list);
+ mutex_unlock(>mutex);
+ wake_up(>wait);
+}
+
+void *squashfs_decompressor_create(struct squashfs_sb_info *msblk,
+ void *comp_opts)
+{
+ struct squashfs_stream *stream;
+ struct decomp_stream *decomp_strm = NULL;
+ int err = -ENOMEM;
+
+ stream = kzalloc(sizeof(*stream), GFP_KERNEL);
+ if (!stream)
+ goto out;
+
+ stream->comp_opts = comp_opts;
+ mutex_init(>mutex);
+ INIT_LIST_HEAD(>strm_list);
+ init_waitqueue_head(>wait);
+
+ /*
+* We should have a decompressor at least as default
+* so if we fail to allocate new decompressor dynamically,
+* we could always fall back to default decompressor and
+* file system works.
+*/
+ decomp_strm = kmalloc(sizeof(*decomp_strm), GFP_KERNEL);
+ if (!decomp_strm)
+ goto out;
+
+ decomp_strm->stream = msblk->decompressor->init(msblk,
+ stream->comp_opts);
+ if
Re: [RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol
On Mon, 28 Oct 2013 13:44:30 +1030
Rusty Russell wrote:
> Ming Lei writes:
>
> I don't know... It would be your job, as the person making the change,
> to find all the users of kallsyms and prove that.
>
> This is why it is easier not to include incorrect values in the kernel's
> kallsyms in the first place.
OK, thanks for your comment, and I figured out one way to do it in
scripts/kallsyms.c, could you comment on below patch?
--
>From 4327534dedfa60d208ac3e23db7556c243e1c7dc Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Mon, 28 Oct 2013 13:04:49 +0800
Subject: [PATCH] scripts/kallsyms: filter symbols not in kernel address space
This patch uses CONFIG_PAGE_OFFSET to filter symbols which
are not in kernel address space because these symbols are
generally for generating code purpose and can't be run at
kernel mode, so we needn't keep them in /proc/kallsyms.
For example, on ARM there are some symbols which may be
linked in relocatable code section, then perf can't parse
symbols any more from /proc/kallsyms, this patch fixes the
problem.
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: Rusty Russell
Cc: Michal Marek
Signed-off-by: Ming Lei
---
scripts/kallsyms.c | 12 +++-
scripts/link-vmlinux.sh |2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 487ac6f..9a11f9f 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -55,6 +55,7 @@ static struct sym_entry *table;
static unsigned int table_size, table_cnt;
static int all_symbols = 0;
static char symbol_prefix_char = '\0';
+static unsigned long long kernel_start_addr = 0;
int token_profit[0x1];
@@ -65,7 +66,10 @@ unsigned char best_table_len[256];
static void usage(void)
{
- fprintf(stderr, "Usage: kallsyms [--all-symbols]
[--symbol-prefix=] < in.map > out.S\n");
+ fprintf(stderr, "Usage: kallsyms [--all-symbols] "
+ "[--symbol-prefix=] "
+ "[--page-offset=] "
+ "< in.map > out.S\n");
exit(1);
}
@@ -194,6 +198,9 @@ static int symbol_valid(struct sym_entry *s)
int i;
int offset = 1;
+ if (s->addr < kernel_start_addr)
+ return 0;
+
/* skip prefix char */
if (symbol_prefix_char && *(s->sym + 1) == symbol_prefix_char)
offset++;
@@ -646,6 +653,9 @@ int main(int argc, char **argv)
if ((*p == '"' && *(p+2) == '"') || (*p == '\''
&& *(p+2) == '\''))
p++;
symbol_prefix_char = *p;
+ } else if (strncmp(argv[i], "--page-offset=", 14) == 0)
{
+ const char *p = [i][14];
+ kernel_start_addr = strtoull(p, NULL, 16);
} else
usage();
}
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 0149949..32b10f5 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,6 +82,8 @@ kallsyms()
kallsymopt="${kallsymopt} --all-symbols"
fi
+ kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
+
local aflags="${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} \
${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS}"
--
1.7.9.5
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit e1264ebe9ff4 ("Revert
"drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is
done"") from Linus' tree and commit ce352550327b ("drm/i915: Fix
unclaimed register access due to delayed VGA memory disable") from the
drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_dma.c
index d5c784d48671,437886641d90..
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1348,6 -1358,13 +1355,8 @@@ static int i915_load_modeset_init(struc
*/
intel_fbdev_initial_config(dev);
- /*
- * Must do this after fbcon init so that
- * vgacon_save_screen() works during the handover.
- */
- i915_disable_vga_mem(dev);
+ intel_display_power_put(dev, POWER_DOMAIN_VGA);
+
/* Only enable hotplug handling once the fbdev is fully set up. */
dev_priv->enable_hotplug_processing = true;
pgpPDgY0Jpk5R.pgp
Description: PGP signature
Re: State of "perf: Add a new sort order: SORT_INCLUSIVE"
Hi Rodrigo, On Fri, 25 Oct 2013 16:07:21 +0100, Rodrigo Campos wrote: > Hi Namhyung, > > Frederic Weisbecker and Arnaldo Carvalho de Melo told me on IRC that you were > working to forward-port a patch that adds a new sort order to perf report, > SORT_INCLUSIVE. > > That will be useful for me and I was wondering if you are still working on > that > or if there is a newer version than v6: > > http://thread.gmane.org/gmane.linux.kernel.perf.user/882 > > > Maybe you have a newer version of it not sent to the list ? Or do you plan to > work on it anytime soon ? > > If there is any branch to test, please let me know :) Yes I have a patch series for that. But it's not a new sort order but a new command line option --culumate. I don't think it should be a new sort order since it affects only how it counts period value on each sample not how samples are sorted/grouped. It's about a year since I sent this series to list. I'll work on it and send it to the list soon. But before that I have to re-read what's the Frederic's concern - IIRC it's about consolidating code in perf report that does similar things on branch stack. Frederic, can you remember what was the problem? Anyway, You can find the series and discussion on the link below: https://lkml.org/lkml/2012/9/13/81 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] f2fs: fix a deadlock during init_acl procedure
The deadlock is found through the following scenario.
sys_mkdir()
-> f2fs_add_link()
-> __f2fs_add_link()
-> init_inode_metadata()
: lock_page(inode);
-> f2fs_init_acl()
-> f2fs_set_acl()
-> f2fs_setxattr(..., NULL)
: This NULL page incurs a deadlock at update_inode_page().
So, likewise f2fs_init_security(), this patch adds a parameter to transfer the
locked inode page to f2fs_setxattr().
Found by Linux File System Verification project (linuxtesting.org).
Reported-by: Alexey Khoroshilov
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/acl.c | 15 ---
fs/f2fs/acl.h | 5 +++--
fs/f2fs/dir.c | 2 +-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index f1a6975..d0fc287 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -205,7 +205,8 @@ struct posix_acl *f2fs_get_acl(struct inode *inode, int
type)
return acl;
}
-static int f2fs_set_acl(struct inode *inode, int type, struct posix_acl *acl)
+static int f2fs_set_acl(struct inode *inode, int type,
+ struct posix_acl *acl, struct page *ipage)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct f2fs_inode_info *fi = F2FS_I(inode);
@@ -250,7 +251,7 @@ static int f2fs_set_acl(struct inode *inode, int type,
struct posix_acl *acl)
}
}
- error = f2fs_setxattr(inode, name_index, "", value, size, NULL);
+ error = f2fs_setxattr(inode, name_index, "", value, size, ipage);
kfree(value);
if (!error)
@@ -260,7 +261,7 @@ static int f2fs_set_acl(struct inode *inode, int type,
struct posix_acl *acl)
return error;
}
-int f2fs_init_acl(struct inode *inode, struct inode *dir)
+int f2fs_init_acl(struct inode *inode, struct inode *dir, struct page *ipage)
{
struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
struct posix_acl *acl = NULL;
@@ -280,7 +281,7 @@ int f2fs_init_acl(struct inode *inode, struct inode *dir)
goto cleanup;
if (S_ISDIR(inode->i_mode)) {
- error = f2fs_set_acl(inode, ACL_TYPE_DEFAULT, acl);
+ error = f2fs_set_acl(inode, ACL_TYPE_DEFAULT, acl, ipage);
if (error)
goto cleanup;
}
@@ -288,7 +289,7 @@ int f2fs_init_acl(struct inode *inode, struct inode *dir)
if (error < 0)
return error;
if (error > 0)
- error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl, ipage);
cleanup:
posix_acl_release(acl);
return error;
@@ -314,7 +315,7 @@ int f2fs_acl_chmod(struct inode *inode)
if (error)
return error;
- error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl, NULL);
posix_acl_release(acl);
return error;
}
@@ -389,7 +390,7 @@ static int f2fs_xattr_set_acl(struct dentry *dentry, const
char *name,
acl = NULL;
}
- error = f2fs_set_acl(inode, type, acl);
+ error = f2fs_set_acl(inode, type, acl, NULL);
release_and_out:
posix_acl_release(acl);
diff --git a/fs/f2fs/acl.h b/fs/f2fs/acl.h
index 3839048..4963313 100644
--- a/fs/f2fs/acl.h
+++ b/fs/f2fs/acl.h
@@ -38,7 +38,7 @@ struct f2fs_acl_header {
extern struct posix_acl *f2fs_get_acl(struct inode *, int);
extern int f2fs_acl_chmod(struct inode *);
-extern int f2fs_init_acl(struct inode *, struct inode *);
+extern int f2fs_init_acl(struct inode *, struct inode *, struct page *);
#else
#define f2fs_check_acl NULL
#define f2fs_get_acl NULL
@@ -49,7 +49,8 @@ static inline int f2fs_acl_chmod(struct inode *inode)
return 0;
}
-static inline int f2fs_init_acl(struct inode *inode, struct inode *dir)
+static inline int f2fs_init_acl(struct inode *inode, struct inode *dir,
+ struct page *page)
{
return 0;
}
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 384c6da..c9d53fc 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -346,7 +346,7 @@ static struct page *init_inode_metadata(struct inode *inode,
goto error;
}
- err = f2fs_init_acl(inode, dir);
+ err = f2fs_init_acl(inode, dir, page);
if (err)
goto error;
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs: clean up acl flow for better readability
This patch cleans up a couple of acl codes.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/acl.c | 25 +
fs/f2fs/acl.h | 6 +++---
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index b7826ec..f1a6975 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -262,8 +262,8 @@ static int f2fs_set_acl(struct inode *inode, int type,
struct posix_acl *acl)
int f2fs_init_acl(struct inode *inode, struct inode *dir)
{
- struct posix_acl *acl = NULL;
struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
+ struct posix_acl *acl = NULL;
int error = 0;
if (!S_ISLNK(inode->i_mode)) {
@@ -276,19 +276,19 @@ int f2fs_init_acl(struct inode *inode, struct inode *dir)
inode->i_mode &= ~current_umask();
}
- if (test_opt(sbi, POSIX_ACL) && acl) {
+ if (!test_opt(sbi, POSIX_ACL) || !acl)
+ goto cleanup;
- if (S_ISDIR(inode->i_mode)) {
- error = f2fs_set_acl(inode, ACL_TYPE_DEFAULT, acl);
- if (error)
- goto cleanup;
- }
- error = posix_acl_create(, GFP_KERNEL, >i_mode);
- if (error < 0)
- return error;
- if (error > 0)
- error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ if (S_ISDIR(inode->i_mode)) {
+ error = f2fs_set_acl(inode, ACL_TYPE_DEFAULT, acl);
+ if (error)
+ goto cleanup;
}
+ error = posix_acl_create(, GFP_KERNEL, >i_mode);
+ if (error < 0)
+ return error;
+ if (error > 0)
+ error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
cleanup:
posix_acl_release(acl);
return error;
@@ -313,6 +313,7 @@ int f2fs_acl_chmod(struct inode *inode)
error = posix_acl_chmod(, GFP_KERNEL, mode);
if (error)
return error;
+
error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
posix_acl_release(acl);
return error;
diff --git a/fs/f2fs/acl.h b/fs/f2fs/acl.h
index 80f4306..3839048 100644
--- a/fs/f2fs/acl.h
+++ b/fs/f2fs/acl.h
@@ -36,9 +36,9 @@ struct f2fs_acl_header {
#ifdef CONFIG_F2FS_FS_POSIX_ACL
-extern struct posix_acl *f2fs_get_acl(struct inode *inode, int type);
-extern int f2fs_acl_chmod(struct inode *inode);
-extern int f2fs_init_acl(struct inode *inode, struct inode *dir);
+extern struct posix_acl *f2fs_get_acl(struct inode *, int);
+extern int f2fs_acl_chmod(struct inode *);
+extern int f2fs_init_acl(struct inode *, struct inode *);
#else
#define f2fs_check_acl NULL
#define f2fs_get_acl NULL
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] blk-throttle: trim tokens generated for an idle tree
Hi, Vivek, I tested the PATCH v4 for some basic hierarchical setup as I did before. And I get the similar result. Preparation 1) mount subsys blkio with "__DEVEL__sane_behavior" 2) Create 3 levels of directories under the blkio mount point: mkdir 1 mkdir 1/2 mkdir 1/2/3 mkdir 4 3) start 4 bash sessions, write their PIDs into: 1/cgroup.procs 1/2/cgroup.procs 1/2/3/cgroup.procs 4/cgroup.procs 4) prepare 4 10MB files on sdb(ext4 fs) Note: in below hierarchy graph: "[50k]" means configured value for read_bps_device is 50kB/s "(50k)" means bandwidth reported by dd is 50kB/s Test A: 1 process throttled by ancestor group = Hierarchy set-up: (echo "8:16 204800" > 1/blkio.throttle.read_bps_device) |-- 1 [200k] |`-- 2 [-] | `-- 3 [-] `-- 4 [-] dd within group 3: (drop cache then: dd if=10M-file-3 of=/dev/null) Result: 206kB/s (I did same test without the token-bucket patch, The result is 205kB/s) dd within group 2: (drop cache then: dd if=10M-file-2 of=/dev/null) Result: 206kB/s Test B: 4 processes in 3 levels of hierarchy = Hierarchy set-up: echo "8:16 204800" > 1/blkio.throttle.read_bps_device echo "8:16 102400" > 1/2/blkio.throttle.read_bps_device echo "8:16 51200" > 1/2/3/blkio.throttle.read_bps_device echo "8:16 51200" > 4/blkio.throttle.read_bps_device |-- 1 [200k] |`-- 2 [100k] | `-- 3 [50k] `-- 4 [50k] start 4 dd processes from 4 bash sessions (dd if=10M-file-x of=/dev/null) Result: |-- 1 (104k) |`-- 2 (52.1k) | `-- 3 (51.3k) `-- 4 (51.4k) On Wed, Oct 23, 2013 at 5:02 AM, Vivek Goyal wrote: > Hi Hong, > > This approach looks good in general. Only downside I can think of > updation of nr_requests throughout the hierarchy. So deeper the > hierarchy, higher the overhead. > > I am not sure if that's a concern or not. I will have a closer look > a the patches tomorrow and do some testing too. > > Thanks > Vivek -- best regards Hong Zhiguo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] f2fs: remove unnecessary segment bitmap updates
From: Changman Lee
From: Changman Lee
Only one dirty type is set in __locate_dirty_segment and we can know
dirty type of segment. So we don't need to check other dirty types.
Signed-off-by: Changman Lee
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 487af61..8f92c18 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -58,20 +58,10 @@ static void __locate_dirty_segment(struct f2fs_sb_info
*sbi, unsigned int segno,
if (dirty_type == DIRTY) {
struct seg_entry *sentry = get_seg_entry(sbi, segno);
- enum dirty_type t = DIRTY_HOT_DATA;
+ enum dirty_type t = sentry->type;
- dirty_type = sentry->type;
-
- if (!test_and_set_bit(segno, dirty_i->dirty_segmap[dirty_type]))
- dirty_i->nr_dirty[dirty_type]++;
-
- /* Only one bitmap should be set */
- for (; t <= DIRTY_COLD_NODE; t++) {
- if (t == dirty_type)
- continue;
- if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
- dirty_i->nr_dirty[t]--;
- }
+ if (!test_and_set_bit(segno, dirty_i->dirty_segmap[t]))
+ dirty_i->nr_dirty[t]++;
}
}
@@ -84,16 +74,11 @@ static void __remove_dirty_segment(struct f2fs_sb_info
*sbi, unsigned int segno,
dirty_i->nr_dirty[dirty_type]--;
if (dirty_type == DIRTY) {
- enum dirty_type t = DIRTY_HOT_DATA;
-
- /* clear its dirty bitmap */
- for (; t <= DIRTY_COLD_NODE; t++) {
- if (test_and_clear_bit(segno,
- dirty_i->dirty_segmap[t])) {
- dirty_i->nr_dirty[t]--;
- break;
- }
- }
+ struct seg_entry *sentry = get_seg_entry(sbi, segno);
+ enum dirty_type t = sentry->type;
+
+ if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
+ dirty_i->nr_dirty[t]--;
if (get_valid_blocks(sbi, segno, sbi->segs_per_sec) == 0)
clear_bit(GET_SECNO(sbi, segno),
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings Date: Mon, 28 Oct 2013 04:51:25 + > On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote: >> From: Ben Hutchings >> Date: Sun, 27 Oct 2013 21:51:44 + >> >> > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len); >> > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len); >> >> Please use %p for the skb pointer instead of casting it (which btw >> will introduce a warning on 64-bit). > > skb is the DMA address of the data in the sk_buff. Yes, this is really > unusual naming. Hmmm, Ok then I guess. :-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] MTD: UBI: try to avoid program data to NOR flash after erasure interrupted
On Sa, 2013-10-26 at 05:19 +, Artem Bityutskiy wrote:
>On Thu, 2013-10-10 at 08:28 +, Qi Wang 王起 (qiwang) wrote:
>> But I want to say the potential risk is if low level driver program data to
>> this block, it will get “timeout error”. And the timeout period could be
>> very
>> long(almost several minutes), during this period, any operation on NOR flash
>> cannot be accept. so program data to a erasure interrupted block isn’t a
>> sensible action. in order to avoid program a erasure interrupted block,
>> I suggest UBIFS can read this block before program data. the code changing
>> as below:
>
>Yes, reading first sounds like a good idea. Would you please send a
>patch implementing it?
From: Qi Wang
nor_erase_prepare() will be called before erase a NOR flash, it will program '0'
into a block to mark this block. But program data into a erasure interrupted
block
can cause program timtout(several minutes at most) error, could impact other
operation on NOR flash. So UBIFS can read this block first to avoid unneeded
program operation.
This patch try to put read operation at at head of write operation in
nor_erase_prepare(), read out the data.
If the data is already corrupt, then no need to program any data into this
block,
just go to erase this block.
Signed-off-by: Qi Wang
---
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index bf79def..be6ab56 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -509,26 +509,10 @@ static int nor_erase_prepare(struct ubi_device *ubi, int
pnum)
struct ubi_vid_hdr vid_hdr;
/*
-* It is important to first invalidate the EC header, and then the VID
-* header. Otherwise a power cut may lead to valid EC header and
-* invalid VID header, in which case UBI will treat this PEB as
-* corrupted and will try to preserve it, and print scary warnings.
-*/
- addr = (loff_t)pnum * ubi->peb_size;
- err = mtd_write(ubi->mtd, addr, 4, , (void *));
- if (!err) {
- addr += ubi->vid_hdr_aloffset;
- err = mtd_write(ubi->mtd, addr, 4, , (void *));
- if (!err)
- return 0;
- }
-
- /*
-* We failed to write to the media. This was observed with Spansion
-* S29GL512N NOR flash. Most probably the previously eraseblock erasure
+* Most probably the previously eraseblock erasure
* was interrupted at a very inappropriate moment, so it became
-* unwritable. In this case we probably anyway have garbage in this
-* PEB.
+* unwritable. In order to avoid program data into a unwritable block,
+* read this block first, and check if do need to program it.
*/
err1 = ubi_io_read_vid_hdr(ubi, pnum, _hdr, 0);
if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR ||
@@ -547,6 +531,22 @@ static int nor_erase_prepare(struct ubi_device *ubi, int
pnum)
}
/*
+* VID or EC is valid, need to corrupt these header before erase
operation.
+* It is important to first invalidate the EC header, and then the VID
+* header. Otherwise a power cut may lead to valid EC header and
+* invalid VID header, in which case UBI will treat this PEB as
+* corrupted and will try to preserve it, and print scary warnings.
+*/
+ addr = (loff_t)pnum * ubi->peb_size;
+ err = mtd_write(ubi->mtd, addr, 4, , (void *));
+ if (!err) {
+ addr += ubi->vid_hdr_aloffset;
+ err = mtd_write(ubi->mtd, addr, 4, , (void *));
+ if (!err)
+ return 0;
+ }
+
+ /*
* The PEB contains a valid VID header, but we cannot invalidate it.
* Supposedly the flash media or the driver is screwed up, so return an
* error.
---
Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote: > From: Ben Hutchings > Date: Sun, 27 Oct 2013 21:51:44 + > > > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len); > > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len); > > Please use %p for the skb pointer instead of casting it (which btw > will introduce a warning on 64-bit). skb is the DMA address of the data in the sk_buff. Yes, this is really unusual naming. Ben. -- Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought. ... I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. - Maurice Wilkes, 1949 signature.asc Description: This is a digitally signed message part
[PATCH 1/1] MTD: UBI: try to avoid program data to NOR flash after erasure interrupted
On Sa, 2013-10-26 at 05:19 +, Artem Bityutskiy wrote:
>On Thu, 2013-10-10 at 08:28 +, Qi Wang 王起 (qiwang) wrote:
>> But I want to say the potential risk is if low level driver program data to
>> this block, it will get “timeout error”. And the timeout period could be
>> very
>> long(almost several minutes), during this period, any operation on NOR flash
>> cannot be accept. so program data to a erasure interrupted block isn’t a
>> sensible action. in order to avoid program a erasure interrupted block,
>> I suggest UBIFS can read this block before program data. the code changing
>> as below:
>
>Yes, reading first sounds like a good idea. Would you please send a
>patch implementing it?
From: Qi Wang
nor_erase_prepare() will be called before erase a NOR flash, it will program '0'
into a block to mark this block. But program data into a erasure interrupted
block
can cause program timtout(several minutes at most) error, could impact other
operation on NOR flash. So UBIFS can read this block first to avoid unneeded
program operation.
This patch try to put read operation at at head of write operation in
nor_erase_prepare(), read out the data.
If the data is already corrupt, then no need to program any data into this
block,
just go to erase this block.
Signed-off-by: Qi Wang
---
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index bf79def..be6ab56 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -509,26 +509,10 @@ static int nor_erase_prepare(struct ubi_device *ubi, int
pnum)
struct ubi_vid_hdr vid_hdr;
/*
-* It is important to first invalidate the EC header, and then the VID
-* header. Otherwise a power cut may lead to valid EC header and
-* invalid VID header, in which case UBI will treat this PEB as
-* corrupted and will try to preserve it, and print scary warnings.
-*/
- addr = (loff_t)pnum * ubi->peb_size;
- err = mtd_write(ubi->mtd, addr, 4, , (void *));
- if (!err) {
- addr += ubi->vid_hdr_aloffset;
- err = mtd_write(ubi->mtd, addr, 4, , (void *));
- if (!err)
- return 0;
- }
-
- /*
-* We failed to write to the media. This was observed with Spansion
-* S29GL512N NOR flash. Most probably the previously eraseblock erasure
+* Most probably the previously eraseblock erasure
* was interrupted at a very inappropriate moment, so it became
-* unwritable. In this case we probably anyway have garbage in this
-* PEB.
+* unwritable. In order to avoid program data into a unwritable block,
+* read this block first, and check if do need to program it.
*/
err1 = ubi_io_read_vid_hdr(ubi, pnum, _hdr, 0);
if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR ||
@@ -547,6 +531,22 @@ static int nor_erase_prepare(struct ubi_device *ubi, int
pnum)
}
/*
+* VID or EC is valid, need to corrupt these header before erase
operation.
+* It is important to first invalidate the EC header, and then the VID
+* header. Otherwise a power cut may lead to valid EC header and
+* invalid VID header, in which case UBI will treat this PEB as
+* corrupted and will try to preserve it, and print scary warnings.
+*/
+ addr = (loff_t)pnum * ubi->peb_size;
+ err = mtd_write(ubi->mtd, addr, 4, , (void *));
+ if (!err) {
+ addr += ubi->vid_hdr_aloffset;
+ err = mtd_write(ubi->mtd, addr, 4, , (void *));
+ if (!err)
+ return 0;
+ }
+
+ /*
* The PEB contains a valid VID header, but we cannot invalidate it.
* Supposedly the flash media or the driver is screwed up, so return an
* error.
---
Re: [PATCH 2/3] net, datagram: fix the uncorrect comment in zerocopy_sg_from_iovec()
"uncorrect" is not a word, you mean to say "incorrect". Same goes for patch #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 1/3] vxlan: silence one build warning
From: Stephen Hemminger
Date: Fri, 25 Oct 2013 08:41:34 -0700
> I would rather not fix the warning this way since it risks masking
> later bugs if this code ever changes.
But this is suboptimally coded, and is asking for the warning.
Anything returning a pointer by reference is asking for trouble
in my opinion.
The correct thing to do is to make create_v{4,6}_sock() return
the "struct socket *" as an error pointer.
No more ambiguous initializations, no more warnings.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/8] rds: Pass pointers to virt_to_page(), not integers
From: Ben Hutchings Date: Sun, 27 Oct 2013 21:54:16 + > Most architectures define virt_to_page() as a macro that casts its > argument such that an argument of type unsigned long will be accepted > without complaint. However, the proper type is void *, and passing > unsigned long results in a warning on MIPS. > > Compile-tested only. > > Signed-off-by: Ben Hutchings This looks fine: 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 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings Date: Sun, 27 Oct 2013 21:51:44 + > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len); > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len); Please use %p for the skb pointer instead of casting it (which btw will introduce a warning on 64-bit). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit e9e2a904ef0a
("be2net: Warn users of possible broken functionality on BE2 cards with
very old FW versions with latest driver") from the net tree and commit
6384a4d0dcf9 ("be2net: add support for ndo_busy_poll") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/emulex/benet/be.h
index c99dac6a9ddf,b2765ebb0268..
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -696,23 -733,114 +733,123 @@@ static inline int qnq_async_evt_rcvd(st
return adapter->flags & BE_FLAGS_QNQ_ASYNC_EVT_RCVD;
}
+static inline int fw_major_num(const char *fw_ver)
+{
+ int fw_major = 0;
+
+ sscanf(fw_ver, "%d.", _major);
+
+ return fw_major;
+}
+
- extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
- u16 num_popped);
- extern void be_link_status_update(struct be_adapter *adapter, u8 link_status);
- extern void be_parse_stats(struct be_adapter *adapter);
- extern int be_load_fw(struct be_adapter *adapter, u8 *func);
- extern bool be_is_wol_supported(struct be_adapter *adapter);
- extern bool be_pause_supported(struct be_adapter *adapter);
- extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+ #ifdef CONFIG_NET_RX_BUSY_POLL
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock(>lock); /* BH is already disabled */
+ if (eqo->state & BE_EQ_LOCKED) {
+ WARN_ON(eqo->state & BE_EQ_NAPI);
+ eqo->state |= BE_EQ_NAPI_YIELD;
+ status = false;
+ } else {
+ eqo->state = BE_EQ_NAPI;
+ }
+ spin_unlock(>lock);
+ return status;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ spin_lock(>lock); /* BH is already disabled */
+
+ WARN_ON(eqo->state & (BE_EQ_POLL | BE_EQ_NAPI_YIELD));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock(>lock);
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock_bh(>lock);
+ if (eqo->state & BE_EQ_LOCKED) {
+ eqo->state |= BE_EQ_POLL_YIELD;
+ status = false;
+ } else {
+ eqo->state |= BE_EQ_POLL;
+ }
+ spin_unlock_bh(>lock);
+ return status;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_bh(>lock);
+
+ WARN_ON(eqo->state & (BE_EQ_NAPI));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock_bh(>lock);
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_init(>lock);
+ eqo->state = BE_EQ_IDLE;
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ local_bh_disable();
+
+ /* It's enough to just acquire napi lock on the eqo to stop
+* be_busy_poll() from processing any queueus.
+*/
+ while (!be_lock_napi(eqo))
+ mdelay(1);
+
+ local_bh_enable();
+ }
+
+ #else /* CONFIG_NET_RX_BUSY_POLL */
+
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ return true;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ return false;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ #endif /* CONFIG_NET_RX_BUSY_POLL */
+
+ void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
+ u16 num_popped);
+ void be_link_status_update(struct be_adapter *adapter, u8 link_status);
+ void be_parse_stats(struct be_adapter *adapter);
+ int be_load_fw(struct be_adapter *adapter, u8 *func);
+ bool be_is_wol_supported(struct be_adapter *adapter);
+ bool be_pause_supported(struct be_adapter *adapter);
+ u32 be_get_fw_log_level(struct be_adapter *adapter);
int be_update_queues(struct be_adapter *adapter);
int be_poll(struct napi_struct *napi, int budget);
pgpUp9ZMvijBU.pgp
Description: PGP signature
Re: [PATCH] arc: kernel: export symbol for pm_power_off in reset.c
After this patch, and with limitations below, arc finishes allmodconfig. - with EXTRA_CFLAGS=-mmedium-calls. - disable CONFIG_CC_OPTIMIZE_FOR_SIZE. - by pass 5-7 gcc issues (4-5 may duplicate). - by pass 1 binutils issue (when disable CONFIG_CC_OPTIMIZE_FOR_SIZE). Next (within 2013-10-31) I will/should: - shrink cross-compilers information, at least. - finish the patch for "portable assembler code - newline" Left: - it also content sevaval warnings (even not use "EXTRA_CFLAGS=-W"). - for next-20130927 tree, arc can not pass defconfig, either. - not let it run under kvm (I don't know whether we support kvm). Thanks. On 10/28/2013 11:49 AM, Chen Gang wrote: > Need export symbol for it, or can not pass compiling, the related error > with allmodconfig: > > MODPOST 2994 modules > ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! > ERROR: "pm_power_off" [drivers/char/ipmi/ipmi_poweroff.ko] undefined! > > > Signed-off-by: Chen Gang > --- > arch/arc/kernel/reset.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c > index e227a2b..2768fa1 100644 > --- a/arch/arc/kernel/reset.c > +++ b/arch/arc/kernel/reset.c > @@ -31,3 +31,4 @@ void machine_power_off(void) > } > > void (*pm_power_off) (void) = NULL; > +EXPORT_SYMBOL(pm_power_off); > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add support for POD HD400 to line6usb driver
Hello,
This patch adds support for the Line 6 POD HD400 to the line6usb
driver.
--- 8< Patch starts here
diff -ur stock/linux-3.11.6/drivers/staging/line6/driver.c
line6/linux-3.11.6/drivers/staging/line6/driver.c
--- stock/linux-3.11.6/drivers/staging/line6/driver.c2013-10-18
14:24:16.0 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/driver.c2013-10-27
23:49:03.238659004 -0400
@@ -38,6 +38,7 @@
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_GUITARPORT)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_POCKETPOD)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD300)},
+{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD400)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODHD500)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_GX)},
{USB_DEVICE(LINE6_VENDOR_ID, LINE6_DEVID_PODSTUDIO_UX1)},
@@ -64,6 +65,7 @@
{ LINE6_BIT_GUITARPORT,"GuitarPort","GuitarPort",
LINE6_BIT_PCM },
{ LINE6_BIT_POCKETPOD, "PocketPOD", "Pocket POD",
LINE6_BIT_CONTROL },
{ LINE6_BIT_PODHD300, "PODHD300", "POD HD300",
LINE6_BIT_CONTROL_PCM_HWMON },
+{ LINE6_BIT_PODHD400, "PODHD400", "POD HD400",
LINE6_BIT_CONTROL_PCM_HWMON },
{ LINE6_BIT_PODHD500, "PODHD500", "POD HD500",
LINE6_BIT_CONTROL_PCM_HWMON },
{ LINE6_BIT_PODSTUDIO_GX, "PODStudioGX", "POD Studio GX",
LINE6_BIT_PCM },
{ LINE6_BIT_PODSTUDIO_UX1, "PODStudioUX1", "POD Studio UX1",
LINE6_BIT_PCM },
@@ -352,6 +354,7 @@
break;
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
case LINE6_DEVID_PODHD500:
break; /* let userspace handle MIDI */
@@ -693,6 +696,7 @@
case LINE6_DEVID_PODXT:
case LINE6_DEVID_PODXTPRO:
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
alternate = 5;
break;
@@ -747,6 +751,7 @@
break;
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
size = sizeof(struct usb_line6_podhd);
ep_read = 0x84;
ep_write = 0x03;
@@ -905,6 +910,7 @@
break;
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
case LINE6_DEVID_PODHD500:
ret = line6_podhd_init(interface,
(struct usb_line6_podhd *)line6);
@@ -1032,6 +1038,7 @@
break;
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
case LINE6_DEVID_PODHD500:
line6_podhd_disconnect(interface);
break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/pcm.c
line6/linux-3.11.6/drivers/staging/line6/pcm.c
--- stock/linux-3.11.6/drivers/staging/line6/pcm.c2013-10-18
14:24:16.0 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/pcm.c2013-10-27
23:49:03.238659004 -0400
@@ -439,6 +439,7 @@
case LINE6_DEVID_PODXTLIVE:
case LINE6_DEVID_PODXTPRO:
case LINE6_DEVID_PODHD300:
+case LINE6_DEVID_PODHD400:
ep_read = 0x82;
ep_write = 0x01;
break;
diff -ur stock/linux-3.11.6/drivers/staging/line6/usbdefs.h
line6/linux-3.11.6/drivers/staging/line6/usbdefs.h
--- stock/linux-3.11.6/drivers/staging/line6/usbdefs.h2013-10-18
14:24:16.0 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/usbdefs.h2013-10-27
23:49:03.238659004 -0400
@@ -25,6 +25,7 @@
#define LINE6_DEVID_GUITARPORT0x4750
#define LINE6_DEVID_POCKETPOD 0x5051
#define LINE6_DEVID_PODHD300 0x5057
+#define LINE6_DEVID_PODHD400 0x5058
#define LINE6_DEVID_PODHD500 0x414D
#define LINE6_DEVID_PODSTUDIO_GX 0x4153
#define LINE6_DEVID_PODSTUDIO_UX1 0x4150
@@ -48,6 +49,7 @@
LINE6_INDEX_GUITARPORT,
LINE6_INDEX_POCKETPOD,
LINE6_INDEX_PODHD300,
+LINE6_INDEX_PODHD400,
LINE6_INDEX_PODHD500,
LINE6_INDEX_PODSTUDIO_GX,
LINE6_INDEX_PODSTUDIO_UX1,
@@ -68,6 +70,7 @@
LINE6_BIT(GUITARPORT),
LINE6_BIT(POCKETPOD),
LINE6_BIT(PODHD300),
+LINE6_BIT(PODHD400),
LINE6_BIT(PODHD500),
LINE6_BIT(PODSTUDIO_GX),
LINE6_BIT(PODSTUDIO_UX1),
@@ -88,7 +91,9 @@
LINE6_BITS_PODXTALL = LINE6_BIT_PODXT | LINE6_BIT_PODXTLIVE |
LINE6_BIT_PODXTPRO,
LINE6_BITS_PODX3ALL = LINE6_BIT_PODX3 | LINE6_BIT_PODX3LIVE,
-LINE6_BITS_PODHDALL = LINE6_BIT_PODHD300 | LINE6_BIT_PODHD500,
+LINE6_BITS_PODHDALL = LINE6_BIT_PODHD300 |
+LINE6_BIT_PODHD400 |
+LINE6_BIT_PODHD500,
LINE6_BITS_BASSPODXTALL= LINE6_BIT_BASSPODXT |
LINE6_BIT_BASSPODXTLIVE |
LINE6_BIT_BASSPODXTPRO
diff -ur stock/linux-3.11.6/drivers/staging/line6/driver.c line6/linux-3.11.6/drivers/staging/line6/driver.c
--- stock/linux-3.11.6/drivers/staging/line6/driver.c 2013-10-18 14:24:16.0 -0400
+++ line6/linux-3.11.6/drivers/staging/line6/driver.c 2013-10-27 23:49:03.238659004 -0400
@@ -38,6 +38,7 @@
[PATCH] arc: kernel: export symbol for pm_power_off in reset.c
Need export symbol for it, or can not pass compiling, the related error with allmodconfig: MODPOST 2994 modules ERROR: "pm_power_off" [drivers/mfd/retu-mfd.ko] undefined! ERROR: "pm_power_off" [drivers/char/ipmi/ipmi_poweroff.ko] undefined! Signed-off-by: Chen Gang --- arch/arc/kernel/reset.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c index e227a2b..2768fa1 100644 --- a/arch/arc/kernel/reset.c +++ b/arch/arc/kernel/reset.c @@ -31,3 +31,4 @@ void machine_power_off(void) } void (*pm_power_off) (void) = NULL; +EXPORT_SYMBOL(pm_power_off); -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/7] power_supply: Add charger control properties
Anton,
> But do we really want to control the chargers through the power_supply's
> user-visible
> interface? It makes the whole power supply thing so complicated that I'm
> already losing
> track of it. Right now I think I would prefer to move all the charger logic
> out of the psy
> class.
>
I think exposing properties make the logic generic, otherwise it may end up in
having callback
functions. Also there are some scenarios where the charging algorithm has to be
in the
user space. If the driver need to remove the control interface from the user
space, it can use
property_is_writeable callback. Using standard power supply properties, provide
the
flexibility to interface the charging algorithms from the user space or the
kernel space.
This makes the charger driver implementation simple - it just need to register
with psy class,
no extra API or callback required.
> More specifically, this code:
>
> > @@ -561,6 +575,11 @@ int power_supply_register(struct device *parent, struct
> power_supply *psy)
> > if (rc)
> > goto create_triggers_failed;
> >
> > + if (psy_is_charger(psy))
> > + rc = power_supply_register_charger(psy);
> > + if (rc)
> > + pr_debug("device: '%s': power_supply_register_charger
> > failed\n",
> > + dev_name(dev));
>
> I have a weird feeling about the fact that the power_supply_register()
> registers a charger.
> OK, we have thermal stuff registration there, but it is completely different.
> We have the
> cooling device registration there as well, and this stuff would be really
> nice to move out to
> some "chargers subsystem".
>
> So, Jenny, the question is: can we separate chargers logic from the power
> supply? So that
> we don't have "charger enable"/"charger disable" knobs in the psy class
> itself. It is still fine
> if you need to have some interface to the psy class so that the chargers
> subsystem would
> interface with it, though. But I think that charger drivers have to register
> itself with two
> subsystems: chargers and power_supply (optionally).
>
If your concern is in clubbing the charger framework related changes with psy
class,
then I have an alternate proposal. Using the patch
https://lkml.org/lkml/2013/7/25/204,
the power supply change notification can be broadcasted. We can add notifier
events
for power_supply_register and thermal throttling. This way
power_supply_charger.c can
be a separate driver and it can listen to psy notifications to take actions.
> Thanks,
>
> Anton
>
> > Signed-off-by: Jenny TC
> >
> > Change-Id: Id91dbbd8f34499afa97b7d8f11ecf5467847f6a8
> > ---
> > Documentation/power/power_supply_class.txt | 16
> > drivers/power/power_supply_sysfs.c |8
> > include/linux/power_supply.h |8
> > 3 files changed, 32 insertions(+)
> >
> > diff --git a/Documentation/power/power_supply_class.txt
> > b/Documentation/power/power_supply_class.txt
> > index 3f10b39..5a5e7fa 100644
> > --- a/Documentation/power/power_supply_class.txt
> > +++ b/Documentation/power/power_supply_class.txt
> > @@ -118,6 +118,10 @@ relative, time-based measurements.
> > CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
> > CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by
> the
> > power supply object.
> > +INPUT_CURRENT_LIMIT - input current limit programmed by charger.
> > +Indicates the current drawn from a charging source.
> > +CHARGE_TERM_CUR - Charge termination current used to detect the end
> > +of charge condition
> >
> > CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
> > CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by
> the
> > @@ -140,12 +144,24 @@ TEMP_ALERT_MAX - maximum battery temperature alert
> value in milli centigrade.
> > TEMP_AMBIENT - ambient temperature.
> > TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert value in milli
> centigrade.
> > TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert value in milli
> centigrade.
> > +MIN_TEMP - minimum operatable temperature MAX_TEMP - maximum
> > +operatable temperature
>
> TEMP_MAX, TEMP_MIN. Be consistent with the rest of the properties...
Agreed. Will fix it
Re: [PATCH 2/2] virtio_blk: blk-mq support
Christoph Hellwig writes:
> Switch virtio-blk from the dual support for old-style requests and bios
> to use the block-multiqueue. For now pretend to have 4 issue queues
> as Jens pulled that out of his this hair and it worked.
Let's pretend I'm stupid.
We don't actually have multiple queues through to the host, but we're
pretending to, because it makes the block layer go faster?
Do I want to know *why* it's faster? Or should I look the other way?
Thanks,
Rusty.
> Signed-off-by: Jens Axboe
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/virtio_blk.c | 312
> +---
> 1 file changed, 65 insertions(+), 247 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 5cdf88b..87f099d 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -11,12 +11,11 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #define PART_BITS 4
>
> -static bool use_bio;
> -module_param(use_bio, bool, S_IRUGO);
> -
> static int major;
> static DEFINE_IDA(vd_index_ida);
>
> @@ -26,13 +25,11 @@ struct virtio_blk
> {
> struct virtio_device *vdev;
> struct virtqueue *vq;
> - wait_queue_head_t queue_wait;
> + spinlock_t vq_lock;
>
> /* The disk structure for the kernel. */
> struct gendisk *disk;
>
> - mempool_t *pool;
> -
> /* Process context for config space updates */
> struct work_struct config_work;
>
> @@ -47,15 +44,11 @@ struct virtio_blk
>
> /* Ida index - used to track minor number allocations. */
> int index;
> -
> - /* Scatterlist: can be too big for stack. */
> - struct scatterlist sg[/*sg_elems*/];
> };
>
> struct virtblk_req
> {
> struct request *req;
> - struct bio *bio;
> struct virtio_blk_outhdr out_hdr;
> struct virtio_scsi_inhdr in_hdr;
> struct work_struct work;
> @@ -84,22 +77,6 @@ static inline int virtblk_result(struct virtblk_req *vbr)
> }
> }
>
> -static inline struct virtblk_req *virtblk_alloc_req(struct virtio_blk *vblk,
> - gfp_t gfp_mask)
> -{
> - struct virtblk_req *vbr;
> -
> - vbr = mempool_alloc(vblk->pool, gfp_mask);
> - if (!vbr)
> - return NULL;
> -
> - vbr->vblk = vblk;
> - if (use_bio)
> - sg_init_table(vbr->sg, vblk->sg_elems);
> -
> - return vbr;
> -}
> -
> static int __virtblk_add_req(struct virtqueue *vq,
>struct virtblk_req *vbr,
>struct scatterlist *data_sg,
> @@ -143,83 +120,8 @@ static int __virtblk_add_req(struct virtqueue *vq,
> return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
> }
>
> -static void virtblk_add_req(struct virtblk_req *vbr, bool have_data)
> -{
> - struct virtio_blk *vblk = vbr->vblk;
> - DEFINE_WAIT(wait);
> - int ret;
> -
> - spin_lock_irq(vblk->disk->queue->queue_lock);
> - while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr, vbr->sg,
> - have_data)) < 0)) {
> - prepare_to_wait_exclusive(>queue_wait, ,
> - TASK_UNINTERRUPTIBLE);
> -
> - spin_unlock_irq(vblk->disk->queue->queue_lock);
> - io_schedule();
> - spin_lock_irq(vblk->disk->queue->queue_lock);
> -
> - finish_wait(>queue_wait, );
> - }
> -
> - virtqueue_kick(vblk->vq);
> - spin_unlock_irq(vblk->disk->queue->queue_lock);
> -}
> -
> -static void virtblk_bio_send_flush(struct virtblk_req *vbr)
> -{
> - vbr->flags |= VBLK_IS_FLUSH;
> - vbr->out_hdr.type = VIRTIO_BLK_T_FLUSH;
> - vbr->out_hdr.sector = 0;
> - vbr->out_hdr.ioprio = 0;
> -
> - virtblk_add_req(vbr, false);
> -}
> -
> -static void virtblk_bio_send_data(struct virtblk_req *vbr)
> -{
> - struct virtio_blk *vblk = vbr->vblk;
> - struct bio *bio = vbr->bio;
> - bool have_data;
> -
> - vbr->flags &= ~VBLK_IS_FLUSH;
> - vbr->out_hdr.type = 0;
> - vbr->out_hdr.sector = bio->bi_sector;
> - vbr->out_hdr.ioprio = bio_prio(bio);
> -
> - if (blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg)) {
> - have_data = true;
> - if (bio->bi_rw & REQ_WRITE)
> - vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
> - else
> - vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
> - } else
> - have_data = false;
> -
> - virtblk_add_req(vbr, have_data);
> -}
> -
> -static void virtblk_bio_send_data_work(struct work_struct *work)
> -{
> - struct virtblk_req *vbr;
> -
> - vbr = container_of(work, struct virtblk_req, work);
> -
> - virtblk_bio_send_data(vbr);
> -}
> -
> -static void virtblk_bio_send_flush_work(struct work_struct *work)
> -{
> - struct virtblk_req *vbr;
> -
> - vbr = container_of(work, struct virtblk_req, work);
> -
> -
Re: [PATCH] lglock: Map to spinlock when !CONFIG_SMP
Josh Triplett writes: > When the system has only one CPU, lglock is effectively a spinlock; map > it directly to spinlock to eliminate the indirection and duplicate code. > > In addition to removing overhead, this drops 1.6k of code with a defconfig > modified to have !CONFIG_SMP, and 1.1k with a minimal config. > > Signed-off-by: Josh Triplett Nice. Looks like a patch for Andrew Morton though. Cheers, Rusty. > --- > include/linux/lglock.h | 16 > kernel/Makefile| 4 ++-- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/include/linux/lglock.h b/include/linux/lglock.h > index 0d24e93..6561b1c 100644 > --- a/include/linux/lglock.h > +++ b/include/linux/lglock.h > @@ -35,6 +35,8 @@ > #define DEFINE_BRLOCK(name) DEFINE_LGLOCK(name) > #define DEFINE_STATIC_BRLOCK(name) DEFINE_STATIC_LGLOCK(name) > > +#ifdef CONFIG_SMP > + > #ifdef CONFIG_DEBUG_LOCK_ALLOC > #define LOCKDEP_INIT_MAP lockdep_init_map > #else > @@ -67,4 +69,18 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu); > void lg_global_lock(struct lglock *lg); > void lg_global_unlock(struct lglock *lg); > > +#else > +/* When !CONFIG_SMP, map lglock to spinlock */ > +#define lglock spinlock > +#define DEFINE_LGLOCK(name) DEFINE_SPINLOCK(name) > +#define DEFINE_STATIC_LGLOCK(name) static DEFINE_SPINLOCK(name) > +#define lg_lock_init(lg, name) spin_lock_init(lg) > +#define lg_local_lock spin_lock > +#define lg_local_unlock spin_unlock > +#define lg_local_lock_cpu(lg, cpu) spin_lock(lg) > +#define lg_local_unlock_cpu(lg, cpu) spin_unlock(lg) > +#define lg_global_lock spin_lock > +#define lg_global_unlock spin_unlock > +#endif > + > #endif > diff --git a/kernel/Makefile b/kernel/Makefile > index 1ce4755..84a89f7 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -10,7 +10,7 @@ obj-y = fork.o exec_domain.o panic.o \ > kthread.o wait.o sys_ni.o posix-cpu-timers.o mutex.o \ > hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \ > notifier.o ksysfs.o cred.o reboot.o \ > - async.o range.o groups.o lglock.o smpboot.o > + async.o range.o groups.o smpboot.o > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace debug files and internal ftrace files > @@ -50,7 +50,7 @@ obj-$(CONFIG_SMP) += smp.o > ifneq ($(CONFIG_SMP),y) > obj-y += up.o > endif > -obj-$(CONFIG_SMP) += spinlock.o > +obj-$(CONFIG_SMP) += lglock.o spinlock.o > obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o > obj-$(CONFIG_PROVE_LOCKING) += spinlock.o > obj-$(CONFIG_UID16) += uid16.o > -- > 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kernel/kallsyms.c: only show legal kernel symbol
Ming Lei writes: > On Fri, Oct 25, 2013 at 7:58 PM, Rusty Russell wrote: >>> >>> Basically these symbols are only used to generate code, and in >>> kernel mode, CPU won't run into the corresponding addresses >>> because the generate code is copied to other address during booting, >>> so I understand they won't appear in backtraces. >> >> An oops occurs when something went *wrong*. We look up all kinds of >> stuff. Are you so sure that *none* of the callers will ever see these >> strange symbols and produce a confusing result? > > Suppose that might happen, kernel should be smart enough to know > that the address is not inside kernel address space and won't produce > confusing result, right? I don't know... It would be your job, as the person making the change, to find all the users of kallsyms and prove that. This is why it is easier not to include incorrect values in the kernel's kallsyms in the first place. Hope that helps, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arc: kernel: use exporting symbol instead of static inline for arc_get_core_freq()
Need export arc_get_core_freq() instead of let it static inline, or if
other individual modules use it (e.g. use BASE_BAUD), it can not find
core_freq variable.
Signed-off-by: Chen Gang
---
arch/arc/include/asm/clk.h |9 +
arch/arc/kernel/clk.c |9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arc/include/asm/clk.h b/arch/arc/include/asm/clk.h
index bf9d29f..256321a 100644
--- a/arch/arc/include/asm/clk.h
+++ b/arch/arc/include/asm/clk.h
@@ -9,14 +9,7 @@
#ifndef _ASM_ARC_CLK_H
#define _ASM_ARC_CLK_H
-/* Although we can't really hide core_freq, the accessor is still better way */
-extern unsigned long core_freq;
-
-static inline unsigned long arc_get_core_freq(void)
-{
- return core_freq;
-}
-
+extern unsigned long arc_get_core_freq(void);
extern int arc_set_core_freq(unsigned long);
#endif
diff --git a/arch/arc/kernel/clk.c b/arch/arc/kernel/clk.c
index 10c7b0b..9f4602f 100644
--- a/arch/arc/kernel/clk.c
+++ b/arch/arc/kernel/clk.c
@@ -6,9 +6,16 @@
* published by the Free Software Foundation.
*/
+#include
#include
-unsigned long core_freq = 8000;
+static unsigned long core_freq = 8000;
+
+unsigned long arc_get_core_freq(void)
+{
+ return core_freq;
+}
+EXPORT_SYMBOL_GPL(arc_get_core_freq);
/*
* As of now we default to device-tree provided clock
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Sun, Oct 27, 2013 at 08:24:08PM +, Rob Herring wrote:
> On Sun, Oct 27, 2013 at 8:46 AM, Grant Likely wrote:
> > On Tue, 15 Oct 2013 21:39:23 +0100, Grant Likely
> > wrote:
> >> The standard interrupts property in device tree can only handle
> >> interrupts coming from a single interrupt parent. If a device is wired
> >> to multiple interrupt controllers, then it needs to be attached to a
> >> node with an interrupt-map property to demux the interrupt specifiers
> >> which is confusing. It would be a lot easier if there was a form of the
> >> interrupts property that allows for a separate interrupt phandle for
> >> each interrupt specifier.
> >>
> >> This patch does exactly that by creating a new interrupts-extended
> >> property which reuses the phandle+arguments pattern used by GPIOs and
> >> other core bindings.
> >>
> >> Signed-off-by: Grant Likely
> >> Cc: Rob Herring
> >
> > Alright, I want to merge this one. I've got an Ack from Tony, general
> > agreement from an in person converstaion from Ben (aside from wishing he
> > could think of a better property name), and various rumblings of
> > approval from anyone I talked to about it at ksummit. I'd like to have
> > something more that that to put into the commit text. Please take a look
> > and let me know if you agree/disagree with this binding.
The only comment I have is that I'm not keen on the name (it's a bit generic
and we might want to extend the interrupts binding in future), but I'm happy to
leave that as a matter of personal taste.
The best alternative I could come up with was parented-interrupts, but that
could be misinterpreted as describing the relationship backwards (i.e. this
device is the parent for those interrupts).
>
> I think it looks fine, but I'll throw out an alternative proposal.
> Simply allow for interrupt-parent to be an array in equal size to
> interrupts property. Then it is a minimal change to the existing
> binding:
>
> interrupt-parent = <>, <>;
> interrupts = <5 0>, <6 0>;
I'd prefer the interrupts-extended approach.
This might not matter, but if you have an existing driver with two interrupts,
and you attempt to describe the situation this way, e.g.
intc1: interrupt_controller1 {
compatible = "vendor,interrupt-controller";
#interrupt-cells = <1>;
};
intc2: interrupt_controller2 {
compatible = "vendor,another-interrupt-controller";
#interrupt-cells = <2>;
};
dev {
compatible = "vendor,some-device";
interrupt-parent = <>, <>;
interrupts = <5>, <65 73>;
};
The existing driver may read interrupts as two interrupts for intc1, and
believe it's been successful when it has not, and one of those interrupts might
never fire. That would be very bad for a timer for example.
Additionally it makes the interrupts list difficult for a human to read, as you
need to match it with an entry in another list (this problem exists with other
parallel properties like interrupt-names too, but we can't do much better
there).
It's also easy to make a typo (e.g. an extra cell in an interrupt) that will
parse as valid when you don't expect it to. At least with the phandle in the
list it's less likely to happen.
>
> Of course interrupts-extended is more inline with standard patterns
> for bindings.
I think for this reason alone it should be preferable. Unless I'm mistaken it
would be identical to the clock bindings pattern with a uniformly named
phandle+args property and a parallel -names property. I don't think the gpio
style ${NAME}-interrupts would easily fit here.
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/
Re: [PATCH v3 10/15] KVM: MMU: allocate shadow pages from slab
On 10/24/2013 08:32 PM, Gleb Natapov wrote:
> On Thu, Oct 24, 2013 at 07:01:49PM +0800, Xiao Guangrong wrote:
>> On 10/24/2013 06:39 PM, Gleb Natapov wrote:
>>> On Thu, Oct 24, 2013 at 06:10:46PM +0800, Xiao Guangrong wrote:
On 10/24/2013 05:52 PM, Gleb Natapov wrote:
> On Thu, Oct 24, 2013 at 05:29:44PM +0800, Xiao Guangrong wrote:
>> On 10/24/2013 05:19 PM, Gleb Natapov wrote:
>>
@@ -946,7 +947,7 @@ static inline struct kvm_mmu_page
*page_header(hpa_t shadow_page)
{
struct page *page = pfn_to_page(shadow_page >> PAGE_SHIFT);
- return (struct kvm_mmu_page *)page_private(page);
+ return (struct kvm_mmu_page *)(page->mapping);
>>> Why?
>>
>> That's because page->private has been used by slab:
>>
> But does lockless path actually looks at it?
Lockless path does not use it, however, it is used by kvm_mmu_page():
static inline struct kvm_mmu_page *page_header(hpa_t shadow_page)
{
struct page *page = pfn_to_page(shadow_page >> PAGE_SHIFT);
return (struct kvm_mmu_page *)(page->mapping);
}
which is used in the common code.
>>> Ah, so the pointer is not available even after object is allocated.
>>> Make sense since we allocate object, not page here, but is it safe to
>>> use mapping like that?
>>
>> The commens says:
>>
>> struct address_space *mapping; /* If low bit clear, points to
>> * inode address_space, or NULL.
>> * If page mapped as anonymous
>> * memory, low bit is set, and
>> * it points to anon_vma object:
>> * see PAGE_MAPPING_ANON below.
>>
>> It seems mapping is used for address_space or anonymous memory, in
>> our case, the page is used by slab, so I guess it is ok. And the bug
>> i put in set_page_header() was not tiggered on both slab and slub.
>>
> Yeah, I also think so. I asked Andrea (copied) and he thinks that it is
> safe too currently, but things changes fast in this area. Andrea?
> Another option is too save slab_cache pointer and reset it before
> freeing the object but it looks ugly.
It's ugly but it isn't too bad. :)
Since currently kvm is extensively used to test/measure linux kernel
and the BUG_ON() in set_page_header() can help us to detect the potential
issue, it is easy for us to fix the possible bug in the development-cycle
if 'mapping' is used by slab. If that really happen, maybe we can switch
it to your way instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: N900 DT
>
> On Saturday 26 October 2013 02:25:02 Sebastian Reichel wrote:
> > Hi Pali,
> >
> > On Fri, Oct 25, 2013 at 08:39:40PM +0200, Pali Rohár wrote:
> > > Now I found this patch and it looks like it will be in mainline
> > > kernel. And after that it could be simple to listen for needed
> > > events from isp driver in my bq driver (without touching isp).
> > >
> > > https://lkml.org/lkml/2013/7/25/204
> > >
> > > Can you look at isp1704 driver for DT support? I think that only one
> > > gpio needs to be passed to driver from board data.
> >
> > I had a quick overview over Jenny's patchset [0] (the patch you
> > referenced is part of a bigger patchset). I don't think the scenario
> > found in the Nokia N900 is covered by it, but probably now is the time
> > to change it :)
> >
> > So for everybody new to this thread:
> >
> > Multiple chips are involved in the charging of the Nokia N900
> > battery:
> >
> > bq27200: This chip is used for reading battery status. AFAIK
> >it's not directly involved in charging the battery.
> > bq24150a: This chip takes care of actually charging the battery. It
> > has no clue about USB related stuff. The maximum
> > current it draws can be configured, though. isp1704: USB
> > charger detector. This chip is used to detect how much current may be
> > used by the bq24150a chip. rx51-temp: Analog temperature sensor for
> > the battery, which is connected via an analog-digital-converter.
> >
> > The question is how to connected these driver with each other if
> > device tree is used to boot the system. Any suggestions?
> >
The patch http://thread.gmane.org/gmane.linux.kernel/1377608 is intended to
cover similar
scenario. It connects different components involved in charging to monitor and
control the
charging. This keeps the charging logic outside the charger driver and the
charger driver just
need to be a h/w abstraction layer. It doesn't take care of the device tree
part. But as long as the
drivers are registered with power supply class, the framework can take
actions. Hope this helps.
> > [0] http://thread.gmane.org/gmane.linux.kernel/1377608
> >
> > -- Sebastian
>
> What I need is receive property change event (from isp1704) in bq24150a. And
> with this
> patch https://lkml.org/lkml/2013/7/25/204
> bq24150a driver can receive them and use only these which comes from driver
> specified in
> DT (on n900 from isp1704).
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] arc: kernel: export symbol for save_stack_trace() in stacktrace.c
Need export its symbol just like other architectures done, or can not
pass compiling with allmodconfig, the related error:
MODPOST 2994 modules
ERROR: "save_stack_trace" [kernel/backtracetest.ko] undefined!
ERROR: "save_stack_trace" [drivers/md/persistent-data/dm-persistent-data.ko]
undefined!
Signed-off-by: Chen Gang
---
arch/arc/kernel/stacktrace.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index f8b7d88..607c6e4 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -244,4 +244,5 @@ void save_stack_trace(struct stack_trace *trace)
{
arc_unwind_core(current, NULL, __collect_all, trace);
}
+EXPORT_SYMBOL_GPL(save_stack_trace);
#endif
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] percpu: stop the loop when a cpu belongs to a new group
On Sun, Oct 27, 2013 at 08:30:08AM -0400, Tejun Heo wrote: >On Mon, Oct 21, 2013 at 04:58:11PM +0800, Wei Yang wrote: >> When a cpu belongs to a new group, there is no cpu has the same group id. >> This >> means it can be assigned a new group id without checking with every others. >> >> This patch does this optimiztion. > >Does this actually matter? If so, it'd probably make a lot more sense >to start inner loop at @cpu + 1 so that it becomes O(N). One of the worst case in my mind: CPU:01234... Group: 01234... (sounds it is impossible in the real world) Every time, when we encounter a new CPU and try to assign it to a group, we found it belongs to a new group. The original logic will iterate on all old CPUs again, while the new logic could skip this and assign it to a new group. Again, this is a tiny change, which doesn't matters a lot. BTW, I don't get your point for "start inner loop at @cpu+1". The original logic is: loop 1: 0 - nr_cpus loop 2: 0 - (cpu - 1) If you found one better approach to improve the logic, I believe all the users will appreciate your efforts :-) Thanks for your review and comments again ~ > >Thanks. > >-- >tejun -- Richard Yang Help you, Help me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: remove extra put_online_cpus() inside sched_setaffinity()
v2:
Fix the whitespace issue.
commit 6acce3ef84520537f8a09a12c9ddbe814a584dd2
sched: Remove get_online_cpus() usage
has left one extra put_online_cpus() inside sched_setaffinity(), remove it
to fix the WARN:
[3165] Watchdog is alive
[3159] Started watchdog thread 3165
[ 58.695502] [ cut here ]
[ 58.697835] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84
put_online_cpus+0x43/0x70()
[ 58.702423] Modules linked in:
[ 58.704404] CPU: 0 PID: 3166 Comm: trinity-child0 Not tainted
3.12.0-rc5-01882-gf3db366 #1172
[ 58.708530] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 58.710992] 88000acfbe50 81a24643
[ 58.715410] 88000acfbe88 810c3e6b 810c3fef
[ 58.719826] 6ee0 0ffc
88000acfbe98
[ 58.724348] Call Trace:
[ 58.726190] [] dump_stack+0x4d/0x66
[ 58.728531] [] warn_slowpath_common+0x7f/0x98
[ 58.731069] [] ? put_online_cpus+0x43/0x70
[ 58.733664] [] warn_slowpath_null+0x1a/0x1c
[ 58.736258] [] put_online_cpus+0x43/0x70
[ 58.738686] [] sched_setaffinity+0x7d/0x1f9
[ 58.741210] [] ? sched_setaffinity+0x5/0x1f9
[ 58.743775] [] ? _raw_spin_unlock_irq+0x2c/0x3e
[ 58.746417] [] ? do_setitimer+0x194/0x1f5
[ 58.748899] [] SyS_sched_setaffinity+0x62/0x71
[ 58.751481] [] system_call_fastpath+0x16/0x1b
[ 58.754070] ---[ end trace 034818a1f6f06868 ]---
[ 58.757521] [ cut here ]
CC: Ingo Molnar
CC: Peter Zijlstra
Reported-by: Fengguang Wu
Tested-by: Fengguang Wu
Signed-off-by: Michael Wang
---
kernel/sched/core.c |1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..7c61f31 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct cpumask
*in_mask)
p = find_process_by_pid(pid);
if (!p) {
rcu_read_unlock();
- put_online_cpus();
return -ESRCH;
}
--
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/
Kredit-Angebot
UNION FINANCE LTD hallo Was ist Ihre Situation? Sie müssen 100% Finanzierung . Sind Sie auf der Suche nach finanzieller Hilfe müde? haben Sie konsequent die von Banken und anderen Finanzinstituten abgelehnt , wir geben Darlehen an Gesellschaften, Unternehmen , Branchen bei 3 % Zins , geben wir sowohl mittel-und langfristige Darlehen. Jede interessierte Person, unabhängig von ihrem Land sollte uns per E-Mail kontaktieren Sie jetzt ( unionfinanceli...@webadicta.org ) Wir Darlehen einen Mindestbetrag von 5,000,00 Euro und maximal 1,000,000,00 Euro Bei 3 % Zins . Füllen Sie das untenstehende Formular aus , um mit den AGB weiter Beachten Sie, dass dieser Prozess nicht länger als drei Arbeitstage , es sei denn es gibt Fahrlässigkeit des Kreditnehmers Name : ... . Familienstand: ... .. CITY : . LAND: . Telefon . ... Monatliches Einkommen . .. Darlehensbetrag benötigt: . .. Dauer des Darlehens . BERUF: ... Ausweis Nr.: .. Zweck des Darlehens : . ... Holen Sie sich zurück zu uns so bald wie möglich. Treffen Sie Ihre Nachfrage ist unser Ziel Mit freundlichen Grüßen, Mr. John Taylor Generaldirektor UNION FINANCE LTD Company No 04562011 Head Office : Mansfield Road, Floride, North Yorkshire 240 5EB , UK. e-mail: unionfinanceli...@webadicta.org Copyright © 2004-2013 UNION FINANCE LTD. Alle Rechte vorbehalten. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] commit: Add -f, --fixes option to add Fixes: line
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
wrote:
> On Sun, Oct 27, 2013 at 2:30 PM, Johan Herland wrote:
>> On Sun, Oct 27, 2013 at 1:30 PM, Christian Couder
>> wrote:
>>>
>>> Your suggestion is very good, and it is not incompatible with command
>>> line options.
>>> So both could be implemented and even work together.
>>>
>>> For example if "-f ack:Peff" was passed to the command line, "git commit"
>>> could
>>> lookup in the commit message template and see if there is one
>>> RFC822-style header
>>> that starts with or contains "ack" (discarding case) and it could look
>>> in some previous commits if
>>> there is an author whose name contains "Peff" (discarding case)
>>
>> ...may be cheaper to (first) look at the .mailmap?
>
> Ok. I haven't really had a look at how it could best be done.
>
>>> and if it is the case
>>> it could append the following to the bottom of the commit message:
>>>
>>> Fixes:
>>> Reported-by:
>>> Suggested-by:
>>> Improved-by:
>>> Acked-by: Jeff King
>>> Reviewed-by:
>>> Tested-by:
>>> Signed-off-by: Myself
>>>
>>> (I suppose that the sob is automatically added.)
>>>
>>> It would work also with "-f fix:security-bug" and would put something
>>> like what you suggested:
>>>
>>> Fixes: 1234beef56 (Commit message summmary)
>>
>> Even better: Imagine "-f" (or whatever is decided) as a general
>> mechanism for forwarding parameters to the prepare-commit-msg hook.
>> When you run "git commit -f ack:Peff -f fix:security-bug", the -f
>> arguments will be forwarded to prepare-commit-msg (as additional
>> command-line args, or on stdin), and then the prepare-commit-msg hook
>> can do whatever it wants with them (e.g. the things you describe
>> above).
>
> If "git commit" processes these arguments and puts the result in the
> commit message file that is passed to the
> prepare-commit-msg hook, then this hook can still get them from the
> file and process them however it wants.
>
> And in most cases the processing could be the same as what is done by
> the commit-msg hook when the user changes the "Fixes: xxx" and
> "Stuffed-by: yyy" lines in the editor.
>
> So it would probably be easier for people customizing the
> prepare-commit-msg and commit-msg if "git commit" processes the
> arguments instead of just passing them to the prepare-commit-msg hook.
>
> And it will be better for people who don't set up any *commit-msg hook.
> Even if there is no commit template, "-f Acked-by:Peff" and "-f
> Fixes:security-bug" could still work.
> I suspect most users don't setup any hook or commit template.
Hmm. I'm not sure what you argue about which part of the system should
perform which function. Let's examine the above options in more
detail. Roughly, the flow of events look like this
git commit -f ack:Peff -f fix:security-bug
|
v
builtin/commit.c (i.e. inside "git commit")
|
v
prepare-commit-msg hook
|
v
commit message template:
Fixes: security-bug
Acked-by: Peff
|
v
user edits commit message (may or may not change Fixes/Acked-by lines)
|
v
commit-msg hook
|
v
commit message:
Fixes: 1234beef56 (Commit message summmary)
Acked-by: Jeff King
(The above is even a bit simplified, but I believe it's sufficient for
the current discussion.) So, there are several expansions happening
between the initial "git commit" and the final commit message. They
are:
1. "fix" -> "Fixes: "
2. "security-bug" -> "1234beef56 (Commit message summmary)"
3. "ack" -> "Acked-by: "
4. "Peff" -> "Jeff King "
First, I think we both agree that expansions #2 and #4 MUST be done by
the commit-msg hook. The reason for this is two-fold: (a) the
expansion must be done (at least) after the user has edited the commit
message (since the values entered by the user might require the same
expansion), and (b) how (and whether) to perform the expansion is a
project-specific policy question, and not something that Git can
dictate. Obviously, common functionality can be made available in the
default hook shipped by Git, but it's up to each project to enable
and/or customize this.
Second, there is #1 and #3, the expansion of "ack" -> "Acked-by:" and
"fix" -> "Fixes:". Is this expansion performed by the
prepare-commit-msg hook, or directly inside builtin/commit.c?
If you are arguing for the latter (and I'm not sure that you are), we
would need to add a dictionary to "git commit" that maps shorthand
field names ("ack") to the RFC822 -style equivalent ("Acked-by: ").
I would instead argue for the former, i.e. simply forwarding "ack" and
"fix" as-is to the prepare-commit-msg hook, and let it deal with the
appropriate expansion. The main reason for this is that if a project
wants to add another shorthand expansion (e.g. "bug" ->
"Related-Bugzilla-Id: "), they can do so without hacking
builtin/commit.c.
Certainly, we could ship a default prepare-commit-msg hook that knows
how to expand the usual suspects (like "ack" and "fix"), but
hardcoding this
Re: [PATCH 3/3] percpu: little optimization on calculating pcpu_unit_size
On Sun, Oct 27, 2013 at 08:36:34AM -0400, Tejun Heo wrote: >On Mon, Oct 21, 2013 at 04:58:13PM +0800, Wei Yang wrote: >> pcpu_unit_size exactly equals to ai->unit_size. >> >> This patch assign this value instead of calculating from pcpu_unit_pages. >> Also >> it reorder them to make it looks more friendly to audience. > >Ditto. I'd rather not change unless this is clearly better. This one change an assignement to a shift, which in my mind is a little faster. Well, this is just executed once during the boot time, not a big deal. > >Thanks. > >-- >tejun -- Richard Yang Help you, Help me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: remove extra put_online_cpus() inside sched_setaffinity()
Hi, Ingo
On 10/25/2013 07:48 PM, Ingo Molnar wrote:
[snip]
>> ---
>> kernel/sched/core.c |1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c06b8d3..7c61f31 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct cpumask
>> *in_mask)
>> p = find_process_by_pid(pid);
>> if (!p) {
>> rcu_read_unlock();
>> - put_online_cpus();
>> return -ESRCH;
>> }
>
> The patch is whitespace damaged.
Forgive me for the silly mistake... the line may be cursed... will
recheck and send out the right format, thanks for the notify :)
Regards,
Michael Wang
>
> Thanks,
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH V2] f2fs: check all ones or zeros bitmap with bitops for better mount performance
On 10/28/2013 10:19 AM, 이창만 wrote:
> To check whether bitmap are all zeros or all ones, I think memcmp is more
> neat.
> But I don't know exactly performance gap between memcmp and find_next_bit.
According to my understanding,
memcmp: one by one search,
find_next_bit: binary search.
Regards,
Gu
>
>
> -Original Message-
> From: Chao Yu [mailto:chao2...@samsung.com]
> Sent: Thursday, October 24, 2013 5:21 PM
> To: jaegeuk@samsung.com
> Cc: linux-fsde...@vger.kernel.org; '谭姝'; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH V2] f2fs: check all ones or zeros bitmap with
> bitops for better mount performance
>
> Previously, check_block_count check valid_map with bit data type in common
> scenario that sit has all ones or zeros bitmap, it makes low mount
> performance.
> So let's check the special bitmap with integer data type instead of the bit
> one.
>
> v2:
> use find_next_bit_le/find_next_zero_bit_le for better performance and
> readable as Jaegeuk suggested.
>
> Suggested-by: Jaegeuk Kim
> Signed-off-by: Tan Shu
> Signed-off-by: Yu Chao
> ---
> fs/f2fs/segment.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 7f94d78..d25b6af
> 100644
> --- a/fs/f2fs/segment.h
> +++ b/fs/f2fs/segment.h
> @@ -552,6 +552,23 @@ static inline void check_block_count(struct f2fs_sb_info
> *sbi,
> /* check boundary of a given segment number */
> BUG_ON(segno > end_segno);
>
> + /* check all ones or zeros valid_map */
> + if (GET_SIT_VBLOCKS(raw_sit) == 0) {
> + int pos = find_next_bit_le(_sit->valid_map,
> + sbi->blocks_per_seg,
> + 0);
> + if (pos != sbi->blocks_per_seg)
> + BUG();
> + return;
> + } else if (GET_SIT_VBLOCKS(raw_sit) == sbi->blocks_per_seg) {
> + int pos = find_next_zero_bit_le(_sit->valid_map,
> + sbi->blocks_per_seg,
> + 0);
> + if (pos != sbi->blocks_per_seg)
> + BUG();
> + return;
> + }
> +
> /* check bitmap with valid block count */
> for (i = 0; i < sbi->blocks_per_seg; i++)
> if (f2fs_test_bit(i, raw_sit->valid_map))
> --
> 1.7.9.5
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991=/4140/ostg.clktrk
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] percpu: merge two loops when setting up group info
On Sun, Oct 27, 2013 at 08:35:42AM -0400, Tejun Heo wrote: >On Mon, Oct 21, 2013 at 04:58:12PM +0800, Wei Yang wrote: >> There are two loops setting up the group info of pcpu_alloc_info. They share >> the same logic, so merge them could be time efficient when there are many >> groups. >> >> This patch merge these two loops into one. > >It *looks* correct to me but I'd rather not change this unless you can >show me this actually matters, which I find extremely doubtful given >nr_groups would be in the order of few thousands even on an extremely >large machine. Tejun, thanks for your review and comments. I agree with you that the nr_groups won't be very large, which means it will not bring many benefits. This is just a small code refine. If you don't like it, just drop it :-) > >Thanks. > >-- >tejun -- Richard Yang Help you, Help me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else
Hello it was pointed out to me that in the 3.7 kernel (more specifically, 3581fe0ef37ce12ac7a4f74831168352ae848edc ) a change was made in the ARM architecture to change how PERF_EVENT_IOC_PERIOD is handled. Unlike other architectures, post-3.7 ARM updates the period right away rather than waiting until the next overflow. I can't find any discussion as to why this change was made. Should other architectures be updated to? I just wanted to find out the rationale for this before I update the manpage to reflect the difference in behaviors between architectures. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH V2] f2fs: check all ones or zeros bitmap with bitops for better mount performance
To check whether bitmap are all zeros or all ones, I think memcmp is more neat.
But I don't know exactly performance gap between memcmp and find_next_bit.
-Original Message-
From: Chao Yu [mailto:chao2...@samsung.com]
Sent: Thursday, October 24, 2013 5:21 PM
To: jaegeuk@samsung.com
Cc: linux-fsde...@vger.kernel.org; '谭姝'; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net
Subject: [f2fs-dev] [PATCH V2] f2fs: check all ones or zeros bitmap with bitops
for better mount performance
Previously, check_block_count check valid_map with bit data type in common
scenario that sit has all ones or zeros bitmap, it makes low mount performance.
So let's check the special bitmap with integer data type instead of the bit one.
v2:
use find_next_bit_le/find_next_zero_bit_le for better performance and
readable as Jaegeuk suggested.
Suggested-by: Jaegeuk Kim
Signed-off-by: Tan Shu
Signed-off-by: Yu Chao
---
fs/f2fs/segment.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 7f94d78..d25b6af 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -552,6 +552,23 @@ static inline void check_block_count(struct f2fs_sb_info
*sbi,
/* check boundary of a given segment number */
BUG_ON(segno > end_segno);
+ /* check all ones or zeros valid_map */
+ if (GET_SIT_VBLOCKS(raw_sit) == 0) {
+ int pos = find_next_bit_le(_sit->valid_map,
+ sbi->blocks_per_seg,
+ 0);
+ if (pos != sbi->blocks_per_seg)
+ BUG();
+ return;
+ } else if (GET_SIT_VBLOCKS(raw_sit) == sbi->blocks_per_seg) {
+ int pos = find_next_zero_bit_le(_sit->valid_map,
+ sbi->blocks_per_seg,
+ 0);
+ if (pos != sbi->blocks_per_seg)
+ BUG();
+ return;
+ }
+
/* check bitmap with valid block count */
for (i = 0; i < sbi->blocks_per_seg; i++)
if (f2fs_test_bit(i, raw_sit->valid_map))
--
1.7.9.5
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991=/4140/ostg.clktrk
___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to get PGP/GPG public key fingerprint
Got it. Thank you. On Fri, Sep 27, 2013 at 12:45 PM, Greg KH wrote: > On Fri, Sep 27, 2013 at 09:33:39AM +0800, Li, Zhen-Hua wrote: >> Hi Guys, >> In the FAQ page of kernel.org (https://www.kernel.org/faq.html) , >> it says if one wants to get a kernel.org account, he needs to provide >> "PGP/GPG public key fingerprint", and the key should: >> >> Key should be signed by as many kernel developers as you know >> Accounts will not be issued until key carries enough signatures >> Key and signatures must be available on public key servers >> >> My Question Is: how can I get the key? > > You create it yourself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/kconfig/menu.c: warning: jump may be used uninitialized in this function
On Sun, 27 Oct 2013 at 18:28, Christian Kujau wrote:
> While doing "make oldconfig" on 3.12-rc7 with gcc-4.7.2 (Debian), the
> following warning is printed:
>
> HOSTCC scripts/kconfig/zconf.tab.o
> In file included from scripts/kconfig/zconf.tab.c:2537:0:
> /usr/local/src/linux-git/scripts/kconfig/menu.c: In function ‘get_symbol_str’:
> /usr/local/src/linux-git/scripts/kconfig/menu.c:586:18: warning: ‘jump’ may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> /usr/local/src/linux-git/scripts/kconfig/menu.c:547:19: note: ‘jump’ was
> declared here
Grrr, only after I sent this message I found this was reported in
September already by Madhavan Srinivasan: https://lkml.org/lkml/2013/9/19/24
Does anybody know the state of this fix?
Thanks,
Christian.
> The following patch seems to fix that:
>
> Signed-off-by: Christian Kujau
>
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index c1d5320..23b1827 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -544,7 +544,7 @@ static void get_prompt_str(struct gstr *r, struct
> property *prop,
> {
> int i, j;
> struct menu *submenu[8], *menu, *location = NULL;
> - struct jump_key *jump;
> + struct jump_key *jump = NULL;
>
> str_printf(r, _("Prompt: %s\n"), _(prop->text));
> menu = prop->menu->parent;
>
>
> Christian.
> --
> BOFH excuse #177:
>
> sticktion
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
BOFH excuse #449:
greenpeace free'd the mallocs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] commit: Add -f, --fixes option to add Fixes: line
There are unbound number of kinds of trailers people would want to add, depending on their projects' needs. We should not have to add a specific support for a tailer like this one, before thinking through to see if we can add generic support for adding arbitrary trailers to avoid code and interface bloat. Think of the existing --signoff as a historical mistake. Such a generic "adding arbitrary trailers" support, when done properly, should be able to express what "--signoff" does, and we should be able to redo "--signoff" as a special case of that generic "adding arbitrary trailers" support, and at that point, "Fixes:" trailer the kernel project wants to use should fall out as a natural consequence. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] AHCI: disabled FBS prior to issuing software reset
Hi, > Your patch is still completely white space corrupted. Please check > your mail settings. Using git-send-email is usually a good idea. I'm > applying the patch manually this time but *please* make sure your mail > setup is working before posting things next time. Sorry, my gmail maybe has setting issue. I'll use git to send mail next time, thank very much. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scripts/kconfig/menu.c: warning: jump may be used uninitialized in this function
While doing "make oldconfig" on 3.12-rc7 with gcc-4.7.2 (Debian), the
following warning is printed:
HOSTCC scripts/kconfig/zconf.tab.o
In file included from scripts/kconfig/zconf.tab.c:2537:0:
/usr/local/src/linux-git/scripts/kconfig/menu.c: In function ‘get_symbol_str’:
/usr/local/src/linux-git/scripts/kconfig/menu.c:586:18: warning: ‘jump’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
/usr/local/src/linux-git/scripts/kconfig/menu.c:547:19: note: ‘jump’ was
declared here
The following patch seems to fix that:
Signed-off-by: Christian Kujau
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index c1d5320..23b1827 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -544,7 +544,7 @@ static void get_prompt_str(struct gstr *r, struct property
*prop,
{
int i, j;
struct menu *submenu[8], *menu, *location = NULL;
- struct jump_key *jump;
+ struct jump_key *jump = NULL;
str_printf(r, _("Prompt: %s\n"), _(prop->text));
menu = prop->menu->parent;
Christian.
--
BOFH excuse #177:
sticktion
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RFC: paravirtualizing perf_clock
Often when debugging performance problems in a virtualized environment
you need to correlate what is happening in the guest with what is
happening in the host. To correlate events you need a common time basis
(or the ability to directly correlate the two).
The attached patch paravirtualizes perf_clock, pulling the timestamps in
VMs from the host using an MSR read if the option is available (exposed
via KVM feature flag). I realize this is not the correct end code but it
illustrates what I would like to see -- host and guests using the same
perf_clock so timestamps directly correlate.
Any suggestions on how to do this and without impacting performance. I
noticed the MSR path seems to take about twice as long as the current
implementation (which I believe results in rdtsc in the VM for x86 with
stable TSC).
David
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca434e0..5a023ddf085e 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
#define KVM_FEATURE_STEAL_TIME 5
#define KVM_FEATURE_PV_EOI 6
#define KVM_FEATURE_PV_UNHALT 7
+#define KVM_FEATURE_PV_PERF_CLOCK 8
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -40,6 +41,7 @@
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
#define MSR_KVM_STEAL_TIME 0x4b564d03
#define MSR_KVM_PV_EOI_EN 0x4b564d04
+#define MSR_KVM_PV_PERF_CLOCK 0x4b564d05
struct kvm_steal_time {
__u64 steal;
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 9d8449158cf9..fb7824a64823 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,7 @@
#include
#include
#include
+#include
#include "perf_event.h"
@@ -52,6 +54,38 @@ u64 __read_mostly hw_cache_extra_regs
[PERF_COUNT_HW_CACHE_OP_MAX]
[PERF_COUNT_HW_CACHE_RESULT_MAX];
+
+#ifdef CONFIG_PARAVIRT
+
+static int have_pv_perf_clock;
+
+static void __init perf_clock_init(void)
+{
+ if (kvm_para_available() &&
+ kvm_para_has_feature(KVM_FEATURE_PV_PERF_CLOCK)) {
+ have_pv_perf_clock = 1;
+ }
+}
+
+u64 perf_clock(void)
+{
+ if (have_pv_perf_clock)
+ return native_read_msr(MSR_KVM_PV_PERF_CLOCK);
+
+ /* otherwise return local_clock */
+ return local_clock();
+}
+
+#else
+u64 perf_clock(void)
+{
+ return local_clock();
+}
+
+static inline void __init perf_clock_init(void)
+{
+}
+#endif
/*
* Propagate event elapsed time into the generic event.
* Can only be executed on the CPU where the event is active.
@@ -1496,6 +1530,8 @@ static int __init init_hw_perf_events(void)
struct x86_pmu_quirk *quirk;
int err;
+ perf_clock_init();
+
pr_info("Performance Events: ");
switch (boot_cpu_data.x86_vendor) {
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index b110fe6c03d4..5b258a18f9c0 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -414,7 +414,8 @@ static int do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32
function,
(1 << KVM_FEATURE_ASYNC_PF) |
(1 << KVM_FEATURE_PV_EOI) |
(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
-(1 << KVM_FEATURE_PV_UNHALT);
+(1 << KVM_FEATURE_PV_UNHALT) |
+(1 << KVM_FEATURE_PV_PERF_CLOCK);
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e5ca72a5cdb6..61ec1f1c7d38 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2418,6 +2418,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr,
u64 *pdata)
case MSR_KVM_PV_EOI_EN:
data = vcpu->arch.pv_eoi.msr_val;
break;
+ case MSR_KVM_PV_PERF_CLOCK:
+ data = perf_clock();
+ break;
case MSR_IA32_P5_MC_ADDR:
case MSR_IA32_P5_MC_TYPE:
case MSR_IA32_MCG_CAP:
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index c8ba627c1d60..c8a51954ea9e 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -865,4 +865,7 @@ _name##_show(struct device *dev,
\
\
static struct device_attribute format_attr_##_name = __ATTR_RO(_name)
+#if defined(CONFIG_X86_64)
+u64 perf_clock(void);
+#endif
#endif /* _LINUX_PERF_EVENT_H */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d49a9d29334c..b073975af05a
Re: [patch 1/6] Add function efi_remap_region for remapping to saved virt address
Hi, Thanks for review
On 10/27/13 at 12:50pm, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 11:47:14AM +0800, dyo...@redhat.com wrote:
> > Kexec kernel will use saved runtime virtual mapping, so add a
> > new function efi_remap_region to remapping it directly without
> > calculate the virt addr from efi_va.
> >
> > The md is passed in from 1st kernel, the virtual addr is
> > saved in md->virt_addr.
> >
> > Signed-off-by: Dave Young
> > ---
> > arch/x86/include/asm/efi.h |1 +
> > arch/x86/platform/efi/efi_32.c |4
> > arch/x86/platform/efi/efi_64.c | 13 +
> > 3 files changed, 18 insertions(+)
> >
> > --- linux-2.6.orig/arch/x86/include/asm/efi.h
> > +++ linux-2.6/arch/x86/include/asm/efi.h
> > @@ -112,6 +112,7 @@ extern void efi_call_phys_epilog(void);
> > extern void efi_unmap_memmap(void);
> > extern void efi_memory_uc(u64 addr, unsigned long size);
> > extern void __init efi_map_region(efi_memory_desc_t *md);
> > +extern void __init efi_remap_region(efi_memory_desc_t *md);
> > extern void efi_sync_low_kernel_mappings(void);
> > extern void __init old_map_region(efi_memory_desc_t *md);
> >
> > --- linux-2.6.orig/arch/x86/platform/efi/efi_64.c
> > +++ linux-2.6/arch/x86/platform/efi/efi_64.c
> > @@ -177,6 +177,19 @@ void __init efi_map_region(efi_memory_de
> > md->virt_addr = efi_va;
> > }
> >
> > +void __init efi_remap_region(efi_memory_desc_t *md)
>
> remap? Why?
>
> You did have efi_map_region_fixed() which made more sense.
remap here means mapping to same virt addr in 2nd kernel, I feel
it's a little better, but I have no strong opinion.
Will change to _fixed
>
> > +{
> > + pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
> > + unsigned long pf = 0;
> > +
> > + if (!(md->attribute & EFI_MEMORY_WB))
> > + pf |= _PAGE_PCD;
> > +
> > + if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr,
> > md->num_pages, pf))
>
> ERROR: space required before the open parenthesis '('
> #59: FILE: arch/x86/platform/efi/efi_64.c:188:
> + if(kernel_map_pages_in_pgd(pgd, md->phys_addr, md->virt_addr,
> md->num_pages, pf))
Will fix
>
>
> Please run them all through checkpatch.pl - better yet, integrate
> checkpatch into your workflow like using git hooks, for example.
Hmm, will do. Have been long time being away from sending patches.
>
> > + pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
>
> WARNING: Prefer pr_warn(... to pr_warning(...
> #60: FILE: arch/x86/platform/efi/efi_64.c:189:
> + pr_warning("Error mapping PA 0x%llx -> VA 0x%llx!\n",
Will fix
>
> > + md->phys_addr, md->virt_addr);
> > +}
> > +
> > void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long
> > size,
> > u32 type, u64 attribute)
> > {
> > --- linux-2.6.orig/arch/x86/platform/efi/efi_32.c
> > +++ linux-2.6/arch/x86/platform/efi/efi_32.c
> > @@ -46,6 +46,10 @@ void __init efi_map_region(efi_memory_de
> > old_map_region(md);
> > }
> >
> > +void __init efi_remap_region(efi_memory_desc_t *md)
> > +{
> > +}
>
> Let's keep braces on the same line as the function to save space:
Ok, will update
>
> void __init efi_remap_region(efi_memory_desc_t *md) {}
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/6] x86 efi: reserve boot service fix
On 10/27/13 at 08:30pm, Matt Fleming wrote: > On Sun, 27 Oct, at 11:50:09AM, Borislav Petkov wrote: > > On Sun, Oct 27, 2013 at 11:47:15AM +0800, dyo...@redhat.com wrote: > > > Current code check boot service region with kernel text region by: > > > start+size >= __pa_symbol(_text) > > > The end of the above region should be start + size - 1 instead. > > > > > > I see this problem in ovmf + Fedora 19 grub boot: > > > text start: 100 md start: 80 md size: 80 > > > > > > Signed-off-by: Dave Young > > > > Acked-by: Borislav Petkov > > > > Btw, Matt, this being a bugfix and all, shouldn't it be tagged for > > stable? > > Well that depends. Dave, am I correct in thinking that you only noticed > this bug when writing kexec support? I'm inclined not to bother with a > stable tag if no one has ever noticed any fallout from this bug until > now. There should be some people see below message with non-kexec kernel: "Could not reserve boot range ..." But it's hard for them to notice the bad functionality because it's only one mem range which might be not the boot range what SetVirtualAddressMap need -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI / processor: Do not request ACPI cpufreq module directly
From: Rafael J. Wysocki
Function acpi_processor_load_module() used by the ACPI processor
driver can only really work if the acpi-cpufreq module is available
when acpi_processor_start() is executed which usually is not the case
for systems loading the processor driver module from an initramfs.
Moreover, that used to be a hackish workaround for module autoloading
issues, but udev loads acpi-cpufreq just fine nowadays, so that
function isn't really necessary any more. For this reason, drop
acpi_processor_load_module() entirely.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/processor_driver.c |1 -
drivers/acpi/processor_perflib.c | 22 --
include/acpi/processor.h |1 -
3 files changed, 24 deletions(-)
Index: linux-pm/drivers/acpi/processor_driver.c
===
--- linux-pm.orig/drivers/acpi/processor_driver.c
+++ linux-pm/drivers/acpi/processor_driver.c
@@ -171,7 +171,6 @@ static int __acpi_processor_start(struct
#ifdef CONFIG_CPU_FREQ
acpi_processor_ppc_has_changed(pr, 0);
- acpi_processor_load_module(pr);
#endif
acpi_processor_get_throttling_info(pr);
Index: linux-pm/drivers/acpi/processor_perflib.c
===
--- linux-pm.orig/drivers/acpi/processor_perflib.c
+++ linux-pm/drivers/acpi/processor_perflib.c
@@ -235,28 +235,6 @@ void acpi_processor_ppc_exit(void)
acpi_processor_ppc_status &= ~PPC_REGISTERED;
}
-/*
- * Do a quick check if the systems looks like it should use ACPI
- * cpufreq. We look at a _PCT method being available, but don't
- * do a whole lot of sanity checks.
- */
-void acpi_processor_load_module(struct acpi_processor *pr)
-{
- static int requested;
- acpi_status status = 0;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
-
- if (!arch_has_acpi_pdc() || requested)
- return;
- status = acpi_evaluate_object(pr->handle, "_PCT", NULL, );
- if (!ACPI_FAILURE(status)) {
- printk(KERN_INFO PREFIX "Requesting acpi_cpufreq\n");
- request_module_nowait("acpi_cpufreq");
- requested = 1;
- }
- kfree(buffer.pointer);
-}
-
static int acpi_processor_get_performance_control(struct acpi_processor *pr)
{
int result = 0;
Index: linux-pm/include/acpi/processor.h
===
--- linux-pm.orig/include/acpi/processor.h
+++ linux-pm/include/acpi/processor.h
@@ -225,7 +225,6 @@ struct acpi_processor_errata {
} piix4;
};
-extern void acpi_processor_load_module(struct acpi_processor *pr);
extern int acpi_processor_preregister_performance(struct
acpi_processor_performance
__percpu *performance);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hello !
Hi, i got your email from a marketing company in the US, and i decided to tell you about the business opportunity in the company where i work. I work with a multi national jewelry company in Texas USA. We are in need of raw materials in our company and i will like you to stand as the supplier of the raw material in India so we both can make extra profit from it. My Company always visit your country (India) to procure most of their raw materials since the past 2 years in huge quantity.They pay for the materials on Cash on Delivery (C.O.D.) basis upon verification of the materials. I am looking for a reliable person/businessman that understands the Indian local language who will assist me in contacting the local dealer of this product in India. I have called the local dealer many times, but could not understand the local language or rather my accent, to enable me negotiate the terms of the supply with them. This proposal is 100% risk free and will be another income generating business outside your Specialization. I will give you more details of this proposal the moment I hear from you. I await your urgent response, to my email (andrew.mart...@outlook.com) Best Regards, Andrew Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] commit: Add -f, --fixes option to add Fixes: line
On 10/26/13 18:34, Josh Triplett wrote:
Linux Kernel ... "Fixes:" line ... containing an abbreviated commit hash
This helps people (or automated tools) determine how far to backport
I beg pardon if I'm rehearsing an old debate, but it seems to me it
would be better and worthwhile to bring more of git to bear by adding
`reference` links as follows from considering this proposed sequence:
# ...G---B---...history-with-bug-at-B
Gprime=`git commit-tree --reference G`
Bprime=`git commit-tree --reference B -p $Gprime`
# ...G---B---... history-with-bug-at-B
# : : # <-- `:`'s are `reference` links
# G'--B'$Bprime is a mergeable cherry-pick for B
`reference` links have no enforced semantics. Teach all current logic to
ignore them (fetch doesn't fetch through them, fsck doesn't care, etc.).
Elaborating some of the good parts:
* If the author and committer data are left untouched when
`commit-tree`'s tree and message arguments are defaulted, as above, to
the referenced commit's tree and message, the resulting commit is unique.
* Bullet-proof cherry-pick creation becomes easy and idempotent:
git-make-cherry-pick() {
local picked=$1
set -- `git rev-list --parents $picked^!`
shift
local parents
local parent
local p2
for parent; do
p2="$p2 -p `git commit-tree --reference $parent`"
done
git commit-tree --reference $picked $parents`
}
* Which makes the created commit id a fully-implemented _change-id_ for
the referenced commit:
git merge $(git-make-cherry-pick $B)
can be done from anywhere, merge won't have to rely on patch-id's
to detect cherry-picks done this way.
* A bugged commit gets fixed by fixing its reference commit and merging
normally, worry-free:
...G---B ... -F Merge fix X for a bug in B
: : /
G'--B'---X X's commit message is the `Fixes:` equivalent
Bugfix commit X can be safely merged anywhere. Worst case, `git
merge -s ours --no-commit X` and do whatever you would have done otherwise.
`merge` might usefully be updated to warn about merging from a commit
with only a reference parent, I think merging from `G'` would probably
be a mistake.
---
So, this is as far as I've gotten with this, is there reason to think it
should or shouldn't be pursued?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Transcend's "one of the most cavalier GPL violations in a long time"
On 10/15/2013 01:42:56 AM, Rogelio Serrano wrote: On Sun, Oct 13, 2013 at 1:02 PM, Pavel Machek wrote: You have a piece of code under the GPL and the majority of the copyright holders say they will not enforce it. Thats virtually public domain code. Thats why i stopped contributing to the linux kernel and opted to maintain a massive patch instead. So in response to other people not pushing their code upstream, you stopped pushing any of your code upstream. That'll show 'em! Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/11] Staging: bcm: Replace UCHAR with unsigned char in Adapter.h
On Sun, Oct 27, 2013 at 11:25:55AM +0300, Dan Carpenter wrote: > On Sat, Oct 26, 2013 at 02:15:13AM -0400, Kevin McKinney wrote: > > This patch replace "UCHAR" with "unsigned > > char" in Adapter.h > > I feel like these should pretty much all be u8 instead of "unsigned > char". Yeah, I thought about changing these to u8. I will resubmit these 11 patches. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] charger-manager: Use IIO subsystem to read battery temperature instead of legacy method
Hi Pavel,
On 10/27/2013 08:17 PM, Pavel Machek wrote:
> Hi!
>
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index e6f92b4..6700191 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -309,6 +309,7 @@ config CHARGER_MANAGER
>> bool "Battery charger manager for multiple chargers"
>> depends on REGULATOR && RTC_CLASS
>> select EXTCON
>> +select IIO
>> help
>>Say Y to enable charger-manager support, which allows multiple
>>chargers attached to a battery and multiple batteries attached to
>> a
>
> Umm. Are there charger-manager users that don't have temperature sensor on
> IIO?
I'll remove tightly coupled dependency between IIO and Charger-manager.
>
>> +if (desc->channel) {
>> +temp = iio_read_channel_raw(desc->channel, last_temp_mC);
>> +
>> +/*
>> + * The charger-manager use IIO subsystem to read ADC raw data
>> + * from IIO ADC device drvier. The each device driver has
>> + * own non-standard ADC table. If user of charger-manager
>> + * would like to get correct temperature value, have to convert
>> + * 'last_temp_mC' variable according to proper calculation
>> + * method and own ADC table.
>> + */
>> +
>> +if (*last_temp_mC >= desc->iio_adc_overheat)
>> +temp = CM_TEMP_NORMAL; /* Overheat */
>> +else if (*last_temp_mC <= desc->iio_adc_cold)
>> +temp = CM_TEMP_COLD;/* Cold */
>> +else
>> +temp = CM_TEMP_NORMAL; /* Normal */
>
> Something is definitely wrong here.
I'll fix it as below:
temp = CM_TEMP_NORMAL; /* Overheat */
-> temp = CM_TEMP_OVERHEAT; /* Overheat */
Also, as you mentioned, this patch haven't included the converting sequence
from ADC value to correct temperature because currently iio driver haven't
support this feature. So, I'm going to discuss this issue on following mailing
thread:
- https://lkml.org/lkml/2013/10/26/42
If I find proper method to get temperature on IIO driver, I'll modify it.
Thanks for your comment.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter
On Fri, Oct 25, 2013 at 06:07:16PM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> This patch addresses a long-standing bug where the get_user_pages_fast()
> write parameter used for setting the underlying page table entry permission
> bits was incorrectly set to write=1 for data_direction=DMA_TO_DEVICE, and
> passed into get_user_pages_fast() via vhost_scsi_map_iov_to_sgl().
>
> However, this parameter is intended to signal WRITEs to pinned userspace
> PTEs for the virtio-scsi DMA_FROM_DEVICE -> READ payload case, and *not*
> for the virtio-scsi DMA_TO_DEVICE -> WRITE payload case.
>
> This bug would manifest itself as random process segmentation faults on
> KVM host after repeated vhost starts + stops and/or with lots of vhost
> endpoints + LUNs.
>
> Cc: Stefan Hajnoczi
> Cc: Michael S. Tsirkin
> Cc: Asias He
> Cc: # 3.6+
> Signed-off-by: Nicholas Bellinger
Reviewed-by: Asias He
> ---
> drivers/vhost/scsi.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index ce5221f..e663921 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -1056,7 +1056,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
> vhost_virtqueue *vq)
> if (data_direction != DMA_NONE) {
> ret = vhost_scsi_map_iov_to_sgl(cmd,
> >iov[data_first], data_num,
> - data_direction == DMA_TO_DEVICE);
> + data_direction == DMA_FROM_DEVICE);
> if (unlikely(ret)) {
> vq_err(vq, "Failed to map iov to sgl\n");
> goto err_free;
> --
> 1.7.2.5
>
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] power_supply: Add charger control properties
Hello Jenny,
Thanks a lot for your work on this!
On Mon, Sep 23, 2013 at 11:33:59PM +0530, Jenny TC wrote:
> The battery charger needs to have control path along
> with the reporting charger properties. In existing solutions
> this is implemented using regulator framework. A regulator
> framework doesn't fit a charger driver requirement because of the
> following reason
>
General note:
Please always Cc as many relevant developers as possible, not just me. For
me it takes months to review patches, and you surely want to get at least
a preliminary review from other power supply folks. By Cc'ing just me you
are slowing yourself down.
If you get some Acks/Reviews from other developers on your patches that
shows that the feature is surely in demand and makes sense in general.
"git shortlog -s -n -e drivers/power/*charg*" is a good start to see whom
you'd better Cc in this case.
(Unrelated to these patches, but just FYI, having a chain of
Reviewed-by: Somebody1 <...@same_company.foo>
Reviewed-by: Somebody2 <...@same_company.foo>
...
Reviewed-by: SomebodyN <...@same_company.foo>
Works in opposite direction, it makes me suspicious. :)
> and charging (charger to battery).Disabling the charging path alone
> (eg over battery temperature) will allow the platform to work with
> power from charger without discharging the battery. And the charger
> may need to be disabled completely based on the charger temperature
> or the platform temperature.
> Charger has more than one pair of voltage/current to control (CC,CV,INLMT)
> These features will not directly fit in the regulator framework
>
> Since the charger driver sits in the power supply subsystem it make sense
> to add the properties to control the charger.
Looking into the patches, it seems that we are putting a lot of
charger-specific knobs into the power supply class, but the primary idea
of power supply subsystem is to monitor the power supplies of the system
itself and system's devices like mouse/keyboard's batteries.
The border of what we define as power supply class object is blurry, so
there is a lot of confusion indeed. For example, some chargers register
TYPE_MAINS or TYPE_USB power_supply objects, but they do it since the
charger chip itself is responsible for monitoring these supplies, so it is
fine, and it does not affect the power supply class itself.
But do we really want to control the chargers through the power_supply's
user-visible interface? It makes the whole power supply thing so
complicated that I'm already losing track of it. Right now I think I would
prefer to move all the charger logic out of the psy class.
More specifically, this code:
> @@ -561,6 +575,11 @@ int power_supply_register(struct device *parent, struct
> power_supply *psy)
> if (rc)
> goto create_triggers_failed;
>
> + if (psy_is_charger(psy))
> + rc = power_supply_register_charger(psy);
> + if (rc)
> + pr_debug("device: '%s': power_supply_register_charger failed\n",
> + dev_name(dev));
I have a weird feeling about the fact that the power_supply_register()
registers a charger. OK, we have thermal stuff registration there, but it
is completely different. We have the cooling device registration there as
well, and this stuff would be really nice to move out to some "chargers
subsystem".
So, Jenny, the question is: can we separate chargers logic from the power
supply? So that we don't have "charger enable"/"charger disable" knobs in
the psy class itself. It is still fine if you need to have some interface
to the psy class so that the chargers subsystem would interface with it,
though. But I think that charger drivers have to register itself with two
subsystems: chargers and power_supply (optionally).
Thanks,
Anton
> Signed-off-by: Jenny TC
>
> Change-Id: Id91dbbd8f34499afa97b7d8f11ecf5467847f6a8
> ---
> Documentation/power/power_supply_class.txt | 16
> drivers/power/power_supply_sysfs.c |8
> include/linux/power_supply.h |8
> 3 files changed, 32 insertions(+)
>
> diff --git a/Documentation/power/power_supply_class.txt
> b/Documentation/power/power_supply_class.txt
> index 3f10b39..5a5e7fa 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
> @@ -118,6 +118,10 @@ relative, time-based measurements.
> CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
> CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
> power supply object.
> +INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
> +the current drawn from a charging source.
> +CHARGE_TERM_CUR - Charge termination current used to detect the end of charge
> +condition
>
> CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
> CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
> @@ -140,12 +144,24 @@
Re: [PATCH 2/4] charger-manager: Use IIO subsystem to read battery temperature instead of legacy method
On 10/26/2013 08:20 PM, Lars-Peter Clausen wrote:
> On 10/22/2013 02:51 PM, Chanwoo Choi wrote:
>> This patch support charger-manager use IIO(Industrial I/O) subsystem to read
>> current battery temperature instead of legacy methor about callback function.
>
> How does this look in hardware? Do you have a general purpose ADC connected
> to a temperature sensor that has a temperature dependent voltage output? And
> at some point during the board design you measure the raw value of the ADC
> both for the lower and the upper threshold temperatures?
As you comment, I have to convert ADC value with h/w constraint(voltage ouput,
resistance).
Previously, I used exynos-adc driver(drivers/iio/adc/exynos_adc.c) to get ADC
value
about temperature and then use ntc_thermistor(drivers/hwmon/ntc_thermistor.c)
for converting temperature. But, I didn't find same driver of ntc_thermistor
in drivers/iio for converting. So, this patchset only connected with iio drvier
to get ADC value. In next, I'm cosidering how to get the correct temperature
from iio driver.
If you possible, could you give me advices about this issue?
Also, I will support POWER_SUPPLY_PROP_TEMP* property of power_supply class
to get temperature from fuel-gauge or charger device.
>
>>
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Kyungmin Park
>> Signed-off-by: Myungjoo Ham
>> ---
>> drivers/power/Kconfig | 1 +
>> drivers/power/charger-manager.c | 88
>> +--
>> include/linux/power/charger-manager.h | 13 ++
>> 3 files changed, 97 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index e6f92b4..6700191 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -309,6 +309,7 @@ config CHARGER_MANAGER
>> bool "Battery charger manager for multiple chargers"
>> depends on REGULATOR && RTC_CLASS
>> select EXTCON
>> +select IIO
>
> Are you sure you want to force select the IIO framework? It looks like we do
> not stub out iio_channel_get() and friends yet if CONFIG_IIO is not
> selected. But I think that will the better solution here.
>
>> help
>>Say Y to enable charger-manager support, which allows multiple
>>chargers attached to a battery and multiple batteries attached to
>> a
>> diff --git a/drivers/power/charger-manager.c
>> b/drivers/power/charger-manager.c
>> index cc720f9..02a395c 100644
>> --- a/drivers/power/charger-manager.c
>> +++ b/drivers/power/charger-manager.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> static const char * const default_event_names[] = {
>> [CM_EVENT_UNKNOWN] = "Unknown",
>> @@ -542,6 +543,50 @@ static int check_charging_duration(struct
>> charger_manager *cm)
>> }
>>
>> /**
>> + * read_battery_temperature - Read current battery temperature
>> + * @cm: the Charger Manager representing the battery.
>> + * @last_temp_mC: store current battery temperature
>> + *
>> + * Returns current state of temperature by using IIO or legacy method
>> + * - CM_TEMP_NORMAL
>> + * - CM_TEMP_OVERHEAT
>> + * - CM_TEMP_COLD
>> + */
>> +static int read_battery_temperature(struct charger_manager *cm,
>> +int *last_temp_mC)
>> +{
>> +struct charger_desc *desc = cm->desc;
>> +int temp;
>> +
>> +if (desc->channel) {
>> +temp = iio_read_channel_raw(desc->channel, last_temp_mC);
>> +
>> +/*
>> + * The charger-manager use IIO subsystem to read ADC raw data
>> + * from IIO ADC device drvier. The each device driver has
>> + * own non-standard ADC table. If user of charger-manager
>> + * would like to get correct temperature value, have to convert
>> + * 'last_temp_mC' variable according to proper calculation
>> + * method and own ADC table.
>> + */
>> +
>> +if (*last_temp_mC >= desc->iio_adc_overheat)
>> +temp = CM_TEMP_NORMAL; /* Overheat */
>
> temp = CM_TEMP_OVERHEAT ?
I found this problem after send patchset. I'll fix it.
>
>> +else if (*last_temp_mC <= desc->iio_adc_cold)
>> +temp = CM_TEMP_COLD;/* Cold */
>> +else
>> +temp = CM_TEMP_NORMAL; /* Normal */
>> +
>> +} else if (desc->temperature_out_of_range) {
>> +temp = desc->temperature_out_of_range(last_temp_mC);
>> +} else {
>> +temp = INT_MAX;
>> +}
>> +
>> +return temp;
>> +}
>> +
>> +/**
>> * _cm_monitor - Monitor the temperature and return true for exceptions.
>> * @cm: the Charger Manager representing the battery.
>> *
>> @@ -551,7 +596,7 @@ static int check_charging_duration(struct
>> charger_manager *cm)
>> static bool _cm_monitor(struct charger_manager *cm)
>> {
>> struct charger_desc *desc = cm->desc;
>> -int temp =
Linux 3.12-rc7
The KS week is over, and thus the seventh - and likely the last - rc for 3.12 is out, and I'm back on the normal Sunday schedule. The slowdown in -rc sizes sadly reversed itself here, mostly due to the networking updates that hadn't come in for rc5-rc6. You can see that in the diffstat, with more than 50% being networking (both driver and core) patches. The rest is generally other drivers (gpu, media, scsi, thermal, HID) and some smaller arch updates (s390, parisc, x86). Nothing looks particularly shocking, though, so we're still on track for 3.12. Which does mean, that with me having more travel coming up, the 3.13 merge window will likely end up being a bit messed up. I can usually schedule around these kinds of things, but with two different trips and just a week in between, I have the choice of either just delaying 3.12 for no good reason, or just saying "ok, we'll just keep the merge window open a bit longer because I won't be able to be as responsive as I should be". But who knows. If something particularly worrisome comes up during the upcoming week, I might just say "Ok, we'll do an rc8 instead". So I'm keeping my options open. Linus --- Aaron Lu (1): [SCSI] sd: call blk_pm_runtime_init before add_disk AceLan Kao (2): HID: usbhid: quirk for Synaptics Large Touchccreen HID: usbhid: quirk for SiS Touchscreen Al Viro (1): nfsd regression since delayed fput() Alan Ott (5): 6lowpan: Only make 6lowpan links to IEEE802154 devices 6lowpan: Sync default hardware address of lowpan links to their wpan mrf24j40: Move INIT_COMPLETION() to before packet transmission mrf24j40: Use threaded IRQ handler mrf24j40: Use level-triggered interrupts Alex Deucher (6): drm/radeon/atom: workaround vbios bug in transmitter table on rs780 drm/radeon: make missing smc ucode non-fatal (r7xx-SI) drm/radeon: make missing smc ucode non-fatal (CI) drm/radeon/audio: don't set speaker allocation on DCE3.2 drm/radeon: rework audio option drm/radeon/audio: don't set speaker allocation on DCE4+ Alexander Bondar (1): iwlwifi: mvm: Disable uAPSD for D3 image Alexandre Belloni (1): mac802154: correct a typo in ieee802154_alloc_device() prototype Alexei Starovoitov (1): net: fix unsafe set_memory_rw from softirq Amir Vadai (2): net/mlx4_en: Rename name of mlx4_en_rx_alloc members net/mlx4_en: Fix pages never dma unmapped on rx Amitkumar Karwar (1): mwifiex: fix SDIO interrupt lost issue Andi Kleen (2): igb: Avoid uninitialized advertised variable in eee_set_cur tcp: Always set options to 0 before calling tcp_established_options Andreas Matthies (1): [media] tda10071: change firmware download condition Andy Gospodarek (1): bonding: update MAINTAINERS Anjana V Kumar (1): cgroup: fix to break the while loop in cgroup_attach_task() correctly Antti Palosaari (3): [media] e4000: fix PLL calc bug on 32-bit arch [media] msi3101: Kconfig select VIDEOBUF2_VMALLOC [media] msi3101: correct max videobuf2 alloc Ariel Elior (3): bnx2x: Unlock VF-PF channel on MAC/VLAN config error bnx2x: Fix config when SR-IOV and iSCSI are enabled bnx2x: Lock DMAE when used by statistic flow Arnaldo Carvalho de Melo (1): perf scripting perl: Fix build error on Fedora 12 Avinash Patil (2): mwifiex: inform cfg80211 about disconnect if device is removed mwifiex: inform cfg80211 about disconnect for P2P client interface Axel Lin (3): ASoC: pcm1681: Fix max_register setting ASoC: pcm1681: Fix max_register setting ASoC: pcm1792a: Fix max_register setting Ben Hutchings (1): sfc: Only bind to EF10 functions with the LinkCtrl and Trusted flags Ben Widawsky (2): drm/i915: Make PTE valid encoding optional drm/i915: Disable GGTT PTEs on GEN6+ suspend Bian Yu (1): md: avoid deadlock when md_set_badblocks. Brennan Shacklett (1): intel_pstate: Improve accuracy by not truncating until final result Bruno Randolf (1): cfg80211: fix warning when using WEXT for IBSS Chad Dupuis (1): [SCSI] qla2xxx: Fix request queue null dereference. Chris Wilson (2): drm: Prevent overwriting from userspace underallocating core ioctl structs drm: Pad drm_mode_get_connector to 64-bit boundary Christian König (2): drm/radeon: stop the leaks in cik_ib_test drm/radeon/uvd: revert lower msg buffer requirements on UVD3 Christophe Gouault (1): vti: get rid of nf mark rule in prerouting Chun-Yeow Yeoh (1): mac80211: fix the setting of extended supported rate IE Claudiu Manoil (3): gianfar: Enable eTSEC-A002 erratum w/a for all parts gianfar: Use mpc85xx support for errata detection gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1 Colin Ian King (1): eCryptfs: fix 32 bit corruption issue Dan Carpenter (5): [media] sh_vou:
Re: linux-next: Tree for Oct 18 (netdev: nf_tables_bridge.c)
On Sat, Oct 19, 2013 at 10:22:29AM -0700, Randy Dunlap wrote: > On 10/19/13 05:50, 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-20131018 tag is also provided for convenience. > > > > A few new conflicts today but otherwise uneventful. x86_64 allmodconfig > > builds after each merge but no other build tests were done. > > on i386: > > when CONFIG_NF_TABLES[_MODULE] is not enabled, > but CONFIG_NF_TABLES_BRIDGE is enabled: Patch attached, thanks for reporting. >From 2724ade097d59aaa3879ca485ae0fd61994cbc38 Mon Sep 17 00:00:00 2001 From: Pablo Neira Ayuso Date: Mon, 28 Oct 2013 00:18:33 +0100 Subject: [PATCH] netfilter: bridge: fix nf_tables bridge dependencies with main core when CONFIG_NF_TABLES[_MODULE] is not enabled, but CONFIG_NF_TABLES_BRIDGE is enabled: net/bridge/netfilter/nf_tables_bridge.c: In function 'nf_tables_bridge_init_net': net/bridge/netfilter/nf_tables_bridge.c:24:5: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c:25:9: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c:28:2: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c:30:34: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c:35:11: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c: In function 'nf_tables_bridge_exit_net': net/bridge/netfilter/nf_tables_bridge.c:41:27: error: 'struct net' has no member named 'nft' net/bridge/netfilter/nf_tables_bridge.c:42:11: error: 'struct net' has no member named 'nft' Reported-by: Randy Dunlap Reported-by: kbuild test robot Signed-off-by: Pablo Neira Ayuso --- net/bridge/netfilter/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig index 68f8128..5ca74a0 100644 --- a/net/bridge/netfilter/Kconfig +++ b/net/bridge/netfilter/Kconfig @@ -3,6 +3,7 @@ # # config NF_TABLES_BRIDGE + depends on NF_TABLES tristate "Ethernet Bridge nf_tables support" menuconfig BRIDGE_NF_EBTABLES -- 1.7.10.4
Re: [PATCH 1/8] IB/cxgb4: Fix formatting of physical address
On Sun, 2013-10-27 at 22:26 +, Ben Hutchings wrote:
> I don't think so. This doesn't find anything:
> git grep '&[ (]*pci_resource_start'
> and I was able to build drivers/{net,pci,scsi}/ successfully with
> pci_resource_start() changed to an inline function.
Hi again Ben. You're right.
It could be nice though to have some mechanism to get from
a pci_resource_start/end that could be emitted via %pa
without an intermediate or casting like
(unsigned long long)pci_resource_(struct resource *)
There are at least a few dozen uses of dmesg/seq_printf with
%llx or %lx and (some_cast)pci_resource_ that could be
converted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blk-mq flush fix
On Sat, Oct 26 2013, Christoph Hellwig wrote: > I think this variant of the patch from Alexander should fix the issue > in a minimally invasive way. Longer term I'd prefer to use q->flush_rq > like in the non-mq case by copying over the context and tag information. This one is pretty simple, we could definitely use it as a band aid. I too would greatly prefer using the static ->flush_rq instead. Just have it marked to bypass most of the free logic. I'll add this one. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 12/29] PCI/MSI: Introduce pcim_enable_msi*() family helpers
On Fri, 2013-10-25 at 12:01 +0200, Alexander Gordeev wrote: > On Fri, Oct 25, 2013 at 10:10:02AM +0100, David Laight wrote: > > What this doesn't resolve is a driver requesting a lot of interrupts > > early on and leaving none for later drivers. > > If this problem really exists anywhere besides pSeries? > > I can imagine x86 hitting lack of vectors in interrupt table when > number of CPUs exceeds hundreds, but do we have this problem now? > > > Really the system needs to allocate the minimum number to all > > drivers before giving out any extra ones - I've NFI how this > > would be arranged! > > Do not know. The pSeries quota approach seems more reasonable to me. When the system boots each driver should get a fair share of the available MSIs, the quota achieves this. But ideally the sysadmin would then be able to override that, and give more MSIs to one device, the quota doesn't allow that. Hopefully we'll see the number of available MSIs grow faster than the number required by devices (usually driven by NR_CPUs), and so this will become a non-problem. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] IB/cxgb4: Fix formatting of physical address
On Sun, 2013-10-27 at 15:14 -0700, Joe Perches wrote:
> On Sun, 2013-10-27 at 22:02 +, Ben Hutchings wrote:
> > On Sun, 2013-10-27 at 14:58 -0700, Joe Perches wrote:
> > > On Sun, 2013-10-27 at 21:50 +, Ben Hutchings wrote:
> > > > Physical addresses may be wider than virtual addresses (e.g. on i386
> > > > with PAE) and must not be formatted with %p.
> > >
> > > %pa works. %pa also prefixes with 0x.
> >
> > Only as long as pci_resource_start() happens to be an lvalue. I'd
> > rather not introduce that assumption.
>
> pci_resource_start returns a resource_size_t which is a phys_addr_t.
>
> Changing that from an lvalue would cause a _lot_ of breakage.
I don't think so. This doesn't find anything:
git grep '&[ (]*pci_resource_start'
and I was able to build drivers/{net,pci,scsi}/ successfully with
pci_resource_start() changed to an inline function.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] add new prctl for a per process wide close on exec V.3
On Sun, Oct 27, 2013 at 12:48:06PM +0100, Stefani Seibold wrote:
> This small patch adds a runtime prctl config option for a per process
> "close on exec" without breaking existing code.
>
> With this feature a developer can decide if the application will pass all non
> "close on exec" file descriptors to a new process or not.
>
> The mode of the process wide "close on exec" can be set with PR_SET_CLOEXEC
> and
> PR_GET_CLOEXEC returns the current mode. Mode is one of the following:
>
> - PR_CLOEXEC_DEFAULT closes only the fd's marked as "close on exec" in
>the child process, this is the linux default behaviour.
>
> - PR_CLOEXEC_ONCE closes all fd's expect 0, 1 and 2 which are regular
>handled as in PR_CLOEXEC_DEFAULT and reset the mode of the child to
>PR_CLOEXEC_DEFAULT.
>
> - PR_CLOEXEC_INHERIT is like PR_CLOEXEC_ONCE, but the mode will stay in the
>child
>
> STDIO file descriptors will be passed to the child process depending on the
> ..._CLOEXEC flag. So the new modes should be compatible to regular code.
>
> This patch will increase security since no developers can review all libraries
> which there are using. Also in a team of developers it is not always possible
> to have a full survey over the code which is produced. Or the output of a code
> generators and so one. This patch allows a kind of preventive measures.
>
> It can also prevent resource occupation. Imagine a long running process (a
> daemon) is execute from the application after open some file desciptors. For
> example libpcsclite.so will not open the socket with SOCK_CLOEXEC. Or a device
> driver which alows only a single open. In both cases the resource cannot
> reopened after a close. Sigh!
>
> The usage is very simple:
>
> if (prctl(PR_SET_CLOEXEC, PR_CLOEXEC_INHERIT, 0, 0, 0)) {
> perror("PR_SET_CLOEXEC");
> exit(1);
> }
>
> If the prctl PR_SET_CLOEXEC was missused in a library, the caller will
> fail!
NAK. All your arguments about Big Bad Wolf^WLibrary leaking opened files
through execve() are completely missing that possibility that "proactive"
program using this kludge might be linked against a Big Bad Library that
spawns a process and expects close-on-exec to work as designed.
And if execve() is in your program and under your control and you worry about
library-opened descriptors leaking through execve(), something like
unshare(CLONE_FILES | CLONE_CLOSEALL) before execve() would be a much
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] IB/cxgb4: Fix formatting of physical address
On Sun, 2013-10-27 at 22:02 +, Ben Hutchings wrote: > On Sun, 2013-10-27 at 14:58 -0700, Joe Perches wrote: > > On Sun, 2013-10-27 at 21:50 +, Ben Hutchings wrote: > > > Physical addresses may be wider than virtual addresses (e.g. on i386 > > > with PAE) and must not be formatted with %p. > > > > %pa works. %pa also prefixes with 0x. > > Only as long as pci_resource_start() happens to be an lvalue. I'd > rather not introduce that assumption. pci_resource_start returns a resource_size_t which is a phys_addr_t. Changing that from an lvalue would cause a _lot_ of breakage. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] IB/cxgb4: Fix formatting of physical address
On Sun, 2013-10-27 at 14:58 -0700, Joe Perches wrote:
> On Sun, 2013-10-27 at 21:50 +, Ben Hutchings wrote:
> > Physical addresses may be wider than virtual addresses (e.g. on i386
> > with PAE) and must not be formatted with %p.
>
> %pa works. %pa also prefixes with 0x.
Only as long as pci_resource_start() happens to be an lvalue. I'd
rather not introduce that assumption.
Ben.
> > diff --git a/drivers/infiniband/hw/cxgb4/device.c
> > b/drivers/infiniband/hw/cxgb4/device.c
> []
> > @@ -602,10 +602,10 @@ static int c4iw_rdev_open(struct c4iw_rdev *rdev)
> > rdev->lldi.vr->qp.size,
> > rdev->lldi.vr->cq.start,
> > rdev->lldi.vr->cq.size);
> > - PDBG("udb len 0x%x udb base %p db_reg %p gts_reg %p qpshift %lu "
> > + PDBG("udb len 0x%x udb base %llx db_reg %p gts_reg %p qpshift %lu "
> > "qpmask 0x%x cqshift %lu cqmask 0x%x\n",
> > (unsigned)pci_resource_len(rdev->lldi.pdev, 2),
> > -(void *)(unsigned long)pci_resource_start(rdev->lldi.pdev, 2),
> > +(u64)pci_resource_start(rdev->lldi.pdev, 2),
> > rdev->lldi.db_reg,
> > rdev->lldi.gts_reg,
> > rdev->qpshift, rdev->qpmask,
> >
> >
>
>
>
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/8] IB/cxgb4: Fix formatting of physical address
On Sun, 2013-10-27 at 21:50 +, Ben Hutchings wrote:
> Physical addresses may be wider than virtual addresses (e.g. on i386
> with PAE) and must not be formatted with %p.
%pa works. %pa also prefixes with 0x.
> diff --git a/drivers/infiniband/hw/cxgb4/device.c
> b/drivers/infiniband/hw/cxgb4/device.c
[]
> @@ -602,10 +602,10 @@ static int c4iw_rdev_open(struct c4iw_rdev *rdev)
>rdev->lldi.vr->qp.size,
>rdev->lldi.vr->cq.start,
>rdev->lldi.vr->cq.size);
> - PDBG("udb len 0x%x udb base %p db_reg %p gts_reg %p qpshift %lu "
> + PDBG("udb len 0x%x udb base %llx db_reg %p gts_reg %p qpshift %lu "
>"qpmask 0x%x cqshift %lu cqmask 0x%x\n",
>(unsigned)pci_resource_len(rdev->lldi.pdev, 2),
> - (void *)(unsigned long)pci_resource_start(rdev->lldi.pdev, 2),
> + (u64)pci_resource_start(rdev->lldi.pdev, 2),
>rdev->lldi.db_reg,
>rdev->lldi.gts_reg,
>rdev->qpshift, rdev->qpmask,
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: add missing files to timers/00-INDEX
On Sun, 27 Oct 2013, Paul E. McKenney wrote: > > From: Henrik Austad > > > > - timers-howto was added by commit 0fcb8081 (Documentation: Add > > timers/timers-howto.txt) > > - NO_HZ was added by commit 0c87f9b5 (nohz_full: Add documentation.) > > > > Cc: Patrick Pannuto > > Cc: Paul E. McKenney > > Cc: Jiri Kosina > > Signed-off-by: Henrik Austad > > Reviewed-by: Paul E. McKenney Thanks a lot, I am taking this one. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] [SCSI] pmcraid: Pass pointers to access_ok(), not integers
Most architectures define access_ok() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on sparc64.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
drivers/scsi/pmcraid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 1eb7b028..4e0a2f3 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -3794,7 +3794,8 @@ static long pmcraid_ioctl_passthrough(
}
if (request_size > 0) {
- rc = access_ok(access, arg, request_offset + request_size);
+ rc = access_ok(access, (void *)arg,
+ request_offset + request_size);
if (!rc) {
rc = -EFAULT;
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH 6/8] uio: Pass pointers to virt_to_page(), not integers
Most architectures define virt_to_page() as a macro that casts its argument such that an argument of type unsigned long will be accepted without complaint. However, the proper type is void *, and passing unsigned long results in a warning on MIPS. Compile-tested only. Signed-off-by: Ben Hutchings --- drivers/uio/uio.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index 11d4e0a..ef30ec9 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -601,6 +601,7 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf) struct uio_device *idev = vma->vm_private_data; struct page *page; unsigned long offset; + void *addr; int mi = uio_find_mem_index(vma); if (mi < 0) @@ -612,10 +613,11 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf) */ offset = (vmf->pgoff - mi) << PAGE_SHIFT; + addr = (void *)(unsigned long)idev->info->mem[mi].addr + offset; if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL) - page = virt_to_page(idev->info->mem[mi].addr + offset); + page = virt_to_page(addr); else - page = vmalloc_to_page((void *)(unsigned long)idev->info->mem[mi].addr + offset); + page = vmalloc_to_page(addr); get_page(page); vmf->page = page; return 0; -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
[PATCH 7/8] rds: Pass pointers to virt_to_page(), not integers
Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
net/rds/message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/message.c b/net/rds/message.c
index aba232f..1913fc9 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -257,7 +257,7 @@ struct rds_message *rds_message_map_pages(unsigned long
*page_addrs, unsigned in
for (i = 0; i < rm->data.op_nents; ++i) {
sg_set_page(>data.op_sg[i],
- virt_to_page(page_addrs[i]),
+ virt_to_page((void *)page_addrs[i]),
PAGE_SIZE, 0);
}
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH 5/8] [SCSI] tgt: Pass pointers to virt_to_page(), not integers
Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
drivers/scsi/scsi_tgt_if.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_tgt_if.c b/drivers/scsi/scsi_tgt_if.c
index 6209110..7199753 100644
--- a/drivers/scsi/scsi_tgt_if.c
+++ b/drivers/scsi/scsi_tgt_if.c
@@ -286,7 +286,7 @@ static int uspace_ring_map(struct vm_area_struct *vma,
unsigned long addr,
int i, err;
for (i = 0; i < TGT_RING_PAGES; i++) {
- struct page *page = virt_to_page(ring->tr_pages[i]);
+ struct page *page = virt_to_page((void *)ring->tr_pages[i]);
err = vm_insert_page(vma, addr, page);
if (err)
return err;
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH 4/8] drm: Pass pointers to virt_to_page()
Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_vm.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 1f96cee..4c47954 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -80,7 +80,7 @@ drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev,
size_t size, size_t ali
/* Reserve */
for (addr = (unsigned long)dmah->vaddr, sz = size;
sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- SetPageReserved(virt_to_page(addr));
+ SetPageReserved(virt_to_page((void *)addr));
}
return dmah;
@@ -103,7 +103,7 @@ void __drm_pci_free(struct drm_device * dev,
drm_dma_handle_t * dmah)
/* Unreserve */
for (addr = (unsigned long)dmah->vaddr, sz = dmah->size;
sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- ClearPageReserved(virt_to_page(addr));
+ ClearPageReserved(virt_to_page((void *)addr));
}
dma_free_coherent(>pdev->dev, dmah->size, dmah->vaddr,
dmah->busaddr);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 8ef6503..93e95d7 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -301,7 +301,7 @@ static int drm_do_vm_dma_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
offset = (unsigned long)vmf->virtual_address - vma->vm_start; /*
vm_[pg]off[set] should be 0 */
page_nr = offset >> PAGE_SHIFT; /* page_nr could just be vmf->pgoff */
- page = virt_to_page(dma->pagelist[page_nr]);
+ page = virt_to_page((void *)dma->pagelist[page_nr]);
get_page(page);
vmf->page = page;
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH 3/8] drm: Do not include page offset in argument to virt_to_page()
By definition, the page offset will not affect the result. Compile-tested only. Signed-off-by: Ben Hutchings --- drivers/gpu/drm/drm_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index b5c5af7..8ef6503 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -301,7 +301,7 @@ static int drm_do_vm_dma_fault(struct vm_area_struct *vma, struct vm_fault *vmf) offset = (unsigned long)vmf->virtual_address - vma->vm_start; /* vm_[pg]off[set] should be 0 */ page_nr = offset >> PAGE_SHIFT; /* page_nr could just be vmf->pgoff */ - page = virt_to_page((dma->pagelist[page_nr] + (offset & (~PAGE_MASK; + page = virt_to_page(dma->pagelist[page_nr]); get_page(page); vmf->page = page; -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
[PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
Use dma_addr_t for DMA address parameters and u32 for shared memory
offset parameters.
Do not assume that dma_addr_t is the same as unsigned long; it will
not be in PAE configurations. Truncate DMA addresses to 32 bits when
printing them. This is OK because the DMA mask for this device is
32-bit (per default).
Compile-tested only.
Signed-off-by: Ben Hutchings
---
drivers/net/wan/farsync.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index 3f0c4f2..4b36676 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -886,15 +886,13 @@ fst_rx_dma_complete(struct fst_card_info *card, struct
fst_port_info *port,
* Receive a frame through the DMA
*/
static inline void
-fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
- dma_addr_t mem, int len)
+fst_rx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
{
/*
* This routine will setup the DMA and start it
*/
- dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
- (unsigned long) skb, (unsigned long) mem, len);
+ dbg(DBG_RX, "In fst_rx_dma %x %x %d\n", (u32)skb, mem, len);
if (card->dmarx_in_progress) {
dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");
}
@@ -915,20 +913,19 @@ fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
* Send a frame through the DMA
*/
static inline void
-fst_tx_dma(struct fst_card_info *card, unsigned char *skb,
- unsigned char *mem, int len)
+fst_tx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
{
/*
* This routine will setup the DMA and start it.
*/
- dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
+ dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
if (card->dmatx_in_progress) {
dbg(DBG_ASS, "In fst_tx_dma while dma in progress\n");
}
- outl((unsigned long) skb, card->pci_conf + DMAPADR1); /* Copy from
here */
- outl((unsigned long) mem, card->pci_conf + DMALADR1); /* to here */
+ outl(skb, card->pci_conf + DMAPADR1); /* Copy from here */
+ outl(mem, card->pci_conf + DMALADR1); /* to here */
outl(len, card->pci_conf + DMASIZ1);/* for this length */
outl(0x4, card->pci_conf + DMADPR1);/* In this direction */
@@ -1405,9 +1402,7 @@ do_bottom_half_tx(struct fst_card_info *card)
card->dma_len_tx = skb->len;
card->dma_txpos = port->txpos;
fst_tx_dma(card,
- (char *) card->
- tx_dma_handle_card,
- (char *)
+ card->tx_dma_handle_card,
BUF_OFFSET(txBuffer[pi]
[port->txpos][0]),
skb->len);
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH 1/8] IB/cxgb4: Fix formatting of physical address
Physical addresses may be wider than virtual addresses (e.g. on i386
with PAE) and must not be formatted with %p.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
The resource could also be printed using '%pR' or '%pr', but that makes
a bigger change to the output.
Ben.
drivers/infiniband/hw/cxgb4/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c
b/drivers/infiniband/hw/cxgb4/device.c
index 33d2cc6..4a03385 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -602,10 +602,10 @@ static int c4iw_rdev_open(struct c4iw_rdev *rdev)
rdev->lldi.vr->qp.size,
rdev->lldi.vr->cq.start,
rdev->lldi.vr->cq.size);
- PDBG("udb len 0x%x udb base %p db_reg %p gts_reg %p qpshift %lu "
+ PDBG("udb len 0x%x udb base %llx db_reg %p gts_reg %p qpshift %lu "
"qpmask 0x%x cqshift %lu cqmask 0x%x\n",
(unsigned)pci_resource_len(rdev->lldi.pdev, 2),
-(void *)(unsigned long)pci_resource_start(rdev->lldi.pdev, 2),
+(u64)pci_resource_start(rdev->lldi.pdev, 2),
rdev->lldi.db_reg,
rdev->lldi.gts_reg,
rdev->qpshift, rdev->qpmask,
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
[PATCH] kfifo API type safety
This patch enhances the type safety for the kfifo API. It is now safe to put
const data into a non const FIFO and the API will now generate a compiler
warning when reading from the fifo where the destination address is pointing to
a const variable.
As a side effect the kfifo_put() does now expect the value of an element
instead a pointer to the element. This was suggested Russel King. It make the
handling of the kfifo_put easier since there is no need to create a
helper variable for getting the address of a pointer or to pass integers
of different sizes.
IMHO the API break is okay, since there are currently only six users of
kfifo_put().
The code is also cleaner by kicking out the "if (0)" expressions.
The patch is against 3.12.0-rc6
- Stefani
Signed-off-by: Stefani Seibold
---
drivers/gpu/drm/drm_flip_work.c | 2 +-
drivers/iio/industrialio-event.c| 2 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/pci/pcie/aer/aerdrv_core.c | 2 +-
include/linux/kfifo.h | 47 ++---
mm/memory-failure.c | 2 +-
samples/kfifo/bytestream-example.c | 4 +--
samples/kfifo/dma-example.c | 2 +-
samples/kfifo/inttype-example.c | 4 +--
10 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
index e72..f9c7fa3 100644
--- a/drivers/gpu/drm/drm_flip_work.c
+++ b/drivers/gpu/drm/drm_flip_work.c
@@ -34,7 +34,7 @@
*/
void drm_flip_work_queue(struct drm_flip_work *work, void *val)
{
- if (kfifo_put(>fifo, (const void **))) {
+ if (kfifo_put(>fifo, val)) {
atomic_inc(>pending);
} else {
DRM_ERROR("%s fifo full!\n", work->name);
diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
index 6be65ef..3431443 100644
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@ -56,7 +56,7 @@ int iio_push_event(struct iio_dev *indio_dev, u64 ev_code,
s64 timestamp)
ev.id = ev_code;
ev.timestamp = timestamp;
- copied = kfifo_put(_int->det_events, );
+ copied = kfifo_put(_int->det_events, ev);
if (copied != 0)
wake_up_locked_poll(_int->wait, POLLIN);
}
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c
b/drivers/net/wireless/rt2x00/rt2800pci.c
index f8f2abb..fce25ee 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -1025,7 +1025,7 @@ static void rt2800pci_txstatus_interrupt(struct
rt2x00_dev *rt2x00dev)
if (!rt2x00_get_field32(status, TX_STA_FIFO_VALID))
break;
- if (!kfifo_put(>txstatus_fifo, )) {
+ if (!kfifo_put(>txstatus_fifo, status)) {
rt2x00_warn(rt2x00dev, "TX status FIFO overrun, drop tx
status report\n");
break;
}
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index 96961b9..52eae82 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -162,7 +162,7 @@ static bool rt2800usb_tx_sta_fifo_read_completed(struct
rt2x00_dev *rt2x00dev,
valid = rt2x00_get_field32(tx_status, TX_STA_FIFO_VALID);
if (valid) {
- if (!kfifo_put(>txstatus_fifo, _status))
+ if (!kfifo_put(>txstatus_fifo, tx_status))
rt2x00_warn(rt2x00dev, "TX status FIFO overrun\n");
queue_work(rt2x00dev->workqueue, >txdone_work);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 85ca36f..6b3a958 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -574,7 +574,7 @@ void aer_recover_queue(int domain, unsigned int bus,
unsigned int devfn,
};
spin_lock_irqsave(_recover_ring_lock, flags);
- if (kfifo_put(_recover_ring, ))
+ if (kfifo_put(_recover_ring, entry))
schedule_work(_recover_work);
else
pr_err("AER recover: Buffer overflow when recovering AER for
%04x:%02x:%02x:%x\n",
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 10308c6..b358d9a 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -1,7 +1,7 @@
/*
* A generic kernel FIFO implementation
*
- * Copyright (C) 2009/2010 Stefani Seibold
+ * Copyright (C) 2013 Stefani Seibold
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -67,9 +67,10 @@ struct __kfifo {
union { \
struct __kfifo kfifo; \
datatype*type; \
+ const datatype *const_type; \
[GIT PULL] EFI changes
Guys, do you think we could get the EFI earlyprintk support into the 'x86/efi' branch for the upcoming merge window? I know it's quite late in the game but since it's a new feature it shouldn't introduce any kind of regression and is a much needed feature. The following changes since commit c158c3bf59951bbb44bd7ccca9e6665dfd1617c5: boot, efi: Remove redundant memset() (2013-10-04 20:07:47 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next for you to fetch changes up to 32c9e70fc3912c3b9c7d53ce016960ce99ff93d4: x86/efi: Add EFI framebuffer earlyprintk support (2013-10-27 21:18:48 +) * Add support for earlyprintk=efi which uses the EFI framebuffer. Very useful for debugging boot issues. Matt Fleming (2): efi: Add asm-generic/efi.h for non-x86 x86/efi: Add EFI framebuffer earlyprintk support Documentation/kernel-parameters.txt | 8 +- arch/ia64/include/asm/efi.h | 6 ++ arch/x86/Kconfig.debug | 9 ++ arch/x86/boot/compressed/eboot.c | 1 - arch/x86/include/asm/efi.h | 12 +++ arch/x86/kernel/early_printk.c | 6 ++ arch/x86/kernel/setup.c | 1 - arch/x86/platform/efi/Makefile | 1 + arch/x86/platform/efi/early_printk.c | 191 +++ arch/x86/platform/efi/efi.c | 1 - arch/x86/platform/efi/efi_32.c | 1 - arch/x86/platform/efi/efi_64.c | 1 - arch/x86/platform/uv/bios_uv.c | 1 - include/asm-generic/efi.h| 17 include/linux/efi.h | 31 +- 15 files changed, 249 insertions(+), 38 deletions(-) create mode 100644 arch/ia64/include/asm/efi.h create mode 100644 arch/x86/platform/efi/early_printk.c create mode 100644 include/asm-generic/efi.h -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] Fix minor address type errors
Various bits of code are mixing making assumptions about the size of dma_addr_t or resource_size_t, or mixing up pointer and integer types. All these fixes are based on compiler warnings and so far as I can see the bugs are practically harmless. Ben. Ben Hutchings (8): IB/cxgb4: Fix formatting of physical address farsync: Fix confusion about DMA address and buffer offset types drm: Do not include page offset in argument to virt_to_page() drm: Pass pointers to virt_to_page() [SCSI] tgt: Pass pointers to virt_to_page(), not integers uio: Pass pointers to virt_to_page(), not integers rds: Pass pointers to virt_to_page(), not integers [SCSI] pmcraid: Pass pointers to access_ok(), not integers drivers/gpu/drm/drm_pci.c| 4 ++-- drivers/gpu/drm/drm_vm.c | 2 +- drivers/infiniband/hw/cxgb4/device.c | 4 ++-- drivers/net/wan/farsync.c| 19 +++ drivers/scsi/pmcraid.c | 3 ++- drivers/scsi/scsi_tgt_if.c | 2 +- drivers/uio/uio.c| 6 -- net/rds/message.c| 2 +- 8 files changed, 20 insertions(+), 22 deletions(-) -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
ACCOUNT NOTIFICATION..
You are to click the link to verify your account login details. http://webmail-users-urgentaccountverification.bravesites.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/
ACCOUNT NOTIFICATION..
You are to click the link to verify your account login details. http://webmail-users-urgentaccountverification.bravesites.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/
[RFC 0/4] DT support for rx51-audio
Hi,
This patchset adds DT support in rx51-audio. I tested it on the Nokia N900
and was able to play sound with aplay using earphones and earspeaker. The
Loudspeakers did not work. I don't know the reason.
The patchset consists of 4 patches:
1. convert rx51-audio to snd_soc_register_card()
2. init audio in rx51 platform file
3. add some DT helpers to ASoC core
4. add DT support to rx51-audio
Please note, that the patch is RFC level for now. For example non DT boot
does not work, because I did not yet add pdata in boardcode.
Proposed DTS node would look like this:
sound: rx51-audio {
compatible = "nokia,rx51-audio";
ti,mcbsp = <>;
ti,codec = <>;
ti,codec_aux = <_aux>;
ti,headset_amp = <>;
tvout-selection-gpio = < 8 GPIO_ACTIVE_HIGH>; /* 40 */
jack-detection-gpio = < 17 GPIO_ACTIVE_HIGH>; /* 177 */
eci-sw-gpio = < 22 GPIO_ACTIVE_HIGH>; /* 182 */
speaker-amp-gpio = <_gpio 7 GPIO_ACTIVE_HIGH>;
};
-- Sebastian
Pali Rohár (2):
ASoC: omap: rx51: Use snd_soc_register_card
ARM: OMAP: rx51: Register audio device
Sebastian Reichel (2):
ASoC: Allow Aux Codecs to be specified using DT
ASoC: RX-51: Add DT support to sound driver
.../devicetree/bindings/sound/nokia,rx51.txt | 28 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++
include/sound/rx51.h | 18 ++
include/sound/soc.h| 13 +-
sound/soc/omap/omap-mcbsp.c| 5 +-
sound/soc/omap/omap-mcbsp.h| 2 +-
sound/soc/omap/rx51.c | 212 +++--
sound/soc/soc-core.c | 68 +--
9 files changed, 277 insertions(+), 81 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/nokia,rx51.txt
create mode 100644 include/sound/rx51.h
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/4] ARM: OMAP: rx51: Register audio device
From: Pali Rohár
This patch adds support for the audio chip to the legacy
boardcode of the Nokia N900.
Signed-off-by: Pali Rohár
Signed-off-by: Sebastian Reichel
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 68dc998..65e3627 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1205,6 +1205,16 @@ error:
*/
}
+static struct platform_device rx51_audio_device = {
+ .name = "rx51-audio",
+ .id = -1,
+};
+
+static void __init rx51_init_audio(void)
+{
+ platform_device_register(_audio_device);
+}
+
static struct tsc2005_platform_data tsc2005_pdata = {
.ts_pressure_max= 2048,
.ts_pressure_fudge = 2,
@@ -1287,6 +1297,7 @@ void __init rx51_peripherals_init(void)
gpmc_onenand_init(board_onenand_data);
board_smc91x_init();
rx51_add_gpio_keys();
+ rx51_init_audio();
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/4] ASoC: Allow Aux Codecs to be specified using DT
This patch adds support for specifying auxiliary codecs and
codec configuration via device tree phandles.
This change adds new fields to snd_soc_aux_dev and snd_soc_codec_conf
and adds support for the changes to SoC core methods.
Signed-off-by: Sebastian Reichel
---
include/sound/soc.h | 13 +-
sound/soc/soc-core.c | 68
2 files changed, 59 insertions(+), 22 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index d22cb0a..00b25a8 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -937,7 +937,12 @@ struct snd_soc_dai_link {
};
struct snd_soc_codec_conf {
+ /*
+* specify device either by device name, or by
+* DT/OF node, but not both.
+*/
const char *dev_name;
+ const struct device_node *of_node;
/*
* optional map of kcontrol, widget and path name prefixes that are
@@ -954,7 +959,13 @@ struct snd_soc_codec_conf {
struct snd_soc_aux_dev {
const char *name; /* Codec name */
- const char *codec_name; /* for multi-codec */
+
+ /*
+* specify multi-codec either by device name, or by
+* DT/OF node, but not both.
+*/
+ const char *codec_name;
+ const struct device_node *codec_of_node;
/* codec/machine specific init - e.g. add machine controls */
int (*init)(struct snd_soc_dapm_context *dapm);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 1a38be0..392f479 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1085,10 +1085,12 @@ static void soc_set_name_prefix(struct snd_soc_card
*card,
for (i = 0; i < card->num_configs; i++) {
struct snd_soc_codec_conf *map = >codec_conf[i];
- if (map->dev_name && !strcmp(codec->name, map->dev_name)) {
- codec->name_prefix = map->name_prefix;
- break;
- }
+ if (map->of_node && codec->dev->of_node != map->of_node)
+ continue;
+ if (map->dev_name && strcmp(codec->name, map->dev_name))
+ continue;
+ codec->name_prefix = map->name_prefix;
+ break;
}
}
@@ -1527,15 +1529,23 @@ static void soc_unregister_ac97_dai_link(struct
snd_soc_codec *codec)
static int soc_check_aux_dev(struct snd_soc_card *card, int num)
{
struct snd_soc_aux_dev *aux_dev = >aux_dev[num];
+ const char *codecname = aux_dev->codec_name;
struct snd_soc_codec *codec;
/* find CODEC from registered CODECs*/
list_for_each_entry(codec, _list, list) {
- if (!strcmp(codec->name, aux_dev->codec_name))
+ if (aux_dev->codec_of_node &&
+ codec->dev->of_node == aux_dev->codec_of_node)
+ return 0;
+ if (aux_dev->codec_name &&
+ !strcmp(codec->name, aux_dev->codec_name))
return 0;
}
- dev_err(card->dev, "ASoC: %s not registered\n", aux_dev->codec_name);
+ if (aux_dev->codec_of_node)
+ codecname = of_node_full_name(aux_dev->codec_of_node);
+
+ dev_err(card->dev, "ASoC: %s not registered\n", codecname);
return -EPROBE_DEFER;
}
@@ -1544,22 +1554,31 @@ static int soc_probe_aux_dev(struct snd_soc_card *card,
int num)
{
struct snd_soc_aux_dev *aux_dev = >aux_dev[num];
struct snd_soc_codec *codec;
+ const char *codecname = aux_dev->codec_name;
int ret = -ENODEV;
/* find CODEC from registered CODECs*/
list_for_each_entry(codec, _list, list) {
- if (!strcmp(codec->name, aux_dev->codec_name)) {
- if (codec->probed) {
- dev_err(codec->dev,
- "ASoC: codec already probed");
- ret = -EBUSY;
- goto out;
- }
- goto found;
+ if (aux_dev->codec_of_node &&
+ codec->dev->of_node != aux_dev->codec_of_node)
+ continue;
+ if (aux_dev->codec_name &&
+ strcmp(codec->name, aux_dev->codec_name))
+ continue;
+
+ if (codec->probed) {
+ dev_err(codec->dev, "ASoC: codec already probed");
+ ret = -EBUSY;
+ goto out;
}
+ goto found;
}
+
+ if (aux_dev->codec_of_node)
+ codecname = of_node_full_name(aux_dev->codec_of_node);
+
/* codec not found */
- dev_err(card->dev, "ASoC: codec %s not found", aux_dev->codec_name);
+ dev_err(card->dev, "ASoC: codec %s not found", codecname);
return
[RFC 1/4] ASoC: omap: rx51: Use snd_soc_register_card
From: Pali Rohár
This patch converts the rx51 ASoC module to use
snd_soc_register_card. It also adds module alias
to support driver autoloading.
Signed-off-by: Pali Rohár
Signed-off-by: Sebastian Reichel
---
sound/soc/omap/rx51.c | 49 +
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index 611179c..41f26ae 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -390,10 +390,9 @@ static struct snd_soc_card rx51_sound_card = {
.num_configs = ARRAY_SIZE(rx51_codec_conf),
};
-static struct platform_device *rx51_snd_device;
-
-static int __init rx51_soc_init(void)
+static int rx51_soc_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = _sound_card;
int err;
if (!machine_is_nokia_rx51() &&
!of_machine_is_compatible("nokia,omap3-n900"))
@@ -408,22 +407,17 @@ static int __init rx51_soc_init(void)
if (err)
goto err_gpio_eci_sw;
- rx51_snd_device = platform_device_alloc("soc-audio", -1);
- if (!rx51_snd_device) {
- err = -ENOMEM;
- goto err1;
- }
-
- platform_set_drvdata(rx51_snd_device, _sound_card);
+ card->dev = >dev;
- err = platform_device_add(rx51_snd_device);
- if (err)
- goto err2;
+ err = snd_soc_register_card(card);
+ if (err) {
+ dev_err(>dev, "snd_soc_register_card failed (%d)\n", err);
+ goto err_snd;
+ }
return 0;
-err2:
- platform_device_put(rx51_snd_device);
-err1:
+err_snd:
+ card->dev = NULL;
gpio_free(RX51_ECI_SW_GPIO);
err_gpio_eci_sw:
gpio_free(RX51_TVOUT_SEL_GPIO);
@@ -432,19 +426,34 @@ err_gpio_tvout_sel:
return err;
}
-static void __exit rx51_soc_exit(void)
+static int rx51_soc_remove(struct platform_device *pdev)
{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
snd_soc_jack_free_gpios(_av_jack, ARRAY_SIZE(rx51_av_jack_gpios),
rx51_av_jack_gpios);
- platform_device_unregister(rx51_snd_device);
+ snd_soc_unregister_card(card);
+ card->dev = NULL;
+
gpio_free(RX51_ECI_SW_GPIO);
gpio_free(RX51_TVOUT_SEL_GPIO);
+
+ return 0;
}
-module_init(rx51_soc_init);
-module_exit(rx51_soc_exit);
+static struct platform_driver rx51_soc_driver = {
+ .driver = {
+ .name = "rx51-audio",
+ .owner = THIS_MODULE,
+ },
+ .probe = rx51_soc_probe,
+ .remove = rx51_soc_remove,
+};
+
+module_platform_driver(rx51_soc_driver);
MODULE_AUTHOR("Nokia Corporation");
MODULE_DESCRIPTION("ALSA SoC Nokia RX-51");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:rx51-audio");
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 4/4] ASoC: RX-51: Add DT support to sound driver
This patch adds device tree support to the Nokia N900 audio driver.
It also removes GPIO defines and gets them from platform data /
device tree, since some GPIO numbers may be different with DT boot.
The binding also changes a helper function in omap-mcbsp, which
is currently only used by the Nokia N900. This change is needed,
because DT instanced omap-mcbsp driver has no valid id assigned.
Last but not least the DT binding is documented.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/sound/nokia,rx51.txt | 28
.../devicetree/bindings/vendor-prefixes.txt| 1 +
include/sound/rx51.h | 18 +++
sound/soc/omap/omap-mcbsp.c| 5 +-
sound/soc/omap/omap-mcbsp.h| 2 +-
sound/soc/omap/rx51.c | 175 -
6 files changed, 184 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/nokia,rx51.txt
create mode 100644 include/sound/rx51.h
diff --git a/Documentation/devicetree/bindings/sound/nokia,rx51.txt
b/Documentation/devicetree/bindings/sound/nokia,rx51.txt
new file mode 100644
index 000..4f985ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nokia,rx51.txt
@@ -0,0 +1,28 @@
+* Nokia N900 audio setup
+
+Required properties:
+- compatible: "nokia,rx51-audio"
+- ti,mcbsp: phandle for the McBSP node
+- ti,codec: phandle for the main TLV320AIC3X node
+- ti,codec_aux: phandle for the main TLV320AIC3X auxiliary node
+- ti,headset_amp: phandle for the TPA6130A2 node
+- tvout-selection-gpio: GPIO for tvout selection
+- jack-detection-gpio: GPIO for jack detection
+- eci-sw-gpio: GPIO for ECI SW
+- speaker-amp-gpio: GPIO for Speaker Amp
+
+Example:
+
+sound {
+ compatible = "nokia,rx51-audio";
+
+ ti,mcbsp = <>;
+ ti,codec = <>;
+ ti,codec_aux = <_aux>;
+ ti,headset_amp = <>;
+
+ tvout-selection-gpio = < 8 GPIO_ACTIVE_HIGH>; /* 40 */
+ jack-detection-gpio = < 17 GPIO_ACTIVE_HIGH>; /* 177 */
+ eci-sw-gpio = < 22 GPIO_ACTIVE_HIGH>; /* 182 */
+ speaker-amp-gpio = <_gpio 7 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800..2cc3dad 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -42,6 +42,7 @@ microchip Microchip Technology Inc.
mosaixtech Mosaix Technologies, Inc.
national National Semiconductor
nintendo Nintendo
+nokia Nokia Corporation
nvidia NVIDIA
nxpNXP Semiconductors
onnn ON Semiconductor Corp.
diff --git a/include/sound/rx51.h b/include/sound/rx51.h
new file mode 100644
index 000..190d745
--- /dev/null
+++ b/include/sound/rx51.h
@@ -0,0 +1,18 @@
+/*
+ * Platform data for Nokia RX-51 SoC audio
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __RX51_AUDIO_H__
+#define __RX51_AUDIO_H__
+
+struct rx51_audio_pdata {
+ int tvout_selection_gpio;
+ int jack_detection_gpio;
+ int eci_sw_gpio;
+ int speaker_amp_gpio;
+};
+
+#endif
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6c19bba..f88e31e 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -691,7 +691,7 @@ OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP" #port " Sidetone
Channel 1 Volume", \
OMAP_MCBSP_ST_CONTROLS(2);
OMAP_MCBSP_ST_CONTROLS(3);
-int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime *rtd)
+int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime *rtd, int port_id)
{
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai);
@@ -701,7 +701,7 @@ int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime
*rtd)
return 0;
}
- switch (mcbsp->id) {
+ switch (port_id) {
case 2: /* McBSP 2 */
return snd_soc_add_dai_controls(cpu_dai,
omap_mcbsp2_st_controls,
@@ -711,6 +711,7 @@ int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime
*rtd)
omap_mcbsp3_st_controls,
ARRAY_SIZE(omap_mcbsp3_st_controls));
default:
+ dev_err(mcbsp->dev, "Port %d not supported\n", port_id);
break;
}
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index ba8386a..2e3369c 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -39,6 +39,6 @@ enum omap_mcbsp_div {
OMAP_MCBSP_CLKGDV, /* Sample rate generator divider */
};
-int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime *rtd);
+int
Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
On Sun, Oct 27, 2013 at 09:13:29PM +, Linus Torvalds wrote: > .. and one more case of freeing a delayed work object (likely a kobject > again): > > This time it looks like it's in the PCI layer, freeing the msi irq > information. > > It looks like that code simply does > > kobject_del(>kobj); > kobject_put(>kobj); > list_del(>list); > kfree(entry); > > and the problem is that the "entry->kobj" may have *other* references > to it, thanks to people accessing it through /sys, so despite doing a > kojbect_del/kobject_put(), it's not at all ok to then do a "kfree()" > on it. The embedded kobj might still be in use. > > Afaik, that code should do the kfree() on the kobject in the _release_ > method, not synchronously like that. > > We already have a msi_kobj_release(), I'm wondering why that doesn't > do the kfree(). > > Bjorn? Yinghai? Greg, comments about that msi kobj usage? Ick, it really should be doing a kfree() in the release only. Bjorn has had a bunch of changes in this area recently, perhaps they are in linux-next waiting for 3.13, and I've talked to him about getting rid of all of the kobjects for msi files, as I don't think it's needed at all. Bjorn, don't you have a fix for this problem already done somewhere? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
.. and one more case of freeing a delayed work object (likely a kobject again): This time it looks like it's in the PCI layer, freeing the msi irq information. It looks like that code simply does kobject_del(>kobj); kobject_put(>kobj); list_del(>list); kfree(entry); and the problem is that the "entry->kobj" may have *other* references to it, thanks to people accessing it through /sys, so despite doing a kojbect_del/kobject_put(), it's not at all ok to then do a "kfree()" on it. The embedded kobj might still be in use. Afaik, that code should do the kfree() on the kobject in the _release_ method, not synchronously like that. We already have a msi_kobj_release(), I'm wondering why that doesn't do the kfree(). Bjorn? Yinghai? Greg, comments about that msi kobj usage? Linus --- [ 2373.142964] mei_me :00:16.0: stop [ 2373.143023] kobject: 'pn544' (88011808f810): kobject_release, parent (null) (delayed) [ 2373.143076] kobject: '59' (8800d268f648): kobject_release, parent (null) (delayed) [ 2373.143080] [ cut here ] [ 2373.143087] WARNING: CPU: 3 PID: 2922 at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() [ 2373.143094] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x20 [ 2373.143096] Modules linked in: fuse ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep bluetooth ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6ta$ [ 2373.143159] CPU: 3 PID: 2922 Comm: rmmod Tainted: GW 3.12.0-rc6-00331-ga2ff82065b5b #2 [ 2373.143162] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 [ 2373.143164] 0009 8800b74b5c20 8160d4a2 8800b74b5c68 [ 2373.143170] 8800b74b5c58 810514e8 8800b74a4f00 81c365e0 [ 2373.143174] 819f9133 81f4c1b0 0001 8800b74b5cb8 [ 2373.143179] Call Trace: [ 2373.143189] [] dump_stack+0x45/0x56 [ 2373.143195] [] warn_slowpath_common+0x78/0xa0 [ 2373.143200] [] warn_slowpath_fmt+0x47/0x50 [ 2373.143204] [] debug_print_object+0x83/0xa0 [ 2373.143209] [] ? execute_in_process_context+0x90/0x90 [ 2373.143214] [] debug_check_no_obj_freed+0x20b/0x250 [ 2373.143219] [] ? free_msi_irqs+0x103/0x150 [ 2373.143224] [] kfree+0x89/0x160 [ 2373.143227] [] free_msi_irqs+0x103/0x150 [ 2373.143232] [] pci_disable_msi+0x3d/0x60 [ 2373.143241] [] mei_me_remove+0x61/0xb0 [mei_me] [ 2373.143248] [] pci_device_remove+0x36/0xb0 [ 2373.143254] [] __device_release_driver+0x7a/0xe0 [ 2373.143260] [] driver_detach+0xc8/0xd0 [ 2373.143266] [] bus_remove_driver+0x96/0x120 [ 2373.143273] [] driver_unregister+0x27/0x50 [ 2373.143278] [] pci_unregister_driver+0x1c/0x90 [ 2373.143286] [] mei_me_driver_exit+0x10/0xf78 [mei_me] [ 2373.143291] [] SyS_delete_module+0x15d/0x2c0 [ 2373.143299] [] ? do_notify_resume+0x59/0x90 [ 2373.143305] [] system_call_fastpath+0x16/0x1b [ 2373.143308] ---[ end trace 25f53c192da70827 ]--- [ 2373.143313] kobject: 'msi_irqs' (880037327a18): kobject_release, parent 880119bb40a8 (delayed) [ 2373.143458] kobject: 'misc' (8800d6487500): kobject_release, parent 880119bb40a8 (delayed) [ 2373.143463] kobject: 'mei' (8800d35f3410): kobject_release, parent (null) (delayed) [ 2373.143607] kobject: 'mei_me' (88003717ce00): kobject_release, parent 8801194b2818 (delayed) [ 2373.143670] kobject: 'drivers' (8800d6487600): kobject_release, parent a01d5330 (delayed) [ 2373.143678] kobject: 'holders' (8800d6714700): kobject_release, parent a01d5330 (delayed) [ 2373.143682] kobject: 'notes' (8800d6714600): kobject_release, parent a01d5330 (delayed) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
