Re: [PATCH v2 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl
Hi Paul,
thank you for your review.
Am 27.03.2015 um 18:10 schrieb Paul Bolle:
> This patch adds a mismatch between the Kconfig symbol (bool) and the
> code (which assumes a modular built too).
>
> On Fri, 2015-03-27 at 10:36 +0100, Oleksij Rempel wrote:
>> --- a/drivers/pinctrl/Kconfig
>> +++ b/drivers/pinctrl/Kconfig
>> @@ -47,6 +47,14 @@ config PINCTRL_AS3722
>>open drain configuration for the GPIO pins of AS3722 devices. It also
>>supports the GPIO functionality through gpiolib.
>>
>> +config PINCTRL_ASM9260
>> +bool "Pinctrl driver for Alphascale asm9260"
>
> This adds a bool symbol.
>
>> +depends on MACH_ASM9260
>> +select PINMUX
>> +select GENERIC_PINCONF
>> +help
>> + Say Y here to enable the Alphascale asm9260 pinctrl driver
>> +
>
>> -- a/drivers/pinctrl/Makefile
>> +++ b/drivers/pinctrl/Makefile
>
>> +obj-$(CONFIG_PINCTRL_ASM9260) += pinctrl-asm9260.o
>
> So this object can now only be built-in.
>
>> --- /dev/null
>> +++ b/drivers/pinctrl/pinctrl-asm9260.c
>> @@ -0,0 +1,733 @@
>> +/*
>> + * Pinctrl driver for the Alphascale ASM9260 SoC
>> + *
>> + * Copyright (c) 2014, Oleksij Rempel
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>
> This include is probably not needed.
This include is still needed for MODULE_DEVICE_TABLE.
>> +#include
>> +#include
>> +#include
>> +
>> +#include "core.h"
>> +#include "pinctrl-utils.h"
>
>> +/*
>> + * Pin control driver setup
>> + */
>> +static struct pinctrl_desc asm9260_pinctrl_desc = {
>> +.pctlops= _pinctrl_ops,
>> +.pmxops = _pinmux_ops,
>> +.confops= _pinconf_ops,
>> +.owner = THIS_MODULE,
>
> THIS_MODULE is, basically, equivalent to NULL for built-in code.
>
>> +};
>> +
>
>> +MODULE_DEVICE_TABLE(of, asm9260_pinctrl_of_match);
>
> This will be preprocessed away for built-in code.
>
>> +module_platform_driver(asm9260_pinctrl_driver);
>
> The built-in equivalent of this seems to be a wrapper that
> only does
> platform_driver_register(_pinctrl_driver);
>
> and mark that wrapper as a device_initcall(). There appears to be no
> macro that does all that in one line.
>
>> +MODULE_AUTHOR("Oleksij Rempel ");
>> +MODULE_DESCRIPTION("Alphascale ASM9260 pinctrl driver");
>> +MODULE_LICENSE("GPL");
>
> These three macros will be, effectively, preprocessed away for built-in
> code. (By the way, you probably want to use "GPL v2" as the license
> ident if it would be possible to build this code modular.)
>
According to:
http://lxr.free-electrons.com/source/include/linux/module.h#L100
"GPL" [GNU Public License v2 or later]
which reflects statement provided in the header :)
I assume all this changes are in the grey zone between: "make it pretty"
and "it won't make any difference" :D
Are you ok if we leave it as is?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
RE: [LKP] [cfg80211] eeca9fce1d7: BUG: kernel boot oversize
Hi,
> -Original Message-
> From: Tomeu Vizoso [mailto:tomeu.viz...@gmail.com]
> Sent: Thursday, April 02, 2015 17:49
> To: Peer, Ilan
> Cc: Huang, Ying; Berg, Johannes; LKML; l...@01.org
> Subject: Re: [LKP] [cfg80211] eeca9fce1d7: BUG: kernel boot oversize
>
> On 24 March 2015 at 09:34, Peer, Ilan wrote:
> > Hi,
> >
> > This mean u probably do not have crda installed, or it is not properly
> configured. These are debug prints so the simplest would be to disable
> CONFIG_CFG80211_REG_DEBUG .. unless you are debugging wireless
> regulatory flows.
>
> Are you sure? I see lots (one every ~3 seconds) of this after rebasing on
> latest
> linux-next and CONFIG_CFG80211_REG_DEBUG isn't enabled:
>
> [ 19.382847] cfg80211: Calling CRDA to update world regulatory domain
>
These are printed directly using pr_info regardless of the configuration option.
> Reverting this patch brings back the old behavior.
>
This fixes the issue you reported (sorry I forgot to CC u).
https://kernel.googlesource.com/pub/scm/linux/kernel/git/jberg/mac80211-next/+/c37722bd1972118142ee54c0e1a727142d944068
Regards,
Ilan.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH RFC] nohz,blk-mq: do not create blk-mq workqueues on nohz dedicated CPUs
On Tue, 2015-03-31 at 10:27 -0400, Rik van Riel wrote: > CPUs with nohz_full do not want disruption from timer interrupts, > or other random system things. This includes block mq work. > > There is another issue with block mq vs. realtime tasks that run > 100% of the time, which is not uncommon on systems that have CPUs > dedicated to real time use with isolcpus= and nohz_full= > > Specifically, on systems like that, a block work item may never > get to run, which could lead to filesystems getting stuck forever. What reason is there to run a compute hog as RT if it's the only task on an isolated core? In an RT kernel, PI may be a reason, but if a task is so critical that it needs bare metal, it had better not be. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blackfin: lib: ucmpdi2: Add ucmpdi2 from libgcc2
Just copy the output of "gcc -S". The related error:
kernel/built-in.o: In function `perf_swevent_init':
kernel/events/core.c:(.text+0xa97e4): undefined reference to `__ucmpdi2'
make: *** [vmlinux] Error 1
Signed-off-by: Chen Gang
---
arch/blackfin/kernel/bfin_ksyms.c | 2 ++
arch/blackfin/lib/Makefile| 2 +-
arch/blackfin/lib/ucmpdi2.S | 42 +++
3 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 arch/blackfin/lib/ucmpdi2.S
diff --git a/arch/blackfin/kernel/bfin_ksyms.c
b/arch/blackfin/kernel/bfin_ksyms.c
index c446591..7fcfc06 100644
--- a/arch/blackfin/kernel/bfin_ksyms.c
+++ b/arch/blackfin/kernel/bfin_ksyms.c
@@ -60,6 +60,7 @@ extern void __modsi3(void);
extern void __muldi3(void);
extern void __udivsi3(void);
extern void __umodsi3(void);
+extern void __ucmpdi2(void);
EXPORT_SYMBOL(__ashldi3);
EXPORT_SYMBOL(__ashrdi3);
EXPORT_SYMBOL(__umulsi3_highpart);
@@ -70,6 +71,7 @@ EXPORT_SYMBOL(__modsi3);
EXPORT_SYMBOL(__muldi3);
EXPORT_SYMBOL(__udivsi3);
EXPORT_SYMBOL(__umodsi3);
+EXPORT_SYMBOL(__ucmpdi2);
/* Input/output symbols: lib/{in,out}s.S */
EXPORT_SYMBOL(outsb);
diff --git a/arch/blackfin/lib/Makefile b/arch/blackfin/lib/Makefile
index 42c47dc..c0b6959 100644
--- a/arch/blackfin/lib/Makefile
+++ b/arch/blackfin/lib/Makefile
@@ -4,7 +4,7 @@
lib-y := \
ashldi3.o ashrdi3.o lshrdi3.o \
- muldi3.o divsi3.o udivsi3.o modsi3.o umodsi3.o \
+ muldi3.o divsi3.o udivsi3.o modsi3.o umodsi3.o ucmpdi2.o \
memcpy.o memset.o memcmp.o memchr.o memmove.o \
strcmp.o strcpy.o strncmp.o strncpy.o \
umulsi3_highpart.o smulsi3_highpart.o \
diff --git a/arch/blackfin/lib/ucmpdi2.S b/arch/blackfin/lib/ucmpdi2.S
new file mode 100644
index 000..654f34c
--- /dev/null
+++ b/arch/blackfin/lib/ucmpdi2.S
@@ -0,0 +1,42 @@
+/*
+ * libgcc2 routines for Blackfin
+ *
+ * Copyright 2015 Chen Gang
+ *
+ * Licensed under the Clear BSD license or the GPL-2 (or later)
+ */
+
+#ifdef CONFIG_ARITHMETIC_OPS_L1
+.section .l1.text
+#else
+.text
+#endif
+ .align 4
+.global ___ucmpdi2;
+.type ___ucmpdi2, STT_FUNC;
+___ucmpdi2:
+ LINK 0;
+ R3 = ROT R2 BY 0 ||
+ R2 = [FP+20] ||
+ nop;
+ cc =R1http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/signal: Remove pax argument from restore_sigcontext
* Brian Gerst wrote:
> On Sat, Apr 4, 2015 at 10:14 AM, Ingo Molnar wrote:
> >
> > * Brian Gerst wrote:
> >
> >> The pax argument is unnecesary. Instead, store the RAX value directly
> >> in regs.
> >>
> >> Signed-off-by: Brian Gerst
> >> Cc: Ingo Molnar
> >> Cc: "H. Peter Anvin"
> >> Cc: Andy Lutomirski
> >> Cc: Denys Vlasenko
> >> Cc: Linus Torvalds
> >> Cc: Borislav Petkov
> >> Cc: x...@kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> ---
> >> arch/x86/ia32/ia32_signal.c| 17 ++---
> >> arch/x86/include/asm/sighandling.h | 4 +---
> >> arch/x86/kernel/signal.c | 22 --
> >> 3 files changed, 15 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> >> index 1f5e2b0..c81d35e6 100644
> >> --- a/arch/x86/ia32/ia32_signal.c
> >> +++ b/arch/x86/ia32/ia32_signal.c
> >> @@ -161,8 +161,7 @@ int copy_siginfo_from_user32(siginfo_t *to,
> >> compat_siginfo_t __user *from)
> >> }
> >>
> >> static int ia32_restore_sigcontext(struct pt_regs *regs,
> >> -struct sigcontext_ia32 __user *sc,
> >> -unsigned int *pax)
> >> +struct sigcontext_ia32 __user *sc)
> >> {
> >> unsigned int tmpflags, err = 0;
> >> void __user *buf;
> >> @@ -184,7 +183,7 @@ static int ia32_restore_sigcontext(struct pt_regs
> >> *regs,
> >> RELOAD_SEG(es);
> >>
> >> COPY(di); COPY(si); COPY(bp); COPY(sp); COPY(bx);
> >> - COPY(dx); COPY(cx); COPY(ip);
> >> + COPY(dx); COPY(cx); COPY(ip); COPY(ax);
> >> /* Don't touch extended registers */
> >>
> >> COPY_SEG_CPL3(cs);
> >> @@ -197,8 +196,6 @@ static int ia32_restore_sigcontext(struct pt_regs
> >> *regs,
> >>
> >> get_user_ex(tmp, >fpstate);
> >> buf = compat_ptr(tmp);
> >> -
> >> - get_user_ex(*pax, >ax);
> >> } get_user_catch(err);
> >
> > Note that arch/x86/kernel/signal.c appears to have a similar pattern -
> > and there it could be removed as well?
>
> I'm guessing you didn't read the whole patch, because I did change it.
Yes :-/
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] nohz: make nohz_full imply isolcpus
* Chris Metcalf wrote: > On 4/4/2015 10:10 AM, Rik van Riel wrote: > >>Rik, what's the change you're proposing that's similar to this one? Thanks! > >I don't have this particular one, and I like it. > > > >I know there are use cases where isolcpus= without > >nohz_full= makes sense, but I cannot think of the > >reverse. > > > >Acked-by: Rik van Riel > > Thanks, I'll push it via the tile tree unless someone would prefer otherwise. Yes, I'd prefer otherwise: please send the final, agreed upon patch to the timer tree. > (The tick_nohz_full_set_cpus() and tick_nohz_full_clear_cpus() > routines are in earlier tile tree commits, the latter supporting a > change to the tile network driver.) This is absolutely not OK, please push this through the timer tree. We don't do generic timer changes through architecture trees. 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/
[PATCH] Documentation: blackfin: gptimers-example: Use new switch macro SAMPLE_IRQ_TIMER instead of IRQ_TIMER5
Not all blackfin machines support IRQ_TIMER5, but all machines support
IRQ_TIMER2. So add a switch macro for them. The related error:
Documentation/blackfin/gptimers-example.c: In function 'gptimer_example_init':
Documentation/blackfin/gptimers-example.c:60:20: error: 'IRQ_TIMER5'
undeclared (first use in this function)
ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED,
DRIVER_NAME, );
^
Documentation/blackfin/gptimers-example.c:60:20: note: each undeclared
identifier is reported only once for each function it appears in
Documentation/blackfin/gptimers-example.c: In function 'gptimer_example_exit':
Documentation/blackfin/gptimers-example.c:78:11: error: 'IRQ_TIMER5'
undeclared (first use in this function)
free_irq(IRQ_TIMER5, );
^
Also notice about 80 columns limitation.
Signed-off-by: Chen Gang
---
Documentation/blackfin/gptimers-example.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/blackfin/gptimers-example.c
b/Documentation/blackfin/gptimers-example.c
index b1bd634..283eba9 100644
--- a/Documentation/blackfin/gptimers-example.c
+++ b/Documentation/blackfin/gptimers-example.c
@@ -17,6 +17,12 @@
#define DRIVER_NAME "gptimer_example"
+#ifdef IRQ_TIMER5
+#define SAMPLE_IRQ_TIMER IRQ_TIMER5
+#else
+#define SAMPLE_IRQ_TIMER IRQ_TIMER2
+#endif
+
struct gptimer_data {
uint32_t period, width;
};
@@ -57,7 +63,8 @@ static int __init gptimer_example_init(void)
}
/* grab the IRQ for the timer */
- ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED,
DRIVER_NAME, );
+ ret = request_irq(SAMPLE_IRQ_TIMER, gptimer_example_irq,
+ IRQF_SHARED, DRIVER_NAME, );
if (ret) {
printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n");
peripheral_free(P_TMR5);
@@ -65,7 +72,8 @@ static int __init gptimer_example_init(void)
}
/* setup the timer and enable it */
- set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT |
IRQ_ENA);
+ set_gptimer_config(TIMER5_id,
+ WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA);
enable_gptimers(TIMER5bit);
return 0;
@@ -75,7 +83,7 @@ module_init(gptimer_example_init);
static void __exit gptimer_example_exit(void)
{
disable_gptimers(TIMER5bit);
- free_irq(IRQ_TIMER5, );
+ free_irq(SAMPLE_IRQ_TIMER, );
peripheral_free(P_TMR5);
}
module_exit(gptimer_example_exit);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: blackfin: Makefile: Typo building issue
Miss a ')' for ifneq in Makefile, the related building error: Documentation/blackfin/Makefile:2: *** invalid syntax in conditional. Stop. make[1]: *** [Documentation/blackfin] Error 2 Signed-off-by: Chen Gang --- Documentation/blackfin/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile index 03f7805..6782c58 100644 --- a/Documentation/blackfin/Makefile +++ b/Documentation/blackfin/Makefile @@ -1,5 +1,5 @@ ifneq ($(CONFIG_BLACKFIN),) -ifneq ($(CONFIG_BFIN_GPTIMERS,) +ifneq ($(CONFIG_BFIN_GPTIMERS),) obj-m := gptimers-example.o endif endif -- 1.9.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] drm/msm: fix build warning - missing prototype
On Sat, 04 Apr 2015, Rob Clark wrote: > On Fri, Apr 3, 2015 at 10:39 PM, Nicholas Mc Guire wrote: > > fix build warning when building edp/edp_aux.o due to missing > > prototype for edp_aux_transfer. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > building drivers/gpu/drm/msm/msm.ko gives the following warning: > > drivers/gpu/drm/msm/edp/edp_aux.c:118:9: warning: no previous prototype for > > 'edp_aux_transfer' [-Wmissing-prototypes] > > ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct drm_dp_aux_msg > > *msg) > > ^ > > > > thx.. fwiw, looks like edp_aux_transfer is only used in that one > file.. so probably it actually wants to be static instead.. > yup - missed that - making it static is the cleaner solution will resend. thx! hofrat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI: Introduce pci_bus_addr_t
On Sat, Apr 4, 2015 at 2:48 PM, Rob Herring wrote: > On Sat, Apr 4, 2015 at 7:46 AM, Bjorn Helgaas wrote: >> I think there's still an unresolved question about the OF parsing code. > > Got a pointer to what that is? I'll take a guess. Generally, we make > the parsing code independent of the kernel addr sizes and use u64 > types. The DT sizes and kernel sizes are not always aligned. For > example, an LPAE capable platform running a non-LPAE kernel build. Yep: http://lkml.kernel.org/r/1427857069-6789-3-git-send-email-ying...@kernel.org Yinghai made a change to the sparc OF parsing code. The question is whether a similar change should be made to clones of that code (two others in arch/sparc, one in arch/powerpc, and one in drivers/of). Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 04/03/15 at 05:21pm, Dave Young wrote: > On 04/03/15 at 05:01pm, Li, ZhenHua wrote: > > Hi Dave, > > > > There may be some possibilities that the old iommu data is corrupted by > > some other modules. Currently we do not have a better solution for the > > dmar faults. > > > > But I think when this happens, we need to fix the module that corrupted > > the old iommu data. I once met a similar problem in normal kernel, the > > queue used by the qi_* functions was written again by another module. > > The fix was in that module, not in iommu module. > > It is too late, there will be no chance to save vmcore then. > > Also if it is possible to continue corrupt other area of oldmem because > of using old iommu tables then it will cause more problems. > > So I think the tables at least need some verifycation before being used. > Yes, it's a good thinking anout this and verification is also an interesting idea. kexec/kdump do a sha256 calculation on loaded kernel and then verify this again when panic happens in purgatory. This checks whether any code stomps into region reserved for kexec/kernel and corrupt the loaded kernel. If this is decided to do it should be an enhancement to current patchset but not a approach change. Since this patchset is going very close to point as maintainers expected maybe this can be merged firstly, then think about enhancement. After all without this patchset vt-d often raised error message, hung. By the way I tested this patchset it works very well on my HP z420 work station. Thanks Baoquan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: sm750fb: Remove extra parentheses around right bit shift operation
Removes extra parentheses around bitwise right shift operation. The issue was detected using the following coccinelle script. @@ expression e, e1; constant c; @@ e = -(e1 +e1 << -c); +c; @@ identifier i; constant c; type t; expression e; @@ t i = -(e +e << -c); +c; @@ expression e, e1; identifier f; constant c; @@ e1 = f(..., -(e +e << -c) +c ,...); Signed-off-by: Amitoj Kaur Chawla --- drivers/staging/sm750fb/sm750.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c index 4074375..626b841 100644 --- a/drivers/staging/sm750fb/sm750.c +++ b/drivers/staging/sm750fb/sm750.c @@ -737,7 +737,7 @@ static int sm750fb_set_drv(struct lynxfb_par * par) output->paths = sm750_crt; crtc->channel = sm750_secondary; /* not consider of padding stuffs for oScreen,need fix*/ -crtc->oScreen = (share->vidmem_size >> 1); +crtc->oScreen = share->vidmem_size >> 1; crtc->vScreen = share->pvMem + crtc->oScreen; } break; @@ -751,7 +751,7 @@ static int sm750fb_set_drv(struct lynxfb_par * par) output->paths = sm750_crt; crtc->channel = sm750_primary; /* not consider of padding stuffs for oScreen,need fix*/ -crtc->oScreen = (share->vidmem_size >> 1); +crtc->oScreen = share->vidmem_size >> 1; crtc->vScreen = share->pvMem + crtc->oScreen; } break; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/19] x86, boot: kaslr cleanup and 64bit kaslr support
Hi Yinghai, Seems this patchset contains much content at one time so that it's not very convenient to understand and review. Could it be made by 2 or 3 steps? like Firstly post a patchset to handle kaslr putting kernel above 4G. This involves many lines of code change but its concept is simple. And code change can be understood and reviewed very easily. Secondly a patchset to clean up the VO/ZO/runsize issue. This involves less codes but very complicated and a good description is necessary. At last, based on the 2nd change handle the mem_avoid issue and furthur clean up issues, then based on them kaslr can random to below the loaded address. Otherwise this patchset got too much fix. Reviewers need spend much time to understand and review. And also not easy to explain each of them and connections between them. What do you think? Thanks Baoquan On 03/18/15 at 12:28am, Yinghai Lu wrote: > First make ZO (arch/x86/boot/compressed/vmlinux) data region is not > overwritten by VO (vmlinux) after decompress. So could pass data from ZO to > VO. > > Second one is second try for kaslr_setup_data support. > > Patch 3-11, are kaslr clean up and enable ident mapping for He's patches. > kill run_size calculation shell scripts. > create new ident mapping for kasl 64bit, so we can cover >above 4G random kernel base, also don't need to track pagetable >for 64bit bootloader (patched grub2 or kexec). >that will make mem_avoid handling simple. > > Also put 7 patches from He that support random random, as I already used > his patches to test the ident mapping code, and could save some rebase > work for him. > > also at: > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-x86-4.0-rc5-aslr > > Thanks > > Yinghai > > > Baoquan He (7): > x86, kaslr: Fix a bug that relocation can not be handled when kernel is > loaded above 2G > x86, kaslr: Introduce struct slot_area to manage randomization slot info > x86, kaslr: Add two functions which will be used later > x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text > mapping address > x86, kaslr: Randomize physical and virtual address of kernel separately > x86, kaslr: Add support of kernel physical address randomization above 4G > x86, kaslr: Remove useless codes > > Jiri Kosina (1): > x86, kaslr: Propagate base load address calculation v2 > > Yinghai Lu (11): > x86, boot: Make data from decompress_kernel stage live longer > x86, boot: Simplify run_size calculation > x86, kaslr: Kill not used run_size related code. > x86, kaslr: Use output_run_size > x86, kaslr: Consolidate mem_avoid array filling > x86, boot: Move z_extract_offset calculation to header.S > x86, kaslr: Get correct max_addr for relocs pointer > x86, boot: Split kernel_ident_mapping_init to another file > x86, 64bit: Set ident_mapping for kaslr > x86, boot: Add checking for memcpy > x86, kaslr: Allow random address could be below loaded address > > arch/x86/boot/Makefile | 13 +- > arch/x86/boot/compressed/Makefile | 19 ++- > arch/x86/boot/compressed/aslr.c| 281 > - > arch/x86/boot/compressed/head_32.S | 14 +- > arch/x86/boot/compressed/head_64.S | 15 +- > arch/x86/boot/compressed/misc.c| 71 + > arch/x86/boot/compressed/misc.h| 32 ++-- > arch/x86/boot/compressed/misc_pgt.c| 91 +++ > arch/x86/boot/compressed/mkpiggy.c | 28 +--- > arch/x86/boot/compressed/string.c | 28 +++- > arch/x86/boot/compressed/vmlinux.lds.S | 2 + > arch/x86/boot/header.S | 43 - > arch/x86/include/asm/aslr.h| 10 ++ > arch/x86/include/asm/boot.h| 19 +++ > arch/x86/include/asm/page.h| 5 + > arch/x86/include/asm/page_types.h | 2 + > arch/x86/include/uapi/asm/bootparam.h | 1 + > arch/x86/kernel/asm-offsets.c | 1 + > arch/x86/kernel/module.c | 10 +- > arch/x86/kernel/setup.c| 27 +++- > arch/x86/kernel/vmlinux.lds.S | 1 + > arch/x86/mm/ident_map.c| 74 + > arch/x86/mm/init_64.c | 74 + > arch/x86/tools/calc_run_size.sh| 42 - > 24 files changed, 610 insertions(+), 293 deletions(-) > create mode 100644 arch/x86/boot/compressed/misc_pgt.c > create mode 100644 arch/x86/include/asm/aslr.h > create mode 100644 arch/x86/mm/ident_map.c > delete mode 100644 arch/x86/tools/calc_run_size.sh > > -- > 1.8.4.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] rtc: hym8563: fix swapped enable/disable of clockout control bit
The hym8563 datasheet describes the clock output control-bit as "when set
to logic 0, the square wave output is enable, when set to logic 1, the
CLKOUT output is inhibited". But in reality the setting is exactly
opposite.
Before now, the clock output was not really used, but on the rk3288 soc
this generated clock is used to supply the temperature sensor block and
the swapped bit value prevented it from working. With the corrected value,
the tsadc now reports correct values.
Signed-off-by: Heiko Stuebner
---
drivers/rtc/rtc-hym8563.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
index d4a6561..0f710e9 100644
--- a/drivers/rtc/rtc-hym8563.c
+++ b/drivers/rtc/rtc-hym8563.c
@@ -66,7 +66,7 @@
#define HYM8563_ALM_BIT_DISABLEBIT(7)
#define HYM8563_CLKOUT 0x0d
-#define HYM8563_CLKOUT_DISABLE BIT(7)
+#define HYM8563_CLKOUT_ENABLE BIT(7)
#define HYM8563_CLKOUT_32768 0
#define HYM8563_CLKOUT_10241
#define HYM8563_CLKOUT_32 2
@@ -360,9 +360,9 @@ static int hym8563_clkout_control(struct clk_hw *hw, bool
enable)
return ret;
if (enable)
- ret &= ~HYM8563_CLKOUT_DISABLE;
+ ret |= HYM8563_CLKOUT_ENABLE;
else
- ret |= HYM8563_CLKOUT_DISABLE;
+ ret &= ~HYM8563_CLKOUT_ENABLE;
return i2c_smbus_write_byte_data(client, HYM8563_CLKOUT, ret);
}
@@ -386,7 +386,7 @@ static int hym8563_clkout_is_prepared(struct clk_hw *hw)
if (ret < 0)
return ret;
- return !(ret & HYM8563_CLKOUT_DISABLE);
+ return !!(ret & HYM8563_CLKOUT_ENABLE);
}
static const struct clk_ops hym8563_clkout_ops = {
@@ -407,7 +407,7 @@ static struct clk *hym8563_clkout_register_clk(struct
hym8563 *hym8563)
int ret;
ret = i2c_smbus_write_byte_data(client, HYM8563_CLKOUT,
- HYM8563_CLKOUT_DISABLE);
+ 0);
if (ret < 0)
return ERR_PTR(ret);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/signal: Remove pax argument from restore_sigcontext
On Sat, Apr 4, 2015 at 10:14 AM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> The pax argument is unnecesary. Instead, store the RAX value directly
>> in regs.
>>
>> Signed-off-by: Brian Gerst
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: Andy Lutomirski
>> Cc: Denys Vlasenko
>> Cc: Linus Torvalds
>> Cc: Borislav Petkov
>> Cc: x...@kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> arch/x86/ia32/ia32_signal.c| 17 ++---
>> arch/x86/include/asm/sighandling.h | 4 +---
>> arch/x86/kernel/signal.c | 22 --
>> 3 files changed, 15 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
>> index 1f5e2b0..c81d35e6 100644
>> --- a/arch/x86/ia32/ia32_signal.c
>> +++ b/arch/x86/ia32/ia32_signal.c
>> @@ -161,8 +161,7 @@ int copy_siginfo_from_user32(siginfo_t *to,
>> compat_siginfo_t __user *from)
>> }
>>
>> static int ia32_restore_sigcontext(struct pt_regs *regs,
>> -struct sigcontext_ia32 __user *sc,
>> -unsigned int *pax)
>> +struct sigcontext_ia32 __user *sc)
>> {
>> unsigned int tmpflags, err = 0;
>> void __user *buf;
>> @@ -184,7 +183,7 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
>> RELOAD_SEG(es);
>>
>> COPY(di); COPY(si); COPY(bp); COPY(sp); COPY(bx);
>> - COPY(dx); COPY(cx); COPY(ip);
>> + COPY(dx); COPY(cx); COPY(ip); COPY(ax);
>> /* Don't touch extended registers */
>>
>> COPY_SEG_CPL3(cs);
>> @@ -197,8 +196,6 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
>>
>> get_user_ex(tmp, >fpstate);
>> buf = compat_ptr(tmp);
>> -
>> - get_user_ex(*pax, >ax);
>> } get_user_catch(err);
>
> Note that arch/x86/kernel/signal.c appears to have a similar pattern -
> and there it could be removed as well?
>
> I'm wondering what the original reason for adding the extra handling
> of regs->ax was. Maybe something changed regs->ax - but I cannot find
> such code path anymore.
>
> It would be nice to try to do a bit of Git archeology to figure out
> the origins of this complication - maybe it's something subtle - or
> it's something that has changed meanwhile.
It goes all the way back to 2.1.106pre1, when restore_sigcontext() was
changed to return an error code instead of EAX directly.
https://git.kernel.org/cgit/linux/kernel/git/history/history.git/diff/arch/i386/kernel/signal.c?id=9a8f8b7ca3f319bd668298d447bdf32730e51174
--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] iio: add driver for Freescale MMA9553
Irina Tirdea schrieb am 27.01.2015 um 19:41: > Add support for Freescale MMA9553L Intelligent Pedometer Platform. > > The following functionalities are supported: > - step counter (counts the number of steps using a HW register) > - step detector (generates an iio event at every step the user takes) > - activity recognition (rest, walking, jogging, running) > - speed > - calories > - distance > > To get accurate pedometer results, the user's height, weight and gender > need to be configured. > > The specifications can be downloaded from: > http://www.freescale.com/files/sensors/doc/ref_manual/MMA955xLSWRM.pdf > http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf > Hi Irina, I still spotted a few issues and have some recommendations which you could address in a follow-up patch. Also, there are some minor style issues (spaces after cast, alignment issues, unnecessary blank lines), which checkpatch.pl --strict reveals. One other issue, where I would like to get the opinion of the other maintainers as well, concerns some of the functions you added to mma9551_core.c. The way they are used so far doesn't pose a threat, yet. But I am worried about the __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS], where the elements are accessed in relation to the len parameter. So, should there be a check in those functions to prevent buffer overrun problems, or just be very careful when using those functions? > Signed-off-by: Irina Tirdea > --- > Documentation/ABI/testing/sysfs-bus-iio | 49 +- > drivers/iio/accel/Kconfig | 10 + > drivers/iio/accel/Makefile |1 + > drivers/iio/accel/mma9551_core.c| 183 + > drivers/iio/accel/mma9551_core.h| 17 +- > drivers/iio/accel/mma9553.c | 1334 > +++ > 6 files changed, 1589 insertions(+), 5 deletions(-) > create mode 100644 drivers/iio/accel/mma9553.c > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > b/Documentation/ABI/testing/sysfs-bus-iio > index 588620e..9a70c31 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -343,7 +343,30 @@ Description: > production inaccuracies). If shared across all channels, > _calibscale is used. > > -What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibheight > +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender > +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender > +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender > +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender > +KernelVersion: 3.20 > +Contact: linux-...@vger.kernel.org > +Description: > + Gender of the user (e.g.: male, female) used by some pedometers > + to compute the stride length, distance, speed and activity > + type. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available > +What: > /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available > +What: > /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available > +What: > /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available > +KernelVersion: 3.20 > +Contact: linux-...@vger.kernel.org > +Description: > + Lists all available gender values (e.g.: male, female). > + > +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibheight > +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibheight > +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibheight > +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibheight > KernelVersion: 3.19 > Contact: linux-...@vger.kernel.org > Description: > @@ -818,6 +841,14 @@ What: > /sys/.../events/in_tempY_roc_falling_period > What:/sys/.../events/in_accel_x_mag_falling_period > What:/sys/.../events/in_intensity0_thresh_period > What:/sys/.../events/in_proximity0_thresh_period > +What:/sys/.../events/in_activity_still_thresh_rising_period > +What:/sys/.../events/in_activity_still_thresh_falling_period > +What:/sys/.../events/in_activity_walking_thresh_rising_period > +What: > /sys/.../events/in_activity_walking_thresh_falling_period > +What:/sys/.../events/in_activity_jogging_thresh_rising_period > +What: > /sys/.../events/in_activity_jogging_thresh_falling_period > +What:/sys/.../events/in_activity_running_thresh_rising_period > +What: > /sys/.../events/in_activity_running_thresh_falling_period > KernelVersion: 2.6.37 > Contact: linux-...@vger.kernel.org > Description: > @@ -1142,6 +1173,12 @@
[PATCH] staging : unisys: Fix brace coding style issue
This is a patch to visorchannel/visorchannel_funcs.c that fixes a couple
of brace warnings found by checkpatch.pl.
Signed-off-by: Andreas Theodosiou
---
drivers/staging/unisys/visorchannel/visorchannel_funcs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/unisys/visorchannel/visorchannel_funcs.c
b/drivers/staging/unisys/visorchannel/visorchannel_funcs.c
index 7a9a724..9ae5f75 100644
--- a/drivers/staging/unisys/visorchannel/visorchannel_funcs.c
+++ b/drivers/staging/unisys/visorchannel/visorchannel_funcs.c
@@ -405,9 +405,8 @@ signalremove_inner(struct visorchannel *channel, u32 queue,
void *msg)
return FALSE; /* no signals to remove */
sig_hdr.tail = (sig_hdr.tail + 1) % sig_hdr.max_slots;
- if (!sig_read_data(channel, queue, _hdr, sig_hdr.tail, msg)) {
+ if (!sig_read_data(channel, queue, _hdr, sig_hdr.tail, msg))
return FALSE;
- }
sig_hdr.num_received++;
/* For each data field in SIGNAL_QUEUE_HEADER that was modified,
@@ -470,9 +469,8 @@ signalinsert_inner(struct visorchannel *channel, u32 queue,
void *msg)
mb(); /* required for channel synch */
if (!SIG_WRITE_FIELD(channel, queue, _hdr, head))
return FALSE;
- if (!SIG_WRITE_FIELD(channel, queue, _hdr, num_sent)) {
+ if (!SIG_WRITE_FIELD(channel, queue, _hdr, num_sent))
return FALSE;
- }
return TRUE;
}
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: atkbd: Fix release quirk for Dell models
On Sunday 29 March 2015 16:36:19 Pali Rohár wrote:
> This patch fixes commit 61579ba83934 ("Input: atkbd - expand
> Latitude's force release quirk to other Dells"). Before that
> commit release quirks were called for all Dell Latitude
> models. After that commit only for Portable Dell devices. But
> lot of Latitude models are Laptop or Notebook DMI devices so
> quirks are not called.
>
> Release quirks are still needed also for new Dell Latitude
> models, so this patch enables quirks for all Portable,
> Laptop, Notebook and Sub-Notebook Dell devices.
>
> Signed-off-by: Pali Rohár
Dmitry, Matthew: Can be this patch pushed to 4.0 and backported
to stable releases? It fix regression caused by specified commit.
I tested this patch on Latitude E6440 and now all keys are
correctly released.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] usb: musb: Kconfig: Depend on some machines under blackfin
On 4/4/15 17:54, Greg Kroah-Hartman wrote: > On Sat, Apr 04, 2015 at 05:51:21AM +0800, Chen Gang wrote: >> Under blackfin, only bf527, bf548 and bf609 may use musb. The related >> error with allmodconfig: >> >> CC [M] drivers/usb/misc/trancevibrator.o >> In file included from drivers/usb/musb/musb_core.h:70:0, >>from drivers/usb/musb/musb_core.c:103: >> drivers/usb/musb/musb_core.c: In function 'musb_indexed_ep_select': >> drivers/usb/musb/musb_regs.h:458:32: error: 'USB_INDEX' undeclared (first >> use in this function) >>#define MUSB_INDEX USB_OFFSET(USB_INDEX) /* 8 bit */ >> ^ >> >> Signed-off-by: Chen Gang > > Why not fix the root cause and provide this symbol on blackfin? There's > no specific reason why it shouldn't be able to be built on this > platform. > > It's better to make platforms properly build everything, patches like > this just make things messier and harder to maintain. > I am not quite sure all machines of blackfin can support musb (according to current code, at present, we can only sure bf527, bf548 and bf609 can support it). So, I suggest to add new macro HAVE_MUSB for BLACKFIN in patch v2. And welcome any other members' idea. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: samples: kdbus: kdbus-workers: Define dummy prime_new()
On 4/4/15 16:26, Greg KH wrote: > On Sat, Apr 04, 2015 at 06:17:23AM +0800, Chen Gang wrote: >> Quite a few of architures (e.g. blackfin, cris, frv ...) do not support >> memfd_create system call which is used in prime_new(). So define a dummy >> one. >> >> The related error (with allmodconfig under blackfin): >> >> CC [M] samples/kfifo/inttype-example.o >> samples/kdbus/kdbus-workers.c: In function ‘prime_new’: >> samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ >> undeclared (first use in this function) >> p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); >> ^ >> samples/kdbus/kdbus-workers.c:930:18: note: each undeclared identifier is >> reported only once for each function it appears in >> make[2]: *** [samples/kdbus/kdbus-workers] Error 1 >> >> Signed-off-by: Chen Gang >> --- >> samples/kdbus/kdbus-workers.c | 11 +++ >> 1 file changed, 11 insertions(+) > > As Richard said, please hook up these syscalls to those architectures. > Don't you want to use the feature there? Why hasn't it been added yet? > OK, thanks. I shall try to finish blackfin within this month. And try the other archs within next month. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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][ASoC]Add ability to remove rate constraints from generic ASoC AC'97 CODEC driver
W dniu 30.03.2015 06:19, Mark Brown pisze: > On Sun, Mar 29, 2015 at 06:00:33PM +0200, Maciej S. Szmigiero wrote: >> W dniu 22.03.2015 19:27, Mark Brown pisze: > >>> Please use subject lines matching the style for the subsystem. This is >>> helpful for identifying relevant patches and not getting your messages >>> deleted unread... > >> I assume "[PATCH] ASoC: driver: subject" format would be right? > > Yes. Thanks for information. >>> I'm sorry but this just doesn't explain what this patch is intended to >>> accomplish. If we can talk to the AC'97 CODEC at all we can already >>> identify whatever constraints it has by looking at the ID registers so >>> it's not clear when or why a platform would need to use this. It feels >>> like there is some underlying problem that you're trying to address. > >> This patch itself is supposed to allow using this CODEC driver with >> CODECs that support other rates that these that were already hard-coded >> in the driver (8000, 11025, 22050, 44100, 48000). > > You're talking about Linux internal implementation details here but the > change you are proposing a change to the device tree? Like I think I > said in reply to a previous iteration of this patch we can clearly > enumerate the required information from the hardware already. > >> While it would be possible to simply add ac97 bus enumeration to >> either fsl_ssi driver or fsl-asoc-card sound card driver it looks to me >> that even in this case a platform device for codec would need to be >> registered anyway. > > That's the way the ASoC AC'97 support currently works, yes. > >> If the ac97 bus enumeration is added to fsl_ssi driver then there is >> also a problem of communicating a name of ac97 platform device >> to sound card driver so it can then reference it in DAI links >> that it builds. > > ... > >> And, naturally, this would result in a small code duplication with >> regard to this generic driver. > > This sounds like something that can easily be put in some generic code > and either used as a helper library by the drivers or just done directly > from the framework when it knows it's dealing with an AC'97 bus. > > Alternatively if you're just trying to open up the constraints why not > just open them up by default and make sure that the AC'97 generic code > is constraining things appropriately if it's not doing so already? By 'open them up by default' do you mean removing them altogether from ASOC AC'97 generic CODEC to let the AC'97 bus driver constrain rates on its own or do you mean retaining ability to constraint in ASOC AC'97 driver, just have it switched off by default? (that is, what the current patch did, just change the default setting). If the rate constraints are removed (or disabled) from the ASOC AC'97 generic CODEC driver then it can be used as-is in the (at least) fsl_ssi driver by registering AC'97 platform device there using index taken from DT property (cell-index) already defined as required in Documentation/devicetree/bindings/sound/fsl,ssi.txt. This way the AC'97 CODECs can be uniquely identified in case there is more than one in the system. Sadly, despite this property being marked as required in documentation no current DT file seems to define it. Now the question is what is more binding: the documentation which defines this property as required or DT files which don't define it at all? Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: Kconfig: Let PLL_BYPASS and MPU depend on some BF_REV of BF533
On 4/5/15 05:56, Richard Weinberger wrote: > Am 04.04.2015 um 23:48 schrieb Chen Gang: >> On 4/4/15 06:59, Richard Weinberger wrote: > So you have a blackfin board and successfully booted such a allmodconfig > kernel on it? No, I have no any related hardware for it. For this issue, I referenced arch/blackfin/Makefile for BF_REL: [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.6 -E - | grep __SILICON_REVISION__ #define __SILICON_REVISION__ 0x0006 [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.5 -E - | grep __SILICON_REVISION__ #define __SILICON_REVISION__ 0x0005 [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.4 -E - | grep __SILICON_REVISION__ #define __SILICON_REVISION__ 0x0004 [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.3 -E - | grep __SILICON_REVISION__ #define __SILICON_REVISION__ 0x0003 [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.2 -E - | grep __SILICON_REVISION__ cc1: error: -mcpu=bf533-0.2 has invalid silicon revision cc1: error: unrecognized command line option '-mcpu=bf533-0.2' [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.1 -E - | grep __SILICON_REVISION__ cc1: error: -mcpu=bf533-0.1 has invalid silicon revision cc1: error: unrecognized command line option '-mcpu=bf533-0.1' [root@localhost linux-next]# echo "" | /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -dD -mcpu=bf533-0.0 -E - | grep __SILICON_REVISION__ cc1: error: -mcpu=bf533-0.0 has invalid silicon revision cc1: error: unrecognized command line option '-mcpu=bf533-0.0' Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tty: serial: Add const to struct uart_ops declarations
Hi Joe,
See comment below...
On 2015-04-04 19:47, Joe Perches wrote:
> These structs can be const, so make them const.
>
> Signed-off-by: Joe Perches
> ---
>
> Done with:
> sed -r -i -e 's/\bstruct\s+uart_ops\s+(\w+)\s*=\s*/const struct
> uart_ops \1 = /g' drivers/tty/serial/*.c
>
> Compiled x86 only, not cross-compiled. Untested.
>
> drivers/tty/serial/21285.c | 2 +-
> drivers/tty/serial/altera_jtaguart.c| 2 +-
> drivers/tty/serial/altera_uart.c| 2 +-
> drivers/tty/serial/amba-pl010.c | 2 +-
> drivers/tty/serial/amba-pl011.c | 2 +-
> drivers/tty/serial/apbuart.c| 2 +-
> drivers/tty/serial/ar933x_uart.c| 2 +-
> drivers/tty/serial/arc_uart.c | 2 +-
> drivers/tty/serial/atmel_serial.c | 2 +-
> drivers/tty/serial/bcm63xx_uart.c | 2 +-
> drivers/tty/serial/bfin_sport_uart.c| 2 +-
> drivers/tty/serial/bfin_uart.c | 2 +-
> drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
> drivers/tty/serial/dz.c | 2 +-
> drivers/tty/serial/efm32-uart.c | 2 +-
> drivers/tty/serial/fsl_lpuart.c | 4 ++--
> drivers/tty/serial/icom.c | 2 +-
> drivers/tty/serial/imx.c| 2 +-
> drivers/tty/serial/ioc3_serial.c| 2 +-
> drivers/tty/serial/ioc4_serial.c| 2 +-
> drivers/tty/serial/ip22zilog.c | 2 +-
> drivers/tty/serial/jsm/jsm_tty.c| 2 +-
> drivers/tty/serial/lantiq.c | 2 +-
> drivers/tty/serial/lpc32xx_hs.c | 2 +-
> drivers/tty/serial/m32r_sio.c | 2 +-
> drivers/tty/serial/max3100.c| 2 +-
> drivers/tty/serial/men_z135_uart.c | 2 +-
> drivers/tty/serial/meson_uart.c | 2 +-
> drivers/tty/serial/mpc52xx_uart.c | 2 +-
> drivers/tty/serial/mpsc.c | 2 +-
> drivers/tty/serial/msm_serial.c | 2 +-
> drivers/tty/serial/mux.c| 2 +-
> drivers/tty/serial/mxs-auart.c | 2 +-
> drivers/tty/serial/netx-serial.c| 2 +-
> drivers/tty/serial/nwpserial.c | 2 +-
> drivers/tty/serial/omap-serial.c| 2 +-
> drivers/tty/serial/pch_uart.c | 2 +-
> drivers/tty/serial/pmac_zilog.c | 2 +-
> drivers/tty/serial/pnx8xxx_uart.c | 2 +-
> drivers/tty/serial/pxa.c| 2 +-
> drivers/tty/serial/sa1100.c | 2 +-
> drivers/tty/serial/samsung.c| 2 +-
> drivers/tty/serial/serial-tegra.c | 2 +-
> drivers/tty/serial/serial_ks8695.c | 2 +-
> drivers/tty/serial/serial_txx9.c| 2 +-
> drivers/tty/serial/sh-sci.c | 2 +-
> drivers/tty/serial/sirfsoc_uart.c | 2 +-
> drivers/tty/serial/sn_console.c | 2 +-
> drivers/tty/serial/sprd_serial.c| 2 +-
> drivers/tty/serial/st-asc.c | 2 +-
> drivers/tty/serial/sunhv.c | 2 +-
> drivers/tty/serial/sunsab.c | 2 +-
> drivers/tty/serial/sunsu.c | 2 +-
> drivers/tty/serial/sunzilog.c | 2 +-
> drivers/tty/serial/timbuart.c | 2 +-
> drivers/tty/serial/uartlite.c | 2 +-
> drivers/tty/serial/ucc_uart.c | 2 +-
> drivers/tty/serial/vr41xx_siu.c | 2 +-
> drivers/tty/serial/vt8500_serial.c | 2 +-
> drivers/tty/serial/xilinx_uartps.c | 2 +-
> drivers/tty/serial/zs.c | 2 +-
> 61 files changed, 62 insertions(+), 62 deletions(-)
>
> --- a/drivers/tty/serial/efm32-uart.c
> +++ b/drivers/tty/serial/efm32-uart.c
> @@ -487,7 +487,7 @@ static int efm32_uart_verify_port(struct uart_port *port,
> return ret;
> }
>
> -static struct uart_ops efm32_uart_pops = {
> +static const struct uart_ops efm32_uart_pops = {
> .tx_empty = efm32_uart_tx_empty,
> .set_mctrl = efm32_uart_set_mctrl,
> .get_mctrl = efm32_uart_get_mctrl,
> diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
> index 08ce76f..738b5c4 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -1494,7 +1494,7 @@ static int lpuart_verify_port(struct uart_port
> *port, struct serial_struct *ser)
> return ret;
> }
>
> -static struct uart_ops lpuart_pops = {
> +static const const struct uart_ops lpuart_pops = {
Something went wrong in this driver, const is twice...
Probably because we have two struct uart_ops in one driver?
> .tx_empty = lpuart_tx_empty,
> .set_mctrl = lpuart_set_mctrl,
> .get_mctrl = lpuart_get_mctrl,
> @@ -1513,7 +1513,7 @@ static struct uart_ops lpuart_pops = {
> .flush_buffer = lpuart_flush_buffer,
> };
>
> -static struct uart_ops lpuart32_pops = {
> +static const const struct uart_ops
Re: [PATCH] blackfin: include: asm: pgtable: Define dummy pgprot_writecombine
Am 05.04.2015 um 00:02 schrieb Chen Gang:
> On 4/4/15 06:50, Richard Weinberger wrote:
>> On Fri, Apr 3, 2015 at 10:36 PM, Chen Gang
>> wrote:
>>> It is copied from asm-generic, the related error with allmodconfig:
>>>
>>> CC [M] sound/core/pcm_native.o
>>> sound/core/pcm_native.c: In function 'snd_pcm_lib_default_mmap':
>>> sound/core/pcm_native.c:3387:24: error: implicit declaration of function
>>> 'pgprot_writecombine' [-Werror=implicit-function-declaration]
>>> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
>>> ^
>>> sound/core/pcm_native.c:3387:22: error: incompatible types when assigning
>>> to type 'pgprot_t {aka struct }' from type 'int'
>>> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
>>> ^
>>>
>>> Signed-off-by: Chen Gang
>>> ---
>>> arch/blackfin/include/asm/pgtable.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/blackfin/include/asm/pgtable.h
>>> b/arch/blackfin/include/asm/pgtable.h
>>> index b88a155..3e730d9 100644
>>> --- a/arch/blackfin/include/asm/pgtable.h
>>> +++ b/arch/blackfin/include/asm/pgtable.h
>>> @@ -36,6 +36,7 @@ typedef pte_t *pte_addr_t;
>>> #define PAGE_READONLY __pgprot(0) /* these mean nothing to
>>> NO_MM */
>>> #define PAGE_KERNEL__pgprot(0) /* these mean nothing to
>>> NO_MM */
>>> #define pgprot_noncached(prot) (prot)
>>> +#define pgprot_writecombinepgprot_noncached
>>
>> This looks fishy as blackfin's pgtable.h already includes
>> asm-generic/pgtable.h.
>> So, copy pgprot_writecombine shouldn't be needed.
>>
>
> pgprot_writecombine in asm-generic/pgtable.h needs MMU, but allmodconfig
> for blackfin is NOMMU.
>
> So, I still suggest to add dummy one in blackfin (although for me, asm-
> generic/pgtable.h may need improvement -- welcome other members for it).
Sounds still fishy as you "introduced" allmodconfig...
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blackfin: include: asm: pgtable: Define dummy pgprot_writecombine
On 4/4/15 06:50, Richard Weinberger wrote:
> On Fri, Apr 3, 2015 at 10:36 PM, Chen Gang
> wrote:
>> It is copied from asm-generic, the related error with allmodconfig:
>>
>> CC [M] sound/core/pcm_native.o
>> sound/core/pcm_native.c: In function 'snd_pcm_lib_default_mmap':
>> sound/core/pcm_native.c:3387:24: error: implicit declaration of function
>> 'pgprot_writecombine' [-Werror=implicit-function-declaration]
>> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
>> ^
>> sound/core/pcm_native.c:3387:22: error: incompatible types when assigning
>> to type 'pgprot_t {aka struct }' from type 'int'
>> area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
>> ^
>>
>> Signed-off-by: Chen Gang
>> ---
>> arch/blackfin/include/asm/pgtable.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/blackfin/include/asm/pgtable.h
>> b/arch/blackfin/include/asm/pgtable.h
>> index b88a155..3e730d9 100644
>> --- a/arch/blackfin/include/asm/pgtable.h
>> +++ b/arch/blackfin/include/asm/pgtable.h
>> @@ -36,6 +36,7 @@ typedef pte_t *pte_addr_t;
>> #define PAGE_READONLY __pgprot(0) /* these mean nothing to
>> NO_MM */
>> #define PAGE_KERNEL__pgprot(0) /* these mean nothing to
>> NO_MM */
>> #define pgprot_noncached(prot) (prot)
>> +#define pgprot_writecombinepgprot_noncached
>
> This looks fishy as blackfin's pgtable.h already includes
> asm-generic/pgtable.h.
> So, copy pgprot_writecombine shouldn't be needed.
>
pgprot_writecombine in asm-generic/pgtable.h needs MMU, but allmodconfig
for blackfin is NOMMU.
So, I still suggest to add dummy one in blackfin (although for me, asm-
generic/pgtable.h may need improvement -- welcome other members for it).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blackfin: Kconfig: Let PLL_BYPASS and MPU depend on some BF_REV of BF533
Am 04.04.2015 um 23:48 schrieb Chen Gang: > On 4/4/15 06:59, Richard Weinberger wrote: >> On Thu, Apr 2, 2015 at 11:25 PM, Chen Gang >> wrote: >>> For allmodconfig, it uses BF533 which will cause 3 issues for common >>> checking: >>> >>> - The first 2 issues are about PLL_BYPASS, it needs BF_REV_0_6 (which >>>just match the compiler's output for __SILICON_REVISION__). >>> >>> - The last issue is about MPU, it needs BF_REV_0_5 or BF_REV_0_6 (which >>>just match the compiler's output for __SILICON_REVISION__). >>> >>> The related error with allmodconfig: >>> >>> CC arch/blackfin/mach-common/arch_checks.o >>> arch/blackfin/mach-common/arch_checks.c:24:3: error: #error "Sclk value >>> selected is less than minimum. Please select a proper value for SCLK >>> multiplier" >>># error "Sclk value selected is less than minimum. Please select a >>> proper value for SCLK multiplier" >>> ^ >>> arch/blackfin/mach-common/arch_checks.c:28:3: error: #error "ANOMALY >>> 05000273, please make sure CCLK is at least 2x SCLK" >>># error "ANOMALY 05000273, please make sure CCLK is at least 2x SCLK" >>> ^ >>> arch/blackfin/mach-common/arch_checks.c:51:3: error: #error the MPU will >>> not function safely while Anomaly 05000263 applies >>># error the MPU will not function safely while Anomaly 05000263 applies >>> ^ >>> >>> config PLL_BYPASS >>> bool "Bypass PLL" >>> - depends on BFIN_KERNEL_CLOCK && (!BF60x) >>> + depends on BFIN_KERNEL_CLOCK && (!BF60x) && ((!BF533) || BF_REV_0_6) >>> default n >>> >>> config CLKIN_HALF >>> @@ -1112,6 +1112,7 @@ endchoice >>> comment "Memory Protection Unit" >>> config MPU >>> bool "Enable the memory protection unit" >>> + depends on (!BF533) || BF_REV_0_6 || BF_REV_0_5 >>> default n >>> help >>> Use the processor's MPU to protect applications from accessing >> >> This answers my question wrt. allmodconfig. ;) >> I'm not sure if this is the correct way. Isn't this the reason why we >> have COMPILE_TEST? >> > > For me, COMPILE_TEST is for compiling test without the related hardware > supports, but the code should no any logical issues firstly (at least, > COMPILE_TEST itself should not generate additional logical bugs). > > In our case, I guess the first 2 issues are about logical issues (not > hardware supporting issues), so I guess, it is not suitable to use > COMPILE_TEST to bypass them. So you have a blackfin board and successfully booted such a allmodconfig kernel on it? Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: dsa: fix filling routing table from OF description
Le 04/04/2015 14:46, Pavel Nakonechny a écrit :
> According to description in 'include/net/dsa.h', in cascade switches
> configurations where there are more than one interconnected devices,
> 'rtable' array in 'dsa_chip_data' structure is used to indicate which
> port on this switch should be used to send packets to that are destined
> for corresponding switch.
>
> However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
> of the _target_ switch, but not current one.
>
> This commit removes redundant devicetree parsing and adds needed port
> number as a function argument. So dsa_of_setup_routing_table() now just
> looks for target switch number by parsing parent of 'link' device node.
>
> To remove possible misunderstandings with the way of determining target
> switch number, a corresponding comment was added to the source code and
> to the DSA device tree bindings documentation file.
>
> This was tested on a custom board with two Marvell 88E6095 switches with
> following corresponding routing tables: { -1, 10 } and { 8, -1 }.
>
> Signed-off-by: Pavel Nakonechny
> Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blackfin: Kconfig: Let PLL_BYPASS and MPU depend on some BF_REV of BF533
On 4/4/15 06:59, Richard Weinberger wrote: > On Thu, Apr 2, 2015 at 11:25 PM, Chen Gang > wrote: >> For allmodconfig, it uses BF533 which will cause 3 issues for common >> checking: >> >> - The first 2 issues are about PLL_BYPASS, it needs BF_REV_0_6 (which >>just match the compiler's output for __SILICON_REVISION__). >> >> - The last issue is about MPU, it needs BF_REV_0_5 or BF_REV_0_6 (which >>just match the compiler's output for __SILICON_REVISION__). >> >> The related error with allmodconfig: >> >> CC arch/blackfin/mach-common/arch_checks.o >> arch/blackfin/mach-common/arch_checks.c:24:3: error: #error "Sclk value >> selected is less than minimum. Please select a proper value for SCLK >> multiplier" >># error "Sclk value selected is less than minimum. Please select a proper >> value for SCLK multiplier" >> ^ >> arch/blackfin/mach-common/arch_checks.c:28:3: error: #error "ANOMALY >> 05000273, please make sure CCLK is at least 2x SCLK" >># error "ANOMALY 05000273, please make sure CCLK is at least 2x SCLK" >> ^ >> arch/blackfin/mach-common/arch_checks.c:51:3: error: #error the MPU will >> not function safely while Anomaly 05000263 applies >># error the MPU will not function safely while Anomaly 05000263 applies >> ^ >> >> config PLL_BYPASS >> bool "Bypass PLL" >> - depends on BFIN_KERNEL_CLOCK && (!BF60x) >> + depends on BFIN_KERNEL_CLOCK && (!BF60x) && ((!BF533) || BF_REV_0_6) >> default n >> >> config CLKIN_HALF >> @@ -1112,6 +1112,7 @@ endchoice >> comment "Memory Protection Unit" >> config MPU >> bool "Enable the memory protection unit" >> + depends on (!BF533) || BF_REV_0_6 || BF_REV_0_5 >> default n >> help >> Use the processor's MPU to protect applications from accessing > > This answers my question wrt. allmodconfig. ;) > I'm not sure if this is the correct way. Isn't this the reason why we > have COMPILE_TEST? > For me, COMPILE_TEST is for compiling test without the related hardware supports, but the code should no any logical issues firstly (at least, COMPILE_TEST itself should not generate additional logical bugs). In our case, I guess the first 2 issues are about logical issues (not hardware supporting issues), so I guess, it is not suitable to use COMPILE_TEST to bypass them. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net: dsa: fix filling routing table from OF description
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.
However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.
This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.
To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.
This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: Pavel Nakonechny
Reviewed-by: Andrew Lunn
---
Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 +++-
net/dsa/dsa.c | 23 +++
2 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt
b/Documentation/devicetree/bindings/net/dsa/dsa.txt
index a62c889..e25e58d 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.txt
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt
@@ -19,7 +19,9 @@ the parent DSA node. The maximum number of allowed child
nodes is 4
(DSA_MAX_SWITCHES).
Each of these switch child nodes should have the following required properties:
-- reg : Describes the switch address on the MII bus
+- reg : Contains two fields. The first one describes the
+ address on the MII bus. The second is the switch
+ number that must be unique in cascaded configurations
- #address-cells : Must be 1
- #size-cells : Must be 0
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 947f550..1d56f84 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -375,12 +375,10 @@ static struct net_device *dev_to_net_device(struct device
*dev)
#ifdef CONFIG_OF
static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
struct dsa_chip_data *cd,
- int chip_index,
+ int chip_index, int port_index,
struct device_node *link)
{
- int ret;
const __be32 *reg;
- int link_port_addr;
int link_sw_addr;
struct device_node *parent_sw;
int len;
@@ -393,6 +391,10 @@ static int dsa_of_setup_routing_table(struct
dsa_platform_data *pd,
if (!reg || (len != sizeof(*reg) * 2))
return -EINVAL;
+ /*
+* Get the destination switch number from the second field of its 'reg'
+* property, i.e. for "reg = <0x19 1>" sw_addr is '1'.
+*/
link_sw_addr = be32_to_cpup(reg + 1);
if (link_sw_addr >= pd->nr_chips)
@@ -409,20 +411,9 @@ static int dsa_of_setup_routing_table(struct
dsa_platform_data *pd,
memset(cd->rtable, -1, pd->nr_chips * sizeof(s8));
}
- reg = of_get_property(link, "reg", NULL);
- if (!reg) {
- ret = -EINVAL;
- goto out;
- }
-
- link_port_addr = be32_to_cpup(reg);
-
- cd->rtable[link_sw_addr] = link_port_addr;
+ cd->rtable[link_sw_addr] = port_index;
return 0;
-out:
- kfree(cd->rtable);
- return ret;
}
static void dsa_of_free_platform_data(struct dsa_platform_data *pd)
@@ -528,7 +519,7 @@ static int dsa_of_probe(struct platform_device *pdev)
if (!strcmp(port_name, "dsa") && link &&
pd->nr_chips > 1) {
ret = dsa_of_setup_routing_table(pd, cd,
- chip_index, link);
+ chip_index, port_index, link);
if (ret)
goto out_free_chip;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] vfs: check kiocb->ki_flags instead filp->fl_flags
On Sat, Apr 04, 2015 at 11:13:11PM +0400, Dmitry Monakhov wrote: > generic_write_checks now accept kiocb as an argument > Unfortunetly it is impossible to get rid of old interface because some crappy > do not support write_iter interface so leave __generic_write_checks as > backward > compatibility helper. Check the current vfs.git#for-next (there's even some generic_write_checks() work in it). The same goes for the rest of the series. Please, rebase it. What's more, generic_write_checks() should take iov_iter *, not the address of something its ->count had been copied into. Note that all callers of that thing end up doing iov_iter_truncate() pretty soon afterwards. I hadn't pushed that one out yet (there is some weirdness in ocfs2 which might be a bug; I want to sort that out first), but that's where it's going. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: Makefile: Add -D__linux__ flag for KBUILD_CFLAGS
On 4/5/15 05:17, Richard Weinberger wrote: > Am 04.04.2015 um 23:13 schrieb Chen Gang: >> Is what I have done above correct? Or can we treate it as gcc's issue? > > At least ask gcc folks about that before you add a random hack to the kernel. > For the latest compiler, it should contents -D__linux__, and what I have done for building gcc/binutils is the common way, so I guess binutils or gcc need improvement (I shall try to fix it within this month). But, I am not quite sure whether the old version bfin compilers also supports -D__linux__ (comparing some of the old compilers of the other archs, I guess not). Are you sure the old version bfin compilers are OK? BTW, for the latest bfin compiler from upstream, it contents another issues which I bypassed now. I shall try to fix them within this month (try to send all fix patches v1 within 2015-04-20). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: samples: kdbus: kdbus-workers: Define dummy prime_new()
On 4/4/15 06:42, Richard Weinberger wrote: > On Sat, Apr 4, 2015 at 12:17 AM, Chen Gang > wrote: >> Quite a few of architures (e.g. blackfin, cris, frv ...) do not support >> memfd_create system call which is used in prime_new(). So define a dummy >> one. > > Don't paper over the issue, just wire up the system call on blackfin. > > For an example see: > commit f3240c1f6d18591b2c1ef33ed18d5ca91e62c104 > Author: Hans-Christian Egtvedt > Date: Thu Dec 25 19:58:50 2014 +0100 > > avr32: wire up missing syscalls > OK, thanks. I shall try to send patch v2 for it within this month. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: Makefile: Add -D__linux__ flag for KBUILD_CFLAGS
Am 04.04.2015 um 23:13 schrieb Chen Gang: > Is what I have done above correct? Or can we treate it as gcc's issue? At least ask gcc folks about that before you add a random hack to the kernel. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blackfin: Makefile: Add -D__linux__ flag for KBUILD_CFLAGS
On 4/4/15 06:56, Richard Weinberger wrote: > On Fri, Apr 3, 2015 at 10:19 PM, Chen Gang > wrote: >> The related error with allmodconfig: > > BTW: How do you generate this allmodconfig? > "make allmodconfig ARCH=blackfin" cannot work as you need to specify a > board... > [...] > Hmm, what compiler are you using? > It's odd that __linux__ is not defined... > I built the raw cross compiler from the latest gcc/binutils's upsteam code: - binutils: ../binutils-gdb/configure --prefix=/upstream/release-blackfin --target=bfin-gchen-elf --disable-nls --with-sysroot=/upstream/release-blackfin --without-headers target_alias=bfin-gchen-elf make && make install [root@localhost build-binutils-blackfin]# /upstream/release-blackfin/bin/bfin-gchen-elf-ld -v GNU ld (GNU Binutils) 2.25.51.20150401 - gcc: ../gcc-blackfin/configure --target=bfin-gchen-elf --disable-nls --disable-threads --disable-shared --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin --without-headers target_alias=bfin-gchen-elf --enable-languages=c,lto make all-gcc && make all-target-libgcc && make install [root@localhost build-binutils-blackfin]# /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -v Using built-in specs. COLLECT_GCC=/upstream/release-blackfin/bin/bfin-gchen-elf-gcc COLLECT_LTO_WRAPPER=/upstream/release-blackfin/libexec/gcc/bfin-gchen-elf/5.0.0/lto-wrapper Target: bfin-gchen-elf Configured with: ../gcc-blackfin/configure --target=bfin-gchen-elf --disable-nls --disable-threads --disable-shared --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin --without-headers target_alias=bfin-gchen-elf --enable-languages=c,lto Thread model: single gcc version 5.0.0 20150401 (experimental) (GCC) - kernel using: make ARCH=blackfin CROSS_COMPILE=/upstream/release-blackfin/bin/bfin-gchen-elf- Is what I have done above correct? Or can we treate it as gcc's issue? Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86/alternatives: Guard NOPs optimization
From: Borislav Petkov
Take a look at the first insn byte before optimizing the NOP -
there might be something else already, like the ALTERNATIVE_2() in
rdtsc_barrier() which nops out on AMD even though we just patched in an
MFENCE.
This happens because the alternatives sees X86_FEATURE_MFENCE_RDTSC,
AMD CPUs set it, we patch in the MFENCE and right afterwards it sees
X86_FEATURE_LFENCE_RDTSC which AMD CPUs don't set and we blindly
optimize the NOP.
Checking whether at least the first byte is 0x90 prevents that.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/alternative.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 7c4ad005d7a0..aef653193160 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -325,6 +325,9 @@ done:
static void __init_or_module optimize_nops(struct alt_instr *a, u8 *instr)
{
+ if (instr[0] != 0x90)
+ return;
+
add_nops(instr + (a->instrlen - a->padlen), a->padlen);
DUMP_BYTES(instr, a->instrlen, "%p: [%d:%d) optimized NOPs: ",
--
2.3.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] net: dsa: fix filling rtable from OF description
On Sat, Apr 04, 2015 at 04:48:48PM +0300, Pavel Nakonechny wrote:
> According to description in 'include/net/dsa.h', in cascade switches
> configurations where there are more than one interconnected devices,
> 'rtable' array in 'dsa_chip_data' structure is used to indicate which
> port on this switch should be used to send packets to that are destined
> for corresponding switch.
>
> However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
> of the _target_ switch, but not current one.
>
> This commit removes redundant devicetree parsing and adds needed port
> number as a function argument. So dsa_of_setup_routing_table() now just
> looks for target switch number by parsing parent of 'link' device node.
>
> This was tested on custom board with two Marvell 88E6095 switches with
> following corresponding rtables: { -1, 10 } and { 8, -1 }.
>
> Signed-off-by: Pavel Nakonechny
Hi Pavel
Reviewed-by: Andrew Lunn
As i said in my other email, it would be nice to add a comment about
the switch number being the second value in reg.
Andrew
> ---
> net/dsa/dsa.c | 19 +++
> 1 file changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 947f550..5593a0d 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -375,12 +375,10 @@ static struct net_device *dev_to_net_device(struct
> device *dev)
> #ifdef CONFIG_OF
> static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
> struct dsa_chip_data *cd,
> - int chip_index,
> + int chip_index, int port_index,
> struct device_node *link)
> {
> - int ret;
> const __be32 *reg;
> - int link_port_addr;
> int link_sw_addr;
> struct device_node *parent_sw;
> int len;
> @@ -409,20 +407,9 @@ static int dsa_of_setup_routing_table(struct
> dsa_platform_data *pd,
> memset(cd->rtable, -1, pd->nr_chips * sizeof(s8));
> }
>
> - reg = of_get_property(link, "reg", NULL);
> - if (!reg) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> - link_port_addr = be32_to_cpup(reg);
> -
> - cd->rtable[link_sw_addr] = link_port_addr;
> + cd->rtable[link_sw_addr] = port_index;
>
> return 0;
> -out:
> - kfree(cd->rtable);
> - return ret;
> }
>
> static void dsa_of_free_platform_data(struct dsa_platform_data *pd)
> @@ -528,7 +515,7 @@ static int dsa_of_probe(struct platform_device *pdev)
> if (!strcmp(port_name, "dsa") && link &&
> pd->nr_chips > 1) {
> ret = dsa_of_setup_routing_table(pd, cd,
> - chip_index, link);
> + chip_index, port_index, link);
> if (ret)
> goto out_free_chip;
> }
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/7] tracing: Add 'hist' event trigger command
On Sat, 2015-04-04 at 22:56 +0200, Paul Bolle wrote:
> Tom Zanussi schreef op za 04-04-2015 om 15:09 [-0500]:
> > [PATCH] kallsyms: Include module.h
> >
> > KSYM_SYMBOL_LEN references MODULE_NAME_LEN, defined in module.h, so
> > have kallsyms.h include module.h instead of expecting kallsysms users
> > to do it.
> >
> > Also fix up existing kallsyms users that apparently include module.h
> > for only that reason.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> > include/linux/ftrace.h | 1 -
> > include/linux/kallsyms.h | 1 +
> > kernel/trace/trace_events_hist.c | 2 +-
> > kernel/trace/trace_kprobe.c | 1 +
> > kernel/trace/trace_output.c | 1 +
> > kernel/trace/trace_syscalls.c| 2 +-
> > 6 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 1da6029..8554dd5 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -7,7 +7,6 @@
> > #define _LINUX_FTRACE_H
> >
> > #include
> > -#include
> > #include
> > #include
> > #include
>
> The commit explanation is silent about this change. Are you sure you
> want to include it?
>
Probably, but I'll mention in the changelog. I'll submit a complete
patch with my updated patchset (after looking around for other includes
of module.h to add).
> > diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
> > index 6883e19..e1550a4 100644
> > --- a/include/linux/kallsyms.h
> > +++ b/include/linux/kallsyms.h
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define KSYM_NAME_LEN 128
> > #define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1)
> > + \
> > diff --git a/kernel/trace/trace_events_hist.c
> > b/kernel/trace/trace_events_hist.c
> > index 3d648ee..c290379 100644
> > --- a/kernel/trace/trace_events_hist.c
> > +++ b/kernel/trace/trace_events_hist.c
> > @@ -20,7 +20,7 @@
> > * http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf
> > */
> >
> > -#include
> > +#include
> > #include
> > #include
> > #include
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index 9ba3f43..39019ec 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -19,6 +19,7 @@
> >
> > #include
>
> Note to self: needed for "struct module". But this file has two
> references to THIS_MODULE that look useless.
>
> > #include
> > +#include
> >
> > #include "trace_probe.h"
> >
> > diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> > index 692bf71..5ec310e 100644
> > --- a/kernel/trace/trace_output.c
> > +++ b/kernel/trace/trace_output.c
> > @@ -8,6 +8,7 @@
> > #include
>
> Can't this be dropped too?
>
Yeah, of course that's the whole point, which I missed here ;-)
Tom
> > #include
> > #include
> > +#include
> >
> > #include "trace_output.h"
> >
> > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> > index d137e0a..72af617 100644
> > --- a/kernel/trace/trace_syscalls.c
> > +++ b/kernel/trace/trace_syscalls.c
> > @@ -3,7 +3,7 @@
> > #include
> > #include
> > #include
> > -#include /* for MODULE_NAME_LEN via KSYM_SYMBOL_LEN */
> > +#include
> > #include
> > #include
> > #include
>
> Thanks,
>
>
> Paul Bolle
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: dsa: fix filling rtable from OF description
On Sat, Apr 04, 2015 at 08:10:09PM +0300, Pavel Nakonechny wrote:
> Hi Andrew
>
> ?? 4 2015 18:38:14
> Andrew Lunn ??:
> > There is the code after applying your patch:
> >
> > static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
> > struct dsa_chip_data *cd,
> > int chip_index, int port_index,
> > struct device_node *link)
> > {
> > const __be32 *reg;
> > int link_sw_addr;
> > struct device_node *parent_sw;
> > int len;
> >
> > parent_sw = of_get_parent(link);
> > if (!parent_sw)
> > return -EINVAL;
> >
> > link is the phandle to the port in other switch. parent_sw is then the
> > switch property.
> yep
>
> > reg = of_get_property(parent_sw, "reg", );
> > if (!reg || (len != sizeof(*reg) * 2))
> > return -EINVAL;
> >
> > So now you get the reg property. This is documented as:
> >
> > - reg : Describes the switch address on the MII bus
> Yes, but read further in the entry example:
> "reg = <16 0>;/* MDIO address 16, switch 0 in tree */"
Ah!
O.K. Please add a comment. If i read this wrong, it is quite likely
somebody else will also read this wrong.
I think it would also be good to add some text to dsa.txt explaining
this second field in reg.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/7] tracing: Add 'hist' event trigger command
Tom Zanussi schreef op za 04-04-2015 om 15:09 [-0500]:
> [PATCH] kallsyms: Include module.h
>
> KSYM_SYMBOL_LEN references MODULE_NAME_LEN, defined in module.h, so
> have kallsyms.h include module.h instead of expecting kallsysms users
> to do it.
>
> Also fix up existing kallsyms users that apparently include module.h
> for only that reason.
>
> Signed-off-by: Tom Zanussi
> ---
> include/linux/ftrace.h | 1 -
> include/linux/kallsyms.h | 1 +
> kernel/trace/trace_events_hist.c | 2 +-
> kernel/trace/trace_kprobe.c | 1 +
> kernel/trace/trace_output.c | 1 +
> kernel/trace/trace_syscalls.c| 2 +-
> 6 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 1da6029..8554dd5 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -7,7 +7,6 @@
> #define _LINUX_FTRACE_H
>
> #include
> -#include
> #include
> #include
> #include
The commit explanation is silent about this change. Are you sure you
want to include it?
> diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
> index 6883e19..e1550a4 100644
> --- a/include/linux/kallsyms.h
> +++ b/include/linux/kallsyms.h
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #define KSYM_NAME_LEN 128
> #define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1) +
> \
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index 3d648ee..c290379 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -20,7 +20,7 @@
> * http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf
> */
>
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 9ba3f43..39019ec 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -19,6 +19,7 @@
>
> #include
Note to self: needed for "struct module". But this file has two
references to THIS_MODULE that look useless.
> #include
> +#include
>
> #include "trace_probe.h"
>
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index 692bf71..5ec310e 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -8,6 +8,7 @@
> #include
Can't this be dropped too?
> #include
> #include
> +#include
>
> #include "trace_output.h"
>
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index d137e0a..72af617 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -3,7 +3,7 @@
> #include
> #include
> #include
> -#include /* for MODULE_NAME_LEN via KSYM_SYMBOL_LEN */
> +#include
> #include
> #include
> #include
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sound: Use const struct ac97_quirk
Use const to reduce data by ~3Kb.
Signed-off-by: Joe Perches
---
include/sound/ac97_codec.h | 4 +++-
sound/pci/ac97/ac97_codec.c | 3 ++-
sound/pci/ad1889.c | 2 +-
sound/pci/atiixp.c | 2 +-
sound/pci/cs5535audio/cs5535audio.c | 2 +-
sound/pci/intel8x0.c| 2 +-
sound/pci/via82xx.c | 2 +-
7 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/include/sound/ac97_codec.h b/include/sound/ac97_codec.h
index d315a08..0e9d75b 100644
--- a/include/sound/ac97_codec.h
+++ b/include/sound/ac97_codec.h
@@ -608,7 +608,9 @@ struct ac97_quirk {
int type; /* quirk type above */
};
-int snd_ac97_tune_hardware(struct snd_ac97 *ac97, struct ac97_quirk *quirk,
const char *override);
+int snd_ac97_tune_hardware(struct snd_ac97 *ac97,
+ const struct ac97_quirk *quirk,
+ const char *override);
int snd_ac97_set_rate(struct snd_ac97 *ac97, int reg, unsigned int rate);
/*
diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
index 5bca1a3..82259ca 100644
--- a/sound/pci/ac97/ac97_codec.c
+++ b/sound/pci/ac97/ac97_codec.c
@@ -2902,7 +2902,8 @@ static int apply_quirk_str(struct snd_ac97 *ac97, const
char *typestr)
* Return: Zero if successful, or a negative error code on failure.
*/
-int snd_ac97_tune_hardware(struct snd_ac97 *ac97, struct ac97_quirk *quirk,
const char *override)
+int snd_ac97_tune_hardware(struct snd_ac97 *ac97,
+ const struct ac97_quirk *quirk, const char *override)
{
int result;
diff --git a/sound/pci/ad1889.c b/sound/pci/ad1889.c
index 850a8c9..66ddd98 100644
--- a/sound/pci/ad1889.c
+++ b/sound/pci/ad1889.c
@@ -747,7 +747,7 @@ snd_ad1889_proc_init(struct snd_ad1889 *chip)
snd_info_set_text_ops(entry, chip, snd_ad1889_proc_read);
}
-static struct ac97_quirk ac97_quirks[] = {
+static const struct ac97_quirk ac97_quirks[] = {
{
.subvendor = 0x11d4,/* AD */
.subdevice = 0x1889,/* AD1889 */
diff --git a/sound/pci/atiixp.c b/sound/pci/atiixp.c
index d5f15c9..42a20c8 100644
--- a/sound/pci/atiixp.c
+++ b/sound/pci/atiixp.c
@@ -1390,7 +1390,7 @@ static irqreturn_t snd_atiixp_interrupt(int irq, void
*dev_id)
* ac97 mixer section
*/
-static struct ac97_quirk ac97_quirks[] = {
+static const struct ac97_quirk ac97_quirks[] = {
{
.subvendor = 0x103c,
.subdevice = 0x006b,
diff --git a/sound/pci/cs5535audio/cs5535audio.c
b/sound/pci/cs5535audio/cs5535audio.c
index 802c33f..963b912 100644
--- a/sound/pci/cs5535audio/cs5535audio.c
+++ b/sound/pci/cs5535audio/cs5535audio.c
@@ -43,7 +43,7 @@ static char *ac97_quirk;
module_param(ac97_quirk, charp, 0444);
MODULE_PARM_DESC(ac97_quirk, "AC'97 board specific workarounds.");
-static struct ac97_quirk ac97_quirks[] = {
+static const struct ac97_quirk ac97_quirks[] = {
#if 0 /* Not yet confirmed if all 5536 boards are HP only */
{
.subvendor = PCI_VENDOR_ID_AMD,
diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
index 2c5484e..749069a 100644
--- a/sound/pci/intel8x0.c
+++ b/sound/pci/intel8x0.c
@@ -1795,7 +1795,7 @@ static struct ac97_pcm ac97_pcm_defs[] = {
},
};
-static struct ac97_quirk ac97_quirks[] = {
+static const struct ac97_quirk ac97_quirks[] = {
{
.subvendor = 0x0e11,
.subdevice = 0x000e,
diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
index 8622283..3dd038b 100644
--- a/sound/pci/via82xx.c
+++ b/sound/pci/via82xx.c
@@ -1812,7 +1812,7 @@ static void snd_via82xx_mixer_free_ac97(struct snd_ac97
*ac97)
chip->ac97 = NULL;
}
-static struct ac97_quirk ac97_quirks[] = {
+static const struct ac97_quirk ac97_quirks[] = {
{
.subvendor = 0x1106,
.subdevice = 0x4161,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CAN I TRUST YOU?
Dear Sir/Madam, I am Godwin Emefiele, The new Governor Central Bank of Nigeria. My office controls and monitors the affairs of all other banks in Nigeria. I am the final signatory to any transfer both on local and international levels. I have a beneficial deal for you. I am aware that this letter has come to you as a surprise as we have not met before or handled any business deal in the past. Nevertheless, I have contacted you with good faith and genuine intentions, and I hope I can trust you with this fund which I will explain to you immediately I hear from you. To facilitate the process of this transaction, kindly respond to me through my personal email address below. Best regards, Godwin Emefiele. E-mail: godwinemefielespriv...@accountant.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/7] tracing: Add 'hist' event trigger command
On Sat, 2015-04-04 at 08:36 -0700, Alexei Starovoitov wrote:
> On Fri, Apr 3, 2015 at 8:51 AM, Tom Zanussi
> wrote:
> > +static struct hist_trigger_entry *
> > +tracing_map_insert(struct tracing_map *map, void *key)
> > +{
> > + u32 idx, key_hash, test_key;
> > +
> > + key_hash = jhash(key, map->key_size, 0);
> > + idx = key_hash >> (32 - (map->map_bits + 1));
> > +
> > + while (1) {
> > + idx &= (map->map_size - 1);
> > + test_key = map->map[idx].key;
> > +
> > + if (test_key && test_key == key_hash &&
> > + keys_match(key, map->map[idx].val->key, map->key_size))
> > + return map->map[idx].val;
> > +
> > + if (!test_key && !cmpxchg(>map[idx].key, 0, key_hash))
> > {
> > + struct hist_trigger_entry *entry;
> > +
> > + entry = hist_trigger_entry_create(map);
> > + if (!entry)
> > + break;
> > + memcpy(entry->key, key, map->key_size);
> > + map->map[idx].val = entry;
> > +
> > + return map->map[idx].val;
> > + }
>
> There is obvious race here, since algorithm is not implemented correctly.
> Partially inserted key/value is not handled.
You're right, thanks for pointing it out.
I guess adding '&& map->map[idx].val && keys_match(...' would fix the
problem, but would result in duplicate entries for the same key, which I
wanted to avoid.
My original code didn't even have that keys_match() check, which is only
there for the rare possibility of a key collision - I originally just
set a flag in that case, which was printed out with the run results. In
all my testing I only ever saw it once, so I know it happens very
rarely, but it does happen, and the flag lets the user know and to maybe
try again (my second run of the same test didn't show a collision). I
thought of actually tracking the collisions as well, since they're so
rare, but didn't see that it was worth the bother. Using a 64-bit hash
would make it even more remote, but again, is it necessary in practice?
So I think there are several solutions - I'll probably just keep things
simple and go back to a collision flag..
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/7] tracing: Add 'hist' event trigger command
On Sat, 2015-04-04 at 17:14 +0200, Paul Bolle wrote:
> What follows are a bunch of questions, and not really review remarks,
> triggered by the fact that is included here for reasons
> that were not really obvious when scanning the patch.
>
> TL,DR:
> - why does trace_events_hist.c include ?
> - why doesn't include instead?
> - why does still include ?
> - and why doesn't trace_events_hist.c include
> directly instead?
>
> Even shorter: shouldn't these files include the headers they need
> directly and not rely on other headers to pull them in?
>
All good questions - not sure why linux/kallsyms.h doesn't include
module.h, which would solve the problem.
> On Fri, 2015-04-03 at 10:51 -0500, Tom Zanussi wrote:
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
>
> > +config HIST_TRIGGERS
> > + bool "Histogram triggers"
> > + depends on ARCH_HAVE_NMI_SAFE_CMPXCHG
> > + help
> > + [...]
>
> > --- a/kernel/trace/Makefile
> > +++ b/kernel/trace/Makefile
>
> > +obj-$(CONFIG_HIST_TRIGGERS) += trace_events_hist.o
>
> To make sure I'm parsing this Makefile correctly: trace_events_hist.o
> will never be part of a module, right?
>
Right.
> > --- /dev/null
> > +++ b/kernel/trace/trace_events_hist.c
>
> > +#include
>
> When scanning this patch I wondered why this include was needed. Because
> this file will never be part of a module and I can't spot anything
> obviously module related in the code.
>
> But deleting that include triggers errors when building
> trace_events_hist.o:
> In file included from include/linux/ftrace.h:10:0,
> from kernel/trace/trace.h:12,
> from kernel/trace/trace_events_hist.c:30:
> kernel/trace/trace_events_hist.c: In function
> ‘hist_trigger_stacktrace_print’:
> include/linux/kallsyms.h:14:31: error: ‘MODULE_NAME_LEN’ undeclared
> (first use in this function)
> 2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + 1)
>^
> kernel/trace/trace_events_hist.c:901:11: note: in expansion of macro
> ‘KSYM_SYMBOL_LEN’
> char str[KSYM_SYMBOL_LEN];
>^
> include/linux/kallsyms.h:14:31: note: each undeclared identifier is
> reported only once for each function it appears in
> 2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + 1)
>^
> [...]
>
> Looking into that I noticed that doesn't include
> , even though it uses MODULE_NAME_LEN. So shouldn't it
> include that header too?
>
> The error I quoted above shows that is included
> indirectly (via "trace.h" and ). But
> itself doesn't use anything from [0]. So I wonder why
> still includes . Just so that other
> files can rely on it to be pulled in if they include ?
>
> See for instance trace_events_hist.c, which I'm discussing here. It uses
> things like KSYM_SYMBOL_LEN, so shouldn't it include
> directly instead of relying of to do so on its behalf?
>
>
Yes, so something like the below could be a start, which fixes up the
problem for trace, but misses a lot of potential others, such as this
obvious one from lib/vsprintf.c?:
#include /* for KSYM_SYMBOL_LEN */
[PATCH] kallsyms: Include module.h
KSYM_SYMBOL_LEN references MODULE_NAME_LEN, defined in module.h, so
have kallsyms.h include module.h instead of expecting kallsysms users
to do it.
Also fix up existing kallsyms users that apparently include module.h
for only that reason.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace.h | 1 -
include/linux/kallsyms.h | 1 +
kernel/trace/trace_events_hist.c | 2 +-
kernel/trace/trace_kprobe.c | 1 +
kernel/trace/trace_output.c | 1 +
kernel/trace/trace_syscalls.c| 2 +-
6 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1da6029..8554dd5 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -7,7 +7,6 @@
#define _LINUX_FTRACE_H
#include
-#include
#include
#include
#include
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 6883e19..e1550a4 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#define KSYM_NAME_LEN 128
#define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s]") + (KSYM_NAME_LEN - 1) + \
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 3d648ee..c290379 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -20,7 +20,7 @@
* http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf
*/
-#include
+#include
#include
#include
#include
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9ba3f43..39019ec 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include "trace_probe.h"
diff --git
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
On Sat, Apr 04, 2015 at 07:11:16PM +0200, Pavel Machek wrote: > Hi! > > > enable-gpios: Specifier of the GPIO connected to EN pin > > > > I can make the changes if you're ok with that, otherwise please send v7. > > Then > > I'll apply that to my tree. > > I'm ok with that. Thanks. The patch is applied here: git://linuxtv.org/sailus/media_tree.git, branch adp1653 -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI: Introduce pci_bus_addr_t
On Sat, Apr 4, 2015 at 7:46 AM, Bjorn Helgaas wrote:
> On Fri, Apr 3, 2015 at 10:34 PM, Yinghai Lu wrote:
>> On Fri, Apr 3, 2015 at 1:52 PM, Bjorn Helgaas wrote:
>>> [+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
>>> linux-mips, Ben, linuxppc-dev, x86]
>>>
>>> On Fri, Apr 03, 2015 at 02:32:34PM -0500, Bjorn Helgaas wrote:
On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
> David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
> to fit in upstream windows") broke booting on sparc/T5-8.
>
> In the boot log, there is
> pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
> 0x110204000)
> but that only could happen when dma_addr_t is 32-bit.
>
> According to David Miller, all DMA occurs behind an IOMMU and these
> IOMMUs only support 32-bit addressing, therefore dma_addr_t is
> 32-bit on sparc64.
>
> Let's introduce pci_bus_addr_t instead of using dma_addr_t,
> and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
>
> Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in
> upstream windows")
> Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs
> larger than 4GB")
> Link:
> http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
> Reported-by: David Ahern
> Tested-by: David Ahern
> Signed-off-by: Yinghai Lu
> Cc: #3.19
> ---
> drivers/pci/Kconfig | 4
> drivers/pci/bus.c | 10 +-
> drivers/pci/probe.c | 12 ++--
> include/linux/pci.h | 12 +---
> 4 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 7a8f1c5..6a5a269 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,6 +1,10 @@
> #
> # PCI configuration
> #
> +config PCI_BUS_ADDR_T_64BIT
> + def_bool y if (64BIT || X86_PAE)
> + depends on PCI
We're going to use pci_bus_addr_t in some places where we previously used
dma_addr_t, which means pci_bus_addr_t should be at least as large as
dma_addr_t. Can you enforce that directly, e.g., with something like this?
def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT || X86_PAE)
>>
>> then should use
>>
>> def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>
> OK, would you mind updating this series, incorporating the doc
> updates, and reposting it?
>
> I think there's still an unresolved question about the OF parsing code.
Got a pointer to what that is? I'll take a guess. Generally, we make
the parsing code independent of the kernel addr sizes and use u64
types. The DT sizes and kernel sizes are not always aligned. For
example, an LPAE capable platform running a non-LPAE kernel build.
Rob
>
> Bjorn
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: sm7xxfb: Fix sparse warning
On Sat, 4 Apr 2015, Nickolaus Woodruff wrote:
> This patch fixes the following sparse warning in sm7xx.h:
>
> drivers/staging/sm7xxfb/sm7xx.h:122:17: warning: symbol 'vgamode'
> was not declared. Should it be static?
>
> Signed-off-by: Nickolaus Woodruff
> ---
> drivers/staging/sm7xxfb/sm7xx.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
> index 7cc1896..c5d6253 100644
> --- a/drivers/staging/sm7xxfb/sm7xx.h
> +++ b/drivers/staging/sm7xxfb/sm7xx.h
> @@ -119,7 +119,7 @@ struct ModeInit {
> /**
>SM712 Mode table.
> **/
> -struct ModeInit vgamode[] = {
> +static struct ModeInit vgamode[] = {
Someone already fixed this:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/sm7xxfb/sm7xx.h?h=staging-testing#n122
Please work against staging-testing branch of the staging tree.
Su pagarba / Regards,
Giedrius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: sm7xxfb: Fix sparse warning
This patch fixes the following sparse warning in sm7xx.h:
drivers/staging/sm7xxfb/sm7xx.h:122:17: warning: symbol 'vgamode'
was not declared. Should it be static?
Signed-off-by: Nickolaus Woodruff
---
drivers/staging/sm7xxfb/sm7xx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 7cc1896..c5d6253 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -119,7 +119,7 @@ struct ModeInit {
/**
SM712 Mode table.
**/
-struct ModeInit vgamode[] = {
+static struct ModeInit vgamode[] = {
{
/* mode#0: 640 x 480 16Bpp 60Hz */
640, 480, 16, 60,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: dts: Add binding for Broadcom MSPI driver.
Le 02/04/2015 12:23, Jonathan Richardson a écrit :
>
> Signed-off-by: Jonathan Richardson
> ---
> .../devicetree/bindings/spi/brcm,mspi-spi.txt | 38
>
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> new file mode 100644
> index 000..16164e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> @@ -0,0 +1,38 @@
> +Broadcom MSPI controller
> +
> +Required properties:
> +- compatible: Must be either "brcm,mspi" or "brcm,bcma-mspi". Use
> + "brcm,bcma-mspi" for controllers on a bcma bus and "brcm,mspi" otherwise.
We need a more specific compatible property here since there are at
least 3 known SoCs families within Broadcom (Cygnus, BCM53xx, BCM7xxx)
that use this controller, also older versions of the core did not have a
revision register, yet they had an internal version numbering that we
might want to reflect here. This does not need to be fixed immediately
though, we can add compatible strings as we start adding support for
older cores.
> +
> +- reg: Physical base address and length of the controller's registers.
> +
> +- interrupts: The interrupt id for the controller.
I think this should be two cells, on BCM7xxx chips there is a MSPI_DONE
and a MSPI_ERROR interrupt bit, we typically only use the first one, but
since we are describing the hardware here, we need to be exhaustive.
> +
> +- #address-cells: should be 1.
> +
> +- #size-cells: should be 0.
> +
> +Optional properties:
> +- clocks: The MSPI reference clock. If not provided then it is assumed a
> clock
> + is enabled by default and no control of clock-frequency (see below) is
> + possible.
> +
> +- clock-names: The name of the reference clock.
> +
> +- clock-frequency: Desired frequency of the clock. This will set the serial
> + clock baud rate (SPBR) based on the reference clock frequency. The
> frequency
> + of the SPBR is mspi_clk / (2 * SPBR) where SPBR is a value between 1-255
> + determined by the desired 'clock-frequency'. If not provided then the
> default
> + baud rate of the controller is used.
See my reply to the patch 4, that does not seem to match the
"clock-frequency" vs. clock phandles practices in DT.
> +
> +Example:
> +
> +mspi@18047000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "brcm,mspi";
> + reg = <0x18047000 0x1000>;
> + clocks = <_clk>;
> + clock-names = "mspi_clk";
> + clock-frequency = <1250>;
Since "interrupts" is a mandatory property you might want the example to
show it for consistency.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/16] vfs: check kiocb->ki_flags instead filp->fl_flags
generic_write_checks now accept kiocb as an argument
Unfortunetly it is impossible to get rid of old interface because some crappy
do not support write_iter interface so leave __generic_write_checks as backward
compatibility helper.
Signed-off-by: Dmitry Monakhov
---
include/linux/fs.h |8 +++-
mm/filemap.c | 13 +++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4c20030..992685e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2570,7 +2570,7 @@ extern int sb_min_blocksize(struct super_block *, int);
extern int generic_file_mmap(struct file *, struct vm_area_struct *);
extern int generic_file_readonly_mmap(struct file *, struct vm_area_struct *);
-int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int
isblk);
+int __generic_write_checks(struct file * file, loff_t *pos, size_t *count, int
isblk, int append);
extern ssize_t generic_file_read_iter(struct kiocb *, struct iov_iter *);
extern ssize_t __generic_file_write_iter(struct kiocb *, struct iov_iter *);
extern ssize_t generic_file_write_iter(struct kiocb *, struct iov_iter *);
@@ -2798,6 +2798,12 @@ static inline bool is_nonblock_kiocb(struct kiocb *kiocb)
return kiocb->ki_flags & IOCB_NONBLOCK;
}
+static inline int generic_write_checks(struct kiocb *iocb, loff_t *pos, size_t
*count, int isblk)
+{
+ return __generic_write_checks(iocb->ki_filp, pos, count, isblk,
+ is_append_kiocb(iocb));
+}
+
/* XXX: this is obsolete helper, and will be removed soon.
* One should use io_direct_kiocb() instead */
static inline bool io_is_direct(struct file *filp)
diff --git a/mm/filemap.c b/mm/filemap.c
index 876f4e6..b519824 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1694,7 +1694,7 @@ generic_file_read_iter(struct kiocb *iocb, struct
iov_iter *iter)
loff_t *ppos = >ki_pos;
loff_t pos = *ppos;
- if (io_is_direct(file)) {
+ if (is_direct_kiocb(iocb)) {
struct address_space *mapping = file->f_mapping;
struct inode *inode = mapping->host;
size_t count = iov_iter_count(iter);
@@ -2260,7 +2260,8 @@ EXPORT_SYMBOL(read_cache_page_gfp);
* Returns appropriate error code that caller should return or
* zero in case that write should be allowed.
*/
-inline int generic_write_checks(struct file *file, loff_t *pos, size_t *count,
int isblk)
+inline int __generic_write_checks(struct file *file, loff_t *pos, size_t
*count,
+ int isblk, int is_append)
{
struct inode *inode = file->f_mapping->host;
unsigned long limit = rlimit(RLIMIT_FSIZE);
@@ -2270,7 +2271,7 @@ inline int generic_write_checks(struct file *file, loff_t
*pos, size_t *count, i
if (!isblk) {
/* FIXME: this is for backwards compatibility with 2.4 */
- if (file->f_flags & O_APPEND)
+ if (is_append)
*pos = i_size_read(inode);
if (limit != RLIM_INFINITY) {
@@ -2333,7 +2334,7 @@ inline int generic_write_checks(struct file *file, loff_t
*pos, size_t *count, i
}
return 0;
}
-EXPORT_SYMBOL(generic_write_checks);
+EXPORT_SYMBOL(__generic_write_checks);
int pagecache_write_begin(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
@@ -2565,7 +2566,7 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
/* We can write back this queue in page reclaim */
current->backing_dev_info = inode_to_bdi(inode);
- err = generic_write_checks(file, , , S_ISBLK(inode->i_mode));
+ err = generic_write_checks(iocb, , , S_ISBLK(inode->i_mode));
if (err)
goto out;
@@ -2582,7 +2583,7 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
if (err)
goto out;
- if (io_is_direct(file)) {
+ if (is_direct_kiocb(iocb)) {
loff_t endbyte;
written = generic_file_direct_write(iocb, from, pos);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/16] cifs: use is_xxx_kiocb instead of filp->fl_flags
Cc: linux-c...@vger.kernel.org
Signed-off-by: Dmitry Monakhov
---
fs/cifs/file.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index a94b3e6..25527e9 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2560,7 +2560,7 @@ cifs_write_from_iter(loff_t offset, size_t len, struct
iov_iter *from,
}
static ssize_t
-cifs_iovec_write(struct file *file, struct iov_iter *from, loff_t *poffset)
+cifs_iovec_write(struct kiocb *iocb, struct iov_iter *from, loff_t *poffset)
{
size_t len;
ssize_t total_written = 0;
@@ -2573,7 +2573,7 @@ cifs_iovec_write(struct file *file, struct iov_iter
*from, loff_t *poffset)
int rc;
len = iov_iter_count(from);
- rc = generic_write_checks(file, poffset, , 0);
+ rc = generic_write_checks(iocb, poffset, , 0);
if (rc)
return rc;
@@ -2583,8 +2583,8 @@ cifs_iovec_write(struct file *file, struct iov_iter
*from, loff_t *poffset)
iov_iter_truncate(from, len);
INIT_LIST_HEAD(_list);
- cifs_sb = CIFS_FILE_SB(file);
- open_file = file->private_data;
+ cifs_sb = CIFS_FILE_SB(iocb->ki_filp);
+ open_file = iocb->ki_filp->private_data;
tcon = tlink_tcon(open_file->tlink);
if (!tcon->ses->server->ops->async_writev)
@@ -2670,7 +2670,7 @@ ssize_t cifs_user_writev(struct kiocb *iocb, struct
iov_iter *from)
* write request.
*/
- written = cifs_iovec_write(iocb->ki_filp, from, );
+ written = cifs_iovec_write(iocb, from, );
if (written > 0) {
set_bit(CIFS_INO_INVALID_MAPPING, _I(inode)->flags);
iocb->ki_pos = pos;
@@ -2696,7 +2696,7 @@ cifs_writev(struct kiocb *iocb, struct iov_iter *from)
*/
down_read(>lock_sem);
mutex_lock(>i_mutex);
- if (file->f_flags & O_APPEND)
+ if (is_append_kiocb(iocb))
lock_pos = i_size_read(inode);
if (!cifs_find_lock_conflict(cfile, lock_pos, iov_iter_count(from),
server->vals->exclusive_lock_type, NULL,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/16] btrfs: use is_xxx_kiocb instead of filp->fl_flags
Cc: linux-bt...@vger.kernel.org
Signed-off-by: Dmitry Monakhov
---
fs/btrfs/file.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index aee18f8..4dc3856 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1747,7 +1747,7 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
mutex_lock(>i_mutex);
current->backing_dev_info = inode_to_bdi(inode);
- err = generic_write_checks(file, , , S_ISBLK(inode->i_mode));
+ err = generic_write_checks(iocb, , , S_ISBLK(inode->i_mode));
if (err) {
mutex_unlock(>i_mutex);
goto out;
@@ -1800,7 +1800,7 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,
if (sync)
atomic_inc(_I(inode)->sync_writers);
- if (file->f_flags & O_DIRECT) {
+ if (is_direct_kiocb(iocb)) {
num_written = __btrfs_direct_write(iocb, from, pos);
} else {
num_written = __btrfs_buffered_write(file, from, pos);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/16] fs: fixup racy check file->f_flags for xxx_write_iter
There are many places inside vfs/fs where code flow depends on file->f_flags, but this check is racy because one can change it via fcntl(,F_SETFL,) For example O_DIRECT usually flag checked twice: xxx_file_write_iter -> check O_DIRECT, and perform some optimizations ->__generic_file_write_iter -> check O_DIRECT, which may break things: for example http://www.spinics.net/lists/linux-ext4/msg45683.html For that reason some filesystems simply do not use __generic_file_write_iter() wihch result in code duplication. Right way to fix this is to save volatile flags inside kiocb->ki_flags similar to ->ki_pos Other private discussion: message-id:20141218105101.gd13...@quack.suse.cz TOC: ##First two patches introduce helpers and update generic code kiocb_flags-v1/0001-fs-save-file-f_flags-to-kiocb-ki_flags.patch kiocb_flags-v1/0002-vfs-check-kiocb-ki_flags-instead-filp-fl_flags.patch ## Switch filesystems to kiocb->ki_flags kiocb_flags-v1/0003-ext4-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0004-9p-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0005-btrfs-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0006-ceph-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0007-cifs-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0008-gfs2-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0009-nfs-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0010-ntfs-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0011-ocfs2-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0012-udf-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0013-xfs-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0014-fuse-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch ## Fix pipe and splice issues caused by race with fcntl(,F_SETFL,) kiocb_flags-v1/0015-pipe-use-is_xxx_kiocb-instead-of-filp-fl_flags.patch kiocb_flags-v1/0016-splice-fix-race-beween-splice_write-vs-fcntl-F_SETFL.patch Patch set survived basic run of xfstests -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/16] nfs: use is_xxx_kiocb instead of filp->fl_flags
Cc: linux-...@vger.kernel.org
Signed-off-by: Dmitry Monakhov
---
fs/nfs/direct.c |7 +++
fs/nfs/file.c |6 +++---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index c3929fb..76950c6 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -964,8 +964,7 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter,
loff_t pos)
{
ssize_t result = -EINVAL;
- struct file *file = iocb->ki_filp;
- struct address_space *mapping = file->f_mapping;
+ struct address_space *mapping = iocb->ki_filp->f_mapping;
struct inode *inode = mapping->host;
struct nfs_direct_req *dreq;
struct nfs_lock_context *l_ctx;
@@ -976,9 +975,9 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter,
nfs_add_stats(mapping->host, NFSIOS_DIRECTWRITTENBYTES, count);
dfprintk(FILE, "NFS: direct write(%pD2, %zd@%Ld)\n",
- file, count, (long long) pos);
+ iocb->ki_filp, count, (long long) pos);
- result = generic_write_checks(file, , , 0);
+ result = generic_write_checks(iocb, , , 0);
if (result)
goto out;
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 37b1558..709cb7f 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -170,7 +170,7 @@ nfs_file_read(struct kiocb *iocb, struct iov_iter *to)
struct inode *inode = file_inode(iocb->ki_filp);
ssize_t result;
- if (iocb->ki_filp->f_flags & O_DIRECT)
+ if (is_direct_kiocb(iocb))
return nfs_file_direct_read(iocb, to, iocb->ki_pos);
dprintk("NFS: read(%pD2, %zu@%lu)\n",
@@ -680,7 +680,7 @@ ssize_t nfs_file_write(struct kiocb *iocb, struct iov_iter
*from)
if (result)
return result;
- if (file->f_flags & O_DIRECT)
+ if (is_direct_kiocb(iocb))
return nfs_file_direct_write(iocb, from, pos);
dprintk("NFS: write(%pD2, %zu@%Ld)\n",
@@ -692,7 +692,7 @@ ssize_t nfs_file_write(struct kiocb *iocb, struct iov_iter
*from)
/*
* O_APPEND implies that we must revalidate the file length.
*/
- if (file->f_flags & O_APPEND) {
+ if (is_append_kiocb(iocb)) {
result = nfs_revalidate_file_size(inode, file);
if (result)
goto out;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/16] ceph: use is_xxx_kiocb instead of filp->fl_flags
Cc: ceph-de...@vger.kernel.org
Signed-off-by: Dmitry Monakhov
---
fs/ceph/file.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 139f2fe..3ac67bf 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -442,7 +442,7 @@ static ssize_t ceph_sync_read(struct kiocb *iocb, struct
iov_iter *i,
dout("sync_read on file %p %llu~%u %s\n", file, off,
(unsigned)len,
-(file->f_flags & O_DIRECT) ? "O_DIRECT" : "");
+(is_direct_kiocb(iocb)) ? "O_DIRECT" : "");
if (!len)
return 0;
@@ -457,7 +457,7 @@ static ssize_t ceph_sync_read(struct kiocb *iocb, struct
iov_iter *i,
if (ret < 0)
return ret;
- if (file->f_flags & O_DIRECT) {
+ if (is_direct_kiocb(iocb)) {
while (iov_iter_count(i)) {
size_t start;
ssize_t n;
@@ -828,8 +828,7 @@ again:
return ret;
if ((got & (CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO)) == 0 ||
- (iocb->ki_filp->f_flags & O_DIRECT) ||
- (fi->flags & CEPH_F_SYNC)) {
+ is_direct_kiocb(iocb) || (fi->flags & CEPH_F_SYNC)) {
dout("aio_sync_read %p %llx.%llx %llu~%u got cap refs on %s\n",
inode, ceph_vinop(inode), iocb->ki_pos, (unsigned)len,
@@ -953,7 +952,7 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct
iov_iter *from)
/* We can write back this queue in page reclaim */
current->backing_dev_info = inode_to_bdi(inode);
- err = generic_write_checks(file, , , S_ISBLK(inode->i_mode));
+ err = generic_write_checks(iocb, , , S_ISBLK(inode->i_mode));
if (err)
goto out;
@@ -997,12 +996,12 @@ retry_snap:
inode, ceph_vinop(inode), pos, count, ceph_cap_string(got));
if ((got & (CEPH_CAP_FILE_BUFFER|CEPH_CAP_FILE_LAZYIO)) == 0 ||
- (file->f_flags & O_DIRECT) || (fi->flags & CEPH_F_SYNC)) {
+ is_direct_kiocb(iocb) || (fi->flags & CEPH_F_SYNC)) {
struct iov_iter data;
mutex_unlock(>i_mutex);
/* we might need to revert back to that point */
data = *from;
- if (file->f_flags & O_DIRECT)
+ if (is_direct_kiocb(iocb))
written = ceph_sync_direct_write(iocb, , pos);
else
written = ceph_sync_write(iocb, , pos);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/16] gfs2: use is_xxx_kiocb instead of filp->fl_flags
Cc: cluster-de...@redhat.com
Signed-off-by: Dmitry Monakhov
---
fs/gfs2/file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index f6fc412..25da110 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -709,7 +709,7 @@ static ssize_t gfs2_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
gfs2_size_hint(file, iocb->ki_pos, iov_iter_count(from));
- if (file->f_flags & O_APPEND) {
+ if (is_append_kiocb(iocb)) {
struct gfs2_holder gh;
ret = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED, 0, );
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/16] udf: use is_xxx_kiocb instead of filp->fl_flags
Cc: j...@suse.cz
Signed-off-by: Dmitry Monakhov
---
fs/udf/file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/udf/file.c b/fs/udf/file.c
index 7f885cc..78ccc0f 100644
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -128,7 +128,7 @@ static ssize_t udf_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
mutex_lock(>i_mutex);
down_write(>i_data_sem);
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
- if (file->f_flags & O_APPEND)
+ if (is_append_kiocb(iocb))
pos = inode->i_size;
else
pos = iocb->ki_pos;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/16] ntfs: use is_xxx_kiocb instead of filp->fl_flags
Cc: linux-ntfs-...@lists.sourceforge.net Signed-off-by: Dmitry Monakhov --- fs/ntfs/file.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c index c1da78d..648b3a4 100644 --- a/fs/ntfs/file.c +++ b/fs/ntfs/file.c @@ -345,7 +345,8 @@ static ssize_t ntfs_prepare_file_for_write(struct file *file, loff_t *ppos, (unsigned long long)*ppos, (unsigned long)*count); /* We can write back this queue in page reclaim. */ current->backing_dev_info = inode_to_bdi(vi); - err = generic_write_checks(file, ppos, count, S_ISBLK(vi->i_mode)); + err = __generic_write_checks(file, ppos, count, S_ISBLK(vi->i_mode), +file->f_flags & O_APPEND); if (unlikely(err)) goto out; /* -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/16] ocfs2: use is_xxx_kiocb instead of filp->fl_flags
Cc: ocfs2-de...@oss.oracle.com
Signed-off-by: Dmitry Monakhov
---
fs/ocfs2/file.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index 266845d..c22b240 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -2283,8 +2283,8 @@ static ssize_t ocfs2_file_write_iter(struct kiocb *iocb,
if (count == 0)
return 0;
- appending = file->f_flags & O_APPEND ? 1 : 0;
- direct_io = file->f_flags & O_DIRECT ? 1 : 0;
+ appending = is_append_kiocb(iocb);
+ direct_io = is_direct_kiocb(iocb);
mutex_lock(>i_mutex);
@@ -2374,7 +2374,7 @@ relock:
/* communicate with ocfs2_dio_end_io */
ocfs2_iocb_set_rw_locked(iocb, rw_level);
- ret = generic_write_checks(file, ppos, ,
+ ret = generic_write_checks(iocb, ppos, ,
S_ISBLK(inode->i_mode));
if (ret)
goto out_dio;
@@ -2436,7 +2436,7 @@ relock:
out_dio:
/* buffered aio wouldn't have proper lock coverage today */
- BUG_ON(ret == -EIOCBQUEUED && !(file->f_flags & O_DIRECT));
+ BUG_ON(ret == -EIOCBQUEUED && !is_direct_kiocb(iocb));
if (((file->f_flags & O_DSYNC) && !direct_io) || IS_SYNC(inode) ||
((file->f_flags & O_DIRECT) && !direct_io)) {
@@ -2547,7 +2547,7 @@ static ssize_t ocfs2_file_read_iter(struct kiocb *iocb,
* buffered reads protect themselves in ->readpage(). O_DIRECT reads
* need locks to protect pending reads from racing with truncate.
*/
- if (filp->f_flags & O_DIRECT) {
+ if (is_direct_kiocb(iocb)) {
have_alloc_sem = 1;
ocfs2_iocb_set_sem_locked(iocb);
@@ -2581,7 +2581,7 @@ static ssize_t ocfs2_file_read_iter(struct kiocb *iocb,
trace_generic_file_aio_read_ret(ret);
/* buffered aio wouldn't have proper lock coverage today */
- BUG_ON(ret == -EIOCBQUEUED && !(filp->f_flags & O_DIRECT));
+ BUG_ON(ret == -EIOCBQUEUED && !is_direct_kiocb(iocb));
/* see ocfs2_file_write_iter */
if (ret == -EIOCBQUEUED || !ocfs2_iocb_is_rw_locked(iocb)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] pipe: use is_xxx_kiocb instead of filp->fl_flags
Also fix other long standing issues caused by fcntl(,F_SETFL,):
- One can disable O_DIRECT for pipe[1] (paketized IO), but can not enable it
again.
- Currently we do not set O_APPEND on pipe[1] (IMHO it is wrong, but let it be)
so it is reasonable to completely prohibit change O_APPEND flag on both
end's of pipe. Add ->check_flags method in order to diallow O_APPEND toggling.
Signed-off-by: Dmitry Monakhov
---
fs/fcntl.c |6 --
fs/pipe.c | 20 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index ee85cd4..0bdc9c7 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -51,9 +51,11 @@ static int setfl(int fd, struct file * filp, unsigned long
arg)
if (arg & O_NDELAY)
arg |= O_NONBLOCK;
+ /* allowed only for inodes with ->direct_io method or write pipe */
if (arg & O_DIRECT) {
- if (!filp->f_mapping || !filp->f_mapping->a_ops ||
- !filp->f_mapping->a_ops->direct_IO)
+ if ((!filp->f_mapping || !filp->f_mapping->a_ops ||
+!filp->f_mapping->a_ops->direct_IO) &&
+ !(get_pipe_info(filp) && (filp->f_flags | O_WRONLY)))
return -EINVAL;
}
diff --git a/fs/pipe.c b/fs/pipe.c
index 2d084f2..95b5fe4 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -301,7 +301,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
*/
if (ret)
break;
- if (filp->f_flags & O_NONBLOCK) {
+ if (is_nonblock_kiocb(iocb)) {
ret = -EAGAIN;
break;
}
@@ -329,9 +329,9 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
return ret;
}
-static inline int is_packetized(struct file *file)
+static inline int is_packetized(struct kiocb *kiocb)
{
- return (file->f_flags & O_DIRECT) != 0;
+ return is_direct_kiocb(kiocb);
}
static ssize_t
@@ -427,7 +427,7 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from)
buf->offset = 0;
buf->len = copied;
buf->flags = 0;
- if (is_packetized(filp)) {
+ if (is_packetized(iocb)) {
buf->ops = _pipe_buf_ops;
buf->flags = PIPE_BUF_FLAG_PACKET;
}
@@ -439,7 +439,7 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from)
}
if (bufs < pipe->buffers)
continue;
- if (filp->f_flags & O_NONBLOCK) {
+ if (is_nonblock_kiocb(iocb)) {
if (!ret)
ret = -EAGAIN;
break;
@@ -943,6 +943,15 @@ err:
return ret;
}
+/* XXX: Currently it is not possible distinguish read side from write one */
+static int pipe_check_flags(int flags)
+{
+ if (flags & O_APPEND)
+ return -EINVAL;
+
+ return 0;
+}
+
const struct file_operations pipefifo_fops = {
.open = fifo_open,
.llseek = no_llseek,
@@ -954,6 +963,7 @@ const struct file_operations pipefifo_fops = {
.unlocked_ioctl = pipe_ioctl,
.release= pipe_release,
.fasync = pipe_fasync,
+ .check_flags= pipe_check_flags,
};
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/16] xfs: use is_xxx_kiocb instead of filp->fl_flags
Also function interface cleanup in order to vfs:write_iter interface agreeament
Cc: x...@oss.sgi.com
Signed-off-by: Dmitry Monakhov
---
fs/xfs/xfs_file.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index f44212f..148039b 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -279,7 +279,7 @@ xfs_file_read_iter(
XFS_STATS_INC(xs_read_calls);
- if (unlikely(file->f_flags & O_DIRECT))
+ if (unlikely(is_direct_kiocb(iocb)))
ioflags |= XFS_IO_ISDIRECT;
if (file->f_mode & FMODE_NOCMTIME)
ioflags |= XFS_IO_INVIS;
@@ -544,17 +544,18 @@ xfs_zero_eof(
*/
STATIC ssize_t
xfs_file_aio_write_checks(
- struct file *file,
+ struct kiocb*iocb,
loff_t *pos,
size_t *count,
int *iolock)
{
+ struct file *file = iocb->ki_filp;
struct inode*inode = file->f_mapping->host;
struct xfs_inode*ip = XFS_I(inode);
int error = 0;
restart:
- error = generic_write_checks(file, pos, count, S_ISBLK(inode->i_mode));
+ error = generic_write_checks(iocb, pos, count, S_ISBLK(inode->i_mode));
if (error)
return error;
@@ -678,7 +679,7 @@ xfs_file_dio_aio_write(
xfs_rw_ilock(ip, iolock);
}
- ret = xfs_file_aio_write_checks(file, , , );
+ ret = xfs_file_aio_write_checks(iocb, , , );
if (ret)
goto out;
iov_iter_truncate(from, count);
@@ -739,7 +740,7 @@ xfs_file_buffered_aio_write(
xfs_rw_ilock(ip, iolock);
- ret = xfs_file_aio_write_checks(file, , , );
+ ret = xfs_file_aio_write_checks(iocb, , , );
if (ret)
goto out;
@@ -803,7 +804,7 @@ xfs_file_write_iter(
if (XFS_FORCED_SHUTDOWN(ip->i_mount))
return -EIO;
- if (unlikely(file->f_flags & O_DIRECT))
+ if (unlikely(is_direct_kiocb(iocb)))
ret = xfs_file_dio_aio_write(iocb, from);
else
ret = xfs_file_buffered_aio_write(iocb, from);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/16] fuse: use is_xxx_kiocb instead of filp->fl_flags
Cc: fuse-de...@lists.sourceforge.net
Signed-off-by: Dmitry Monakhov
---
fs/fuse/file.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index ff102cb..ba8ad87 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1167,7 +1167,7 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
/* We can write back this queue in page reclaim */
current->backing_dev_info = inode_to_bdi(inode);
- err = generic_write_checks(file, , , S_ISBLK(inode->i_mode));
+ err = generic_write_checks(iocb, , , S_ISBLK(inode->i_mode));
if (err)
goto out;
@@ -1183,7 +1183,7 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb,
struct iov_iter *from)
if (err)
goto out;
- if (file->f_flags & O_DIRECT) {
+ if (is_direct_kiocb(iocb)) {
written = generic_file_direct_write(iocb, from, pos);
if (written < 0 || !iov_iter_count(from))
goto out;
@@ -1421,7 +1421,8 @@ static ssize_t __fuse_direct_write(struct fuse_io_priv
*io,
ssize_t res;
- res = generic_write_checks(file, ppos, , 0);
+ res = __generic_write_checks(file, ppos, , 0,
+file->f_flags & O_APPEND);
if (!res) {
iov_iter_truncate(iter, count);
res = fuse_direct_io(io, iter, ppos, FUSE_DIO_WRITE);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] splice: fix race beween splice_write vs fcntl(,F_SETFL,)
file->f_flags & O_APPEND is checked twice
-> do_splice_direct or do_splice: return EINVAL if O_APPEND enabled
-> generic_write_checks: seek to end in case of O_APPEND
This is obviously whong and result in unpredictable behaviour if raced with
fcntl. It is reasonable to recheck append flag after kiocb was constructed (
f_flags becomes stable), for that reason we should use special analog of
vfs_write_iter()
Signed-off-by: Dmitry Monakhov
---
fs/splice.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/fs/splice.c b/fs/splice.c
index 41cbb16..7ac43db 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -922,6 +922,27 @@ ssize_t splice_from_pipe(struct pipe_inode_info *pipe,
struct file *out,
return ret;
}
+ssize_t splice_iter_write(struct file *file, struct iov_iter *iter, loff_t
*ppos)
+{
+ struct kiocb kiocb;
+ ssize_t ret;
+
+ if (!file->f_op->write_iter)
+ return -EINVAL;
+
+ init_sync_kiocb(, file);
+ if (is_append_kiocb())
+ return -EINVAL;
+
+ kiocb.ki_pos = *ppos;
+ iter->type |= WRITE;
+ ret = file->f_op->write_iter(, iter);
+ BUG_ON(ret == -EIOCBQUEUED);
+ if (ret > 0)
+ *ppos = kiocb.ki_pos;
+ return ret;
+}
+
/**
* iter_file_splice_write - splice data from a pipe to a file
@@ -1005,7 +1026,7 @@ iter_file_splice_write(struct pipe_inode_info *pipe,
struct file *out,
iov_iter_bvec(, ITER_BVEC | WRITE, array, n,
sd.total_len - left);
- ret = vfs_iter_write(out, , );
+ ret = splice_iter_write(out, , );
if (ret <= 0)
break;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] 9p: use is_xxx_kiocb instead of filp->fl_flags
Cc: v9fs-develo...@lists.sourceforge.net Signed-off-by: Dmitry Monakhov --- fs/9p/vfs_file.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index b401337..c2a120a 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c @@ -509,7 +509,8 @@ v9fs_file_write(struct file *filp, const char __user * data, loff_t origin = *offset; - retval = generic_write_checks(filp, , , 0); + retval = __generic_write_checks(filp, , , 0, + filp->f_flags & O_APPEND); if (retval) goto out; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/16] fs: save file->f_flags to kiocb->ki_flags
There are many places inside vfs/fs where code flow depends on file->f_flags,
but this check is racy because one can change it via fcntl(,F_SETFL,)
For example O_DIRECT usually flag checked twice:
xxx_file_write_iter -> check O_DIRECT, and perform some optimization
->__generic_file_write_iter -> check O_DIRECT,
which may break things: for example
http://www.spinics.net/lists/linux-ext4/msg45683.html
For that reason some filesystems simply do not use __generic_file_write_iter()
which result in code duplication. Right way to fix this is to save volatile
flags
inside kiocb->ki_flags similar to ->ki_pos
Other private discussion: message-id:20141218105101.gd13...@quack.suse.cz
This patch store O_DIRECT|O_APPEND|O_NONBLOCK|O_NDELAY
to kiocb->ki_flags on kiocb initialization.
Signed-off-by: Dmitry Monakhov
---
fs/aio.c |7 ---
fs/read_write.c| 20
include/linux/fs.h | 30 +++---
3 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 3b8467a..f58c4d6 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1482,6 +1482,7 @@ static int io_submit_one(struct kioctx *ctx, struct iocb
__user *user_iocb,
struct iocb *iocb, bool compat)
{
struct aio_kiocb *req;
+ struct file* filp;
ssize_t ret;
/* enforce forwards compatibility on users */
@@ -1504,14 +1505,14 @@ static int io_submit_one(struct kioctx *ctx, struct
iocb __user *user_iocb,
if (unlikely(!req))
return -EAGAIN;
- req->common.ki_filp = fget(iocb->aio_fildes);
- if (unlikely(!req->common.ki_filp)) {
+ filp = fget(iocb->aio_fildes);
+ if (unlikely(!filp)) {
ret = -EBADF;
goto out_put_req;
}
+ kiocb_init_file(>common, filp);
req->common.ki_pos = iocb->aio_offset;
req->common.ki_complete = aio_complete;
- req->common.ki_flags = 0;
if (iocb->aio_flags & IOCB_FLAG_RESFD) {
/*
diff --git a/fs/read_write.c b/fs/read_write.c
index 69128b3..00e1ca4 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -41,6 +41,26 @@ static inline int unsigned_offsets(struct file *file)
return file->f_mode & FMODE_UNSIGNED_OFFSET;
}
+void kiocb_init_file(struct kiocb *kiocb, struct file *filp)
+{
+ kiocb->ki_flags = 0;
+ kiocb->ki_filp = filp;
+
+ /* Socket aio */
+ if (kiocb->ki_filp == NULL)
+ return;
+
+ if (filp->f_flags & O_APPEND)
+ kiocb->ki_flags |= IOCB_APPEND;
+ if (filp->f_flags & O_NONBLOCK)
+ kiocb->ki_flags |= IOCB_NONBLOCK;
+ if (filp->f_flags & O_NDELAY)
+ kiocb->ki_flags |= IOCB_NDELAY;
+ if (filp->f_flags & O_DIRECT)
+ kiocb->ki_flags |= IOCB_DIRECT;
+}
+EXPORT_SYMBOL(kiocb_init_file);
+
/**
* vfs_setpos - update the file offset for lseek
* @file: file structure in question
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dfbd88a..4c20030 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -315,6 +315,10 @@ struct address_space;
struct writeback_control;
#define IOCB_EVENTFD (1 << 0)
+#define IOCB_APPEND(1 << 1)
+#define IOCB_NONBLOCK (1 << 2)
+#define IOCB_NDELAY(1 << 3)
+#define IOCB_DIRECT(1 << 4)
struct kiocb {
struct file *ki_filp;
@@ -329,11 +333,11 @@ static inline bool is_sync_kiocb(struct kiocb *kiocb)
return kiocb->ki_complete == NULL;
}
+extern void kiocb_init_file(struct kiocb *kiocb, struct file *filp);
static inline void init_sync_kiocb(struct kiocb *kiocb, struct file *filp)
{
- *kiocb = (struct kiocb) {
- .ki_filp = filp,
- };
+ memset(kiocb, 0 , sizeof(*kiocb));
+ kiocb_init_file(kiocb, filp);
}
/*
@@ -2776,6 +2780,26 @@ extern int generic_show_options(struct seq_file *m,
struct dentry *root);
extern void save_mount_options(struct super_block *sb, char *options);
extern void replace_mount_options(struct super_block *sb, char *options);
+static inline bool is_append_kiocb(struct kiocb *kiocb)
+{
+ return kiocb->ki_flags & IOCB_APPEND;
+}
+
+static inline bool is_direct_kiocb(struct kiocb *kiocb)
+{
+ return (kiocb->ki_flags & IOCB_DIRECT) |
+ IS_DAX(file_inode(kiocb->ki_filp));
+
+}
+
+
+static inline bool is_nonblock_kiocb(struct kiocb *kiocb)
+{
+ return kiocb->ki_flags & IOCB_NONBLOCK;
+}
+
+/* XXX: this is obsolete helper, and will be removed soon.
+ * One should use io_direct_kiocb() instead */
static inline bool io_is_direct(struct file *filp)
{
return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/16] ext4: use is_xxx_kiocb instead of filp->fl_flags
Cc: linux-e...@vger.kernel.org
Signed-off-by: Dmitry Monakhov
---
fs/ext4/file.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 598abbb..27cf1cc 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -95,7 +95,6 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter
*from)
struct inode *inode = file_inode(iocb->ki_filp);
struct mutex *aio_mutex = NULL;
struct blk_plug plug;
- int o_direct = io_is_direct(file);
int overwrite = 0;
size_t length = iov_iter_count(from);
ssize_t ret;
@@ -105,18 +104,17 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter
*from)
* Unaligned direct AIO must be serialized; see comment above
* In the case of O_APPEND, assume that we must always serialize
*/
- if (o_direct &&
+ if (is_direct_kiocb(iocb) &&
ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) &&
!is_sync_kiocb(iocb) &&
- (file->f_flags & O_APPEND ||
-ext4_unaligned_aio(inode, from, pos))) {
+ (is_append_kiocb(iocb) || ext4_unaligned_aio(inode, from, pos))) {
aio_mutex = ext4_aio_mutex(inode);
mutex_lock(aio_mutex);
ext4_unwritten_wait(inode);
}
mutex_lock(>i_mutex);
- if (file->f_flags & O_APPEND)
+ if (is_append_kiocb(iocb))
iocb->ki_pos = pos = i_size_read(inode);
/*
@@ -138,7 +136,7 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter
*from)
}
iocb->private =
- if (o_direct) {
+ if (is_direct_kiocb(iocb)) {
blk_start_plug();
@@ -182,7 +180,7 @@ ext4_file_write_iter(struct kiocb *iocb, struct iov_iter
*from)
if (err < 0)
ret = err;
}
- if (o_direct)
+ if (is_direct_kiocb(iocb))
blk_finish_plug();
errout:
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] spi: bcm-mspi: Add support to set serial baud clock rate
Le 02/04/2015 12:23, Jonathan Richardson a écrit :
> The driver wasn't setting the SPBR (serial clock baud rate) which caused
> it to run at the slowest speed possible. The driver now calculates the
> SPBR based on the reference clock frequency resulting in much faster
> SPI transfers.
>
> Signed-off-by: Jonathan Richardson
> ---
[snip]
> + data->clk = devm_clk_get(dev, "mspi_clk");
> + if (!IS_ERR(data->clk)) {
> + int ret = clk_prepare_enable(data->clk);
> +
> + if (ret < 0) {
> + dev_err(dev, "failed to enable clock: %d\n", ret);
> + return 0;
> + }
> +
> + /* Calculate SPBR if clock-frequency provided. */
> + if (of_property_read_u32(dev->of_node, "clock-frequency",
> + _rate) >= 0) {
> + u32 spbr = clk_get_rate(data->clk) / (2 * desired_rate);
Usually, specifying a "clock-frequency" property is done when there is
no clock provider available, yet we take this code path only if we could
find a "mspi_clk" which sounds a litle weird.
Once there is a proper "mspi_clk" clock, I would make it mandatory for
the clock provider to be able to provide the rate as well?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: clear EXTRA_REGS for all executable formats
On failure, sys_execve does not clobber EXTRA_REGS, so we can just
return to userpsace without saving/restoring them.
On success, ELF_PLAT_INIT in sys_execve clears all these registers.
On other executable formats:
binfmt_flat.c has similar FLAT_PLAT_INIT, but x86 (and everyone else
except sh) doesn't define it.
binfmt_elf_fdpic.c has ELF_FDPIC_PLAT_INIT, but x86 (and most others)
doesn't define it.
There are no such hooks in binfmt_aout.c et al. We inherit
EXTRA_REGS from the prior executable.
This was not intended.
This change removes SAVE/RESTORE_EXTRA_REGS in stub_execve,
removes register clearing in ELF_PLAT_INIT,
and instead simply clears them on success in stub_execve.
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Linus Torvalds
CC: Steven Rostedt
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Frederic Weisbecker
CC: Alexei Starovoitov
CC: Will Drewry
CC: Kees Cook
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/calling.h | 9
arch/x86/include/asm/elf.h | 7 +++---
arch/x86/kernel/entry_64.S | 50 +++---
3 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
index 4b5f7bf..1c8b50e 100644
--- a/arch/x86/include/asm/calling.h
+++ b/arch/x86/include/asm/calling.h
@@ -151,6 +151,15 @@ For 32-bit we have the following conventions - kernel is
built with
movq_cfi_restore 5*8+\offset, rbx
.endm
+ .macro ZERO_EXTRA_REGS
+ xorl%r15d, %r15d
+ xorl%r14d, %r14d
+ xorl%r13d, %r13d
+ xorl%r12d, %r12d
+ xorl%ebp, %ebp
+ xorl%ebx, %ebx
+ .endm
+
.macro RESTORE_C_REGS_HELPER rstor_rax=1, rstor_rcx=1, rstor_r11=1,
rstor_r8910=1, rstor_rdx=1
.if \rstor_r11
movq_cfi_restore 6*8, r11
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index bd292ce..935588d9 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -171,10 +171,11 @@ do { \
static inline void elf_common_init(struct thread_struct *t,
struct pt_regs *regs, const u16 ds)
{
- regs->ax = regs->bx = regs->cx = regs->dx = 0;
- regs->si = regs->di = regs->bp = 0;
+ /* Commented-out registers are cleared in stub_execve */
+ /*regs->ax = regs->bx =*/ regs->cx = regs->dx = 0;
+ regs->si = regs->di /*= regs->bp*/ = 0;
regs->r8 = regs->r9 = regs->r10 = regs->r11 = 0;
- regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
+ /*regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;*/
t->fs = t->gs = 0;
t->fsindex = t->gsindex = 0;
t->ds = t->es = ds;
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 13185c5..65485b3 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -419,25 +419,27 @@ END(stub_\func)
ENTRY(stub_execve)
CFI_STARTPROC
- addq $8, %rsp
- DEFAULT_FRAME 0
- SAVE_EXTRA_REGS
- call sys_execve
- movq %rax,RAX(%rsp)
- RESTORE_EXTRA_REGS
- jmp int_ret_from_sys_call
+ DEFAULT_FRAME 0, 8
+ callsys_execve
+return_from_execve:
+ testl %eax, %eax
+ jz 1f
+ /* exec failed, can use fast SYSRET code path in this case */
+ ret
+1:
+ /* must use IRET code path (pt_regs->cs may have changed) */
+ addq$8, %rsp
+ ZERO_EXTRA_REGS
+ movq%rax,RAX(%rsp)
+ jmp int_ret_from_sys_call
CFI_ENDPROC
END(stub_execve)
ENTRY(stub_execveat)
CFI_STARTPROC
- addq $8, %rsp
- DEFAULT_FRAME 0
- SAVE_EXTRA_REGS
- call sys_execveat
- movq %rax,RAX(%rsp)
- RESTORE_EXTRA_REGS
- jmp int_ret_from_sys_call
+ DEFAULT_FRAME 0, 8
+ callsys_execveat
+ jmp return_from_execve
CFI_ENDPROC
END(stub_execveat)
@@ -472,25 +474,17 @@ END(stub_x32_rt_sigreturn)
ENTRY(stub_x32_execve)
CFI_STARTPROC
- addq $8, %rsp
- DEFAULT_FRAME 0
- SAVE_EXTRA_REGS
- call compat_sys_execve
- movq %rax,RAX(%rsp)
- RESTORE_EXTRA_REGS
- jmp int_ret_from_sys_call
+ DEFAULT_FRAME 0, 8
+ callcompat_sys_execve
+ jmp return_from_execve
CFI_ENDPROC
END(stub_x32_execve)
ENTRY(stub_x32_execveat)
CFI_STARTPROC
- addq $8, %rsp
- DEFAULT_FRAME 0
- SAVE_EXTRA_REGS
- call compat_sys_execveat
- movq %rax,RAX(%rsp)
- RESTORE_EXTRA_REGS
- jmp int_ret_from_sys_call
+ DEFAULT_FRAME 0, 8
+ callcompat_sys_execveat
+ jmp return_from_execve
CFI_ENDPROC
END(stub_x32_execveat)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Re: [PATCH v2 1/3] iio: configfs: Add configfs support to IIO
On Fri, 2015-04-03 at 18:57 +0300, Daniel Baluta wrote: > --- a/drivers/iio/Kconfig > +++ b/drivers/iio/Kconfig > +config IIO_CONFIGFS > + tristate "Enable IIO configuration via configfs" > + select CONFIGFS_FS > + help > + This allows configuring various IIO bits through configfs > + (e.g. software triggers). For more info see > + Documentation/iio/iio_configfs.txt. > --- a/drivers/iio/Makefile > +++ b/drivers/iio/Makefile > @@ -5,6 +5,7 @@ > obj-$(CONFIG_IIO) += industrialio.o > industrialio-y := industrialio-core.o industrialio-event.o inkern.o > industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o > +industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o > industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o > industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o It seems I didn't pay attention to this Makefile the first time I looked at this series. And actually reading it I noticed that industrialio-configfs.o can only be part of the industrial.ko module, can't it? So this Makefile doesn't allow to build a separate industrialio-configfs.ko module, right? If so, my previous review, in which I claimed to spot a nit, was a waste of our time. Because I now experienced that if this gets build with CONFIG_IIO=m and CONFIG_IIO_CONFIGFS=y one gets: $ make -C ../.. CONFIG_IIO_CONFIGFS=y M=$PWD industrialio.ko make: Entering directory `[...]' CC [M] [...]/drivers/iio/industrialio-core.o CC [M] [...]/linux/drivers/iio/industrialio-event.o CC [M] [...]drivers/iio/inkern.o CC [M] [...]/drivers/iio/industrialio-buffer.o CC [M] [...]/drivers/iio/industrialio-configfs.o CC [M] [...]/drivers/iio/industrialio-trigger.o CC [M] [...]/drivers/iio/buffer_cb.o LD [M] [...]/drivers/iio/industrialio.o [...]/drivers/iio/industrialio-configfs.o: In function `iio_configfs_init': industrialio-configfs.c:(.init.text+0x0): multiple definition of `init_module' [...]/drivers/iio/industrialio-core.o:industrialio-core.c:(.init.text+0x0): first defined here [...]/drivers/iio/industrialio-configfs.o: In function `iio_configfs_exit': industrialio-configfs.c:(.exit.text+0x0): multiple definition of `cleanup_module' [...]/drivers/iio/industrialio-core.o:industrialio-core.c:(.exit.text+0x0): first defined here make[1]: *** [[...]/drivers/iio/industrialio.o] Error 1 make: *** [industrialio.ko] Error 2 make: Leaving directory `[...]' (I didn't yet test other configurations.) So before I waste even more of your time: were you trying to make configfs support a part of the industrialio module or were you trying to make configfs support available as a separate module? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tty: serial: Add const to struct uart_ops declarations
These structs can be const, so make them const.
Signed-off-by: Joe Perches
---
Done with:
sed -r -i -e 's/\bstruct\s+uart_ops\s+(\w+)\s*=\s*/const struct uart_ops \1 =
/g' drivers/tty/serial/*.c
Compiled x86 only, not cross-compiled. Untested.
drivers/tty/serial/21285.c | 2 +-
drivers/tty/serial/altera_jtaguart.c| 2 +-
drivers/tty/serial/altera_uart.c| 2 +-
drivers/tty/serial/amba-pl010.c | 2 +-
drivers/tty/serial/amba-pl011.c | 2 +-
drivers/tty/serial/apbuart.c| 2 +-
drivers/tty/serial/ar933x_uart.c| 2 +-
drivers/tty/serial/arc_uart.c | 2 +-
drivers/tty/serial/atmel_serial.c | 2 +-
drivers/tty/serial/bcm63xx_uart.c | 2 +-
drivers/tty/serial/bfin_sport_uart.c| 2 +-
drivers/tty/serial/bfin_uart.c | 2 +-
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
drivers/tty/serial/dz.c | 2 +-
drivers/tty/serial/efm32-uart.c | 2 +-
drivers/tty/serial/fsl_lpuart.c | 4 ++--
drivers/tty/serial/icom.c | 2 +-
drivers/tty/serial/imx.c| 2 +-
drivers/tty/serial/ioc3_serial.c| 2 +-
drivers/tty/serial/ioc4_serial.c| 2 +-
drivers/tty/serial/ip22zilog.c | 2 +-
drivers/tty/serial/jsm/jsm_tty.c| 2 +-
drivers/tty/serial/lantiq.c | 2 +-
drivers/tty/serial/lpc32xx_hs.c | 2 +-
drivers/tty/serial/m32r_sio.c | 2 +-
drivers/tty/serial/max3100.c| 2 +-
drivers/tty/serial/men_z135_uart.c | 2 +-
drivers/tty/serial/meson_uart.c | 2 +-
drivers/tty/serial/mpc52xx_uart.c | 2 +-
drivers/tty/serial/mpsc.c | 2 +-
drivers/tty/serial/msm_serial.c | 2 +-
drivers/tty/serial/mux.c| 2 +-
drivers/tty/serial/mxs-auart.c | 2 +-
drivers/tty/serial/netx-serial.c| 2 +-
drivers/tty/serial/nwpserial.c | 2 +-
drivers/tty/serial/omap-serial.c| 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pmac_zilog.c | 2 +-
drivers/tty/serial/pnx8xxx_uart.c | 2 +-
drivers/tty/serial/pxa.c| 2 +-
drivers/tty/serial/sa1100.c | 2 +-
drivers/tty/serial/samsung.c| 2 +-
drivers/tty/serial/serial-tegra.c | 2 +-
drivers/tty/serial/serial_ks8695.c | 2 +-
drivers/tty/serial/serial_txx9.c| 2 +-
drivers/tty/serial/sh-sci.c | 2 +-
drivers/tty/serial/sirfsoc_uart.c | 2 +-
drivers/tty/serial/sn_console.c | 2 +-
drivers/tty/serial/sprd_serial.c| 2 +-
drivers/tty/serial/st-asc.c | 2 +-
drivers/tty/serial/sunhv.c | 2 +-
drivers/tty/serial/sunsab.c | 2 +-
drivers/tty/serial/sunsu.c | 2 +-
drivers/tty/serial/sunzilog.c | 2 +-
drivers/tty/serial/timbuart.c | 2 +-
drivers/tty/serial/uartlite.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/tty/serial/vr41xx_siu.c | 2 +-
drivers/tty/serial/vt8500_serial.c | 2 +-
drivers/tty/serial/xilinx_uartps.c | 2 +-
drivers/tty/serial/zs.c | 2 +-
61 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/drivers/tty/serial/21285.c b/drivers/tty/serial/21285.c
index 9b208bd..804632b 100644
--- a/drivers/tty/serial/21285.c
+++ b/drivers/tty/serial/21285.c
@@ -334,7 +334,7 @@ static int serial21285_verify_port(struct uart_port *port,
struct serial_struct
return ret;
}
-static struct uart_ops serial21285_ops = {
+static const struct uart_ops serial21285_ops = {
.tx_empty = serial21285_tx_empty,
.get_mctrl = serial21285_get_mctrl,
.set_mctrl = serial21285_set_mctrl,
diff --git a/drivers/tty/serial/altera_jtaguart.c
b/drivers/tty/serial/altera_jtaguart.c
index 0fefdd8..668158a1 100644
--- a/drivers/tty/serial/altera_jtaguart.c
+++ b/drivers/tty/serial/altera_jtaguart.c
@@ -280,7 +280,7 @@ static int altera_jtaguart_verify_port(struct uart_port
*port,
/*
* Define the basic serial functions we support.
*/
-static struct uart_ops altera_jtaguart_ops = {
+static const struct uart_ops altera_jtaguart_ops = {
.tx_empty = altera_jtaguart_tx_empty,
.get_mctrl = altera_jtaguart_get_mctrl,
.set_mctrl = altera_jtaguart_set_mctrl,
diff --git a/drivers/tty/serial/altera_uart.c b/drivers/tty/serial/altera_uart.c
index b2859fe..555b090 100644
--- a/drivers/tty/serial/altera_uart.c
+++ b/drivers/tty/serial/altera_uart.c
@@ -404,7 +404,7 @@ static void altera_uart_poll_put_char(struct uart_port
*port, unsigned char c)
/*
* Define the basic serial functions we support.
*/
-static struct
[PATCH] checkpatch: Add uart_ops to normally const structs
Add another struct to the list of normally const struct types
Signed-off-by: Joe Perches
---
On Fri, 2015-04-03 at 10:43 -0700, Joe Perches wrote:
> On Fri, 2015-04-03 at 19:01 +0200, Maxime Coquelin wrote:
> > This drivers adds support to the STM32 USART controller, which is a
> > standard serial driver.
> trivia:
> > diff --git a/drivers/tty/serial/stm32-usart.c
> > b/drivers/tty/serial/stm32-usart.c
> []
> > +static struct uart_ops stm32_uart_ops = {
> could be const
> and it could be updated in a separate patch later too.
scripts/checkpatch.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9a8b2bd..db3dcf5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5338,6 +5338,7 @@ sub process {
stacktrace_ops|
sysfs_ops|
tty_operations|
+ uart_ops|
usb_mon_operations|
wd_ops}x;
if ($line !~ /\bconst\b/ &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] earlycon: 8250: Fix command line regression
On Sat, Apr 04, 2015 at 01:24:51PM -0400, Peter Hurley wrote: > On 04/04/2015 01:19 PM, Peter Hurley wrote: > > Restore undocumented behavior of kernel command line parameters of > > the forms: > > console=uart[8250],io|mmio|mmio32,[,options] > > console=uart[8250],[,options] > > where 'options' have not been specified; in this case, the hardware > > is assumed to be initialized. > > > > Document the required behavior of the original implementation. > > Greg, > > Please wait for a Tested-by from Yinghai before pushing; I have no > platform to test if this fixes his regression. Ok, will do, thanks for redoing this and spinning up a fix so quickly. 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/
[PATCH 2/2] perf tools: Add options 'get', 'set' and 'unset' to 'perf-config'.
Add 'get' option that can show value of a specific config variable
and 'set' and 'unset' option that can create or replace a config variable.
Signed-off-by: Taeung Song
---
tools/perf/builtin-config.c | 198
tools/perf/util/cache.h | 18 +++-
tools/perf/util/config.c| 35 +++-
3 files changed, 247 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 494bd73..b0885ff 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -15,14 +15,25 @@
static struct {
bool list_action;
+ bool get_action;
+ bool set_action;
+ bool unset_action;
} params;
+LIST_HEAD(sections);
+static char *section_name_;
+static char *subkey_;
+static char *value_;
+
static const char * const config_usage[] = {
"perf config [options]",
NULL
};
static const struct option config_options[] = {
OPT_BOOLEAN('l', "list", _action, "list up current
configurations"),
+ OPT_BOOLEAN(0, "get", _action, "get value: section.subkey"),
+ OPT_BOOLEAN(0, "set", _action, "create or replace a
variable: section.subkey value"),
+ OPT_BOOLEAN(0, "unset", _action, "remove a variable:
section.subkey"),
OPT_END()
};
@@ -34,6 +45,72 @@ static void check_argc(int argc, int min, int max)
usage_with_options(config_usage, config_options);
}
+static struct config_section *find_config_section(const char *section_name)
+{
+ struct config_section *section_node;
+ list_for_each_entry(section_node, , list)
+ if (!strcmp(section_node->name, section_name))
+ return section_node;
+
+ return NULL;
+}
+
+static struct config_element *find_config_element(const char *subkey
+ , struct config_section
*section_node)
+{
+ struct config_element *element_node;
+
+ list_for_each_entry(element_node, _node->element_head, list)
+ if (!strcmp(element_node->subkey, subkey))
+ return element_node;
+
+ return NULL;
+}
+
+static struct config_section *init_config_section(const char *section_name)
+{
+ struct config_section *section_node;
+ LIST_HEAD(element_head);
+
+ section_node = zalloc(sizeof(*section_node));
+ if (!section_node)
+ return NULL;
+
+ INIT_LIST_HEAD(_node->element_head);
+ list_splice(_head, _node->element_head);
+ section_node->name = strdup(section_name);
+ if (!section_node->name) {
+ pr_err("%s: strdup failed\n", __func__);
+ return NULL;
+ }
+
+ return section_node;
+}
+
+static int add_config_element(struct list_head *head
+ , const char *subkey, const char *value)
+{
+ struct config_element *element_node;
+ element_node = zalloc(sizeof(*element_node));
+ element_node->subkey = strdup(subkey);
+ if (!element_node->subkey) {
+ pr_err("%s: strdup failed\n", __func__);
+ return -1;
+ }
+ if (value) {
+ element_node->value = strdup(value);
+ if (!element_node->value) {
+ pr_err("%s: strdup failed\n", __func__);
+ return -1;
+ }
+ } else
+ element_node->value = NULL;
+
+ list_add_tail(_node->list, head);
+
+ return 0;
+}
+
static int show_config(const char *key, const char *value,
void *cb __maybe_unused)
{
@@ -45,6 +122,112 @@ static int show_config(const char *key, const char *value,
return 0;
}
+static int show_spec_config(struct config_section *section_node
+ , struct config_element *element_node)
+{
+ char key[BUFSIZ];
+
+ if (section_node && element_node) {
+ sprintf(key, "%s.%s", section_node->name, element_node->subkey);
+ show_config(key, element_node->value, NULL);
+ }
+
+ return 0;
+}
+
+static int set_config(struct config_section *section_node, struct
config_element *element_node)
+{
+ if (!value_) {
+ /* value == NULL means unset */
+ if (section_node && element_node)
+ element_node->value = NULL;
+ else /* do nothing */
+ return 0;
+ } else {
+ /* if there isn't existent section, add a new section */
+ if (!section_node) {
+ section_node = init_config_section(section_name_);
+ if (!section_node)
+ return -1;
+ list_add_tail(_node->list, );
+ }
+ /* if nothing to replace, add a new element which contains
key-value pair. */
+ if (!element_node)
+
[PATCH 1/2] perf tools: Add 'perf-config' command
The perf configuration file contain many variables which can make the perf command's action more effective and more skilful. But looking through state of configuration is difficult and there's no knowing what kind of other variables except variables in perfconfig.example exist. So This patch adds 'perf-config' command with '--list' option and a document for it. Signed-off-by: Taeung Song --- tools/perf/Build| 1 + tools/perf/Documentation/perf-config.txt| 418 tools/perf/Documentation/perfconfig.example | 65 - tools/perf/builtin-config.c | 67 + tools/perf/builtin.h| 1 + tools/perf/command-list.txt | 1 + tools/perf/perf.c | 1 + 7 files changed, 543 insertions(+), 11 deletions(-) create mode 100644 tools/perf/Documentation/perf-config.txt create mode 100644 tools/perf/builtin-config.c diff --git a/tools/perf/Build b/tools/perf/Build index b77370e..3c1f437 100644 --- a/tools/perf/Build +++ b/tools/perf/Build @@ -1,5 +1,6 @@ perf-y += builtin-bench.o perf-y += builtin-annotate.o +perf-y += builtin-config.o perf-y += builtin-diff.o perf-y += builtin-evlist.o perf-y += builtin-help.o diff --git a/tools/perf/Documentation/perf-config.txt b/tools/perf/Documentation/perf-config.txt new file mode 100644 index 000..62f6bcb --- /dev/null +++ b/tools/perf/Documentation/perf-config.txt @@ -0,0 +1,418 @@ +perf-config(1) +== + +NAME + +perf-config - Get and set variables in configuration file. + +SYNOPSIS + +[verse] +'perf config' --list + +DESCRIPTION +--- +You can manage variables in configuration file with this command. + +OPTIONS +--- + +-l:: +--list:: + Show all variables with key and value into each sections. + +CONFIGURATION FILE +-- + +The Perf configuration file contain many variables which can make +the perf command's action more effective, more skilful. +The '$HOME/.perfconfig' file is used to store a per-user configuration. +The file 'etc/perfconfig' or '$(sysconfdir)/perfconfig' can be used to +store a system-wide default configuration. + +The variables are divided into sections. In each sections, the variables +can contain a key and values. + +Syntax +~~ + +Example +~~~ + +Given a $HOME/.perfconfig like this: + +# +# This is the config file, and +# a '#' and ';' character indicates a comment +# + +[colors] + # Color variables + top = red, default + medium = green, default + normal = lightgray, default + selected = white, lightgray + code = blue, default + addr = magenta, default + root = white, blue + +[tui] + # Defaults if linked with libslang + report = on + annotate = on + top = on + +[buildid] + # Default, disable using /dev/null + dir = /root/.debug + +[annotate] + # Defaults + hide_src_code = false + use_offset = true + jump_arrows = true + show_nr_jumps = false + +[help] + # Format can be man, info, web or html + format = man + autocorrect = 0 + +[ui] + show-headers= true + +[call-graph] + # fp (framepointer), dwarf + record-mode = fp + print-type = graph + order = caller + sort-key = function + +Variables +~ + +colors.*:: + Color variables can appoint colors of the output which is printed out + from ‘report’, ‘top’,’annotate’ on tui. + Color variables is composed of foreground and background + and should have two values for them. If you want to set as colors + of your terminal, you should use ‘default’ for color value. +The kind of color which can be used as below. + red, green, default, black, blue, white, magenta, lightgray + + colors.top:: + ‘top’ means a overhead percentage which has more than 5%. + And values of it’s variable specify colors of percentage. + Basic key values are foreground-color ’red’ and + background-color ’default’. + colors.medium:: + ‘medium’ means a overhead percentage which has more than 0.5%. + Default values are ’green’ and ’default’. + colors.normal:: + ‘normal’ means rest of overhead percentages + except ‘top’, ‘medium’, ‘selected’. + Default values are ’lightgray’ and ’default’. + colors.selected:: + This appoint colors for forcussed one of the output list + from sub-commands (top,report,annotate). + Default values are ’white’ and ’lightgray’. + colors.code:: + Colors for a arrow and lines on jumping by assembly code + such as ‘jns’,’jmp’,’jane’,etc. Default values are ‘blue’, ‘default’. + colors.addr:: + This appoint colors for addresses from a sub-command
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, Apr 04, 2015 at 07:21:51PM +0200, Julia Lawall wrote: > > OK. Should I update the patch to remove the test? > I thought Greg already applied it. If you want to send a new patch on top which removes it that's fine. Either way someone will eventually. :) regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] earlycon: 8250: Fix command line regression
On 04/04/2015 01:19 PM, Peter Hurley wrote: > Restore undocumented behavior of kernel command line parameters of > the forms: > console=uart[8250],io|mmio|mmio32,[,options] > console=uart[8250],[,options] > where 'options' have not been specified; in this case, the hardware > is assumed to be initialized. > > Document the required behavior of the original implementation. Greg, Please wait for a Tested-by from Yinghai before pushing; I have no platform to test if this fixes his regression. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, 4 Apr 2015, Dan Carpenter wrote: > On Sat, Apr 04, 2015 at 06:20:53PM +0200, Julia Lawall wrote: > > Couldn't one say: > > > > x = NULL; > > y = >whatever; > > z = container_of(y, struct blah, whatever); > > > > and end up with z being NULL? > > That is crazy person code. It looks deliberately wrong. If we start > merging deliberate mistakes then we're already screwed. > > I have a smatch check which warns on container_of() but I should update > it to not complain if it's the first struct member. I have looked at > quite a few of these warnings and I worry that there are some places > where it relies on container_of() to be a no-op... That's also crazy > but it's the kind of crazy that people do in real life. :P OK. Should I update the patch to remove the test? I find 57 NULL tests on the result of container_of in the kernel as a whole. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] earlycon: 8250: Fix command line regression
Restore undocumented behavior of kernel command line parameters of
the forms:
console=uart[8250],io|mmio|mmio32,[,options]
console=uart[8250],[,options]
where 'options' have not been specified; in this case, the hardware
is assumed to be initialized.
Document the required behavior of the original implementation.
Fixes: c7cef0a84912cab3c9df8 ("console: Add extensible console matching")
Reported-by: Yinghai Lu
Signed-off-by: Peter Hurley
---
v4: Removed FIXME comment
v3: Fixed automatic console to port line settings initialization;
open-coded serial8250_console_setup() so the baud can be probed;
added sha reference in commit log
v2: Fixed regression which allowed "console=uart1337,..." to start a
console (but not an earlycon)
+ fixed earlycon= documentation related required behavior fixed by
this patch
Documentation/kernel-parameters.txt | 18 +++---
drivers/tty/serial/8250/8250_core.c | 37 +---
drivers/tty/serial/8250/8250_early.c | 19 --
3 files changed, 49 insertions(+), 25 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index bfcb1a6..1facf0b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -713,10 +713,18 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+ uart[8250],mmio32,[,options]
+ uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
- switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ switching to the matching ttyS device later.
+ MMIO inter-register address stride is either 8-bit
+ (mmio) or 32-bit (mmio32).
+ If none of [io|mmio|mmio32], is assumed to be
+ equivalent to 'mmio'. 'options' are specified in the
+ same format described for ttyS above; if unspecified,
+ the h/w is not re-initialized.
+
hvc Use the hypervisor console device . This is for
both Xen and PowerPC hypervisors.
@@ -944,11 +952,15 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
uart[8250],mmio32,[,options]
+ uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
MMIO inter-register address stride is either 8-bit
(mmio) or 32-bit (mmio32).
- The options are the same as for ttyS, above.
+ If none of [io|mmio|mmio32], is assumed to be
+ equivalent to 'mmio'. 'options' are specified in the
+ same format described for "console=ttyS"; if
+ unspecified, the h/w is not initialized.
pl011,
Start an early, polled-mode console on a pl011 serial
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e0fb5f0..456606f 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3447,6 +3447,21 @@ static int univ8250_console_setup(struct console *co,
char *options)
return serial8250_console_setup(up, options);
}
+static unsigned int probe_baud(struct uart_port *port)
+{
+ unsigned char lcr, dll, dlm;
+ unsigned int quot;
+
+ lcr = serial_port_in(port, UART_LCR);
+ serial_port_out(port, UART_LCR, lcr | UART_LCR_DLAB);
+ dll = serial_port_in(port, UART_DLL);
+ dlm = serial_port_in(port, UART_DLM);
+ serial_port_out(port, UART_LCR, lcr);
+
+ quot = (dlm << 8) | dll;
+ return (port->uartclk / 16) / quot;
+}
+
/**
* univ8250_console_match - non-standard console matching
* @co: registering console
@@ -3455,13 +3470,18 @@ static int univ8250_console_setup(struct console *co,
char *options)
* @options: ptr to option string from console command line
*
* Only attempts to match console command lines of the form:
- * console=uart<>,io|mmio|mmio32,,
- * console=uart<>,,options
+ * console=uart[8250],io|mmio|mmio32,[,]
+ * console=uart[8250],0x[,]
* This form is used to register an initial earlycon boot console and
* replace it with the serial8250_console at 8250 driver init.
*
* Performs console setup for a match (as required by interface)
*
+ *
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, Apr 04, 2015 at 06:20:53PM +0200, Julia Lawall wrote: > Couldn't one say: > > x = NULL; > y = >whatever; > z = container_of(y, struct blah, whatever); > > and end up with z being NULL? That is crazy person code. It looks deliberately wrong. If we start merging deliberate mistakes then we're already screwed. I have a smatch check which warns on container_of() but I should update it to not complain if it's the first struct member. I have looked at quite a few of these warnings and I worry that there are some places where it relies on container_of() to be a no-op... That's also crazy but it's the kind of crazy that people do in real life. :P regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi! > enable-gpios: Specifier of the GPIO connected to EN pin > > I can make the changes if you're ok with that, otherwise please send v7. Then > I'll apply that to my tree. I'm ok with that. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: dsa: fix filling rtable from OF description
Hi Andrew
В письме от 4 апреля 2015 18:38:14 пользователь Andrew Lunn написал:
> There is the code after applying your patch:
>
> static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
> struct dsa_chip_data *cd,
> int chip_index, int port_index,
> struct device_node *link)
> {
> const __be32 *reg;
> int link_sw_addr;
> struct device_node *parent_sw;
> int len;
>
> parent_sw = of_get_parent(link);
> if (!parent_sw)
> return -EINVAL;
>
> link is the phandle to the port in other switch. parent_sw is then the
> switch property.
yep
> reg = of_get_property(parent_sw, "reg", );
> if (!reg || (len != sizeof(*reg) * 2))
> return -EINVAL;
>
> So now you get the reg property. This is documented as:
>
> - reg : Describes the switch address on the MII bus
Yes, but read further in the entry example:
"reg = <16 0>; /* MDIO address 16, switch 0 in tree */"
> link_sw_addr = be32_to_cpup(reg + 1);
Now we extract switch number (" + 1"), but not switch MDIO address.
>
> if (link_sw_addr >= pd->nr_chips)
> return -EINVAL;
>
> This is now not making much sense.
>
> Looking up the MII bus address seems wrong. You want the chip number,
> not its address.
Yes, you are right that its wrong to take MII address, but this code is taking
switch number, not its address. I can agree that this is silly, but it is not
my code originally and patch fixes other thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] nohz: make nohz_full imply isolcpus
On 4/4/2015 10:10 AM, Rik van Riel wrote: Rik, what's the change you're proposing that's similar to this one? Thanks! I don't have this particular one, and I like it. I know there are use cases where isolcpus= without nohz_full= makes sense, but I cannot think of the reverse. Acked-by: Rik van Riel Thanks, I'll push it via the tile tree unless someone would prefer otherwise. (The tick_nohz_full_set_cpus() and tick_nohz_full_clear_cpus() routines are in earlier tile tree commits, the latter supporting a change to the tile network driver.) Mike, I added your Thumbs-Up-by: Mike Galbraith :-) -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] earlycon: 8250: Fix command line regression
On 04/04/2015 12:52 PM, Greg Kroah-Hartman wrote: > On Sat, Apr 04, 2015 at 12:23:14PM -0400, Peter Hurley wrote: >> On 04/04/2015 12:09 PM, Greg Kroah-Hartman wrote: >>> On Sat, Apr 04, 2015 at 10:27:30AM -0400, Peter Hurley wrote: [...] +/* FIXME: this is broken on most other 8250 h/w */ >>> >>> What do you mean by "most other"? What hardware does this work for? >>> What is it broken for? What is someone supposed to think/do with this >>> comment? >> >> It's a direct copy of the existing behavior for 8250 earlycon, which is >> broken for h/w with non-standard divisor registers. That's basically >> _every_ new design, because that's what vendors need to extend to support >> modern bitrates. >> >> Affected h/w that I know of includes: 8250_dw, exar xr17v35 cards, omap8250, >> omap15xx, intel byt, intel mid. >> >> But it was already broken for these and so not a regression. > > Sorry, I know the function is a copy, you haven't broken anything that > wasn't already broken. I see this comment as a "rant", but we might as > well turn that "rant" into something descriptive to let other people > know what is really going on here. It's not intended as rant. My concern is that it appears as "desirable" code because it's new, when that's not my intention. When others go to implement earlycon-to-console handoff, my hope is that they don't follow this exemplar. Unfortunately, since this is the only driver that implements earlycon-to-console handoff (right now), some might just simply copy the behavior here. My intention is to discourage that. > Sound reasonable? Ok. How about "most new"? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/signal: Remove pax argument from restore_sigcontext
On Sat, Apr 4, 2015 at 10:14 AM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> The pax argument is unnecesary. Instead, store the RAX value directly
>> in regs.
>>
>> Signed-off-by: Brian Gerst
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: Andy Lutomirski
>> Cc: Denys Vlasenko
>> Cc: Linus Torvalds
>> Cc: Borislav Petkov
>> Cc: x...@kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> arch/x86/ia32/ia32_signal.c| 17 ++---
>> arch/x86/include/asm/sighandling.h | 4 +---
>> arch/x86/kernel/signal.c | 22 --
>> 3 files changed, 15 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
>> index 1f5e2b0..c81d35e6 100644
>> --- a/arch/x86/ia32/ia32_signal.c
>> +++ b/arch/x86/ia32/ia32_signal.c
>> @@ -161,8 +161,7 @@ int copy_siginfo_from_user32(siginfo_t *to,
>> compat_siginfo_t __user *from)
>> }
>>
>> static int ia32_restore_sigcontext(struct pt_regs *regs,
>> -struct sigcontext_ia32 __user *sc,
>> -unsigned int *pax)
>> +struct sigcontext_ia32 __user *sc)
>> {
>> unsigned int tmpflags, err = 0;
>> void __user *buf;
>> @@ -184,7 +183,7 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
>> RELOAD_SEG(es);
>>
>> COPY(di); COPY(si); COPY(bp); COPY(sp); COPY(bx);
>> - COPY(dx); COPY(cx); COPY(ip);
>> + COPY(dx); COPY(cx); COPY(ip); COPY(ax);
>> /* Don't touch extended registers */
>>
>> COPY_SEG_CPL3(cs);
>> @@ -197,8 +196,6 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
>>
>> get_user_ex(tmp, >fpstate);
>> buf = compat_ptr(tmp);
>> -
>> - get_user_ex(*pax, >ax);
>> } get_user_catch(err);
>
> Note that arch/x86/kernel/signal.c appears to have a similar pattern -
> and there it could be removed as well?
I'm guessing you didn't read the whole patch, because I did change it.
> I'm wondering what the original reason for adding the extra handling
> of regs->ax was. Maybe something changed regs->ax - but I cannot find
> such code path anymore.
>
> It would be nice to try to do a bit of Git archeology to figure out
> the origins of this complication - maybe it's something subtle - or
> it's something that has changed meanwhile.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/memory: print also a_ops->readpage in print_bad_pte
On Sat, Apr 4, 2015 at 4:35 AM, Andrew Morton wrote: > On Sat, 4 Apr 2015 03:47:12 +0300 Konstantin Khlebnikov > wrote: > >> On Sat, Apr 4, 2015 at 1:10 AM, Andrew Morton >> wrote: >> > On Fri, 03 Apr 2015 20:18:18 +0300 Konstantin Khlebnikov >> > wrote: >> > >> >> A lot of filesystems use generic_file_mmap() and filemap_fault(), >> >> f_op->mmap and vm_ops->fault aren't enough to identify filesystem. >> >> >> >> This prints file name, vm_ops->fault, f_op->mmap and a_ops->readpage >> >> (which is almost always implemented and filesystem-specific). >> >> >> >> Example: >> >> >> >> [ 23.676410] BUG: Bad page map in process sh pte:1b7e6025 pmd:19bbd067 >> >> [ 23.676887] page:ea6df980 count:4 mapcount:1 >> >> mapping:8800196426c0 index:0x97 >> >> [ 23.677481] flags: 0x10c(referenced|uptodate) >> >> [ 23.677896] page dumped because: bad pte >> >> [ 23.678205] addr:7f52fcb17000 vm_flags:0075 anon_vma: >> >> (null) mapping:8800196426c0 index:97 >> >> [ 23.678922] file:libc-2.19.so fault:filemap_fault >> >> mmap:generic_file_readonly_mmap readpage:v9fs_vfs_readpage >> > >> > Is that why we print these out? Just to identify the fs type? >> > >> > There's always vma->vm_file->f_inode->i_sb->s_magic ;) >> >> Yes, but that also might be anon inode/file mapped by some driver, so >> s_magic isn't enough. > > Well, we could ensure that every file_system_type has a valid ->name. > Do an audit, put a debug check in register_filesystem()? Anyway there are a lot of pseudo filesystems which are a used in many places (bdev sockfs anon_inodefs). Plus char dev inodes belongs to normal filesystem but their f_ops points to somewhere else. Printed mmap/fault/readpage points exactly to the code which is in charge of that page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] marvell-ccic: fix memory leak on failure path in cafe_smbus_setup()
On 04.04.2015 16:36, Jonathan Corbet wrote: > On Sat, 4 Apr 2015 03:16:01 +0300 > Alexey Khoroshilov wrote: > >> If i2c_add_adapter() fails, adap is not deallocated. >> >> Found by Linux Driver Verification project (linuxtesting.org). >> >> Signed-off-by: Alexey Khoroshilov > > Actually, the worse thing is that it leaves the IRQ enabled...it's good > you moved that lines down. Even better, of course, that the failure path > has probably never been run during the life of this driver...:) And hopefully it will not, but we will be ready:) > > Should there be some sort of proper reported-by line for the driver > verification project? Till now, we used "Found by" line, but we are open to any better way. > > Acked-by: Jonathan Corbet -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: optimize IRET returns to kernel
On Tue, Mar 31, 2015 at 8:59 AM, Denys Vlasenko wrote: > On 03/31/2015 03:54 PM, Andy Lutomirski wrote: >> On Tue, Mar 31, 2015 at 5:46 AM, Denys Vlasenko wrote: >>> This is not proposed to be merged yet. >>> >>> Andy, this patch is in spirit of your crazy ideas of repurposing >>> instructions for the roles they weren't intended for :) >>> >>> Recently I measured IRET timings and was newly "impressed" >>> how slow it is. 200+ cycles. So I started thinking... >>> >>> When we return from interrupt/exception *to kernel*, >>> most of IRET's doings are not necessary. CS and SS >>> do not need changing. And in many (most?) cases >>> saved RSP points right at the top of pt_regs, >>> or (top of pt_regs+8). >>> >>> In which case we can (ab)use POPF and RET! >>> >>> Please see the patch. >> >> I have an old attempt at this here: >> >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=fast-return-to-kernel=6cfe29821979c42cd812878e05577f69f99fafaf > > Your version is better :/ > > I'd only suggests/pop %rsp/mov (%rsp),%rsp/ > > I suspect "pop %rsp" is not an easy insn for CPU to digest. > >> If I were doing it again, I'd add a bit more care: if saved eflags >> have RF set (can kgdb do that?), then we have to use iret. > > Good idea, we can even be paranoid and jump to real IRET if any > of "unusual" flags are set. > >> I think that, if returning to IF=1, you need to do sti;ret to avoid an >> infinite stack usage failure in which, during an IRQ storm, each IRQ >> adds around one word of stack utilization because you haven't done the >> ret yet before the next IRQ comes in. To make that robust, I'd adjust >> the NMI code to clear IF and back up one instruction if it interrupts >> after sti. > > I kinda hoped POPF is secretly a shadowing insn too. > Experiments show it is not. > I'll fiddle with this some more at some point. First I want to get rid of IST for #DB and #BP, which will reduce the number of funny cases to think about. I hope to have patches for that ready short after the next merge window closes. -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, Apr 04, 2015 at 06:20:53PM +0200, Julia Lawall wrote:
>
>
> On Sat, 4 Apr 2015, Greg Kroah-Hartman wrote:
>
> > On Sat, Apr 04, 2015 at 04:59:30PM +0200, Julia Lawall wrote:
> > > Put NULL test on the result of the previous call instead on one of its
> > > arguments. A simplified version of the semantic match that finds this
> > > problem is as follows (http://coccinelle.lip6.fr/):
> > >
> > > //
> > > r@
> > > expression *e1;
> > > expression *e2;
> > > identifier f;
> > > statement S1,S2;
> > > @@
> > >
> > > e1 = f(...,e2,...);
> > > (
> > > if (e1 == NULL || ...) S1 else S2
> > > |
> > > *if (e2 == NULL || ...) S1 else S2
> > > )
> > > //
> > >
> > > Signed-off-by: Julia Lawall
> > >
> > > ---
> > > drivers/staging/emxx_udc/emxx_udc.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> > > b/drivers/staging/emxx_udc/emxx_udc.c
> > > index fbf82bc..7de1e9e 100644
> > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > @@ -2998,7 +2998,7 @@ static void nbu2ss_ep_fifo_flush(struct usb_ep
> > > *_ep)
> > > }
> > >
> > > ep = container_of(_ep, struct nbu2ss_ep, ep);
> > > - if (!_ep) {
> > > + if (!ep) {
> >
> > This is actually even worse, container_of() can't return NULL. Or if it
> > does, something is really wrong (it can only happen if the field happens
> > to be the first field in the structure and the original pointer was
> > NULL). So I would say that all tests for container_of (and
> > functions/macros that are just wrappers around container_of()) can just
> > be deleted as they will never be triggered.
>
> Couldn't one say:
>
> x = NULL;
> y = >whatever;
> z = container_of(y, struct blah, whatever);
>
> and end up with z being NULL?
Yes, if you were really lucky. If you are passing a pointer to
container_of() it had better be checked to be NULL before, not after,
the operation, as afterward makes no sense because this is just pointer
math happening.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] earlycon: 8250: Fix command line regression
On Sat, Apr 04, 2015 at 12:23:14PM -0400, Peter Hurley wrote:
> On 04/04/2015 12:09 PM, Greg Kroah-Hartman wrote:
> > On Sat, Apr 04, 2015 at 10:27:30AM -0400, Peter Hurley wrote:
> >> Restore undocumented behavior of kernel command line parameters of
> >> the forms:
> >> console=uart[8250],io|mmio|mmio32,[,options]
> >> console=uart[8250],[,options]
> >> where 'options' have not been specified; in this case, the hardware
> >> is assumed to be initialized.
> >>
> >> Document the required behavior of the original implementation.
> >>
> >> Fixes: c7cef0a84912cab3c9df8 ("console: Add extensible console matching")
> >> Reported-by: Yinghai Lu
> >> Signed-off-by: Peter Hurley
> >> ---
> >>
> >> v3: Fixed automatic console to port line settings initialization;
> >> open-coded serial8250_console_setup() so the baud can be probed;
> >> added sha reference in commit log
> >>
> >> v2: Fixed regression which allowed "console=uart1337,..." to start a
> >> console (but not an earlycon)
> >> + fixed earlycon= documentation related required behavior fixed by
> >> this patch
> >>
> >> Documentation/kernel-parameters.txt | 18 ++---
> >> drivers/tty/serial/8250/8250_core.c | 38
> >> +---
> >> drivers/tty/serial/8250/8250_early.c | 19 --
> >> 3 files changed, 50 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/Documentation/kernel-parameters.txt
> >> b/Documentation/kernel-parameters.txt
> >> index bfcb1a6..1facf0b 100644
> >> --- a/Documentation/kernel-parameters.txt
> >> +++ b/Documentation/kernel-parameters.txt
> >> @@ -713,10 +713,18 @@ bytes respectively. Such letter suffixes can also be
> >> entirely omitted.
> >>
> >>uart[8250],io,[,options]
> >>uart[8250],mmio,[,options]
> >> + uart[8250],mmio32,[,options]
> >> + uart[8250],0x[,options]
> >>Start an early, polled-mode console on the 8250/16550
> >>UART at the specified I/O port or MMIO address,
> >> - switching to the matching ttyS device later. The
> >> - options are the same as for ttyS, above.
> >> + switching to the matching ttyS device later.
> >> + MMIO inter-register address stride is either 8-bit
> >> + (mmio) or 32-bit (mmio32).
> >> + If none of [io|mmio|mmio32], is assumed to be
> >> + equivalent to 'mmio'. 'options' are specified in the
> >> + same format described for ttyS above; if unspecified,
> >> + the h/w is not re-initialized.
> >> +
> >>hvc Use the hypervisor console device . This is for
> >>both Xen and PowerPC hypervisors.
> >>
> >> @@ -944,11 +952,15 @@ bytes respectively. Such letter suffixes can also be
> >> entirely omitted.
> >>uart[8250],io,[,options]
> >>uart[8250],mmio,[,options]
> >>uart[8250],mmio32,[,options]
> >> + uart[8250],0x[,options]
> >>Start an early, polled-mode console on the 8250/16550
> >>UART at the specified I/O port or MMIO address.
> >>MMIO inter-register address stride is either 8-bit
> >>(mmio) or 32-bit (mmio32).
> >> - The options are the same as for ttyS, above.
> >> + If none of [io|mmio|mmio32], is assumed to be
> >> + equivalent to 'mmio'. 'options' are specified in the
> >> + same format described for "console=ttyS"; if
> >> + unspecified, the h/w is not initialized.
> >>
> >>pl011,
> >>Start an early, polled-mode console on a pl011 serial
> >> diff --git a/drivers/tty/serial/8250/8250_core.c
> >> b/drivers/tty/serial/8250/8250_core.c
> >> index e0fb5f0..f59c7a0 100644
> >> --- a/drivers/tty/serial/8250/8250_core.c
> >> +++ b/drivers/tty/serial/8250/8250_core.c
> >> @@ -3447,6 +3447,22 @@ static int univ8250_console_setup(struct console
> >> *co, char *options)
> >>return serial8250_console_setup(up, options);
> >> }
> >>
> >> +/* FIXME: this is broken on most other 8250 h/w */
> >
> > What do you mean by "most other"? What hardware does this work for?
> > What is it broken for? What is someone supposed to think/do with this
> > comment?
>
> It's a direct copy of the existing behavior for 8250 earlycon, which is
> broken for h/w with non-standard divisor registers. That's basically
> _every_ new design, because that's what vendors need to extend to support
> modern bitrates.
>
> Affected h/w that I know of includes: 8250_dw, exar xr17v35 cards, omap8250,
> omap15xx, intel byt, intel mid.
>
> But it was already broken for these and so not a regression.
Sorry, I know the function is a copy, you haven't broken anything that
wasn't already broken. I see this comment as a "rant", but we
Re: [PATCH] net: dsa: fix filling rtable from OF description
Hi Pavel
There is the code after applying your patch:
static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
struct dsa_chip_data *cd,
int chip_index, int port_index,
struct device_node *link)
{
const __be32 *reg;
int link_sw_addr;
struct device_node *parent_sw;
int len;
parent_sw = of_get_parent(link);
if (!parent_sw)
return -EINVAL;
link is the phandle to the port in other switch. parent_sw is then the
switch property.
reg = of_get_property(parent_sw, "reg", );
if (!reg || (len != sizeof(*reg) * 2))
return -EINVAL;
So now you get the reg property. This is documented as:
- reg : Describes the switch address on the MII bus
link_sw_addr = be32_to_cpup(reg + 1);
if (link_sw_addr >= pd->nr_chips)
return -EINVAL;
This is now not making much sense.
Looking up the MII bus address seems wrong. You want the chip number,
not its address.
Andrew
/* First time routing table allocation */
if (!cd->rtable) {
cd->rtable = kmalloc_array(pd->nr_chips, sizeof(s8),
GFP_KERNEL);
if (!cd->rtable)
return -ENOMEM;
/* default to no valid uplink/downlink */
memset(cd->rtable, -1, pd->nr_chips * sizeof(s8));
}
cd->rtable[link_sw_addr] = port_index;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] iio: Documentation: Add documentation for IIO configfs
A whitespace nit. The horror! On Fri, 2015-04-03 at 18:58 +0300, Daniel Baluta wrote: > --- /dev/null > +++ b/Documentation/iio/iio_configfs.txt > ** create new attributes and them to the IIO configfs core. >+[...] > +4. Further work > + > +* add "sysfs" trigger type > + "git am" whined: "new blank line at EOF". Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86: deinline dma_free_attrs()
Reduces kernel size by 76720 bytes on allyesconfig build:
text data bss dec hex filename
82594029 22255352 20627456 125476837 77a9fe5 vmlinux1
82517277 22255384 20627456 125400117 7797435 vmlinux2
Signed-off-by: Denys Vlasenko
Cc: Marek Szyprowski
Cc: Konrad Rzeszutek Wilk
Cc: David Woodhouse
Cc: Don Dutile
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/dma-mapping.h | 18 +++---
arch/x86/kernel/pci-dma.c | 16
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mapping.h
index 6339320..1f5b728 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -133,20 +133,8 @@ dma_alloc_attrs(struct device *dev, size_t size,
dma_addr_t *dma_handle,
#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
-static inline void dma_free_attrs(struct device *dev, size_t size,
- void *vaddr, dma_addr_t bus,
- struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
-
- WARN_ON(irqs_disabled()); /* for portability */
-
- if (dma_release_from_coherent(dev, get_order(size), vaddr))
- return;
-
- debug_dma_free_coherent(dev, size, vaddr, bus);
- if (ops->free)
- ops->free(dev, size, vaddr, bus, attrs);
-}
+void dma_free_attrs(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t bus,
+ struct dma_attrs *attrs);
#endif
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 74e2f6a..4fa0f15 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -167,6 +167,22 @@ void *dma_alloc_attrs(struct device *dev, size_t size,
dma_addr_t *dma_handle,
return memory;
}
+void dma_free_attrs(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t bus,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ WARN_ON(irqs_disabled()); /* for portability */
+
+ if (dma_release_from_coherent(dev, get_order(size), vaddr))
+ return;
+
+ debug_dma_free_coherent(dev, size, vaddr, bus);
+ if (ops->free)
+ ops->free(dev, size, vaddr, bus, attrs);
+}
+
/*
* See for the iommu kernel
* parameter documentation.
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: deinline dma_alloc_attrs()
Reduces kernel size by 68739 bytes on allyesconfig build:
text data bss dec hex filename
82662736 22255384 20627456 125545576 77bac68 vmlinux0
82594029 22255352 20627456 125476837 77a9fe5 vmlinux1
Signed-off-by: Denys Vlasenko
Cc: Marek Szyprowski
Cc: Konrad Rzeszutek Wilk
Cc: David Woodhouse
Cc: Don Dutile
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/include/asm/dma-mapping.h | 28 ++--
arch/x86/kernel/pci-dma.c | 27 +++
2 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mapping.h
index 808dae6..6339320 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -127,33 +127,9 @@ static inline gfp_t dma_alloc_coherent_gfp_flags(struct
device *dev, gfp_t gfp)
#define dma_alloc_coherent(d,s,h,f)dma_alloc_attrs(d,s,h,f,NULL)
-static inline void *
+void *
dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
- gfp_t gfp, struct dma_attrs *attrs)
-{
- struct dma_map_ops *ops = get_dma_ops(dev);
- void *memory;
-
- gfp &= ~(__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32);
-
- if (dma_alloc_from_coherent(dev, size, dma_handle, ))
- return memory;
-
- if (!dev)
- dev = _dma_fallback_dev;
-
- if (!is_device_dma_capable(dev))
- return NULL;
-
- if (!ops->alloc)
- return NULL;
-
- memory = ops->alloc(dev, size, dma_handle,
- dma_alloc_coherent_gfp_flags(dev, gfp), attrs);
- debug_dma_alloc_coherent(dev, size, *dma_handle, memory);
-
- return memory;
-}
+ gfp_t gfp, struct dma_attrs *attrs);
#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..74e2f6a 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,33 @@ void dma_generic_free_coherent(struct device *dev, size_t
size, void *vaddr,
free_pages((unsigned long)vaddr, get_order(size));
}
+void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
+ gfp_t gfp, struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ void *memory;
+
+ gfp &= ~(__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32);
+
+ if (dma_alloc_from_coherent(dev, size, dma_handle, ))
+ return memory;
+
+ if (!dev)
+ dev = _dma_fallback_dev;
+
+ if (!is_device_dma_capable(dev))
+ return NULL;
+
+ if (!ops->alloc)
+ return NULL;
+
+ memory = ops->alloc(dev, size, dma_handle,
+ dma_alloc_coherent_gfp_flags(dev, gfp), attrs);
+ debug_dma_alloc_coherent(dev, size, *dma_handle, memory);
+
+ return memory;
+}
+
/*
* See for the iommu kernel
* parameter documentation.
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] earlycon: 8250: Fix command line regression
On 04/04/2015 12:09 PM, Greg Kroah-Hartman wrote:
> On Sat, Apr 04, 2015 at 10:27:30AM -0400, Peter Hurley wrote:
>> Restore undocumented behavior of kernel command line parameters of
>> the forms:
>> console=uart[8250],io|mmio|mmio32,[,options]
>> console=uart[8250],[,options]
>> where 'options' have not been specified; in this case, the hardware
>> is assumed to be initialized.
>>
>> Document the required behavior of the original implementation.
>>
>> Fixes: c7cef0a84912cab3c9df8 ("console: Add extensible console matching")
>> Reported-by: Yinghai Lu
>> Signed-off-by: Peter Hurley
>> ---
>>
>> v3: Fixed automatic console to port line settings initialization;
>> open-coded serial8250_console_setup() so the baud can be probed;
>> added sha reference in commit log
>>
>> v2: Fixed regression which allowed "console=uart1337,..." to start a
>> console (but not an earlycon)
>> + fixed earlycon= documentation related required behavior fixed by
>> this patch
>>
>> Documentation/kernel-parameters.txt | 18 ++---
>> drivers/tty/serial/8250/8250_core.c | 38
>> +---
>> drivers/tty/serial/8250/8250_early.c | 19 --
>> 3 files changed, 50 insertions(+), 25 deletions(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index bfcb1a6..1facf0b 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -713,10 +713,18 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>>
>> uart[8250],io,[,options]
>> uart[8250],mmio,[,options]
>> +uart[8250],mmio32,[,options]
>> +uart[8250],0x[,options]
>> Start an early, polled-mode console on the 8250/16550
>> UART at the specified I/O port or MMIO address,
>> -switching to the matching ttyS device later. The
>> -options are the same as for ttyS, above.
>> +switching to the matching ttyS device later.
>> +MMIO inter-register address stride is either 8-bit
>> +(mmio) or 32-bit (mmio32).
>> +If none of [io|mmio|mmio32], is assumed to be
>> +equivalent to 'mmio'. 'options' are specified in the
>> +same format described for ttyS above; if unspecified,
>> +the h/w is not re-initialized.
>> +
>> hvc Use the hypervisor console device . This is for
>> both Xen and PowerPC hypervisors.
>>
>> @@ -944,11 +952,15 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>> uart[8250],io,[,options]
>> uart[8250],mmio,[,options]
>> uart[8250],mmio32,[,options]
>> +uart[8250],0x[,options]
>> Start an early, polled-mode console on the 8250/16550
>> UART at the specified I/O port or MMIO address.
>> MMIO inter-register address stride is either 8-bit
>> (mmio) or 32-bit (mmio32).
>> -The options are the same as for ttyS, above.
>> +If none of [io|mmio|mmio32], is assumed to be
>> +equivalent to 'mmio'. 'options' are specified in the
>> +same format described for "console=ttyS"; if
>> +unspecified, the h/w is not initialized.
>>
>> pl011,
>> Start an early, polled-mode console on a pl011 serial
>> diff --git a/drivers/tty/serial/8250/8250_core.c
>> b/drivers/tty/serial/8250/8250_core.c
>> index e0fb5f0..f59c7a0 100644
>> --- a/drivers/tty/serial/8250/8250_core.c
>> +++ b/drivers/tty/serial/8250/8250_core.c
>> @@ -3447,6 +3447,22 @@ static int univ8250_console_setup(struct console *co,
>> char *options)
>> return serial8250_console_setup(up, options);
>> }
>>
>> +/* FIXME: this is broken on most other 8250 h/w */
>
> What do you mean by "most other"? What hardware does this work for?
> What is it broken for? What is someone supposed to think/do with this
> comment?
It's a direct copy of the existing behavior for 8250 earlycon, which is
broken for h/w with non-standard divisor registers. That's basically
_every_ new design, because that's what vendors need to extend to support
modern bitrates.
Affected h/w that I know of includes: 8250_dw, exar xr17v35 cards, omap8250,
omap15xx, intel byt, intel mid.
But it was already broken for these and so not a regression.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, 4 Apr 2015, Greg Kroah-Hartman wrote:
> On Sat, Apr 04, 2015 at 04:59:30PM +0200, Julia Lawall wrote:
> > Put NULL test on the result of the previous call instead on one of its
> > arguments. A simplified version of the semantic match that finds this
> > problem is as follows (http://coccinelle.lip6.fr/):
> >
> > //
> > r@
> > expression *e1;
> > expression *e2;
> > identifier f;
> > statement S1,S2;
> > @@
> >
> > e1 = f(...,e2,...);
> > (
> > if (e1 == NULL || ...) S1 else S2
> > |
> > *if (e2 == NULL || ...) S1 else S2
> > )
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/staging/emxx_udc/emxx_udc.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> > b/drivers/staging/emxx_udc/emxx_udc.c
> > index fbf82bc..7de1e9e 100644
> > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > @@ -2998,7 +2998,7 @@ static void nbu2ss_ep_fifo_flush(struct usb_ep *_ep)
> > }
> >
> > ep = container_of(_ep, struct nbu2ss_ep, ep);
> > - if (!_ep) {
> > + if (!ep) {
>
> This is actually even worse, container_of() can't return NULL. Or if it
> does, something is really wrong (it can only happen if the field happens
> to be the first field in the structure and the original pointer was
> NULL). So I would say that all tests for container_of (and
> functions/macros that are just wrappers around container_of()) can just
> be deleted as they will never be triggered.
Couldn't one say:
x = NULL;
y = >whatever;
z = container_of(y, struct blah, whatever);
and end up with z being NULL?
> Not to say that this patch is wrong at all, I'll go apply it, and you
> should add it to the lists of tests in the kernel source, but you should
> also consider making a test to catch container_of() results.
>
> Hm, now that I know coccinelle, I guess I should be able to do this :)
Yes indeed :)
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] earlycon: 8250: Fix command line regression
On Sat, Apr 04, 2015 at 10:27:30AM -0400, Peter Hurley wrote:
> Restore undocumented behavior of kernel command line parameters of
> the forms:
> console=uart[8250],io|mmio|mmio32,[,options]
> console=uart[8250],[,options]
> where 'options' have not been specified; in this case, the hardware
> is assumed to be initialized.
>
> Document the required behavior of the original implementation.
>
> Fixes: c7cef0a84912cab3c9df8 ("console: Add extensible console matching")
> Reported-by: Yinghai Lu
> Signed-off-by: Peter Hurley
> ---
>
> v3: Fixed automatic console to port line settings initialization;
> open-coded serial8250_console_setup() so the baud can be probed;
> added sha reference in commit log
>
> v2: Fixed regression which allowed "console=uart1337,..." to start a
> console (but not an earlycon)
> + fixed earlycon= documentation related required behavior fixed by
> this patch
>
> Documentation/kernel-parameters.txt | 18 ++---
> drivers/tty/serial/8250/8250_core.c | 38
> +---
> drivers/tty/serial/8250/8250_early.c | 19 --
> 3 files changed, 50 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index bfcb1a6..1facf0b 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -713,10 +713,18 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>
> uart[8250],io,[,options]
> uart[8250],mmio,[,options]
> + uart[8250],mmio32,[,options]
> + uart[8250],0x[,options]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address,
> - switching to the matching ttyS device later. The
> - options are the same as for ttyS, above.
> + switching to the matching ttyS device later.
> + MMIO inter-register address stride is either 8-bit
> + (mmio) or 32-bit (mmio32).
> + If none of [io|mmio|mmio32], is assumed to be
> + equivalent to 'mmio'. 'options' are specified in the
> + same format described for ttyS above; if unspecified,
> + the h/w is not re-initialized.
> +
> hvc Use the hypervisor console device . This is for
> both Xen and PowerPC hypervisors.
>
> @@ -944,11 +952,15 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> uart[8250],io,[,options]
> uart[8250],mmio,[,options]
> uart[8250],mmio32,[,options]
> + uart[8250],0x[,options]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address.
> MMIO inter-register address stride is either 8-bit
> (mmio) or 32-bit (mmio32).
> - The options are the same as for ttyS, above.
> + If none of [io|mmio|mmio32], is assumed to be
> + equivalent to 'mmio'. 'options' are specified in the
> + same format described for "console=ttyS"; if
> + unspecified, the h/w is not initialized.
>
> pl011,
> Start an early, polled-mode console on a pl011 serial
> diff --git a/drivers/tty/serial/8250/8250_core.c
> b/drivers/tty/serial/8250/8250_core.c
> index e0fb5f0..f59c7a0 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -3447,6 +3447,22 @@ static int univ8250_console_setup(struct console *co,
> char *options)
> return serial8250_console_setup(up, options);
> }
>
> +/* FIXME: this is broken on most other 8250 h/w */
What do you mean by "most other"? What hardware does this work for?
What is it broken for? What is someone supposed to think/do with this
comment?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, Apr 04, 2015 at 04:59:30PM +0200, Julia Lawall wrote:
> Put NULL test on the result of the previous call instead on one of its
> arguments. A simplified version of the semantic match that finds this
> problem is as follows (http://coccinelle.lip6.fr/):
>
> //
> r@
> expression *e1;
> expression *e2;
> identifier f;
> statement S1,S2;
> @@
>
> e1 = f(...,e2,...);
> (
> if (e1 == NULL || ...) S1 else S2
> |
> *if (e2 == NULL || ...) S1 else S2
> )
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/staging/emxx_udc/emxx_udc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> b/drivers/staging/emxx_udc/emxx_udc.c
> index fbf82bc..7de1e9e 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -2998,7 +2998,7 @@ static void nbu2ss_ep_fifo_flush(struct usb_ep *_ep)
> }
>
> ep = container_of(_ep, struct nbu2ss_ep, ep);
> - if (!_ep) {
> + if (!ep) {
This is actually even worse, container_of() can't return NULL. Or if it
does, something is really wrong (it can only happen if the field happens
to be the first field in the structure and the original pointer was
NULL). So I would say that all tests for container_of (and
functions/macros that are just wrappers around container_of()) can just
be deleted as they will never be triggered.
Not to say that this patch is wrong at all, I'll go apply it, and you
should add it to the lists of tests in the kernel source, but you should
also consider making a test to catch container_of() results.
Hm, now that I know coccinelle, I guess I should be able to do this :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
On Sat, Apr 04, 2015 at 06:59:58PM +0300, Dan Carpenter wrote:
> This is a clever Coccinelle check. :)
>
> On Sat, Apr 04, 2015 at 04:59:30PM +0200, Julia Lawall wrote:
> > Put NULL test on the result of the previous call instead on one of its
> > arguments. A simplified version of the semantic match that finds this
> > problem is as follows (http://coccinelle.lip6.fr/):
> >
> > //
> > r@
> > expression *e1;
> > expression *e2;
> > identifier f;
> > statement S1,S2;
> > @@
> >
> > e1 = f(...,e2,...);
> > (
> > if (e1 == NULL || ...) S1 else S2
> > |
> > *if (e2 == NULL || ...) S1 else S2
> > )
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/staging/emxx_udc/emxx_udc.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> > b/drivers/staging/emxx_udc/emxx_udc.c
> > index fbf82bc..7de1e9e 100644
> > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > @@ -2998,7 +2998,7 @@ static void nbu2ss_ep_fifo_flush(struct usb_ep *_ep)
> > }
> >
> > ep = container_of(_ep, struct nbu2ss_ep, ep);
> > - if (!_ep) {
> > + if (!ep) {
> > pr_err("udc: %s, bad ep\n", __func__);
> > return;
>
> The better thing to do here is to remove the condition. container_of()
> takes an pointer and subtracts an offset so testing the return value
> is normally meaningless.
>
> Sometimes (and in this case) the offset is zero. In that situation it
> might make sense to check the return value but it's an ugly thing to
> do because if we re-order the nbu2ss_ep struct layout so "ep" isn't the
> first member then it breaks.
>
> In this case we already verified that "_ep" is non-NULL so the check
> isn't needed.
This will teach me to read ahead in an email thread... :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: emxx_udc: test returned value
This is a clever Coccinelle check. :)
On Sat, Apr 04, 2015 at 04:59:30PM +0200, Julia Lawall wrote:
> Put NULL test on the result of the previous call instead on one of its
> arguments. A simplified version of the semantic match that finds this
> problem is as follows (http://coccinelle.lip6.fr/):
>
> //
> r@
> expression *e1;
> expression *e2;
> identifier f;
> statement S1,S2;
> @@
>
> e1 = f(...,e2,...);
> (
> if (e1 == NULL || ...) S1 else S2
> |
> *if (e2 == NULL || ...) S1 else S2
> )
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/staging/emxx_udc/emxx_udc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> b/drivers/staging/emxx_udc/emxx_udc.c
> index fbf82bc..7de1e9e 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -2998,7 +2998,7 @@ static void nbu2ss_ep_fifo_flush(struct usb_ep *_ep)
> }
>
> ep = container_of(_ep, struct nbu2ss_ep, ep);
> - if (!_ep) {
> + if (!ep) {
> pr_err("udc: %s, bad ep\n", __func__);
> return;
The better thing to do here is to remove the condition. container_of()
takes an pointer and subtracts an offset so testing the return value
is normally meaningless.
Sometimes (and in this case) the offset is zero. In that situation it
might make sense to check the return value but it's an ugly thing to
do because if we re-order the nbu2ss_ep struct layout so "ep" isn't the
first member then it breaks.
In this case we already verified that "_ep" is non-NULL so the check
isn't needed.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: rtl8188eu: Remove zero testing pointer typed value
On Sat, 2015-04-04 at 16:58 +0300, Dan Carpenter wrote: > On Sat, Apr 04, 2015 at 12:04:59AM +0300, Dan Carpenter wrote: > > 1) It's more clear when read in English. "if not strcmp then" or > > "if strcmp NOT EQUAL zero". > Oops. I got that reversed. I meant "if strcmp then". Only serves to > emphasize my point though. :) When I read it I understood what you meant, but I thought the point was everybody makes mistakes. !strcmp to test equality is still pretty idiomatic. !memcmp too. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/7] tracing: Add 'hist' event trigger command
On Fri, Apr 3, 2015 at 8:51 AM, Tom Zanussi wrote:
> +static struct hist_trigger_entry *
> +tracing_map_insert(struct tracing_map *map, void *key)
> +{
> + u32 idx, key_hash, test_key;
> +
> + key_hash = jhash(key, map->key_size, 0);
> + idx = key_hash >> (32 - (map->map_bits + 1));
> +
> + while (1) {
> + idx &= (map->map_size - 1);
> + test_key = map->map[idx].key;
> +
> + if (test_key && test_key == key_hash &&
> + keys_match(key, map->map[idx].val->key, map->key_size))
> + return map->map[idx].val;
> +
> + if (!test_key && !cmpxchg(>map[idx].key, 0, key_hash)) {
> + struct hist_trigger_entry *entry;
> +
> + entry = hist_trigger_entry_create(map);
> + if (!entry)
> + break;
> + memcpy(entry->key, key, map->key_size);
> + map->map[idx].val = entry;
> +
> + return map->map[idx].val;
> + }
There is obvious race here, since algorithm is not implemented correctly.
Partially inserted key/value is not handled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
