Re: [PATCH v3] Add ARCH_MIGHT_HAVE_VGA_CONSOLE
At Wed, 04 Feb 2015 08:37:16 +0100, Arnd Bergmann wrote: > > On Wednesday 04 February 2015 15:03:32 Yoshinori Sato wrote: > > @@ -2,14 +2,14 @@ > > # Video configuration > > # > > > > +config ARCH_MIGHT_HAVE_VGA_CONSOLE > > +bool > > + > > menu "Console display driver support" > > > > > > I just noticed one more problem: The file that you add the option to is > conditional on CONFIG_VT, and that option is user-selectable. If > VT is disabled, you will get a warning from architectures that select > the symbol. > > I think you should move the statement above into drivers/video/Kconfig, > outside of the 'if VT'. I see. Fixed. --- arch/alpha/Kconfig| 1 + arch/arm/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/x86/Kconfig | 1 + drivers/video/Kconfig | 4 +--- drivers/video/console/Kconfig | 11 ++- 8 files changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index b7ff9a3..5940d83 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -27,6 +27,7 @@ config ALPHA select MODULES_USE_ELF_RELA select ODD_RT_SIGACTION select OLD_SIGSUSPEND + select ARCH_MIGHT_HAVE_VGA_CONSOLE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory, diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 97d07ed..cd936c6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -7,6 +7,7 @@ config ARM select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_MIGHT_HAVE_PC_PARPORT + select ARCH_MIGHT_HAVE_VGA_CONSOLE if ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 074e52b..55e91d9 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -47,6 +47,7 @@ config IA64 select MODULES_USE_ELF_RELA select ARCH_USE_CMPXCHG_LOCKREF select HAVE_ARCH_AUDITSYSCALL + select ARCH_MIGHT_HAVE_VGA_CONSOLE default y help The Itanium Processor Family is Intel's 64-bit successor to diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 3289969..d921c4c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -54,6 +54,7 @@ config MIPS select CPU_PM if CPU_IDLE select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_BINFMT_ELF_STATE + select ARCH_MIGHT_HAVE_VGA_CONSOLE menu "Machine selection" diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a2a168e..4c2e2d2 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -152,6 +152,7 @@ config PPC select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN select NO_BOOTMEM select HAVE_GENERIC_RCU_GUP + select ARCH_MIGHT_HAVE_VGA_CONSOLE if !4xx && !8xx config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ba397bd..981c1a2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -138,6 +138,7 @@ config X86 select HAVE_ACPI_APEI_NMI if ACPI select ACPI_LEGACY_TABLES_LOOKUP if ACPI select X86_FEATURE_NAMES if PROC_FS + select ARCH_MIGHT_HAVE_VGA_CONSOLE config INSTRUCTION_DECODER def_bool y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8bf495f..5a8b576 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -42,9 +42,7 @@ config VIDEOMODE_HELPERS config HDMI bool -if VT - source "drivers/video/console/Kconfig" -endif +source "drivers/video/console/Kconfig" if FB || SGI_NEWPORT_CONSOLE source "drivers/video/logo/Kconfig" diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig index fe1cd01..98f0af1 100644 --- a/drivers/video/console/Kconfig +++ b/drivers/video/console/Kconfig @@ -2,14 +2,15 @@ # Video configuration # +config ARCH_MIGHT_HAVE_VGA_CONSOLE +bool + +if VT menu "Console display driver support" config VGA_CONSOLE bool "VGA text console" if EXPERT || !X86 - depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && \ - !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \ - (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \ - !ARM64 + depends on ARCH_MIGHT_HAVE_VGA_CONSOLE default y help Saying Y here will allow you to use Linux in text mode through a @@ -137,4 +138,4 @@ config STI_CONSOLE The alternative is to use your primary serial port as a console. endmenu - +endif -- 2.1.4 > > Arnd -- Yoshinori Sato -- To unsubscribe from this list: send the line
Re: [PATCH] drm: atmel-hlcdc: add discard area support
Rob, Daniel,
On Fri, 6 Feb 2015 18:32:19 -0500
Rob Clark wrote:
> On Fri, Feb 6, 2015 at 4:11 PM, Daniel Vetter wrote:
> > On Fri, Feb 06, 2015 at 04:31:02PM +0100, Boris Brezillon wrote:
> >> The HLCDC IP provides a way to discard a specific area on the primary
> >> plane (in case at least one of the overlay is activated and alpha
> >> blending is disabled).
> >> Doing this will reduce the amount of data to transfer from the main
> >> memory to the Display Controller, and thus alleviate the load on the
> >> memory bus (since this link is quite limited on such hardware,
> >> this kind of optimization is really important).
> >>
> >> Signed-off-by: Boris Brezillon
> >> ---
> >> Hi Daniel,
> >>
> >> Can you tell me if that's what you had in mind for the discard area feature
> >> we talked about yersterday.
> >>
> >> This patch depends on the Atmel HLCDC Atomic mode-setting conversion
> >> work [1].
> >>
> >> Best Regards,
> >>
> >> Boris
> >>
> >> [1]https://lkml.org/lkml/2015/2/4/658
> >>
> >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
> >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 108
> >>
> >> 3 files changed, 111 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> index de6973d..4fd1683 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> @@ -201,7 +201,7 @@ static int atmel_hlcdc_crtc_atomic_check(struct
> >> drm_crtc *c,
> >> if (atmel_hlcdc_dc_mode_valid(crtc->dc, >adjusted_mode) !=
> >> MODE_OK)
> >> return -EINVAL;
> >>
> >> - return 0;
> >> + return atmel_hlcdc_plane_prepare_disc_area(s);
> >> }
> >>
> >> static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> index 015c3f1..1ea9c2c 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> @@ -148,6 +148,8 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc
> >> *dc,
> >> struct atmel_hlcdc_planes *
> >> atmel_hlcdc_create_planes(struct drm_device *dev);
> >>
> >> +int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
> >> +
> >> void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
> >>
> >> void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> index 6c6fcae..dbf97d9 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> @@ -51,6 +51,13 @@ struct atmel_hlcdc_plane_state {
> >>
> >> u8 alpha;
> >>
> >> + bool disc_updated;
> >> +
> >> + int disc_x;
> >> + int disc_y;
> >> + int disc_w;
> >> + int disc_h;
> >> +
> >> /* These fields are private and should not be touched */
> >> int bpp[ATMEL_HLCDC_MAX_PLANES];
> >> unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
> >> @@ -428,6 +435,104 @@ static void atmel_hlcdc_plane_update_buffers(struct
> >> atmel_hlcdc_plane *plane,
> >> }
> >> }
> >>
> >> +int
> >> +atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
> >> +{
> >> + int disc_x = 0, disc_y = 0, disc_w = 0, disc_h = 0;
> >> + const struct atmel_hlcdc_layer_cfg_layout *layout;
> >> + struct atmel_hlcdc_plane_state *primary_state;
> >> + struct drm_plane_state *primary_s;
> >> + struct atmel_hlcdc_plane *primary;
> >> + struct drm_plane *ovl;
> >> +
> >> + primary = drm_plane_to_atmel_hlcdc_plane(c_state->crtc->primary);
> >> + layout = >layer.desc->layout;
> >> + if (!layout->disc_pos || !layout->disc_size)
> >> + return 0;
> >> +
> >> + primary_s = drm_atomic_get_plane_state(c_state->state,
> >> +>base);
> >> + if (IS_ERR(primary_s))
> >> + return PTR_ERR(primary_s);
> >> +
> >> + primary_state =
> >> drm_plane_state_to_atmel_hlcdc_plane_state(primary_s);
> >> +
> >> + drm_atomic_crtc_state_for_each_plane(ovl, c_state) {
> >> + struct atmel_hlcdc_plane_state *ovl_state;
> >> + struct drm_plane_state *ovl_s;
> >> +
> >> + if (ovl == c_state->crtc->primary)
> >> + continue;
> >> +
> >> + ovl_s = drm_atomic_get_plane_state(c_state->state, ovl);
> >> + if (IS_ERR(ovl_s))
> >> + return PTR_ERR(ovl_s);
> >> +
> >> + ovl_state =
> >> drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
> >
> > Note that right now the atomic helpers do not no-op out null plane state
> > updates. The assumption is that such plane states
Re: arm: kprobe compilation error
(2015/02/06 0:17), Janusz Użycki wrote: > Hi, > > I got the compilation error on next-20150204: > >CC arch/arm/probes/kprobes/actions-arm.o > In file included from arch/arm/probes/kprobes/actions-common.c:18: > arch/arm/probes/kprobes/core.h:43: error: '[*]' not allowed in other > than a declaration > make[2]: *** [arch/arm/probes/kprobes/actions-common.o] Błąd 1 > make[2]: *** Oczekiwanie na niezakończone zadania > In file included from arch/arm/probes/kprobes/actions-arm.c:66: > arch/arm/probes/kprobes/core.h:43: error: '[*]' not allowed in other > than a declaration > make[2]: *** [arch/arm/probes/kprobes/actions-arm.o] Błąd 1 > In file included from arch/arm/probes/kprobes/core.c:37: > arch/arm/probes/kprobes/core.h:43: error: '[*]' not allowed in other > than a declaration > make[2]: *** [arch/arm/probes/kprobes/core.o] Błąd 1 > make[1]: *** [arch/arm/probes/kprobes] Błąd 2 > make: *** [arch/arm/probes] Błąd 2 > > reason is *[*]: > const struct decode_checker *[*]); Thank you for reporting! I think there is a typo, it should be "const struct decode_checker *[]". Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit
On Fri, Feb 06, 2015 at 10:34:21PM -0800, Paul E. McKenney wrote: > On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 02/06/2015 06:15 PM, Frederic Weisbecker wrote: > > > > > Just a few things then: > > > > > > 1) In this case rename context_tracking_user_enter/exit() to > > > context_tracking_enter() and context_tracking_exit(), since it's > > > not anymore about user only but about any generic context. > > > > > > 2) We have the "WARN_ON_ONCE(!current->mm);" condition that is a > > > debug check specific to userspace transitions because kernel > > > threads aren't expected to resume to userspace. Can we also expect > > > that we never switch to/from guest from a kernel thread? AFAICS > > > this happens from an ioctl (thus user task) in x86 for kvm. But I > > > only know this case. > > > > > > 3) You might want to update a few comments that assume we only deal > > > with userspace transitions. > > > > > > 4) trace_user_enter/exit() should stay user-transitions specific. > > > > Paul, would you like me to send follow-up patches with the cleanups > > suggested by Frederic, or would you prefer me to send a new series > > with the cleanups integrated? > > I would prefer a new series, in order to prevent possible future > confusion. Of course, if Frederic would rather push them himself, I am fine with that. And in that case, you should ask him for his preferences, which just might differ from mine. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched, autogroup: Fix failure when writing to cpu.rt_runtime_us
>> See this commit:
>>
>> commit f44937718ce3b8360f72f6c68c9481712517a867
>> Author: Mike Galbraith
>> Date: Thu Jan 13 04:54:50 2011 +0100
>>
>> sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure
>> ...
>> + /*
>> +* Autogroup RT tasks are redirected to the root task group
>> ...
>> +* the policy change to proceed. Thereafter, task_group()
>> +* returns _task_group, ...
>> +*/
>
> That comment is misleading; if you look at the actual code what we do is
> redirect RT programs to _run_ in the root_task_group, but their
> task_group() should still be autogroup.
>
> Otherwise people could escape their cgroup by switching to and from a RT
> class.
>
Before 8323f26ce342 "sched: Fix race in task_group()", task_group() of
those RT tasks always return root_task_group, but the escape can't happen.
After commit 8323f26ce342, task_group always return root_task_group except
for the case I showed:
1. Change scheduling policy before setsid():
# cat /proc/sched_debug | grep test
R test 4194 24851.893077 945 120 24851.893077
11196.482331 0.00 /
2. Change policy after setsid():
R test 4142 4962.517723 420 120 4962.517723
4974.126149 0.00 /autogroup-44
I think we can fix it with:
diff --git a/kernel/sched/auto_group.c b/kernel/sched/auto_group.c
index 8a2e230..8c3a169 100644
--- a/kernel/sched/auto_group.c
+++ b/kernel/sched/auto_group.c
@@ -115,9 +115,6 @@ bool task_wants_autogroup(struct task_struct *p, struct
task_group *tg)
if (tg != _task_group)
return false;
- if (p->sched_class != _sched_class)
- return false;
-
/*
* We can only assume the task group can't go away on us if
* autogroup_move_group() can see us on ->thread_group list.
> So what I think you want is something like the below; preferably with a
> comment on ;-)
>
This is exactly what I did at first, but besides the issue described above,
seems it might lead to starving RT tasks.
If there's some rt task in autogroups but none in root cgroup, it's allowed
to set rt_runtime to 0, so I think we have to disallow this setting, like what
we already do with global rt_runtime.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 89e7283..3f6c3ad 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7460,6 +7460,9 @@ static inline int tg_has_rt_tasks(struct task_group *tg)
{
struct task_struct *g, *p;
+ if (task_group_is_autogroup(tg))
+ return 0;
+
for_each_process_thread(g, p) {
if (rt_task(p) && task_group(p) == tg)
return 1;
@@ -7540,6 +7543,9 @@ static int __rt_schedulable(struct task_group *tg, u64
period, u64 runtime)
.rt_runtime = runtime,
};
+ if (tg == _task_group && runtime == 0)
+ return -EINVAL;
+
rcu_read_lock();
ret = walk_tg_tree(tg_rt_schedulable, tg_nop, );
rcu_read_unlock();
> ---
> kernel/sched/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1f37fe7f77a4..f4fd048ce7cf 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7644,6 +7644,9 @@ static inline int tg_has_rt_tasks(struct task_group *tg)
> {
> struct task_struct *g, *p;
>
> + if (task_group_is_autogroup(tg))
> + return 0;
> +
> for_each_process_thread(g, p) {
> if (rt_task(p) && task_group(p) == tg)
> return 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 v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On 2015年02月07日 13:03, Ard Biesheuvel wrote:
On 7 February 2015 at 03:36, Hanjun Guo wrote:
On 2015年02月06日 18:34, G Gregory wrote:
[...]
linux,uefi-stub-kern-ver | string | Copy of linux_banner from
build.
+linux,uefi-stub-generated-dtb | bool | Indication for no DTB
provided by
+| | firmware.
+
Apologies for the late bikeshedding, but the discussion on this topic
previsously was lively enough that I thought I'd let it die down a bit
before seeing if I had anything to add.
That, and I just realised something:
One alternative to this added DT entry is that we could treat the
absence of a registered UEFI configuration table as the indication
that no HW description was provided from firmware, since the stub does
not call InstallConfigurationTable() on the DT it generates. This does
move the ability to detect to after efi_init(), but this should be
fine for ACPI-purposes.
That would not work as expected in the kexec/Xen use case though as they
may genuinely boot with DT from an ACPI host without UEFI.
I'm a little concerned by this case. How do we intend to pass stuff from
Xen to the kernel in this case? When we initially discussed the stub
prior to merging, we weren't quite sure if ACPI without UEFI was
entirely safe.
The linux,uefi-stub-kern-ver property was originally intended as a
sanity-check feature to ensure nothing (including Xen) masqueraded as
the stub, but for some reason the actual sanity check was never
implemented.
If that is deemed undesirable, I would still prefer Catalin's
suggested name ("linux,bare-dtb"), which describes the state rather
than the route we took to get there.
I agree.
I guess this would be ok, though it would be nice to know which agent
generated the DTB.
The most obvious scheme then is
linux,bare-dtb = "uefi-stub";
otherwise we generate a new binding for every component in the boot path.
Leif, Mark, any comments on this?
As far as I remember, we did not finalize the decision to go with a
stub generated property instead of some other means to infer that the
device tree is not suitable for booting and ACPI should be preferred.
We will be discussing the 'stub<->kernel interface as a boot protocol'
topic this week at Connect, so let's discuss it in that context before
signing off on patches like these.
OK, see you guys in Hongkong.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit
On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/06/2015 06:15 PM, Frederic Weisbecker wrote: > > > Just a few things then: > > > > 1) In this case rename context_tracking_user_enter/exit() to > > context_tracking_enter() and context_tracking_exit(), since it's > > not anymore about user only but about any generic context. > > > > 2) We have the "WARN_ON_ONCE(!current->mm);" condition that is a > > debug check specific to userspace transitions because kernel > > threads aren't expected to resume to userspace. Can we also expect > > that we never switch to/from guest from a kernel thread? AFAICS > > this happens from an ioctl (thus user task) in x86 for kvm. But I > > only know this case. > > > > 3) You might want to update a few comments that assume we only deal > > with userspace transitions. > > > > 4) trace_user_enter/exit() should stay user-transitions specific. > > Paul, would you like me to send follow-up patches with the cleanups > suggested by Frederic, or would you prefer me to send a new series > with the cleanups integrated? I would prefer a new series, in order to prevent possible future confusion. Thanx, Paul > Frederic, I will also add the cleanup you suggested for patch 4/5. > > - -- > All rights reversed > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJU1Yw+AAoJEM553pKExN6DhycH/ifPeaRaFcj/BBKaDf7BmKAJ > cGMplf/vMtJA5DCFfZTmRp5Yb/9f3XBk8MU4Z+oWZFPB/msA8WkibhZtRGXpXXl9 > 7XgDXaXUuo++Axhb3SYHXEDhkPkhmfdjlctyr5ZUu3gHqkeWl6utv0t4anIBfo3Z > NdWG8yEhgKU6OyFppf3CH0Cm46xPN+pUyAFMgK9HbSfDkR3a9rMZ32aQq8fyV15e > LV4qE+/lPi7lyoLqbHmmU+pqp6iBqyQ9uFIDCRAoBBXF5jh0jxEynRubBn2D1HZJ > FBi+dBWGhAjRN05tuurvkwbJtcmTpnsHyNrmzNlAeop0Upc/5Vta43zN/nu1AFA= > =Z9mE > -END PGP SIGNATURE- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files
Alexander Holler ahsoftware.de> writes:
>
> Hello.
>
> I've set up a repository at github which contains the 3 pathches to add
> limited support to the Linux kernel for wiping files on ext4 and (v)fat
> with 3 small patches and a total of "9 files changed, 101 insertions(+),
> 8 deletions(-)" here:
>
> https://github.com/aholler/wipe_lnx
>
> Feel free to send me any comments, patches or even flames in privat
> (off-list)! because I don't want to become involved in annoying
> discussions here anymore.
>
> Alexander Holler
>
This is certainly a case of "The Emperor's New Clothes". Lets say I use vim to
edit my file containing my deep dark secrets. Lets strace it and see what
happens when I edit it and save a new copy:
rename("secure_document.txt", "secure_document.txt~") = 0
open("secure_document.txt", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3
write(3, "secrete:s\n", 10) = 10
fsync(3)= 0
close(3)= 0
chmod("secure_document.txt", 0100664) = 0
setxattr("secure_document.txt", "system.posix_acl_access",
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\x
ff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0
unlink("secure_document.txt~") = 0
You'll find that just about every program that deals with files properly does
something like this. If it didn't, there'd be a good chance of losing all your
work if the computer or program crashed while saving your file. This is layer
one of the problem.
Layer 2 is filesystems, as others have noted, filesystems have all sorts of
paths for blocks no longer being associated with inodes. Log structured file
systems doubly so.
And layer 3, media, which we have no control over and may be storing duplicate
copies of the data for any number of reasons. But as you've pointed out, is
likely to require significant funds to get at.
As pointed out, the best you could do is some sort of flag on the inode that
instructed the filesystem to wipe blocks before separating them from the inode.
Programs would need to be modified though as you can see in the vim case, any
copying of file mode bits are only done after data has been written to disk.
Luckily there is an easy solution out there that solves all these problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arm64, ft-1500a: Add initial dts for Phytium FT-1500A SoC
Add initial device tree nodes for Phytium FT-1500A SoC with support of
16 cores, gicv3 interrupt controller, serial port, PCIe host and
on-chip GMAC ethernet controller.
Signed-off-by: Chen Baozi
---
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/phytium/Makefile | 5 +
arch/arm64/boot/dts/phytium/ft-1500a.dtsi | 269 ++
arch/arm64/boot/dts/phytium/ft1500a-v2-dsk-v2.dts | 39
4 files changed, 314 insertions(+)
create mode 100644 arch/arm64/boot/dts/phytium/Makefile
create mode 100644 arch/arm64/boot/dts/phytium/ft-1500a.dtsi
create mode 100644 arch/arm64/boot/dts/phytium/ft1500a-v2-dsk-v2.dts
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c62b0f4..e7e9e3d 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -2,5 +2,6 @@ dts-dirs += amd
dts-dirs += apm
dts-dirs += arm
dts-dirs += cavium
+dts-dirs += phytium
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/phytium/Makefile
b/arch/arm64/boot/dts/phytium/Makefile
new file mode 100644
index 000..12a22c6
--- /dev/null
+++ b/arch/arm64/boot/dts/phytium/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_PHYTIUM) += ft1500a-v2-dsk-v2.dtb
+
+always := $(dtb-y)
+subdir-y := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/phytium/ft-1500a.dtsi
b/arch/arm64/boot/dts/phytium/ft-1500a.dtsi
new file mode 100644
index 000..9005389
--- /dev/null
+++ b/arch/arm64/boot/dts/phytium/ft-1500a.dtsi
@@ -0,0 +1,269 @@
+/*
+ * DTS file for Phytium FT-1500A SoC
+ *
+ * Copyright (C) 2015, Phytium Technology Co., Ltd.
+ *
+ * This file is licensed under a dual GPLv2 or BSD license.
+ */
+
+/memreserve/0x8000 0x10;
+/ {
+ compatible = "phytium,ft-1500a";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x000>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x001>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x002>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x003>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@4 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x100>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@5 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x101>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@6 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x102>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@7 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x103>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@8 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x200>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x8007fff0>;
+ };
+
+ cpu@9 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x201>;
+ enable-method = "spin-table";
+
[PATCH 3/3] stmmac: Add AXI burst length support to platform device.
The AXI Bus Mode Register controls the AXI master behavior. It is mainly used to control the burst splitting and the number of outstanding requests. This register is present and valid only in GMAC-AXI configuration. The old driver only supports this feature on PCI devices. This patch adds an 'snps,apl' properties in DT to enable it on platform devices. Signed-off-by: Chen Baozi --- Documentation/devicetree/bindings/net/stmmac.txt | 1 + drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + 2 files changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index c41afd9..8f3c834 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -43,6 +43,7 @@ Optional properties: available this clock is used for programming the Timestamp Addend Register. If not passed then the system clock will be used and this is fine on some platforms. +- snps,abl: AXI Burst Length Examples: diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 3039de2..abbc897 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -230,6 +230,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev, return -ENOMEM; plat->dma_cfg = dma_cfg; of_property_read_u32(np, "snps,pbl", _cfg->pbl); + of_property_read_u32(np, "snps,abl", _cfg->burst_len); dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst"); dma_cfg->mixed_burst = -- 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/
[PATCH 0/3] Add support for Phytium FT-1500A SoC
This patchset introduces support for Phytium FT-1500A SoC. FT-1500A is the first arm64 SoC designed by Phytium, which includes 16 cores of armv8 processor, a 32-lane PCI-E host, 2 GMAC on-chip ethernet controller and a GICv3 interrupt controller with ITS support. Chen Baozi (3): arm64: Add Kconfig option for Phytium FT SoC Family. arm64, ft-1500a: Add initial dts for Phytium FT-1500A SoC stmmac: Add AXI burst length support to platform device. Documentation/devicetree/bindings/net/stmmac.txt | 1 + arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/phytium/Makefile | 5 + arch/arm64/boot/dts/phytium/ft-1500a.dtsi | 269 + arch/arm64/boot/dts/phytium/ft1500a-v2-dsk-v2.dts | 39 +++ arch/arm64/configs/defconfig | 2 + .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + 8 files changed, 323 insertions(+) create mode 100644 arch/arm64/boot/dts/phytium/Makefile create mode 100644 arch/arm64/boot/dts/phytium/ft-1500a.dtsi create mode 100644 arch/arm64/boot/dts/phytium/ft1500a-v2-dsk-v2.dts -- 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/
[PATCH 1/3] arm64: Add Kconfig option for Phytium FT SoC Family.
This introduces ARCH_PHYTIUM to enable SoC specific drivers and dtb files. Signed-off-by: Chen Baozi --- arch/arm64/Kconfig | 5 + arch/arm64/configs/defconfig | 2 ++ 2 files changed, 7 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b1f9a20..9cfa320 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -153,6 +153,11 @@ config ARCH_SEATTLE help This enables support for AMD Seattle SOC Family +config ARCH_PHYTIUM + bool "Phytium FT SoC Family" + help + This enables support for Phytium FT SoC Family. + config ARCH_THUNDER bool "Cavium Inc. Thunder SoC Family" help diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 5376d90..df50c54 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -31,6 +31,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_PHYTIUM=y CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y @@ -86,6 +87,7 @@ CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16 CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y -- 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 v2 1/1] drivers:hv:vmbus drivers:hv:vmbus Allow for more than one MMIO range for children
> > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Sent: Friday, February 6, 2015 7:04 AM > > To: Jake Oshins > > Cc: gre...@linuxfoundation.org; KY Srinivasan; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com > > Subject: Re: [PATCH v2 1/1] drivers:hv:vmbus drivers:hv:vmbus Allow for more > > than one MMIO range for children > > > > Sorry for beeing late with this message but I'm seeing issues with this > > commit. I added some debug to figure out what's going on and here is > > what I see: > > > > With Gen1 VM we end up doing request_resource for two ranges: > > f800 - fffb > > fe000 - fffef > > > > request_resource() fails (as we already have PCI device at f800 I > > suppose?) but we don't check the return value. release_resource on > > module unload crashes the kernel: > > [ 78.314344] BUG: unable to handle kernel NULL pointer dereference at > > 0030 > > [ 78.315021] IP: [] release_resource+0x25/0x90 > > [ 78.315021] PGD 78c67067 PUD 78c5a067 PMD 0 > > [ 78.315021] Oops: [#1] SMP DEBUG_PAGEALLOC > > [ 78.315021] Modules linked in: hv_vmbus(-) > > ... > > If I'm not mistaken, before the change we didn't do any > > request_resource() for Gen1 VMs at all. > > > > With Gen2 VM we do request_resource for fe000 - f range > > only, that means this commit doesn't change anything. > > > > Can you please take a look? I'd like to help but I don't completely > > understand the essense of the change wrt Gen1 VMs with PCI devices. > > > > I'll take a look immediately. > > Thanks, > Jake I looked at this and I realize that I need to fix this problem structurally. The intent is that VMBus-enumerated paravirtual "devices" suballocate from everything granted to the ACPI node above VMBus, in its _CRS object. But since PCI devices also have to suballocate from those ranges, I need a different approach. I'll work up a fix for this and send it around for review. -- Jake Oshins -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vxlan: Wrong type passed to %pIS
On Fri, Feb 6, 2015 at 6:17 PM, Rasmus Villemoes
wrote:
> src_ip is a pointer to a union vxlan_addr, one member of which is a
> struct sockaddr. Passing a pointer to src_ip is wrong; one should pass
> the value of src_ip itself. Since %pIS formally expects something of
> type struct sockaddr*, let's pass a pointer to the appropriate union
> member, though this of course doesn't change the generated code.
>
It is a union, this doesn't harm.
> Fixes: e4c7ed415387 ("vxlan: add ipv6 support")
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/net/vxlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index a8c755dcab14..11defbb24183 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -991,7 +991,7 @@ static bool vxlan_snoop(struct net_device *dev,
> if (net_ratelimit())
> netdev_info(dev,
> "%pM migrated from %pIS to %pIS\n",
> - src_mac, >remote_ip, _ip);
> + src_mac, >remote_ip.sa,
> _ip->sa);
>
> rdst->remote_ip = *src_ip;
> f->updated = jiffies;
Since you are on it, there is another similar place in vxlan too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On 7 February 2015 at 03:36, Hanjun Guo wrote:
> On 2015年02月06日 18:34, G Gregory wrote:
> [...]
>
>>
>>
>> linux,uefi-stub-kern-ver | string | Copy of linux_banner from
>> build.
>>
>>
>> +linux,uefi-stub-generated-dtb | bool | Indication for no DTB
>> provided by
>> +| | firmware.
>>
>> +
>
>
> Apologies for the late bikeshedding, but the discussion on this topic
> previsously was lively enough that I thought I'd let it die down a bit
> before seeing if I had anything to add.
>
> That, and I just realised something:
> One alternative to this added DT entry is that we could treat the
> absence of a registered UEFI configuration table as the indication
> that no HW description was provided from firmware, since the stub does
> not call InstallConfigurationTable() on the DT it generates. This does
> move the ability to detect to after efi_init(), but this should be
> fine for ACPI-purposes.
>
That would not work as expected in the kexec/Xen use case though as they
may genuinely boot with DT from an ACPI host without UEFI.
>>>
>>>
>>> I'm a little concerned by this case. How do we intend to pass stuff from
>>> Xen to the kernel in this case? When we initially discussed the stub
>>> prior to merging, we weren't quite sure if ACPI without UEFI was
>>> entirely safe.
>>>
>>> The linux,uefi-stub-kern-ver property was originally intended as a
>>> sanity-check feature to ensure nothing (including Xen) masqueraded as
>>> the stub, but for some reason the actual sanity check was never
>>> implemented.
>>>
> If that is deemed undesirable, I would still prefer Catalin's
> suggested name ("linux,bare-dtb"), which describes the state rather
> than the route we took to get there.
>
I agree.
>>>
>>>
>>> I guess this would be ok, though it would be nice to know which agent
>>> generated the DTB.
>>>
>>
>> The most obvious scheme then is
>>
>> linux,bare-dtb = "uefi-stub";
>>
>> otherwise we generate a new binding for every component in the boot path.
>
>
> Leif, Mark, any comments on this?
>
As far as I remember, we did not finalize the decision to go with a
stub generated property instead of some other means to infer that the
device tree is not suitable for booting and ACPI should be preferred.
We will be discussing the 'stub<->kernel interface as a boot protocol'
topic this week at Connect, so let's discuss it in that context before
signing off on patches like these.
--
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [NFSv4.1] 6ae373394c4: kernel boot crash
On Fri, Feb 6, 2015 at 11:31 PM, Fengguang Wu wrote:
> Hi Trond,
>
> On Fri, Feb 06, 2015 at 10:43:34PM -0500, Trond Myklebust wrote:
>> On Fri, Feb 6, 2015 at 9:45 PM, Fengguang Wu wrote:
>> >
>> > Hi Trond,
>> >
>> > We noticed the below kernel crash on
>> >
>> > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git testing
>> > commit 6ae373394c4257bad562817aa60464ff7fe8f9c4 ("NFSv4.1: Ask for no
>> > delegation on OPEN if using O_DIRECT")
>> >
>> >
>> > testbox/testcase/testparams: vm-vp-quantal-x86_64/boot/1
>> >
>> > 0e3b137fbf0f4ab9 6ae373394c4257bad562817aa6
>> > --
>> >fail:runs %reproductionfail:runs
>> >| | |
>> >:100 4% 2:46dmesg.BUG:kernel_test_crashed
>> >
>> > The last dmesg lines before the kernel crash are
>> >
>> > [0.274266] NET: Registered protocol family 1
>> > [0.275236] RPC: Registered named UNIX socket transport module.
>> > [0.276123] RPC: Registered udp transport module.
>> > [0.276860] RPC: Registered tcp transport module.
>> > [0.277617] RPC: Registered tcp NFSv4.1 backchannel transport module
>> >
>> > Thanks,
>> > Fengguang
>>
>>
>> Hi Fengguang,
>>
>> I'm trying to reproduce this issue, but so far no luck. Do you have
>> any details on the test itself that you could share with me?
>
> It looks like a false report, sorry! The real crash dmesg is much
> longer and it ends here:
>
> [ 14.605487] i6300esb: Unexpected close, not stopping watchdog!
>
> Which is not relevant to the NFS change at all.
>
> The dmesg I looked at happen to be truncated (perhaps by email server)
> exactly at a NFS line, which treats me to believe it's a good bisect.
>
> Cheers,
> Fengguang
Phew. So I'm off the hook then. :-)
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.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: [NFSv4.1] 6ae373394c4: kernel boot crash
Hi Trond,
On Fri, Feb 06, 2015 at 10:43:34PM -0500, Trond Myklebust wrote:
> On Fri, Feb 6, 2015 at 9:45 PM, Fengguang Wu wrote:
> >
> > Hi Trond,
> >
> > We noticed the below kernel crash on
> >
> > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git testing
> > commit 6ae373394c4257bad562817aa60464ff7fe8f9c4 ("NFSv4.1: Ask for no
> > delegation on OPEN if using O_DIRECT")
> >
> >
> > testbox/testcase/testparams: vm-vp-quantal-x86_64/boot/1
> >
> > 0e3b137fbf0f4ab9 6ae373394c4257bad562817aa6
> > --
> >fail:runs %reproductionfail:runs
> >| | |
> >:100 4% 2:46dmesg.BUG:kernel_test_crashed
> >
> > The last dmesg lines before the kernel crash are
> >
> > [0.274266] NET: Registered protocol family 1
> > [0.275236] RPC: Registered named UNIX socket transport module.
> > [0.276123] RPC: Registered udp transport module.
> > [0.276860] RPC: Registered tcp transport module.
> > [0.277617] RPC: Registered tcp NFSv4.1 backchannel transport module
> >
> > Thanks,
> > Fengguang
>
>
> Hi Fengguang,
>
> I'm trying to reproduce this issue, but so far no luck. Do you have
> any details on the test itself that you could share with me?
It looks like a false report, sorry! The real crash dmesg is much
longer and it ends here:
[ 14.605487] i6300esb: Unexpected close, not stopping watchdog!
Which is not relevant to the NFS change at all.
The dmesg I looked at happen to be truncated (perhaps by email server)
exactly at a NFS line, which treats me to believe it's a good bisect.
Cheers,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xen-scsiback: some modifications about code comment
From: Tao Chen
Signed-off-by: Tao Chen
---
drivers/xen/xen-scsiback.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 3e32146..59f09fd 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -83,7 +83,7 @@ struct ids_tuple {
struct v2p_entry {
struct ids_tuple v; /* translate from */
- struct scsiback_tpg *tpg; /* translate to */
+ struct scsiback_tpg *tpg; /* translate to */
unsigned int lun;
struct kref kref;
struct list_head l;
@@ -525,7 +525,7 @@ static int scsiback_gnttab_data_map(struct vscsiif_request
*ring_req,
}
}
- /* free of (sgl) in fast_flush_area()*/
+ /* free of (sgl) in fast_flush_area() */
pending_req->sgl = kmalloc_array(nr_segments,
sizeof(struct scatterlist), GFP_KERNEL);
if (!pending_req->sgl)
@@ -1084,7 +1084,7 @@ static void scsiback_do_1lun_hotplug(struct vscsibk_info
*info, int op,
}
}
break;
- /*When it is necessary, processing is added here.*/
+ /* When it is necessary, processing is added here. */
default:
break;
}
@@ -1475,8 +1475,8 @@ static u32 scsiback_tpg_get_inst_index(struct
se_portal_group *se_tpg)
static int scsiback_check_stop_free(struct se_cmd *se_cmd)
{
/*
-* Do not release struct se_cmd's containing a valid TMR
-* pointer. These will be released directly in scsiback_device_action()
+* Do not release struct se_cmd's containing a valid TMR pointer.
+* These will be released directly in scsiback_device_action()
* with transport_generic_free_cmd().
*/
if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
@@ -1642,7 +1642,7 @@ static int scsiback_make_nexus(struct scsiback_tpg *tpg,
return -ENOMEM;
}
/*
-* Initialize the struct se_session pointer
+* Initialize the struct se_session pointer
*/
tv_nexus->tvn_se_sess = transport_init_session(TARGET_PROT_NORMAL);
if (IS_ERR(tv_nexus->tvn_se_sess)) {
@@ -1759,7 +1759,7 @@ static ssize_t scsiback_tpg_store_nexus(struct
se_portal_group *se_tpg,
unsigned char i_port[VSCSI_NAMELEN], *ptr, *port_ptr;
int ret;
/*
-* Shutdown the active I_T nexus if 'NULL' is passed..
+* Shutdown the active I_T nexus if 'NULL' is passed.
*/
if (!strncmp(page, "NULL", 4)) {
ret = scsiback_drop_nexus(tpg);
@@ -1930,7 +1930,7 @@ static void scsiback_drop_tpg(struct se_portal_group
*se_tpg)
*/
scsiback_drop_nexus(tpg);
/*
-* Deregister the se_tpg from TCM..
+* Deregister the se_tpg from TCM.
*/
core_tpg_deregister(se_tpg);
kfree(tpg);
--
1.8.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] thinkpad_acpi: unhandled hkey event
On Sat, Jan 31, 2015 at 07:52:03PM +0100, Xavier Naveira wrote:
> Pressing Fn+Esc in a Lenovo Thinkpad x240 to lock the Fn keys generates
> an unhandled hkey event
>
> Signed-off-by: Xavier Naveira
> ---
> drivers/platform/x86/thinkpad_acpi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index c3d11fa..e61c43b 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -196,6 +196,7 @@ enum tpacpi_hkey_event_t {
> /* Key-related user-interface events */
> TP_HKEY_EV_KEY_NUMLOCK = 0x6000, /* NumLock key pressed */
> TP_HKEY_EV_KEY_FN = 0x6005, /* Fn key pressed? E420 */
> + TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
>
> /* Thermal events */
> TP_HKEY_EV_ALARM_BAT_HOT= 0x6011, /* battery too hot */
> @@ -3717,6 +3718,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
> *send_acpi_ev = false;
> *ignore_acpi_ev = true;
> return true;
> + case TP_HKEY_EV_KEY_FN_ESC:
> + /* key press events, we just ignore them as long as the EC
> + * is still reporting them in the normal keyboard stream */
> + *send_acpi_ev = false;
> + *ignore_acpi_ev = true;
> + return true;
No need to duplicate the logic here, just add TP_HKEY_EV_KEY_FN_ESC to the list
of fallthrough keys (right after TP_HKEY_EV_KEY_FN).
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/tbl/trace: Do not trace on CPU that is offline
On Fri, 6 Feb 2015 15:27:54 -0800 "Paul E. McKenney" wrote: > > Reported-by: Sedat Dilek > > Suggested-by: Paul E. McKenney > > Signed-off-by: Steven Rostedt > > Acked-by: Paul E. McKenney Both patches survived all my tests, now I just need an ack by from Dave and/or Peter, and I'll push it off to Linus. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2015 06:15 PM, Frederic Weisbecker wrote: > Just a few things then: > > 1) In this case rename context_tracking_user_enter/exit() to > context_tracking_enter() and context_tracking_exit(), since it's > not anymore about user only but about any generic context. > > 2) We have the "WARN_ON_ONCE(!current->mm);" condition that is a > debug check specific to userspace transitions because kernel > threads aren't expected to resume to userspace. Can we also expect > that we never switch to/from guest from a kernel thread? AFAICS > this happens from an ioctl (thus user task) in x86 for kvm. But I > only know this case. > > 3) You might want to update a few comments that assume we only deal > with userspace transitions. > > 4) trace_user_enter/exit() should stay user-transitions specific. Paul, would you like me to send follow-up patches with the cleanups suggested by Frederic, or would you prefer me to send a new series with the cleanups integrated? Frederic, I will also add the cleanup you suggested for patch 4/5. - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU1Yw+AAoJEM553pKExN6DhycH/ifPeaRaFcj/BBKaDf7BmKAJ cGMplf/vMtJA5DCFfZTmRp5Yb/9f3XBk8MU4Z+oWZFPB/msA8WkibhZtRGXpXXl9 7XgDXaXUuo++Axhb3SYHXEDhkPkhmfdjlctyr5ZUu3gHqkeWl6utv0t4anIBfo3Z NdWG8yEhgKU6OyFppf3CH0Cm46xPN+pUyAFMgK9HbSfDkR3a9rMZ32aQq8fyV15e LV4qE+/lPi7lyoLqbHmmU+pqp6iBqyQ9uFIDCRAoBBXF5jh0jxEynRubBn2D1HZJ FBi+dBWGhAjRN05tuurvkwbJtcmTpnsHyNrmzNlAeop0Upc/5Vta43zN/nu1AFA= =Z9mE -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFSv4.1] 6ae373394c4: kernel boot crash
On Fri, Feb 6, 2015 at 9:45 PM, Fengguang Wu wrote:
>
> Hi Trond,
>
> We noticed the below kernel crash on
>
> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git testing
> commit 6ae373394c4257bad562817aa60464ff7fe8f9c4 ("NFSv4.1: Ask for no
> delegation on OPEN if using O_DIRECT")
>
>
> testbox/testcase/testparams: vm-vp-quantal-x86_64/boot/1
>
> 0e3b137fbf0f4ab9 6ae373394c4257bad562817aa6
> --
>fail:runs %reproductionfail:runs
>| | |
>:100 4% 2:46dmesg.BUG:kernel_test_crashed
>
> The last dmesg lines before the kernel crash are
>
> [0.274266] NET: Registered protocol family 1
> [0.275236] RPC: Registered named UNIX socket transport module.
> [0.276123] RPC: Registered udp transport module.
> [0.276860] RPC: Registered tcp transport module.
> [0.277617] RPC: Registered tcp NFSv4.1 backchannel transport module
>
> Thanks,
> Fengguang
Hi Fengguang,
I'm trying to reproduce this issue, but so far no luck. Do you have
any details on the test itself that you could share with me?
Thanks
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.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 v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property
On 2015年02月06日 18:34, G Gregory wrote:
[...]
linux,uefi-stub-kern-ver | string | Copy of linux_banner from build.
+linux,uefi-stub-generated-dtb | bool | Indication for no DTB provided by
+| | firmware.
+
Apologies for the late bikeshedding, but the discussion on this topic
previsously was lively enough that I thought I'd let it die down a bit
before seeing if I had anything to add.
That, and I just realised something:
One alternative to this added DT entry is that we could treat the
absence of a registered UEFI configuration table as the indication
that no HW description was provided from firmware, since the stub does
not call InstallConfigurationTable() on the DT it generates. This does
move the ability to detect to after efi_init(), but this should be
fine for ACPI-purposes.
That would not work as expected in the kexec/Xen use case though as they
may genuinely boot with DT from an ACPI host without UEFI.
I'm a little concerned by this case. How do we intend to pass stuff from
Xen to the kernel in this case? When we initially discussed the stub
prior to merging, we weren't quite sure if ACPI without UEFI was
entirely safe.
The linux,uefi-stub-kern-ver property was originally intended as a
sanity-check feature to ensure nothing (including Xen) masqueraded as
the stub, but for some reason the actual sanity check was never
implemented.
If that is deemed undesirable, I would still prefer Catalin's
suggested name ("linux,bare-dtb"), which describes the state rather
than the route we took to get there.
I agree.
I guess this would be ok, though it would be nice to know which agent
generated the DTB.
The most obvious scheme then is
linux,bare-dtb = "uefi-stub";
otherwise we generate a new binding for every component in the boot path.
Leif, Mark, any comments on this?
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vxlan: Wrong type passed to %pIS
On Sat, 2015-02-07 at 03:17 +0100, Rasmus Villemoes wrote: > src_ip is a pointer to a union vxlan_addr, one member of which is a > struct sockaddr. Passing a pointer to src_ip is wrong; one should pass > the value of src_ip itself. Since %pIS formally expects something of > type struct sockaddr*, let's pass a pointer to the appropriate union > member, though this of course doesn't change the generated code. Hello Rasmus Are you finding these mismatches by hand or are you using some tool? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/15] drm: bridge/dw_hdmi: add indentification registers parse and record
On 02/05/2015 11:46 PM, Daniel Kurtz wrote:
On Tue, Feb 3, 2015 at 11:11 PM, Yakir Yang wrote:
By parsing the indentification registers we can know what functions
are present on the hdmi ip.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Add ID registers parse and record
Changes in v2: None
drivers/gpu/drm/bridge/dw_hdmi.c | 59
drivers/gpu/drm/bridge/dw_hdmi.h | 23
2 files changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 08f10da..7b5b664 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -79,6 +79,23 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
{ 0x6756, 0x78ab, 0x2000, 0x0200 }
};
+struct hdmi_id {
+ u8 design;
+ u8 revision;
+
+ bool prepen;
+ bool audspdif;
+ bool audi2s;
+ bool hdmi14;
+ bool csc;
+ bool hdcp;
+ bool hdmi20;
+ bool confapb;
+ bool ahbauddma;
+ bool gpaud;
+ u8 phy_type;
+};
+
struct hdmi_vmode {
bool mdvi;
bool mhsyncpolarity;
@@ -111,6 +128,8 @@ struct dw_hdmi {
struct clk *isfr_clk;
struct clk *iahb_clk;
+ struct hdmi_id id;
+
struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
@@ -1259,6 +1278,36 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
return 0;
}
+static void hdmi_parse_id(struct dw_hdmi *hdmi)
+{
+ u8 config0_id, config1_id, config2_id, config3_id;
+
+ config0_id = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
+ config1_id = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
+ config2_id = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+ config3_id = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
+
+ hdmi->id.prepen = config0_id & HDMI_CONFIG0_ID_PREPEN ? true : false;
These could all be "!!(A & B)", but perhaps that is just a matter of
personal preference.
Okay, "!!(A & B)" looks good, I will modify it.
Thanks. : )
+ hdmi->id.audi2s = config0_id & HDMI_CONFIG0_ID_AUDI2S ? true : false;
+ hdmi->id.hdmi14 = config0_id & HDMI_CONFIG0_ID_HDMI14 ? true : false;
+ hdmi->id.hdcp = config0_id & HDMI_CONFIG0_ID_HDCP ? true : false;
+ hdmi->id.csc = config0_id & HDMI_CONFIG0_ID_CSC ? true : false;
+ hdmi->id.audspdif = config0_id & HDMI_CONFIG0_ID_AUDSPDIF ?
+ true : false;
+
+ hdmi->id.confapb = config1_id & HDMI_CONFIG1_ID_CONFAPB ? true : false;
+ hdmi->id.hdmi20 = config1_id & HDMI_CONFIG1_ID_HDMI20 ? true : false;
+
+ hdmi->id.phy_type = config2_id & HDMI_CONFIG2_ID;
HDMI_CONFIG2_ID is a register offset, not a mask.
Thanks, I will correct it.
+
+ hdmi->id.gpaud = config3_id & HDMI_CONFIG3_ID_GPAUD ? true : false;
+ hdmi->id.ahbauddma = config3_id & HDMI_CONFIG3_ID_AHBAUDDMA ?
+true : false;
+
+ hdmi->id.design = hdmi_readb(hdmi, HDMI_DESIGN_ID);
+ hdmi->id.revision = hdmi_readb(hdmi, HDMI_REVISION_ID);
+}
+
/* Wait until we are registered to enable interrupts */
static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
{
@@ -1670,6 +1719,16 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
hdmi_readb(hdmi, HDMI_PRODUCT_ID0),
hdmi_readb(hdmi, HDMI_PRODUCT_ID1));
+ /* Config IDs */
+ dev_info(dev,
+"Detected HDMI config_id 0x%x:0x%x:0x%x:0x%x\n",
+hdmi_readb(hdmi, HDMI_CONFIG0_ID),
+hdmi_readb(hdmi, HDMI_CONFIG1_ID),
+hdmi_readb(hdmi, HDMI_CONFIG2_ID),
+hdmi_readb(hdmi, HDMI_CONFIG3_ID));
+
+ hdmi_parse_id(hdmi);
It seems a bit silly to read the regs once to print them, and then
again in hdmi_parse_id().
Perhaps move the dev_info() inside hdmi_parse_id().
It would also be nice to print a full summary of all of the parsed fields.
Okay, I will warp them into hdmi_parse_id().
Thanks. : )
+
initialize_hdmi_ih_mutes(hdmi);
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index 175dbc8..e4ba634 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -545,6 +545,29 @@
#define HDMI_I2CM_FS_SCL_LCNT_0_ADDR0x7E12
enum {
+/* HDMI_CONFIG0_ID */
+ HDMI_CONFIG0_ID_PREPEN = 0x80,
+ HDMI_CONFIG0_ID_AUDSPDIF = 0x20,
+ HDMI_CONFIG0_ID_AUDI2S = 0x10,
+ HDMI_CONFIG0_ID_HDMI14 = 0x08,
+ HDMI_CONFIG0_ID_CSC = 0x04,
+ HDMI_CONFIG0_ID_HDCP = 0x01,
+
+/* HDMI_CONFIG1_ID */
+ HDMI_CONFIG1_ID_HDMI20 = 0x20,
+ HDMI_CONFIG1_ID_CONFAPB = 0x02,
+
+/* HDMI_CONFIG2_ID */
+ HDMI_CONFIG2_ID_PHY_GEN2 = 0xf2,
+ HDMI_CONFIG2_ID_PHY_GEN2_HECA = 0xe2,
+ HDMI_CONFIG2_ID_PHY_HDMI_MHL = 0xc2,
+
Re: [PATCH v3 05/15] drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
On 02/05/2015 11:54 PM, Daniel Kurtz wrote:
On Tue, Feb 3, 2015 at 11:12 PM, Yakir Yang wrote:
Signed-off-by: Yakir Yang
Reviewed-by: Daniel Kurtz
Okay, add in next verson4.
Thanks. : )
---
Changes in v3:
- Combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts()
Changes in v2: None
drivers/gpu/drm/bridge/dw_hdmi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 7b5b664..262163f 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -196,19 +196,16 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8
data, unsigned int reg,
hdmi_modb(hdmi, data << shift, mask, reg);
}
-static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
-unsigned int value)
+static void hdmi_set_clock_regenerator(struct dw_hdmi *hdmi,
+ unsigned int n, unsigned int cts)
{
- hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
- hdmi_writeb(hdmi, (value >> 8) & 0xff, HDMI_AUD_N2);
- hdmi_writeb(hdmi, (value >> 16) & 0x0f, HDMI_AUD_N3);
+ hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
+ hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
+ hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
/* nshift factor = 0 */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
-}
-static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
-{
/* Must be set/cleared first */
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_CTS_MANUAL, HDMI_AUD_CTS3);
@@ -374,8 +371,7 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
__func__, hdmi->sample_rate, hdmi->ratio,
pixel_clk, clk_n, clk_cts);
- hdmi_set_clock_regenerator_n(hdmi, clk_n);
- hdmi_regenerate_cts(hdmi, clk_cts);
+ hdmi_set_clock_regenerator(hdmi, clk_n, clk_cts);
}
static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Sony-laptop: fix sparse warning
On Thu, Feb 05, 2015 at 04:00:32PM +, Lad, Prabhakar wrote:
> Hi Giedrius,
>
> On Thu, Feb 5, 2015 at 3:55 PM, Giedrius Statkevičius
> wrote:
> > On 2015.02.05 16:49, Lad Prabhakar wrote:
> >> From: "Lad, Prabhakar"
> >>
> >> this patch fixes following sparse warning:
> >>
> >> sony-laptop.c:1035:29: warning: symbol 'sony_bl_props' was not declared.
> >> Should it be static?
> >>
> >> Signed-off-by: Lad, Prabhakar
> > Don't put a comma between your first and last name, please. Also, is
> > this your real name and surname?
> >
> I have hundreds of patches with:
>
> Lad, Prabhakar
> Lad, Prabhakar
I think there may be a problem with this in an unquoted email address. The
unquoted local part, per RFC 2822 3.4.1, can only contain !#$%'*+-/=?^_`{|}~
and . separators.
David Miller is the one who usually catches this sort of thing. David, do we
have a problem here?
>
> I don’t want to change it now! Yes that's my real name.
>
> Cheers,
> --Prabhakar
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: a method to distinguish between syscall-enter/exit-stop
On Fri, Feb 06, 2015 at 05:07:41PM -0800, Kees Cook wrote: > On Fri, Feb 6, 2015 at 3:17 PM, Dmitry V. Levin wrote: > > On Fri, Feb 06, 2015 at 12:07:03PM -0800, Kees Cook wrote: > >> On Fri, Feb 6, 2015 at 11:32 AM, Andy Lutomirski > >> wrote: > >> > On Fri, Feb 6, 2015 at 11:23 AM, Kees Cook wrote: > > [...] > >> >> And an unrelated thought: > >> >> > >> >> 3) Can't we find some way to fix the inability of a ptracer to > >> >> distinguish between syscall-enter-stop and syscall-exit-stop? > >> > > >> > Couldn't we add PTRACE_O_TRACESYSENTRY and PTRACE_O_TRACESYSEXIT along > >> > the lines of PTRACE_O_TRACESYSGOOD? > >> > >> That might be a nice idea. I haven't written a test to see, but what > >> does PTRACE_GETEVENTMSG return on syscall-enter/exit-stop? > > > > The value returned by PTRACE_GETEVENTMSG is the value set along with the > > latest PTRACE_EVENT_*. > > In case of syscall-enter/exit-stop (which is not a PTRACE_EVENT_*), > > there is no particular value set for PTRACE_GETEVENTMSG. > > Could we define one to help distinguish? I suppose we could define one, but performing extra PTRACE_GETEVENTMSG for every syscall-stop may be too expensive. For example, strace makes about 4.5 syscalls per syscall-stop. The minimum is 4 syscalls: wait4, PTRACE_GETREGSET, write, and PTRACE_SYSCALL; processing some syscall-stops may require additional process_vm_readv calls. That is, forcing strace to make extra PTRACE_GETEVENTMSG per syscall-stop would result to about 20% more syscalls per syscall-stop, that is a noticeable cost. A better alternative is to define an event that wouldn't require this extra PTRACE_GETEVENTMSG per syscall-stop. For example, it could be a PTRACE_EVENT_SYSCALL_ENTRY and/or PTRACE_EVENT_SYSCALL_EXIT. In practice, adding just one of these two events would be enough to distinguish two kinds of syscall-stops. Adding two events would look less surprising, though. If the decision would be to add both events, I'd recommend adding just one new option to cover both events - there is a room only for 32 different PTRACE_O_* options. -- ldv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: thinkpad_acpi.c: fix sparse warning
On Thu, Feb 05, 2015 at 02:45:38PM +, Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > this patch fixes following sparse warning: Please use the imperative, command form, in the future: "Fix the following sparse warning:" For the subject, just the module name is sufficient, no need to preface with x86:. Always capitalize the first word after the filename: thinkpad_acpi: Fix sparse warning Corrected and applied, thanks! -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[sched] 6acbfb96976: kernel BUG at kernel/smpboot.c
Hi Jiangshan,
We noticed the below BUG in commit
6acbfb96976fc3350e30d964acb1dbbdf876d55e ("sched: Fix hotplug vs.
set_cpus_allowed_ptr()")
testbox/testcase/testparams: brickland1/will-it-scale/powersave-page_fault3
brickland1 is an Ivy Bridge-EX with 128G memory.
4dac0b638310d2e9 6acbfb96976fc3350e30d964ac
--
fail:runs %reproductionfail:runs
| | |
:60 33% 20:60
dmesg.kernel_BUG_at_kernel/smpboot.c
:60 33% 20:60dmesg.invalid_opcode
:60 33% 20:60dmesg.RIP:smpboot_thread_fn
:60 33% 20:60
dmesg.Kernel_panic-not_syncing:Fatal_exception
testbox/testcase/testparams: brickland1/will-it-scale/powersave-open2
4dac0b638310d2e9 6acbfb96976fc3350e30d964ac
--
:95 26% 50:190
dmesg.kernel_BUG_at_kernel/smpboot.c
:95 26% 50:190 dmesg.invalid_opcode
:95 26% 50:190 dmesg.RIP:smpboot_thread_fn
:95 26% 50:190
dmesg.Kernel_panic-not_syncing:Fatal_exception
[1.819597] TSC synchronization [CPU#0 -> CPU#15]:
[1.825786] Measured 23680 cycles TSC warp between CPUs, turning off TSC
clock.
[1.834814] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[0.001000] #16
[0.001000] masked ExtINT on CPU#16
[0.558391] #17
[0.558135] masked ExtINT on CPU#17
[0.580199] [ cut here ]
[0.581000] kernel BUG at kernel/smpboot.c:134!
[0.581000] invalid opcode: [#1] SMP
[0.581000] Modules linked in:
[0.581000] CPU: 0 PID: 128 Comm: watchdog/17 Not tainted
3.19.0-rc5-gb711c1d #1
[0.581000] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BKLDSDP1.86B.0031.R01.1304221600 04/22/2013
[0.581000] task: 88105c15 ti: 88105c14c000 task.ti:
88105c14c000
[0.581000] RIP: 0010:[] []
smpboot_thread_fn+0x1e8/0x280
[0.581000] RSP: :88105c14fe68 EFLAGS: 00010206
[0.581000] RAX: RBX: 88105c15 RCX:
[0.581000] RDX: 88105c14ffd8 RSI: 88105c15 RDI: 0011
[0.581000] RBP: 88105c14feb8 R08: 88105c14c000 R09: 0001
[0.581000] R10: 016e3600 R11: 00800711 R12: 88105c5bc060
[0.581000] R13: 81d35040 R14: 88105c15 R15: 88105c15
[0.581000] FS: () GS:88085f80()
knlGS:
[0.581000] CS: 0010 DS: ES: CR0: 80050033
[0.581000] CR2: 88207000 CR3: 01ca5000 CR4: 001407f0
[0.581000] Stack:
[0.581000] 88105c14fee8 88105c15 88105c14fe88
[0.581000] 88105c14feb8 88105c5bd6c0 88105c5bc060
81095fb0
[0.581000] 88105c14ff48
81091f8f
[0.581000] Call Trace:
[0.581000] [] ? SyS_setgroups+0x170/0x170
[0.581000] [] kthread+0xef/0x110
[0.581000] [] ? kthread_create_on_node+0x180/0x180
[0.581000] [] ret_from_fork+0x7c/0xb0
[0.581000] [] ? kthread_create_on_node+0x180/0x180
[0.581000] Code: ff ff 90 41 8b 3c 24 65 8b 15 ad 3f f7 7e 39 d7 0f 85 a5
00 00 00 ff d0 41 c7 44 24 04 02 00 00 00 e9 e4 fe ff ff 0f 1f 44 00 00 <0f> 0b
66 0f 1f 44 00 00 65 ff 0d 39 57 f7 7e e8 94 1d 81 00 e9
[0.581000] RIP [] smpboot_thread_fn+0x1e8/0x280
[0.581000] RSP
[0.581011] ---[ end trace 261458802e83dcc4 ]---
[0.582003] Kernel panic - not syncing: Fatal exception
[0.583000] Shutting down cpus with NMI
Thanks,
Fengguang
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.19.0-rc5-gb711c1d (kbuild@cairo) (gcc version
4.9.1 (Debian 4.9.1-19) ) #1 SMP Tue Jan 20 20:28:11 CST 2015
[0.00] Command line:
BOOT_IMAGE=/kernel/x86_64-rhel/b711c1d75ba250767a33f72018f9f50658596757/vmlinuz-3.19.0-rc5-gb711c1d
user=lkp
job=/lkp/scheduled/brickland1/reconfirm_will-it-scale-powersave-page_fault3-debian-x86_64-2015-01-13.cgz-x86_64-rhel-b711c1d75ba250767a33f72018f9f50658596757-3.yaml
ARCH=x86_64
BOOT_IMAGE=/kernel/x86_64-rhel/b711c1d75ba250767a33f72018f9f50658596757/vmlinuz-3.19.0-rc5-gb711c1d
kconfig=x86_64-rhel commit=b711c1d75ba250767a33f72018f9f50658596757
branch=linux-devel/devel-hourly-2015012001 root=/dev/ram0 max_uptime=1500
RESULT_ROOT=/result/brickland1/will-it-scale/powersave-page_fault3/debian-x86_64-2015-01-13.cgz/x86_64-rhel/b711c1d75ba250767a33f72018f9f50658596757/2
ip=brickland1::dhcp ipmi_si.tryacpi=0 ipmi_watchdog.start_now=1
earlyprintk=ttyS0,115200 debug apic=debug sysrq_always_enabled
Re: [PATCH] samsung-laptop: fix sparse warning
On Thu, Feb 05, 2015 at 02:40:05PM +, Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > this patch fixes following sparse warning: > > samsung-laptop.c:1365:52: warning: Using plain integer as NULL pointer > > Signed-off-by: Lad, Prabhakar Queued, thanks. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[NFSv4.1] 6ae373394c4: kernel boot crash
Hi Trond,
We noticed the below kernel crash on
git://git.linux-nfs.org/projects/trondmy/linux-nfs.git testing
commit 6ae373394c4257bad562817aa60464ff7fe8f9c4 ("NFSv4.1: Ask for no
delegation on OPEN if using O_DIRECT")
testbox/testcase/testparams: vm-vp-quantal-x86_64/boot/1
0e3b137fbf0f4ab9 6ae373394c4257bad562817aa6
--
fail:runs %reproductionfail:runs
| | |
:100 4% 2:46dmesg.BUG:kernel_test_crashed
The last dmesg lines before the kernel crash are
[0.274266] NET: Registered protocol family 1
[0.275236] RPC: Registered named UNIX socket transport module.
[0.276123] RPC: Registered udp transport module.
[0.276860] RPC: Registered tcp transport module.
[0.277617] RPC: Registered tcp NFSv4.1 backchannel transport module
Thanks,
Fengguang
---
testcase: boot
default-monitors:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor:
model: qemu-system-x86_64 -enable-kvm
nr_vm: 64
nr_cpu: 2
memory: 360M
rootfs: quantal-core-x86_64.cgz
boot-slabinfo:
boot-meminfo:
memmap:
boot-memory:
boot-time:
kernel-size:
sleep: 1
branch: nfs/linux-next
commit: 6ae373394c4257bad562817aa60464ff7fe8f9c4
repeat_to: 2
testbox: vm-vp-quantal-x86_64-3
tbox_group: vm-vp-quantal-x86_64
kconfig: x86_64-rhel
enqueue_time: 2015-02-05 18:54:42.323364417 +08:00
kernel:
"/kernel/x86_64-rhel/6ae373394c4257bad562817aa60464ff7fe8f9c4/vmlinuz-3.19.0-rc5-g6ae3733"
user: lkp
queue: rand
result_root:
"/result/vm-vp-quantal-x86_64/boot/1/quantal-core-x86_64.cgz/x86_64-rhel/6ae373394c4257bad562817aa60464ff7fe8f9c4/0"
job_file:
"/lkp/scheduled/vm-vp-quantal-x86_64-3/rand_boot-1-quantal-core-x86_64.cgz-x86_64-rhel-6ae373394c4257bad562817aa60464ff7fe8f9c4-1.yaml"
dequeue_time: 2015-02-05 18:55:49.602324841 +08:00
job_state: finished
Re: [RFT PATCH 2/4] compal-laptop: Check return value of power_supply_register
On Tue, Jan 27, 2015 at 12:30:19PM +0100, Krzysztof Kozlowski wrote:
> The return value of power_supply_register() call was not checked and
> even on error probe() function returned 0. If registering failed then
> during unbind the driver tried to unregister power supply which was not
> actually registered.
>
> This could lead to memory corruption because power_supply_unregister()
> unconditionally cleans up given power supply.
>
> Fix this by checking return status of power_supply_register() call. In
> case of failure, unregister the hwmon device and fail the probe. Add a
> fixme note about missing hwmon_device_unregister() in driver removal.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface")
> Cc:
> ---
> drivers/platform/x86/compal-laptop.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/compal-laptop.c
> b/drivers/platform/x86/compal-laptop.c
> index 15c0fab2bfa1..cf55a9246f12 100644
> --- a/drivers/platform/x86/compal-laptop.c
> +++ b/drivers/platform/x86/compal-laptop.c
> @@ -1036,12 +1036,16 @@ static int compal_probe(struct platform_device *pdev)
>
> /* Power supply */
> initialize_power_supply_data(data);
> - power_supply_register(_device->dev, >psy);
> + err = power_supply_register(_device->dev, >psy);
> + if (err < 0)
> + goto psy_err;
>
> platform_set_drvdata(pdev, data);
>
> return 0;
>
> +psy_err:
> + hwmon_device_unregister(hwmon_dev);
> remove:
> sysfs_remove_group(>dev.kobj, _platform_attr_group);
> return err;
> @@ -1072,6 +1076,7 @@ static int compal_remove(struct platform_device *pdev)
>
> data = platform_get_drvdata(pdev);
> power_supply_unregister(>psy);
> + /* FIXME: missing hwmon_device_unregister() */
Is this FIXME a leftover? Is there a reason we can't fix this now instead of
adding a FIXME?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] samsung-laptop: enable better lid handling
On Thu, Jan 29, 2015 at 01:04:37PM +, Julijonas Kikutis wrote: > Some Samsung laptops with SABI3 delay the sleep for 10 seconds after > the lid is closed and do not wake up from sleep after the lid is opened. > A SABI command is needed to enable the better behavior. > > Command = 0x6e, d0 = 0x81 enables this behavior. Returns d0 = 0x01. > Command = 0x6e, d0 = 0x80 disables this behavior. Returns d0 = 0x00. > > Command = 0x6d and any d0 queries the state. This returns: > d0 = 0x0*01, d1 = 0x00, d2 = 0x00, d3 = 0x0* when it is enabled. > d0 = 0x0*00, d1 = 0x00, d2 = 0x00, d3 = 0x0* when it is disabled. > Where * is 0 - laptop has never slept or hibernated after switch on, >1 - laptop has hibernated just before, >2 - laptop has slept just before. > > Patch addresses bug https://bugzilla.kernel.org/show_bug.cgi?id=75901 . > It adds a sysfs attribute lid_handling with a description and also an > addition to the quirks structure to enable the mode by default. > > A user with another laptop in the bug report says that "power button has > to be pressed twice to wake the machine" when he or she enabled the mode > manually using the SABI command. Therefore, it is enabled by default > only for the single laptop that I have tested. > > Signed-off-by: Julijonas Kikutis Queued up, thanks Jujijonas. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/20] power_supply: Move run-time configuration to separate structure
On Fri, Jan 30, 2015 at 03:47:40PM +0100, Krzysztof Kozlowski wrote: > Add new structure 'power_supply_config' for holding run-time > initialization data like of_node, supplies and private driver data. > > The power_supply_register() function is changed so all power supply > drivers need updating. > > When registering the power supply this new 'power_supply_config' should be > used instead of directly initializing 'struct power_supply'. This allows > changing the ownership of power_supply structure from driver to the > power supply core in next patches. > > When a driver does not use of_node or supplies then it should use NULL > as config. If driver uses of_node or supplies then it should allocate > config on stack and initialize it with proper values. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Bartlomiej Zolnierkiewicz For drivers/platform/x86/compal-laptop.c Reviewed-by: Darren Hart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] vxlan: Wrong type passed to %pIS
src_ip is a pointer to a union vxlan_addr, one member of which is a
struct sockaddr. Passing a pointer to src_ip is wrong; one should pass
the value of src_ip itself. Since %pIS formally expects something of
type struct sockaddr*, let's pass a pointer to the appropriate union
member, though this of course doesn't change the generated code.
Fixes: e4c7ed415387 ("vxlan: add ipv6 support")
Signed-off-by: Rasmus Villemoes
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index a8c755dcab14..11defbb24183 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -991,7 +991,7 @@ static bool vxlan_snoop(struct net_device *dev,
if (net_ratelimit())
netdev_info(dev,
"%pM migrated from %pIS to %pIS\n",
- src_mac, >remote_ip, _ip);
+ src_mac, >remote_ip.sa, _ip->sa);
rdst->remote_ip = *src_ip;
f->updated = jiffies;
--
2.1.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] llist: Fix missing lockless_dereference()
A lockless_dereference() appears to be missing in llist_del_first().
It should only matter for Alpha in practice.
Signed-off-by: Mathieu Desnoyers
CC: Huang Ying
CC: Paul McKenney
CC: David Howells
CC: Pranith Kumar
CC: sta...@vger.kernel.org # v3.1+
---
lib/llist.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/llist.c b/lib/llist.c
index f76196d..f34e176 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
/**
@@ -67,7 +68,12 @@ struct llist_node *llist_del_first(struct llist_head *head)
{
struct llist_node *entry, *old_entry, *next;
- entry = head->first;
+ /*
+* Load entry before entry->next. Matches the implicit
+* memory barrier before the cmpxchg in llist_add_batch(),
+* which ensures entry->next is stored before entry.
+*/
+ entry = lockless_dereference(head->first);
for (;;) {
if (entry == NULL)
return NULL;
--
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: issues on last 32 bit m68k toolchain
On Fri, Feb 06, 2015 at 09:46:52PM +0100, Angelo Dureghello wrote: > Dear all, > > i was using the public x86 32bit toolchain from kernel.org: > > https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz > > Unfortunately, for ColdFire arch, there is a bug in gas/binutils > for this toolchain: > > https://sourceware.org/bugzilla/show_bug.cgi?id=17877 > > Produced binaries are not working on the target. > > Is it possible to have available another m68k toolchain > (including older or newer binutils/as than the bugged 2.22) ? > Can you try the 64 bit toolchain ? https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_m68k-linux.tar.gz Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Hello Tyler, Thank you very much for helping test this patchset! 2015-02-07 2:10 GMT+08:00 Tyler Baker : > Hi Bintian, > > This patch applied to next-20150204 is producing build failures on > various ARM defconfigs[1]. I received the following error in all > cases: > > drivers/built-in.o: In function `hi6220_clk_register_divider': > :(.init.text+0x1a84c): undefined reference to `hi6220_register_clkdiv' > Makefile:925: recipe for target 'vmlinux' failed > make: *** [vmlinux] Error 1 It's my fault, I just test on ARM64, The following patch can fix this error: = diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile index bbf0539..48f0116 100644 --- a/drivers/clk/hisilicon/Makefile +++ b/drivers/clk/hisilicon/Makefile @@ -2,9 +2,9 @@ # Hisilicon Clock specific Makefile # -obj-y += clk.o clkgate-separated.o +obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o -obj-$(CONFIG_COMMON_CLK_HI6220)+= clkdivider-hi6220.o clk-hi6220.o +obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o == I will fix this problem in next version. Thanks, Bintian > > On 5 February 2015 at 01:24, Bintian Wang wrote: >> Add clock drivers for hi6220 SoC, this driver controls the SoC >> registers to supply different clocks to different IPs in the SoC. >> >> We add one divider clock for hi6220 because the divider in hi6220 >> also has a mask bit but it doesnot obey the rule defined by flag >> "CLK_DIVIDER_HIWORD_MASK", we can not get index of the mask bit by >> left shift fixed bits (e.g. 16 bits), so we add this divider clock >> to handle it. >> >> This patch also enables this clock driver for ARCH_HISI and document >> devicetree bindings. >> >> Signed-off-by: Bintian Wang >> Reviewed-by: Haojian Zhuang >> Reviewed-by: Zhangfei Gao >> --- >> .../devicetree/bindings/clock/hi6220-clock.txt | 30 +++ >> arch/arm64/Kconfig |1 + >> drivers/clk/Kconfig|2 + >> drivers/clk/Makefile |4 +- >> drivers/clk/hisilicon/Kconfig |5 + >> drivers/clk/hisilicon/Makefile |1 + >> drivers/clk/hisilicon/clk-hi6220.c | 284 >> >> drivers/clk/hisilicon/clk.c| 29 ++ >> drivers/clk/hisilicon/clk.h| 17 ++ >> drivers/clk/hisilicon/clkdivider-hi6220.c | 273 >> +++ >> include/dt-bindings/clock/hi6220-clock.h | 172 >> 11 files changed, 815 insertions(+), 3 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt >> create mode 100644 drivers/clk/hisilicon/Kconfig >> create mode 100644 drivers/clk/hisilicon/clk-hi6220.c >> create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c >> create mode 100644 include/dt-bindings/clock/hi6220-clock.h >> >> diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> b/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> new file mode 100644 >> index 000..a3ddda1 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt >> @@ -0,0 +1,30 @@ >> +* Hisilicon Hi6220 Clock Controller >> + >> +The hi6220 clock controller generates and supplies clock to various >> +controllers within the hi6220 SoC. >> + >> +Required Properties: >> + >> +- compatible: should be one of the following: >> + - "hisilicon,hi6220-clock-ao" - controller for those clocks under SoC >> + power always on(AO) domain, it is the sub node of SoC power AO >> + controller in dts file. >> + - "hisilicon,hi6220-clock-sys" - controller for those clocks under SoC >> + system control domain, it is the sub node of SoC system controller >> + in dts file. >> + - "hisilicon,hi6220-clock-media" - controller for those clocks under >> + SoC media control domain, it is the sub node of SoC media controller >> + in dts file. >> + - "hisilicon,hi6220-clock-power" - controller for those clocks under >> + SoC power control domain, it is the sub node of SoC power controller >> + in dts file. >> + >> +- reg: physical base address of the controller and length of memory mapped >> + region. >> + >> +- #clock-cells: should be 1. >> + >> +Each clock is assigned an identifier and client nodes use this identifier >> +to specify the clock which they consume. >> + >> +All these identifier could be found in . >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 78cd41c8..6efc3e3 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -175,6 +175,7 @@ config ARCH_XGENE >> >> config ARCH_HISI >> bool "Hisilicon SoC Family" >> + select COMMON_CLK_HI6220 >> help >> This enables
Re: [PATCH] af_packet: don't pass empty blocks for PACKET_V3
On Thu, Feb 5, 2015 at 10:54 PM, Alexander Drozdov wrote:
> On 05.02.2015 23:01:38 +0300 Willem de Bruijn wrote:
>>
>> On Wed, Feb 4, 2015 at 9:58 PM, Alexander Drozdov
>> wrote:
>>>
>>> Don't close an empty block on timeout. Its meaningless to
>>> pass it to the user. Moreover, passing empty blocks wastes
>>> CPU & buffer space increasing probability of packets
>>> dropping on small timeouts.
>>>
>>> Side effect of this patch is indefinite user-space wait
>>> in poll on idle links. But, I believe its better to set
>>> timeout for poll(2) when needed than to get empty blocks
>>> every millisecond when not needed.
>>
>> This change would break existing applications that have come
>> to depend on the periodic signal.
>>
>> I don't disagree with the argument that the data ready signal
>> should be sent only when a block is full or a timer expires and
>> at least some data is waiting, but that is moot at this point.
>
> I missed something. As pointed by Guy Harris ,
> before the previous patch periodic signal was not delivered. The previous
> patch
> (da413eec729dae5dc by Dan Collins ) is for 3.19 kernel
> only. Should we care about existing 3.19-only applications?
It does sound reasonable to expect processes to handle infinite sleep
on no data if that is the historical behavior of the interface.
>>
>>> Signed-off-by: Alexander Drozdov
>>> ---
>>> net/packet/af_packet.c | 10 +-
>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>>> index 9cfe2e1..9a2f70a 100644
>>> --- a/net/packet/af_packet.c
>>> +++ b/net/packet/af_packet.c
>>> @@ -698,6 +698,10 @@ static void prb_retire_rx_blk_timer_expired(unsigned
>>> long data)
>>>
>>> if (pkc->last_kactive_blk_num == pkc->kactive_blk_num) {
>>> if (!frozen) {
>>> + if (!BLOCK_NUM_PKTS(pbd)) {
>>> + /* An empty block. Just refresh the
>>> timer. */
>>> + goto refresh_timer;
>>> + }
>>> prb_retire_current_block(pkc, po,
>>> TP_STATUS_BLK_TMO);
>>> if (!prb_dispatch_next_block(pkc, po))
>>> goto refresh_timer;
>>> @@ -798,7 +802,11 @@ static void prb_close_block(struct tpacket_kbdq_core
>>> *pkc1,
>>> h1->ts_last_pkt.ts_sec = last_pkt->tp_sec;
>>> h1->ts_last_pkt.ts_nsec = last_pkt->tp_nsec;
>>> } else {
>>> - /* Ok, we tmo'd - so get the current time */
>>> + /* Ok, we tmo'd - so get the current time.
>>> +*
>>> +* It shouldn't really happen as we don't close empty
>>> +* blocks. See prb_retire_rx_blk_timer_expired().
>>> +*/
>>> struct timespec ts;
>>> getnstimeofday();
>>> h1->ts_last_pkt.ts_sec = ts.tv_sec;
>>> --
>>> 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: [Linaro-acpi] [PATCH v8 02/21] acpi: fix acpi_os_ioremap for arm64
On 6 February 2015 at 14:16, Catalin Marinas wrote: > On Fri, Feb 06, 2015 at 11:08:51AM +, Ard Biesheuvel wrote: >> On 6 February 2015 at 10:36, Catalin Marinas wrote: >> > On Thu, Feb 05, 2015 at 10:16:03PM +, Ard Biesheuvel wrote: >> >> On 5 February 2015 at 17:48, Catalin Marinas >> >> wrote: >> >> > On Thu, Feb 05, 2015 at 04:42:19PM +, Al Stone wrote: >> >> >> On 02/05/2015 06:54 AM, Mark Salter wrote: >> >> >> > On Thu, 2015-02-05 at 10:41 +, Catalin Marinas wrote: >> >> >> >> On Wed, Feb 04, 2015 at 06:58:14PM +, Mark Salter wrote: >> >> >> >>> On Wed, 2015-02-04 at 17:57 +, Catalin Marinas wrote: >> >> >> On Wed, Feb 04, 2015 at 04:08:27PM +, Mark Salter wrote: >> >> >> > acpi_os_remap() is used to map ACPI tables. These tables may be >> >> >> > in ram >> >> >> > which are already included in the kernel's linear RAM mapping. >> >> >> > So we >> >> >> > need ioremap_cache to avoid two mappings to the same physical >> >> >> > page >> >> >> > having different caching attributes. >> >> >> >> >> >> What's the call path to acpi_os_ioremap() on such tables already >> >> >> in the >> >> >> linear mapping? I can see an acpi_map() function which already >> >> >> takes >> >> >> care of the RAM mapping case but there are other cases where >> >> >> acpi_os_ioremap() is called directly. For example, >> >> >> acpi_os_read_memory(), can it be called on both RAM and I/O? >> >> >> >>> >> >> >> >>> acpi_map() is the one I've seen. >> >> >> >> >> >> >> >> By default, if should_use_kmap() is not patched for arm64, it >> >> >> >> translates >> >> >> >> to page_is_ram(); acpi_map() would simply use a kmap() which >> >> >> >> returns the >> >> >> >> current kernel linear mapping on arm64. >> >> >> > >> >> >> > The problem with kmap() is that it only maps a single page. I've seen >> >> >> > tables over 4k which is why I patched acpi_map() not to use kmap() on >> >> >> > arm64. >> >> >> >> >> >> Right. Mark replied to this before I could; using kmap() enforced a 4k >> >> >> (one page) limit that we kept breaking with some ACPI tables being >> >> >> larger >> >> >> than that (DSDTs and SSDTs, fwiw). This would lead to some very odd >> >> >> behaviors >> >> >> when most but not all of a device definition was within the page; >> >> >> using the >> >> >> table checksums was one way of detecting the issues. >> >> > >> >> > OK. So I think Mark's original patch was ok, assuming that the System >> >> > Memory cases mentioned by Graeme are detected with page_is_ram(). >> >> >> >> page_is_ram() returns whether a pfn is covered by the linear mapping, >> >> so memory before the kernel or after a mem= limit will be >> >> misidentified. >> > >> > OK. So in conclusion acpi_os_ioremap() may need to create a cacheable >> > mapping even when !page_is_ram() but it has no way of knowing that >> > unless we change the core ACPI code to differentiate between >> > ioremap_cache and ioremap_nocache. Did I get it right? >> >> Yes and no. Your analysis about the core issue is correct, but it is >> something we can fix on our end if we like. >> This issue has been on our radar for a while, and we proposed a way to >> fix it here >> >> http://thread.gmane.org/gmane.linux.kernel.efi/5133 > > I looked at it briefly but it had ACPI in the subject and decided it's > not urgent ;). > > IIUC, it relies on the EFI system table to be available and the kernel > will register the appropriate "System RAM" resources. This assumes in > general that the kernel is booted via the EFI stub. Do we expect Xen or > kexec to pass an EFI system table when not booting via EFI stub? > That's just one of the patches, and it is not actually the one that addresses this issue. (Registering the iomem resources is mainly to ensure MMIO regions for the NOR flash or RTC are not claimed by a kernel driver if they are being driven by the firmware at runtime) The point of the series is to wire up the 'physmem' memblock table to record what we know is system RAM, and use that to decide what flavor of mapping to use. The series as-is addresses the non-UEFI case as well, the only thing missing is wiring up page_is_ram() to memblock_is_physmem() (the former is __weak already in the core code, but perhaps it would be better to just use the latter directly) With these changes, we no longer have to care whether a reserved region sits below PHYS_OFFSET or above a mem= limit Note that, in the non-UEFI case, we may need to consider removing memreserve regions from the linear mapping. Code that assumes it is mapped is broken anyway, due to the same concerns outlined above (i.e., < PHYS_OFFSET or > mem=). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
epoll: optimize setting task running after blocking
After waking up a task waiting for an event, we explicitly mark it as TASK_RUNNING (which is necessary as we do the checks for wakeups as TASK_INTERRUPTABLE). Once running and dealing with actually delivering the events, we're obviously not planning on calling schedule, thus we can relax the implied barrier and simply update the state with __set_current_state(). Signed-off-by: Davidlohr Bueso --- fs/eventpoll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index d77f944..1e009ca 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1639,9 +1639,9 @@ fetch_events: spin_lock_irqsave(>lock, flags); } - __remove_wait_queue(>wq, ); - set_current_state(TASK_RUNNING); + __remove_wait_queue(>wq, ); + __set_current_state(TASK_RUNNING); } check_events: /* Is it worth to try to dig for events ? */ -- 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/
[PATCH v8 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Kevin Cernekee
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-bcm-iproc.c | 494
3 files changed, 505 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index ab838d9..3d08731 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,16 @@ config I2C_BCM2835
This support is also available as a module. If so, the module
will be called i2c-bcm2835.
+config I2C_BCM_IPROC
+ tristate "Broadcom iProc I2C controller"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 56388f6..d93b509 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o
obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..5d0a03f
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,494 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CFG_OFFSET 0x00
+#define CFG_RESET_SHIFT 31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET 0x04
+#define TIM_CFG_MODE_400_SHIFT 31
+
+#define M_FIFO_CTRL_OFFSET 0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT 16
+#define M_FIFO_RX_CNT_MASK 0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK 0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT 31
+#define M_CMD_STATUS_SHIFT 25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR 0x2
+#define M_CMD_STATUS_NACK_DATA 0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK 0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT 8
+#define M_CMD_RD_CNT_SHIFT 0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT 31
+#define IE_M_RX_THLD_SHIFT 30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT 31
+#define IS_M_RX_THLD_SHIFT 30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET 0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT 0
+#define M_TX_DATA_MASK 0xff
+
+#define M_RX_OFFSET 0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT 29
+#define M_RX_DATA_SHIFT 0
+#define M_RX_DATA_MASK 0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+ I2C_SPD_100K = 0,
+ I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+
[PATCH v8 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Kevin Cernekee
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..ff5fb6a 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
+ i2c0: i2c@18008000 {
+ compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@1800b000 {
+ compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
+ reg = <0x1800b000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/3] i2c: iProc: define Broadcom iProc I2C binding
Document the I2C device tree binding for Broadcom iProc family of
SoCs
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Kevin Cernekee
---
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+ i2c0: i2c@18008000 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+
+ codec: wm8750@1a {
+ compatible = "wlf,wm8750";
+ reg = <0x1a>;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/3] Add I2C support to Broadcom iProc
This patchset contains the initial I2C support for Broadcom iProc family of SoCs. The iProc I2C controller has separate internal TX and RX FIFOs, each has a size of 64 bytes. The iProc I2C controller supports two bus speeds including standard mode (100 kHz) and fast mode (400 kHz) Changes from v7: - Remove redundant 10-bit address check in the driver - Fix the driver that accidentally emits 1-byte of data with zero content in the case of SMBUS quick command - Improve debugging prints in the driver - Other minor improvements Changes from v6: - Get rid of unnecessary atomic variable usage in the driver - Improve the "waiting for transaction to complete" logic further by making sure there's no pending/ongoing interrupt by the time when flag 'xfer_is_done' is checked - After disabling interrupt with 'writel', add 'readl' to the same register to flush the bus to ensure the write has gone through Changes from v5: - Improve the "waiting for transaction to be complete" logic to take care of the corner case when an interrupt fires after wait_for_completion_timeout times out - Improve the logic to disable I2C interrupt in the remove function. Make it more generic so it works for both dedicated and shared interrupt Changes from v4: - Remove redundant header file includes - Change the logic that waits for the host controller to be idle to simply return -EBUSY - Use proper print level and error codes in the driver - Allow zero length message in the driver to support I2C_SMBUS_QUICK - Change back to use devm_request_irq. Disable interrupt in the remove function so there's no outstanding I2C interrupt when the driver is being removed from the framework - Other minor miscellaneous improvements and fixes Changes from v3: - Add config dependency to COMPILE_TEST to allow the driver to be build tested by other platforms - Improve CPU utilization efficiency in the loop of waiting for bus to idle - Add more comment in the driver to clarify the way how the "start busy" interrupt is triggered from the I2C controller - Fix inconsistent coding style and format - Improve the bus speed validation logic in the driver - Add code to free the interrupt line in driver's remove function. Also change to use non-devm API to request the interrupt line - Other miscellaneous improvements and fixes Changes from v2: - Have the I2C driver default to y so it does not need to be selected from ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still depends on ARCH_BCM_IPROC - Get rid of redundant check on resource returned by platform_get_resource Changes from v1: - Fix function argument parenthesis - Get rid of redundant driver owner field Ray Jui (3): i2c: iProc: define Broadcom iProc I2C binding i2c: iproc: Add Broadcom iProc I2C Driver ARM: dts: add I2C device nodes for Broadcom Cygnus .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37 ++ arch/arm/boot/dts/bcm-cygnus.dtsi | 20 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-bcm-iproc.c | 494 5 files changed, 562 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a method to distinguish between syscall-enter/exit-stop
On Fri, Feb 6, 2015 at 3:17 PM, Dmitry V. Levin wrote: > On Fri, Feb 06, 2015 at 12:07:03PM -0800, Kees Cook wrote: >> On Fri, Feb 6, 2015 at 11:32 AM, Andy Lutomirski wrote: >> > On Fri, Feb 6, 2015 at 11:23 AM, Kees Cook wrote: > [...] >> >> And an unrelated thought: >> >> >> >> 3) Can't we find some way to fix the inability of a ptracer to >> >> distinguish between syscall-enter-stop and syscall-exit-stop? >> > >> > Couldn't we add PTRACE_O_TRACESYSENTRY and PTRACE_O_TRACESYSEXIT along >> > the lines of PTRACE_O_TRACESYSGOOD? >> >> That might be a nice idea. I haven't written a test to see, but what >> does PTRACE_GETEVENTMSG return on syscall-enter/exit-stop? > > The value returned by PTRACE_GETEVENTMSG is the value set along with the > latest PTRACE_EVENT_*. > In case of syscall-enter/exit-stop (which is not a PTRACE_EVENT_*), > there is no particular value set for PTRACE_GETEVENTMSG. Could we define one to help distinguish? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v7,2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 2/6/2015 2:31 PM, Kevin Cernekee wrote: > On Mon, Jan 19, 2015 at 01:51:49PM -0800, Ray Jui wrote: >> Add initial support to the Broadcom iProc I2C controller found in the >> iProc family of SoCs. >> >> The iProc I2C controller has separate internal TX and RX FIFOs, each has >> a size of 64 bytes. The iProc I2C controller supports two bus speeds >> including standard mode (100kHz) and fast mode (400kHz) >> >> Signed-off-by: Ray Jui broadcom.com> >> Reviewed-by: Scott Branden broadcom.com> >> --- >> drivers/i2c/busses/Kconfig | 10 + >> drivers/i2c/busses/Makefile|1 + >> drivers/i2c/busses/i2c-bcm-iproc.c | 505 >> >> 3 files changed, 516 insertions(+) >> create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index 31e8308..af76d23 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> -372,6 +372,16 config I2C_BCM2835 >>This support is also available as a module. If so, the module >>will be called i2c-bcm2835. >> >> +config I2C_BCM_IPROC >> +tristate "Broadcom iProc I2C controller" >> +depends on ARCH_BCM_IPROC || COMPILE_TEST >> +default ARCH_BCM_IPROC >> +help >> + If you say yes to this option, support will be included for the >> + Broadcom iProc I2C controller. >> + >> + If you don't know what to do here, say N. >> + >> config I2C_BCM_KONA >> tristate "BCM Kona I2C adapter" >> depends on ARCH_BCM_MOBILE >> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> index 56388f6..d93b509 100644 >> --- a/drivers/i2c/busses/Makefile >> +++ b/drivers/i2c/busses/Makefile >> -33,6 +33,7 obj-$(CONFIG_I2C_AT91) += >> i2c-at91.o >> obj-$(CONFIG_I2C_AU1550)+= i2c-au1550.o >> obj-$(CONFIG_I2C_AXXIA) += i2c-axxia.o >> obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o >> +obj-$(CONFIG_I2C_BCM_IPROC) += i2c-bcm-iproc.o >> obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o >> obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o >> obj-$(CONFIG_I2C_CBUS_GPIO) += i2c-cbus-gpio.o >> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c >> b/drivers/i2c/busses/i2c-bcm-iproc.c >> new file mode 100644 >> index 000..64c622f >> --- /dev/null >> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c >> -0,0 +1,505 >> +/* >> + * Copyright (C) 2014 Broadcom Corporation >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation version 2. >> + * >> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define CFG_OFFSET 0x00 >> +#define CFG_RESET_SHIFT 31 >> +#define CFG_EN_SHIFT 30 >> +#define CFG_M_RETRY_CNT_SHIFT16 >> +#define CFG_M_RETRY_CNT_MASK 0x0f >> + >> +#define TIM_CFG_OFFSET 0x04 >> +#define TIM_CFG_MODE_400_SHIFT 31 >> + >> +#define M_FIFO_CTRL_OFFSET 0x0c >> +#define M_FIFO_RX_FLUSH_SHIFT31 >> +#define M_FIFO_TX_FLUSH_SHIFT30 >> +#define M_FIFO_RX_CNT_SHIFT 16 >> +#define M_FIFO_RX_CNT_MASK 0x7f >> +#define M_FIFO_RX_THLD_SHIFT 8 >> +#define M_FIFO_RX_THLD_MASK 0x3f >> + >> +#define M_CMD_OFFSET 0x30 >> +#define M_CMD_START_BUSY_SHIFT 31 >> +#define M_CMD_STATUS_SHIFT 25 >> +#define M_CMD_STATUS_MASK0x07 >> +#define M_CMD_STATUS_SUCCESS 0x0 >> +#define M_CMD_STATUS_LOST_ARB0x1 >> +#define M_CMD_STATUS_NACK_ADDR 0x2 >> +#define M_CMD_STATUS_NACK_DATA 0x3 >> +#define M_CMD_STATUS_TIMEOUT 0x4 >> +#define M_CMD_PROTOCOL_SHIFT 9 >> +#define M_CMD_PROTOCOL_MASK 0xf >> +#define M_CMD_PROTOCOL_BLK_WR0x7 >> +#define M_CMD_PROTOCOL_BLK_RD0x8 >> +#define M_CMD_PEC_SHIFT 8 >> +#define M_CMD_RD_CNT_SHIFT 0 >> +#define M_CMD_RD_CNT_MASK0xff >> + >> +#define IE_OFFSET0x38 >> +#define IE_M_RX_FIFO_FULL_SHIFT 31 >> +#define IE_M_RX_THLD_SHIFT 30 >> +#define IE_M_START_BUSY_SHIFT28 >> + >> +#define IS_OFFSET0x3c >> +#define IS_M_RX_FIFO_FULL_SHIFT 31 >> +#define IS_M_RX_THLD_SHIFT 30 >> +#define IS_M_START_BUSY_SHIFT28 >> + >> +#define M_TX_OFFSET 0x40 >> +#define M_TX_WR_STATUS_SHIFT 31 >> +#define M_TX_DATA_SHIFT 0 >> +#define M_TX_DATA_MASK 0xff >> + >>
Re: [PATCH] ext4: fix indirect punch hole corruption
On 02/06/2015 06:28 PM, Omar Sandoval wrote: > On Thu, Feb 05, 2015 at 03:30:47PM -0600, Chris J Arges wrote: >> On 02/05/2015 02:50 PM, Omar Sandoval wrote: >>> Commit 4f579ae7de56 (ext4: fix punch hole on files with indirect >>> mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect >>> mapping. However, the case where the punch happens within one level of >>> indirection is incorrect. It assumes that the partial branches returned >>> from ext4_find_shared will have the same depth, but this is not >>> necessarily the case even when the offsets have the same depth. For >>> example, if the last block occurs at the beginning of an indirect group >>> (i.e., it has an offset of 0 at the end of the offsets array), then >>> ext4_find_shared will return a shallower chain. So, let's handle the >>> mismatch and clean up that case. Tested with generic/270, which no >>> longer leads to an inconsistent filesystem like before. >>> >>> Signed-off-by: Omar Sandoval >> >> >> Omar, >> >> Tried running this with my original reproducer (qcow2 snapshotting and >> rebooting) and got the following: >> [ cut here ] >> kernel BUG at fs/ext4/indirect.c:1488! >> invalid opcode: [#1] SMP >> >> CPU: 4 PID: 9771 Comm: qemu-img Tainted: GW E >> 3.19.0-rc7-b164aa5 #22 >> Hardware name: XXX >> task: 880243a34aa0 ti: 880240f3c000 task.ti: 880240f3c000 >> RIP: 0010:[] [] >> ext4_ind_remove_space+0x737/0x740 >> RSP: 0018:880240f3fc98 EFLAGS: 00010246 >> RAX: 880240f3fd98 RBX: 880240f3fd98 RCX: 880098c684dc >> RDX: 880098c684d4 RSI: 880240f3fd08 RDI: 880098c684e0 >> RBP: 880240f3fdf8 R08: 880098c684e0 R09: >> R10: 880240f3faa0 R11: 0038 R12: 88009bb65810 >> R13: 0003 R14: 880240f3fd08 R15: 880240f3fd68 >> FS: 7f7ad84ad700() GS:88024e50() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 7f7ae19a78ff CR3: 000241c52000 CR4: 003427e0 >> DR0: DR1: DR2: >> DR3: DR6: fffe0ff0 DR7: 0400 >> Stack: >> ea0002596600 88009bb65960 0050 0100 >> 8802447a2900 0003 880240f3fd08 88009b96c030 >> 880240f3fd08 024b 000d 8834 >> Call Trace: >> [] ? ext4_discard_preallocations+0x16c/0x480 >> [] ext4_punch_hole+0x3bf/0x430 >> [] ext4_fallocate+0x16e/0x8c0 >> [] ? __sb_start_write+0x49/0xf0 >> [] vfs_fallocate+0x12f/0x250 >> [] ? SyS_futex+0x71/0x150 >> [] SyS_fallocate+0x48/0x80 >> [] system_call_fastpath+0x16/0x1b >> Code: 40 4c 8d 0c c5 e8 ff ff ff 49 c1 f9 03 45 69 c9 ab aa aa aa e8 6b >> e2 ff ff 48 8b 85 10 ff ff ff c7 00 00 00 00 00 e9 fd fa ff ff <0f> 0b >> 0f 0b 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 >> RIP [] ext4_ind_remove_space+0x737/0x740 >> RSP >> ---[ end trace 05f053fdd5d908a8 ]--- >> >> So this is hitting the BUG_ON you added. >> --chris >> > > Chris, > > Would you mind sending over your exact reproduction steps? I've cooked > up a patch which appears to be working, but I want to test it out a bit > more before I send it out. > > Thanks, > Omar, To reproduce this issue do the following: 1) Setup ext4 ^extents, or ext3 filesystem with CONFIG_EXT4_USE_FOR_EXT23=y 2) Create and install a VM using a qcow2 image and store the file on the filesystem 3) Snapshot the image with qemu-img 4) Boot the image and do some disk operations (fio,etc) 5) Shutdown image and delete snapshot 6) Repeat 3-5 until VM no longer boots due to image corruption, generally this takes a few iterations depending on disk operations. I have the reproducer ready to go on my system to feel free to send me a preliminary patch and I'll test it again over the weekend. Thanks, --chris j arges -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ext4: fix indirect punch hole corruption
On Thu, Feb 05, 2015 at 03:30:47PM -0600, Chris J Arges wrote: > On 02/05/2015 02:50 PM, Omar Sandoval wrote: > > Commit 4f579ae7de56 (ext4: fix punch hole on files with indirect > > mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect > > mapping. However, the case where the punch happens within one level of > > indirection is incorrect. It assumes that the partial branches returned > > from ext4_find_shared will have the same depth, but this is not > > necessarily the case even when the offsets have the same depth. For > > example, if the last block occurs at the beginning of an indirect group > > (i.e., it has an offset of 0 at the end of the offsets array), then > > ext4_find_shared will return a shallower chain. So, let's handle the > > mismatch and clean up that case. Tested with generic/270, which no > > longer leads to an inconsistent filesystem like before. > > > > Signed-off-by: Omar Sandoval > > > Omar, > > Tried running this with my original reproducer (qcow2 snapshotting and > rebooting) and got the following: > [ cut here ] > kernel BUG at fs/ext4/indirect.c:1488! > invalid opcode: [#1] SMP > > CPU: 4 PID: 9771 Comm: qemu-img Tainted: GW E > 3.19.0-rc7-b164aa5 #22 > Hardware name: XXX > task: 880243a34aa0 ti: 880240f3c000 task.ti: 880240f3c000 > RIP: 0010:[] [] > ext4_ind_remove_space+0x737/0x740 > RSP: 0018:880240f3fc98 EFLAGS: 00010246 > RAX: 880240f3fd98 RBX: 880240f3fd98 RCX: 880098c684dc > RDX: 880098c684d4 RSI: 880240f3fd08 RDI: 880098c684e0 > RBP: 880240f3fdf8 R08: 880098c684e0 R09: > R10: 880240f3faa0 R11: 0038 R12: 88009bb65810 > R13: 0003 R14: 880240f3fd08 R15: 880240f3fd68 > FS: 7f7ad84ad700() GS:88024e50() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f7ae19a78ff CR3: 000241c52000 CR4: 003427e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Stack: > ea0002596600 88009bb65960 0050 0100 > 8802447a2900 0003 880240f3fd08 88009b96c030 > 880240f3fd08 024b 000d 8834 > Call Trace: > [] ? ext4_discard_preallocations+0x16c/0x480 > [] ext4_punch_hole+0x3bf/0x430 > [] ext4_fallocate+0x16e/0x8c0 > [] ? __sb_start_write+0x49/0xf0 > [] vfs_fallocate+0x12f/0x250 > [] ? SyS_futex+0x71/0x150 > [] SyS_fallocate+0x48/0x80 > [] system_call_fastpath+0x16/0x1b > Code: 40 4c 8d 0c c5 e8 ff ff ff 49 c1 f9 03 45 69 c9 ab aa aa aa e8 6b > e2 ff ff 48 8b 85 10 ff ff ff c7 00 00 00 00 00 e9 fd fa ff ff <0f> 0b > 0f 0b 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 > RIP [] ext4_ind_remove_space+0x737/0x740 > RSP > ---[ end trace 05f053fdd5d908a8 ]--- > > So this is hitting the BUG_ON you added. > --chris > Chris, Would you mind sending over your exact reproduction steps? I've cooked up a patch which appears to be working, but I want to test it out a bit more before I send it out. Thanks, -- Omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: omap1_defconfig: drop obsolete Kconfig symbols
scripts/checkkconfigsymbols.py indicates that omap1_defconfig references the following obsolete Kconfig symbols: CONFIG_BT_L2CAP CONFIG_BT_SCO CONFIG_DEBUG_ERRORS CONFIG_EXPERIMENTAL CONFIG_FB_OMAP_BOOTLOADER_INIT CONFIG_LEDS_CPU CONFIG_MACH_OMAP_HTCWIZARD CONFIG_MTD_CHAR CONFIG_MTD_DEBUG CONFIG_MTD_DEBUG_VERBOSE CONFIG_MTD_PARTITIONS CONFIG_NET_ETHERNET CONFIG_RCU_CPU_STALL_DETECTOR CONFIG_SCSI_MULTI_LUN CONFIG_USB_DEVICE_CLASS CONFIG_VIDEO_OUTPUT_CONTROL Drop them from omap1_defconfig. Signed-off-by: Paul Walmsley Cc: Paul Bolle Cc: Valentin Rothberg Cc: Stefan Hengelein Cc: Russell King Cc: Tony Lindgren Cc: linux-kernel@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org --- Non-critical. Targeted for v3.20-rc1 or v3.21-rc1. I'm unable to boot test it since I don't have any OMAP1 devices currently active in the testbed, but it least compiles and deals with the Kconfig checker warnings: http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/ arch/arm/configs/omap1_defconfig | 16 1 file changed, 16 deletions(-) diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig index a7dce674f1be..0c8a78734536 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -1,4 +1,3 @@ -CONFIG_EXPERIMENTAL=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y @@ -34,7 +33,6 @@ CONFIG_ARCH_OMAP16XX=y CONFIG_MACH_OMAP_INNOVATOR=y CONFIG_MACH_OMAP_H2=y CONFIG_MACH_OMAP_H3=y -CONFIG_MACH_OMAP_HTCWIZARD=y CONFIG_MACH_HERALD=y CONFIG_MACH_OMAP_OSK=y CONFIG_MACH_OMAP_PERSEUS2=y @@ -55,7 +53,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT=y CONFIG_AEABI=y CONFIG_LEDS=y -CONFIG_LEDS_CPU=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="root=1f03 rootfstype=jffs2" @@ -80,8 +77,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IPV6=y CONFIG_NETFILTER=y CONFIG_BT=y -CONFIG_BT_L2CAP=y -CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y @@ -92,11 +87,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_CONNECTOR=y # CONFIG_PROC_EVENTS is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=3 -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y @@ -113,11 +104,9 @@ CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_TUN=y CONFIG_PHYLIB=y -CONFIG_NET_ETHERNET=y CONFIG_SMC91X=y CONFIG_USB_CATC=y CONFIG_USB_KAWETH=y @@ -158,7 +147,6 @@ CONFIG_SPI_OMAP_UWIRE=y CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y CONFIG_OMAP_WATCHDOG=y -CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y @@ -168,7 +156,6 @@ CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y CONFIG_FB_OMAP_MANUAL_UPDATE=y CONFIG_FB_OMAP_LCD_MIPID=y -CONFIG_FB_OMAP_BOOTLOADER_INIT=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_FRAMEBUFFER_CONSOLE=y @@ -194,7 +181,6 @@ CONFIG_SND_OMAP_SOC=y # CONFIG_USB_HID is not set CONFIG_USB=y CONFIG_USB_PHY=y -# CONFIG_USB_DEVICE_CLASS is not set CONFIG_USB_MON=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=y @@ -261,9 +247,7 @@ CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y CONFIG_SECURITY=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_PCBC=y -- 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/
[PATCH] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
Building an OMAP1510-only Kconfig generates the following warnings:
arch/arm/mach-omap1/pm.c: In function ‘omap1_pm_idle’:
arch/arm/mach-omap1/pm.c:123:2: warning: #warning Enable 32kHz OS timer in
order to allow sleep states in idle [-Wcpp]
#warning Enable 32kHz OS timer in order to allow sleep states in idle
^
arch/arm/mach-omap1/pm.c: At top level:
arch/arm/mach-omap1/pm.c:76:23: warning: ‘enable_dyn_sleep’ defined but not
used [-Wunused-variable]
static unsigned short enable_dyn_sleep = 0;
^
These are not so easy to fix in an obviously correct fashion, since I
don't have these devices up and running in my testbed. So, use
arch/arm/plat-omap/Kconfig and the existing pm.c source as a guide,
and posit that deep power saving states are only supported on OMAP16xx
chips with kernels built with both CONFIG_OMAP_DM_TIMER=y and
CONFIG_OMAP_32K_TIMER=y.
While here, clean up a few printk()s and unnecessary #ifdefs.
Signed-off-by: Paul Walmsley
Cc: Jon Hunter
Cc: Aaro Koskinen
Cc: Tuukka Tikkanen
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Hi folks, if anyone out there is still experimenting with OMAP1 PM, or has
a copy of the OMAP1510 TRMs, could you please check this patch? I'm
unable to test it since I don't have any OMAP1 devices currently active
in the testbed. It at least compiles and deals with the build warnings:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Non-critical; targeted for v3.20-rc1 or v3.21-rc1.
arch/arm/mach-omap1/pm.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 34b4c0044961..d46d8a222fbb 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,13 +71,7 @@ static unsigned int
mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifndef CONFIG_OMAP_32K_TIMER
-
-static unsigned short enable_dyn_sleep = 0;
-
-#else
-
-static unsigned short enable_dyn_sleep = 1;
+static unsigned short enable_dyn_sleep;
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
@@ -90,8 +84,9 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
{
unsigned short value;
if (sscanf(buf, "%hu", ) != 1 ||
- (value != 0 && value != 1)) {
- printk(KERN_ERR "idle_sleep_store: Invalid value\n");
+ (value != 0 && value != 1) ||
+ (value != 0 && !IS_ENABLED(CONFIG_OMAP_32K_TIMER))) {
+ pr_err("idle_sleep_store: Invalid value\n");
return -EINVAL;
}
enable_dyn_sleep = value;
@@ -101,7 +96,6 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
static struct kobj_attribute sleep_while_idle_attr =
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
-#endif
static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) = NULL;
@@ -120,12 +114,11 @@ void omap1_pm_idle(void)
local_fiq_disable();
#if defined(CONFIG_OMAP_MPU_TIMER) && !defined(CONFIG_OMAP_DM_TIMER)
-#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 & ~(1 << 9);
-#else
+#endif
+
if (enable_dyn_sleep)
do_sleep = 1;
-#endif
#ifdef CONFIG_OMAP_DM_TIMER
use_idlect1 = omap_dm_timer_modify_idlect_mask(use_idlect1);
@@ -635,15 +628,24 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-
-#ifdef CONFIG_OMAP_32K_TIMER
- int error;
-#endif
+ int error = 0;
if (!cpu_class_is_omap1())
return -ENODEV;
- printk("Power Management for TI OMAP.\n");
+ pr_info("Power Management for TI OMAP.\n");
+
+ if (!IS_ENABLED(CONFIG_OMAP_32K_TIMER))
+ pr_info("OMAP1 PM: sleep states in idle disabled due to no
32KiHz timer\n");
+
+ if (!IS_ENABLED(CONFIG_OMAP_DM_TIMER))
+ pr_info("OMAP1 PM: sleep states in idle disabled due to no
DMTIMER support\n");
+
+ if (IS_ENABLED(CONFIG_OMAP_32K_TIMER) &&
+ IS_ENABLED(CONFIG_OMAP_DM_TIMER) && cpu_is_omap16xx()) {
+ pr_info("OMAP1 PM: sleep states in idle enabled\n");
+ enable_dyn_sleep = 1;
+ }
/*
* We copy the assembler sleep/wakeup routines to SRAM.
@@ -693,17 +695,15 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
error = sysfs_create_file(power_kobj, _while_idle_attr.attr);
if (error)
printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
[PATCH] thermal: ti-soc-thermal: fix compilation warnings when !CONFIG_PM_SLEEP
When CONFIG_PM_SLEEP=n, the following compilation warnings appear:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
‘ti_bandgap_suspend’ defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
‘ti_bandgap_resume’ defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
A few years ago, suspend/resume-related code was protected by CONFIG_PM.
But that was changed and now it's protected by CONFIG_PM_SLEEP. Fix the
warnings by converting the preprocessor test in the TI bandgap thermal
sensor driver from testing CONFIG_PM to testing CONFIG_PM_SLEEP.
Signed-off-by: Paul Walmsley
Cc: Eduardo Valentin
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Non-critical. Targeted for either v3.20-rc1 or v3.21-rc1.
Basic test reports for a series that includes this patch (and a few other
unrelated warning cleanups) is available here:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Compare to:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150204213018/
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce0e63a..62a5d449c388 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
2.1.4
Re: [PATCH v3 0/2] x86/arm64: add xenconfig
On Mon, Feb 2, 2015 at 1:32 PM, Luis R. Rodriguez wrote: > On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek wrote: >> Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a): >>> On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek wrote: On 2015-01-29 21:47, Paul Bolle wrote: > [Added Michal. Removed Yann.] > > On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote: >> On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez >> wrote: >>> On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote: On Fri, 23 Jan 2015, Luis R. Rodriguez wrote: > On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" >> >> This v3 addresses Stefano's feedback from the v2 series, namely >> moving PCI stuff to x86 as its all x86 specific and also just >> removing the CONFIG_TCG_XEN=m from the general config. To be >> clear the changes from the v2 series are below. >> >> Luis R. Rodriguez (2): >> x86, platform, xen, kconfig: clarify kvmconfig is for kvm >> x86, arm, platform, xen, kconfig: add xen defconfig helper >> >> arch/x86/configs/xen.config | 10 ++ >> kernel/configs/xen.config | 26 ++ >> scripts/kconfig/Makefile| 7 ++- >> 3 files changed, 42 insertions(+), 1 deletion(-) >> create mode 100644 arch/x86/configs/xen.config >> create mode 100644 kernel/configs/xen.config > > Who could these changes go through? I would be OK with taking it in the Xen tree, but I would feel more comfortable doing that if you had an ack from Yann Morin (CC'ed). >>> >>> *Poke* >> >> Hey Yann, wondering if you had any feedback. Thanks. > > Yann has disappeared a year ago. Michal now, informally, keeps an eye on > kconfig related patches. I did not see this. Can you please bounce me the original series? >>> >>> Done, let me know if you did not get them >> >> I got them, sorry for the delay. You can add Acked-by: Michal Marek >> if you want. > > Thanks Michal, what tree should this go through though? David should this go through your tree? Can anyone provide pointers? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Making memcg track ownership per address_space or anon_vma
On Fri, Feb 6, 2015 at 6:17 AM, Tejun Heo wrote: > Hello, Greg. > > On Thu, Feb 05, 2015 at 04:03:34PM -0800, Greg Thelen wrote: >> So this is a system which charges all cgroups using a shared inode >> (recharge on read) for all resident pages of that shared inode. There's >> only one copy of the page in memory on just one LRU, but the page may be >> charged to multiple container's (shared_)usage. > > Yeap. > >> Perhaps I missed it, but what happens when a child's limit is >> insufficient to accept all pages shared by its siblings? Example >> starting with 2M cached of a shared file: >> >> A >> +-B(usage=2M lim=3M hosted_usage=2M) >> +-C (usage=0 lim=2M shared_usage=2M) >> +-D (usage=0 lim=2M shared_usage=2M) >> \-E (usage=0 lim=1M shared_usage=0) >> >> If E faults in a new 4K page within the shared file, then E is a sharing >> participant so it'd be charged the 2M+4K, which pushes E over it's >> limit. > > OOM? It shouldn't be participating in sharing of an inode if it can't > match others' protection on the inode, I think. What we're doing now > w/ page based charging is kinda unfair because in the situations like > above the one under pressure can end up siphoning off of the larger > cgroups' protection if they actually use overlapping areas; however, > for disjoint areas, per-page charging would behave correctly. > > So, this part comes down to the same question - whether multiple > cgroups accessing disjoint areas of a single inode is an important > enough use case. If we say yes to that, we better make writeback > support that too. If cgroups are about isolation then writing to shared files should be rare, so I'm willing to say that we don't need to handle shared writers well. Shared readers seem like a more valuable use cases (thin provisioning). I'm getting overwhelmed with the thought exercise of automatically moving inodes to common ancestors and back charging the sharers for shared_usage. I haven't wrapped my head around how these shared data pages will get protected. It seems like they'd no longer be protected by child min watermarks. So I know this thread opened with the claim "both memcg and blkcg must be looking at the same picture. Deviating them is highly likely to lead to long-term issues forcing us to look at this again anyway, only with far more baggage." But I'm still wondering if the following is simpler: (1) leave memcg as a per page controller. (2) maintain a per inode i_memcg which is set to the common dirtying ancestor. If not shared then it'll point to the memcg that the page was charged to. (3) when memcg dirtying page pressure is seen, walk up the cgroup tree writing dirty inodes, this will write shared inodes using blkcg priority of the respective levels. (4) background limit wb_check_background_flush() and time based wb_check_old_data_flush() can feel free to attack shared inodes to hopefully restore them to non-shared state. For non-shared inodes, this should behave the same. For shared inodes it should only affect those in the hierarchy which is sharing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: atmel-hlcdc: add discard area support
On Fri, Feb 6, 2015 at 4:11 PM, Daniel Vetter wrote:
> On Fri, Feb 06, 2015 at 04:31:02PM +0100, Boris Brezillon wrote:
>> The HLCDC IP provides a way to discard a specific area on the primary
>> plane (in case at least one of the overlay is activated and alpha
>> blending is disabled).
>> Doing this will reduce the amount of data to transfer from the main
>> memory to the Display Controller, and thus alleviate the load on the
>> memory bus (since this link is quite limited on such hardware,
>> this kind of optimization is really important).
>>
>> Signed-off-by: Boris Brezillon
>> ---
>> Hi Daniel,
>>
>> Can you tell me if that's what you had in mind for the discard area feature
>> we talked about yersterday.
>>
>> This patch depends on the Atmel HLCDC Atomic mode-setting conversion
>> work [1].
>>
>> Best Regards,
>>
>> Boris
>>
>> [1]https://lkml.org/lkml/2015/2/4/658
>>
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 2 +
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 108
>>
>> 3 files changed, 111 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index de6973d..4fd1683 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -201,7 +201,7 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc
>> *c,
>> if (atmel_hlcdc_dc_mode_valid(crtc->dc, >adjusted_mode) != MODE_OK)
>> return -EINVAL;
>>
>> - return 0;
>> + return atmel_hlcdc_plane_prepare_disc_area(s);
>> }
>>
>> static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c)
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> index 015c3f1..1ea9c2c 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> @@ -148,6 +148,8 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
>> struct atmel_hlcdc_planes *
>> atmel_hlcdc_create_planes(struct drm_device *dev);
>>
>> +int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
>> +
>> void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
>>
>> void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> index 6c6fcae..dbf97d9 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> @@ -51,6 +51,13 @@ struct atmel_hlcdc_plane_state {
>>
>> u8 alpha;
>>
>> + bool disc_updated;
>> +
>> + int disc_x;
>> + int disc_y;
>> + int disc_w;
>> + int disc_h;
>> +
>> /* These fields are private and should not be touched */
>> int bpp[ATMEL_HLCDC_MAX_PLANES];
>> unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
>> @@ -428,6 +435,104 @@ static void atmel_hlcdc_plane_update_buffers(struct
>> atmel_hlcdc_plane *plane,
>> }
>> }
>>
>> +int
>> +atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
>> +{
>> + int disc_x = 0, disc_y = 0, disc_w = 0, disc_h = 0;
>> + const struct atmel_hlcdc_layer_cfg_layout *layout;
>> + struct atmel_hlcdc_plane_state *primary_state;
>> + struct drm_plane_state *primary_s;
>> + struct atmel_hlcdc_plane *primary;
>> + struct drm_plane *ovl;
>> +
>> + primary = drm_plane_to_atmel_hlcdc_plane(c_state->crtc->primary);
>> + layout = >layer.desc->layout;
>> + if (!layout->disc_pos || !layout->disc_size)
>> + return 0;
>> +
>> + primary_s = drm_atomic_get_plane_state(c_state->state,
>> +>base);
>> + if (IS_ERR(primary_s))
>> + return PTR_ERR(primary_s);
>> +
>> + primary_state = drm_plane_state_to_atmel_hlcdc_plane_state(primary_s);
>> +
>> + drm_atomic_crtc_state_for_each_plane(ovl, c_state) {
>> + struct atmel_hlcdc_plane_state *ovl_state;
>> + struct drm_plane_state *ovl_s;
>> +
>> + if (ovl == c_state->crtc->primary)
>> + continue;
>> +
>> + ovl_s = drm_atomic_get_plane_state(c_state->state, ovl);
>> + if (IS_ERR(ovl_s))
>> + return PTR_ERR(ovl_s);
>> +
>> + ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
>
> Note that right now the atomic helpers do not no-op out null plane state
> updates. The assumption is that such plane states aren't requested.
> Usually it's not harmful to add more planes by default (just a bit of
> busy-work really), but if you have more than 1 crtc then suddenly every
> pageflip will be converted into an update spanning more than 1 crtc, and
> you most definitely don't want that. This is because we always must the
> state for the crtc each
Re: [PATCH 2/2] x86/tbl/trace: Do not trace on CPU that is offline
On Fri, Feb 06, 2015 at 03:06:55PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> When taking a CPU down for suspend and resume, a tracepoint may be called
> when the CPU has been designated offline. As tracepoints require RCU for
> protection, they must not be called if the current CPU is offline.
>
> Unfortunately, trace_tlb_flush() is called in this scenario as was noted
> by LOCKDEP:
>
> ...
>
> Disabling non-boot CPUs ...
> intel_pstate CPU 1 exiting
>
> ===
> smpboot: CPU 1 didn't die...
> [ INFO: suspicious RCU usage. ]
> 3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
> ---
> include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> no locks held by swapper/1/0.
>
> stack backtrace:
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 3.19.0-rc7-next-20150204.1-iniza-small #1
> Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> 0001 88011a44fe18 817e370d 0011
> 88011a448290 88011a44fe48 810d6847 8800c66b9600
> 0001 88011a44c000 81cb3900 88011a44fe78
> Call Trace:
> [] dump_stack+0x4c/0x65
> [] lockdep_rcu_suspicious+0xe7/0x120
> [] idle_task_exit+0x205/0x2c0
> [] play_dead_common+0xe/0x50
> [] native_play_dead+0x15/0x140
> [] arch_cpu_idle_dead+0xf/0x20
> [] cpu_startup_entry+0x37e/0x580
> [] start_secondary+0x140/0x150
> intel_pstate CPU 2 exiting
>
> ...
>
> By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
> condition is cpu_online(smp_processor_id()), we can avoid calling RCU
> protected
> code when the CPU is offline.
>
> Link:
> http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com
>
> Reported-by: Sedat Dilek
> Suggested-by: Paul E. McKenney
> Signed-off-by: Steven Rostedt
Acked-by: Paul E. McKenney
> ---
> include/trace/events/tlb.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
> index 13391d288107..0e7635765153 100644
> --- a/include/trace/events/tlb.h
> +++ b/include/trace/events/tlb.h
> @@ -13,11 +13,13 @@
> { TLB_LOCAL_SHOOTDOWN, "local shootdown" },\
> { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }
>
> -TRACE_EVENT(tlb_flush,
> +TRACE_EVENT_CONDITION(tlb_flush,
>
> TP_PROTO(int reason, unsigned long pages),
> TP_ARGS(reason, pages),
>
> + TP_CONDITION(cpu_online(smp_processor_id())),
> +
> TP_STRUCT__entry(
> __field( int, reason)
> __field(unsigned long, pages)
> --
> 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 4/5] kvm,rcu,nohz: use RCU extended quiescent state when running KVM guest
On Thu, Feb 05, 2015 at 03:23:51PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> The host kernel is not doing anything while the CPU is executing
> a KVM guest VCPU, so it can be marked as being in an extended
> quiescent state, identical to that used when running user space
> code.
>
> The only exception to that rule is when the host handles an
> interrupt, which is already handled by the irq code, which
> calls rcu_irq_enter and rcu_irq_exit.
>
> The guest_enter and guest_exit functions already switch vtime
> accounting independent of context tracking, so leave those calls
> where they are, instead of moving them into the context tracking
> code.
>
> Signed-off-by: Rik van Riel
> ---
> include/linux/context_tracking.h | 8 +++-
> include/linux/context_tracking_state.h | 1 +
> include/linux/kvm_host.h | 3 ++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/context_tracking.h
> b/include/linux/context_tracking.h
> index bd9f000fc98d..a5d3bb44b897 100644
> --- a/include/linux/context_tracking.h
> +++ b/include/linux/context_tracking.h
> @@ -43,7 +43,7 @@ static inline enum ctx_state exception_enter(void)
> static inline void exception_exit(enum ctx_state prev_ctx)
> {
> if (context_tracking_is_enabled()) {
> - if (prev_ctx == IN_USER)
> + if (prev_ctx == IN_USER || prev_ctx == IN_GUEST)
That's nitpicking but != IN_KERNEL would be more generic. We are exiting an
exception
and we know that the exception executes IN_KERNEL, so we want to restore any
context
(whether IN_USER, IN_GUEST, or anything added in the future) prior the
exception if that
was anything else than IN_KERNEL.
> context_tracking_user_enter(prev_ctx);
> }
> }
> @@ -78,6 +78,9 @@ static inline void guest_enter(void)
> vtime_guest_enter(current);
> else
> current->flags |= PF_VCPU;
> +
> + if (context_tracking_is_enabled())
> + context_tracking_user_enter(IN_GUEST);
> }
>
> static inline void guest_exit(void)
> @@ -86,6 +89,9 @@ static inline void guest_exit(void)
> vtime_guest_exit(current);
> else
> current->flags &= ~PF_VCPU;
> +
> + if (context_tracking_is_enabled())
> + context_tracking_user_exit(IN_GUEST);
I suggest you to restore RCU before anything else. I believe cputime
accounting doesn't use RCU but we never know with all the debug/tracing
code behind, the acct accounting...
Thanks.
> }
>
> #else
> diff --git a/include/linux/context_tracking_state.h
> b/include/linux/context_tracking_state.h
> index 97a81225d037..f3ef027af749 100644
> --- a/include/linux/context_tracking_state.h
> +++ b/include/linux/context_tracking_state.h
> @@ -15,6 +15,7 @@ struct context_tracking {
> enum ctx_state {
> IN_KERNEL = 0,
> IN_USER,
> + IN_GUEST,
> } state;
> };
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 26f106022c88..c7828a6a9614 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -772,7 +772,8 @@ static inline void kvm_guest_enter(void)
>* one time slice). Lets treat guest mode as quiescent state, just like
>* we do with user-mode execution.
>*/
> - rcu_virt_note_context_switch(smp_processor_id());
> + if (!context_tracking_cpu_is_enabled())
> + rcu_virt_note_context_switch(smp_processor_id());
> }
>
> static inline void kvm_guest_exit(void)
> --
> 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] x86 spinlock: Fix memory corruption on completing completions
On Fri, 2015-02-06 at 16:15 -0500, Sasha Levin wrote: > On 02/06/2015 02:42 PM, Davidlohr Bueso wrote: > > On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote: > >> On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T > >> wrote: > >>> Paravirt spinlock clears slowpath flag after doing unlock. > >> [ fix edited out ] > >> > >> So I'm not going to be applying this for 3.19, because it's much too > >> late and the patch is too scary. Plus the bug probably effectively > >> never shows up in real life (it is probably easy to trigger the > >> speculative *read* but probably never the actual speculative write > >> after dropping the lock last). > >> > >> This will need a lot of testing by the paravirt people - both > >> performance and correctness. So *maybe* for 3.20, but maybe for even > >> later, and then marked for stable, of course. > >> > >> Are there any good paravirt stress-tests that people could run for > >> extended times? > > > > locktorture inside a VM should give a proper pounding. > > Would it catch lifetime issues too? I thought it just tests out correctness. Given enough contention it should, yeah. The spinlock can be acquired by another thread right after releasing the lock in the unlock's slowpath. And all locktorture does is pound on locks with random hold times. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: a method to distinguish between syscall-enter/exit-stop
On Fri, Feb 06, 2015 at 12:07:03PM -0800, Kees Cook wrote: > On Fri, Feb 6, 2015 at 11:32 AM, Andy Lutomirski wrote: > > On Fri, Feb 6, 2015 at 11:23 AM, Kees Cook wrote: [...] > >> And an unrelated thought: > >> > >> 3) Can't we find some way to fix the inability of a ptracer to > >> distinguish between syscall-enter-stop and syscall-exit-stop? > > > > Couldn't we add PTRACE_O_TRACESYSENTRY and PTRACE_O_TRACESYSEXIT along > > the lines of PTRACE_O_TRACESYSGOOD? > > That might be a nice idea. I haven't written a test to see, but what > does PTRACE_GETEVENTMSG return on syscall-enter/exit-stop? The value returned by PTRACE_GETEVENTMSG is the value set along with the latest PTRACE_EVENT_*. In case of syscall-enter/exit-stop (which is not a PTRACE_EVENT_*), there is no particular value set for PTRACE_GETEVENTMSG. -- ldv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit
On Fri, Feb 06, 2015 at 01:51:56PM -0500, Rik van Riel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/06/2015 01:23 PM, Frederic Weisbecker wrote: > > On Fri, Feb 06, 2015 at 01:20:21PM -0500, Rik van Riel wrote: On > > 02/06/2015 12:22 PM, Frederic Weisbecker wrote: > On Thu, Feb 05, 2015 at 03:23:48PM -0500, r...@redhat.com > wrote: > > From: Rik van Riel > > > > Add the expected ctx_state as a parameter to > > context_tracking_user_enter and > > context_tracking_user_exit, allowing the same functions to > > not just track kernel <> user space switching, but also > > kernel <> guest transitions. > > > > Signed-off-by: Rik van Riel > > You should consider using guest_enter() and guest_exit() > instead. These are context tracking APIs too but specifically > for guest. > > > > What do you mean instead? KVM already uses those. > > > > I just wanted to avoid duplicating the code... > > > >> I mean you can call rcu_user APIs directly from > >> guest_enter/exit. You don't really need to call the > >> context_tracking_user functions since guest_enter/guest_exit > >> already handle the vtime accounting. > > I would still have to modify exception_enter and exception_exit, > and with them context_tracking_user_enter and > context_tracking_user_exit. > > We have to re-enable RCU when an exception happens. > > I suspect exceptions in a guest just trigger VMEXIT, and we > figure later why the exception happened. However, if we were > to get an exception during the code where we transition into > or out of guest mode, we would still need exception_enter > and exception_exit... Ah that's a fair point. I didn't think about that. Ok then a real IN_GUEST mode makes sense. And context_tracking_user_enter/exit() can be reused as is indeed. Just a few things then: 1) In this case rename context_tracking_user_enter/exit() to context_tracking_enter() and context_tracking_exit(), since it's not anymore about user only but about any generic context. 2) We have the "WARN_ON_ONCE(!current->mm);" condition that is a debug check specific to userspace transitions because kernel threads aren't expected to resume to userspace. Can we also expect that we never switch to/from guest from a kernel thread? AFAICS this happens from an ioctl (thus user task) in x86 for kvm. But I only know this case. 3) You might want to update a few comments that assume we only deal with userspace transitions. 4) trace_user_enter/exit() should stay user-transitions specific. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2 2/7] implement memmem()
On Fri, Feb 06 2015, Steven Rostedt wrote: > The functionality of strnstr() does not change with this patch, so it > does not need to address your concern. Yeah, I should have checked that, of course. Sorry. > Feel free to submit a patch that states the difference of the kernel > version of strnstr with whatever version is out in the wild. It seems a much better name would be memstr, and "length-limited string" is misleading, since s1 is in no way treated as a string. But I'll leave it for now. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, Feb 06, 2015 at 11:51:19PM +0100, Sedat Dilek wrote: > On Fri, Feb 6, 2015 at 11:48 PM, Paul E. McKenney > wrote: > > On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote: > >> On Fri, 6 Feb 2015 23:13:02 +0100 > >> Sedat Dilek wrote: > >> > >> > >> > OK, so both patches go through Steve's tree. > >> > >> The second patch will require acks from those that maintain the files I > >> touch. > > > > Yep, that is required either way. I will give it an Acked-by in the hope > > that this helps. You have another version on the way, or have I lost > > count? ;-) > > Working on x85 and probably using ed as $EDITOR, it will take some time. The 8085, I remember it well! And Cromemco's text editor, which seemed quite fancy at the time. But it would take some doing to fit a git implementation into 64K of memory. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, 6 Feb 2015 14:48:36 -0800 "Paul E. McKenney" wrote: > On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote: > > On Fri, 6 Feb 2015 23:13:02 +0100 > > Sedat Dilek wrote: > > > > > > > OK, so both patches go through Steve's tree. > > > > The second patch will require acks from those that maintain the files I > > touch. > > Yep, that is required either way. I will give it an Acked-by in the hope > that this helps. You have another version on the way, or have I lost > count? ;-) > It's this patch series that's my latest version. I just need the second patch acked. You could ack the first one as well if you want, but it's not that necessary. I would really like an ack from Dave Hansen for the second patch, and perhaps hpa as well. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, Feb 6, 2015 at 11:51 PM, Sedat Dilek wrote: > On Fri, Feb 6, 2015 at 11:48 PM, Paul E. McKenney > wrote: >> On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote: >>> On Fri, 6 Feb 2015 23:13:02 +0100 >>> Sedat Dilek wrote: >>> >>> >>> > OK, so both patches go through Steve's tree. >>> >>> The second patch will require acks from those that maintain the files I >>> touch. >> >> Yep, that is required either way. I will give it an Acked-by in the hope >> that this helps. You have another version on the way, or have I lost >> count? ;-) >> > > Working on x85 and probably using ed as $EDITOR, it will take some time. > Here is proposal for v2 as a diff to the original posted to LKML. - Sedat - --- 2-2.patch 2015-02-07 00:00:15.151621154 +0100 +++ 2-2-v2.patch2015-02-06 23:59:22.187620716 +0100 @@ -2,7 +2,7 @@ From patchwork Fri Feb 6 20:06:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -Subject: x86/tbl/trace: Do not trace on CPU that is offline +Subject: x86/tlb/trace: Do not trace on CPU that is offline From: Steven Rostedt X-Patchwork-Id: 5794701 Message-Id: <20150206200800.689573...@goodmis.org> @@ -70,11 +70,21 @@ code when the CPU is offline. Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=jb8b9a0eqv-e...@mail.gmail.com +NOTE: This patch requires "tracing: Add condition check to RCU lockdep checks". + Reported-by: Sedat Dilek +Tested-by: Sedat Dilek Suggested-by: Paul E. McKenney +Acked-by: Paul E. McKenney Signed-off-by: Steven Rostedt --- + +[ dileks: v2: + - s/tbl/tlb in subject-line + - Add a reference to a preconditional patch + - Add Paul's Acked-by ] + include/trace/events/tlb.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Re: [v7,2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On Fri, Feb 6, 2015 at 2:48 PM, Dmitry Torokhov wrote:
> On Fri, Feb 6, 2015 at 2:31 PM, Kevin Cernekee wrote:
>> On Mon, Jan 19, 2015 at 01:51:49PM -0800, Ray Jui wrote:
>>> +
>>> + dev_dbg(iproc_i2c->device, "xfer %c, addr=0x%02x, len=%d\n",
>>> + (msg->flags & I2C_M_RD) ? 'R' : 'W', msg->addr,
>>> + msg->len);
>>> + dev_dbg(iproc_i2c->device, " data start \n");
>>> + for (i = 0; i < msg->len; i++)
>>> + dev_dbg(iproc_i2c->device, "0x%02x ", msg->buf[i]);
>>> + dev_dbg(iproc_i2c->device, " data end \n");
>>
>> It might be simpler to just do:
>>
>> print_hex_dump_bytes("iproc_i2c:", DUMP_PREFIX_NONE, msg->buf, msg->len);
>>
>> although you'd lose the ability to see the I2C device name.
>
> We can also do:
>
> dev_dbg(iproc_i2c->device, "*** data: %*ph\n", msg->len, msg->buf);
>
> if we are OK with limiting output to 64 bytes.
msg->len is capped at 63 due to hardware limits, so that should work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] perf/doc: Update perf_event_attr struct
Update the fields in perf_event_attr as currently seen in
include/uapi/linux/perf_event.h
Remove outdated comments on the config field
The doc has not account for commit a21ca2cac582 ("perf_counter:
Separate out attr->type from attr->config").
Signed-off-by: Tom Huynh
---
tools/perf/design.txt | 159 +++---
1 file changed, 113 insertions(+), 46 deletions(-)
diff --git a/tools/perf/design.txt b/tools/perf/design.txt
index a28dca2..96bd261 100644
--- a/tools/perf/design.txt
+++ b/tools/perf/design.txt
@@ -32,60 +32,127 @@ can be used to set the blocking mode, etc.
Multiple counters can be kept open at a time, and the counters
can be poll()ed.
-When creating a new counter fd, 'perf_event_attr' is:
+When creating a new counter fd, 'perf_event_attr' is defined in
+include/linux/uapi/perf_event.h as:
struct perf_event_attr {
-/*
- * The MSB of the config word signifies if the rest contains cpu
- * specific (raw) counter configuration data, if unset, the next
- * 7 bits are an event type and the rest of the bits are the event
- * identifier.
- */
-__u64 config;
-
-__u64 irq_period;
-__u32 record_type;
-__u32 read_format;
-
-__u64 disabled : 1, /* off by default
*/
-inherit: 1, /* children inherit it
*/
-pinned : 1, /* must always be on PMU
*/
-exclusive : 1, /* only group on PMU
*/
-exclude_user : 1, /* don't count user
*/
-exclude_kernel : 1, /* ditto kernel
*/
-exclude_hv : 1, /* ditto hypervisor
*/
-exclude_idle : 1, /* don't count when idle
*/
-mmap : 1, /* include mmap data
*/
-munmap : 1, /* include munmap data
*/
-comm : 1, /* include comm data
*/
-
-__reserved_1 : 52;
-
-__u32 extra_config_len;
-__u32 wakeup_events; /* wakeup every n events */
-
-__u64 __reserved_2;
-__u64 __reserved_3;
-};
-The 'config' field specifies what the counter should count. It
-is divided into 3 bit-fields:
+ /*
+* Major type: hardware/software/tracepoint/etc.
+*/
+ __u32 type;
+
+ /*
+* Size of the attr structure, for fwd/bwd compat.
+*/
+ __u32 size;
+
+ /*
+* Type specific configuration information.
+*/
+ __u64 config;
+
+ union {
+ __u64 sample_period;
+ __u64 sample_freq;
+ };
+
+ __u64 sample_type;
+ __u64 read_format;
+
+ __u64 disabled : 1, /* off by default*/
+ inherit: 1, /* children inherit it */
+ pinned : 1, /* must always be on PMU */
+ exclusive : 1, /* only group on PMU */
+ exclude_user : 1, /* don't count user */
+ exclude_kernel : 1, /* ditto kernel */
+ exclude_hv : 1, /* ditto hypervisor */
+ exclude_idle : 1, /* don't count when idle */
+ mmap : 1, /* include mmap data */
+ comm : 1, /* include comm data */
+ freq : 1, /* use freq, not period */
+ inherit_stat : 1, /* per task counts */
+ enable_on_exec : 1, /* next exec enables */
+ task : 1, /* trace fork/exit */
+ watermark : 1, /* wakeup_watermark */
+ /*
+* precise_ip:
+*
+* 0 - SAMPLE_IP can have arbitrary skid
+* 1 - SAMPLE_IP must have constant skid
+* 2 - SAMPLE_IP requested to have 0 skid
+* 3 - SAMPLE_IP must have 0 skid
+*
+* See also PERF_RECORD_MISC_EXACT_IP
+*/
+
[PATCH 1/3] perf/e6500: Make event translations available in sysfs
Make the perf events in e6500 available via sysfs.
$ ls /sys/devices/cpu/events/
branch-instructions
branch-misses
cache-misses
cpu-cycles
instructions
FSL_0_INST_CMPL
FSL_1_INST_CMPL
...
$ cat /sys/devices/cpu/events/cpu-cycles
event=0x01
Similar to the following commits:
- 1c53a270724d ("perf/POWER7: Make generic event translations
available in sysfs").
- 886c3b2d677f ("perf/POWER7: Make some POWER7 events available
in sysfs")
- cfe0d8ba14a1 ("perf tools: Make Power7 events available for perf")
Signed-off-by: Tom Huynh
---
arch/powerpc/include/asm/perf_event_fsl_emb.h | 20 +-
arch/powerpc/perf/core-fsl-emb.c | 12 ++
arch/powerpc/perf/e6500-events-list.h | 289 ++
arch/powerpc/perf/e6500-pmu.c | 50 -
4 files changed, 365 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/perf/e6500-events-list.h
diff --git a/arch/powerpc/include/asm/perf_event_fsl_emb.h
b/arch/powerpc/include/asm/perf_event_fsl_emb.h
index a581654..d76124f 100644
--- a/arch/powerpc/include/asm/perf_event_fsl_emb.h
+++ b/arch/powerpc/include/asm/perf_event_fsl_emb.h
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#define MAX_HWEVENTS 6
@@ -39,7 +40,7 @@ struct fsl_emb_pmu {
/* Returns event flags and PMLCb (FSL_EMB_EVENT_*) */
u64 (*xlate_event)(u64 event_id);
-
+ const struct attribute_group**attr_groups;
int n_generic;
int *generic_events;
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
@@ -48,3 +49,20 @@ struct fsl_emb_pmu {
};
int register_fsl_emb_pmu(struct fsl_emb_pmu *);
+
+extern ssize_t fsl_emb_events_sysfs_show(struct device *dev,
+struct device_attribute *attr,
+char *page);
+
+#define EVENT_VAR(_id, _suffix) event_attr_##_id##_suffix
+#define EVENT_PTR(_id, _suffix) (_attr_##_id##_suffix.attr.attr)
+
+#define EVENT_ATTR(_name, _id, _suffix) \
+ PMU_EVENT_ATTR(_name, EVENT_VAR(_id, _suffix), PME_##_id, \
+ fsl_emb_events_sysfs_show)
+
+#define GENERIC_EVENT_ATTR(_name, _id) EVENT_ATTR(_name, _id, _g)
+#define GENERIC_EVENT_PTR(_id) EVENT_PTR(_id, _g)
+
+#define FSL_EMB_EVENT_ATTR(_name, _id) EVENT_ATTR(_name, _id, _p)
+#define FSL_EMB_EVENT_PTR(_id) EVENT_PTR(_id, _p)
diff --git a/arch/powerpc/perf/core-fsl-emb.c b/arch/powerpc/perf/core-fsl-emb.c
index 4acaea0..d4af2f3 100644
--- a/arch/powerpc/perf/core-fsl-emb.c
+++ b/arch/powerpc/perf/core-fsl-emb.c
@@ -581,6 +581,16 @@ static int fsl_emb_pmu_event_init(struct perf_event *event)
return err;
}
+ssize_t fsl_emb_events_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *page)
+{
+ struct perf_pmu_events_attr *pmu_attr;
+
+ pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
+
+ return sprintf(page, "event=0x%02llx\n", pmu_attr->id);
+}
+
static struct pmu fsl_emb_pmu = {
.pmu_enable = fsl_emb_pmu_enable,
.pmu_disable= fsl_emb_pmu_disable,
@@ -711,6 +721,8 @@ int register_fsl_emb_pmu(struct fsl_emb_pmu *pmu)
pr_info("%s performance monitor hardware support registered\n",
pmu->name);
+ fsl_emb_pmu.attr_groups = ppmu->attr_groups;
+
perf_pmu_register(_emb_pmu, "cpu", PERF_TYPE_RAW);
return 0;
diff --git a/arch/powerpc/perf/e6500-events-list.h
b/arch/powerpc/perf/e6500-events-list.h
new file mode 100644
index 000..27be38a
--- /dev/null
+++ b/arch/powerpc/perf/e6500-events-list.h
@@ -0,0 +1,289 @@
+/*
+ * Performance counter support for e6500 family processors.
+ *
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+EVENT(FSL_CYC, 1)
+EVENT(FSL_INST_CMPL, 2)
+EVENT(FSL_UOPS_CMPL, 3)
+EVENT(FSL_UOPS_DECODED,5)
+EVENT(FSL_PM_EV_TRANS, 6)
+EVENT(FSL_PM_EV_CYC, 7)
+EVENT(FSL_BR_CMPL, 8)
+EVENT(FSL_BR_TKN, 67)
+EVENT(FSL_BLR_TKN, 68)
+EVENT(FSL_NUM_CQ_REDIR,11)
+EVENT(FSL_LD_UOPS_CMPL,9)
+EVENT(FSL_ST_UOPS_CMPL,10)
+EVENT(FSL_LSU_UOPS_CMPL, 181)
+EVENT(FSL_GPR_LD_CMPL, 182)
+EVENT(FSL_GPR_ST_CMPL,
[PATCH 0/3] Add e6500 perf events to sysfs and update perf doc
This patch set adds generic events, specific events, and format attribute
for the e6500 pmu to sysfs. This makes perf more convenient to use on the
e6500 by allowing the users to see all supported events and specify
events using meaningful names instead of raw event codes.
This patchset includes similar features in the following commits:
- 1c53a270724d
("perf/POWER7: Make generic event translations available in sysfs").
- 886c3b2d677f
("perf/POWER7: Make some POWER7 events available in sysfs")
- cfe0d8ba14a1
("perf tools: Make Power7 events available for perf")
- 3bf7b07ece6e
("perf/POWER7: Create a sysfs format entry for Power7 events").
This patchset also update tool/perf/design.txt to account for the changes
in commit a21ca2cac582 ("perf_counter: Separate out attr->type from
attr->config").
Attached patches:
1/3 perf/e6500: Make event translations available in sysfs
2/3 perf/e6500: Create a sysfs format entry for e6500 events
3/3 perf/doc: Update perf_event_attr struct
arch/powerpc/include/asm/perf_event_fsl_emb.h | 20 +-
arch/powerpc/perf/core-fsl-emb.c | 12 ++
arch/powerpc/perf/e6500-events-list.h | 289 ++
arch/powerpc/perf/e6500-pmu.c | 63 +-
tools/perf/design.txt | 159 ++
5 files changed, 491 insertions(+), 52 deletions(-)
create mode 100644 arch/powerpc/perf/e6500-events-list.h
--
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 5/5] ARM: dts: pxa: add pxa-timer to pxa27x
Sergei Shtylyov writes:
>> +clocksources {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +pxa-timer@40a0 {
>
>Just "timer@40a0", please.
Hi Sergei,
I forgot that in the v2, sorry. I'll put it in v3.
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2 2/7] implement memmem()
On Fri, 06 Feb 2015 23:30:19 +0100
Rasmus Villemoes wrote:
> On Fri, Feb 06 2015, Al Viro wrote:
>
> > +/**
> > + * strnstr - Find the first substring in a length-limited string
> > + * @s1: The string to be searched
> > + * @s2: The string to search for
> > + * @len: the maximum number of characters to search
> > + */
> > +char *strnstr(const char *s1, const char *s2, size_t len)
> > +{
> > + return memmem(s1, len, s2, strlen(s2));
> > +}
>
> Most strn* interfaces don't require the n to be at most the actual
> string length, but it seems that this would happily search past the '\0'
> of s1 if len is large enough, e.g.
>
> strnstr("abc\0def", "def", 1000)
>
> will not return NULL (unlike what the libbsd version does). So either
> that restriction should be documented or len should be replaced by
> min(len, strlen(s1)).
The version that is currently in the kernel will do exactly what the
patched version will do. Although it may be different than what libbsd
might do, we don't really care. The kernel doc states that @len will be
the maximum number of characters to search, and that's exactly what
this does.
The functionality of strnstr() does not change with this patch, so it
does not need to address your concern.
Feel free to submit a patch that states the difference of the kernel
version of strnstr with whatever version is out in the wild. But that
is out of scope with this series.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, Feb 6, 2015 at 11:48 PM, Paul E. McKenney wrote: > On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote: >> On Fri, 6 Feb 2015 23:13:02 +0100 >> Sedat Dilek wrote: >> >> >> > OK, so both patches go through Steve's tree. >> >> The second patch will require acks from those that maintain the files I >> touch. > > Yep, that is required either way. I will give it an Acked-by in the hope > that this helps. You have another version on the way, or have I lost > count? ;-) > Working on x85 and probably using ed as $EDITOR, it will take some time. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] ARM: dts: pxa: add pxa27x-keypad to pxa27x
Each pxa27x has an embedded keypad controller. Add it in the pxa27x
device-tree description.
Signed-off-by: Robert Jarzmik
---
arch/arm/boot/dts/pxa27x.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 979560c..7f93828 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -73,6 +73,15 @@
status = "disabled";
};
+ keypad: keypad@4150 {
+ compatible = "marvell,pxa27x-keypad";
+ reg = <0x4150 0x4c>;
+ interrupts = <4>;
+ clocks = <_clks CLK_KEYPAD>;
+ status = "disabled";
+ };
+ };
+
clocks {
/*
* The muxing of external clocks/internal dividers for osc* clock
--
2.1.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/
[PATCH v2 3/5] ARM: dts: pxa: add pxa27x-udc to pxa27x
Each pxa27x has an embedded usb udc controller. Add it in the pxa27x
device-tree description.
Signed-off-by: Robert Jarzmik
---
arch/arm/boot/dts/pxa27x.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 7cbf36f..979560c 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -65,6 +65,14 @@
clocks = <_clks CLK_I2C>;
};
+ pxa27x_udc: udc@4060 {
+ compatible = "marvell,pxa270-udc";
+ reg = <0x4060 0x1>;
+ interrupts = <11>;
+ clocks = <_clks CLK_USB>;
+ status = "disabled";
+ };
+
clocks {
/*
* The muxing of external clocks/internal dividers for osc* clock
--
2.1.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 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, Feb 06, 2015 at 05:35:48PM -0500, Steven Rostedt wrote: > On Fri, 6 Feb 2015 23:13:02 +0100 > Sedat Dilek wrote: > > > > OK, so both patches go through Steve's tree. > > The second patch will require acks from those that maintain the files I > touch. Yep, that is required either way. I will give it an Acked-by in the hope that this helps. You have another version on the way, or have I lost count? ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/5] ARM: dts: pxa: add clocks
Add clocks to the IPs already described in the pxa device-tree
files. There are more clocks in the clock tree than IPs described in the
current pxa device-tree.
This patch ensures that :
- the current description is correct
- the clocks are actually claimed, so that clock framework doesn't
disable them automatically (unused clocks shutdown)
Signed-off-by: Robert Jarzmik
---
arch/arm/boot/dts/pxa27x.dtsi | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 80fc5d7..7cbf36f 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -1,6 +1,6 @@
/* The pxa3xx skeleton simply augments the 2xx version */
#include "pxa2xx.dtsi"
-#include "dt-bindings/clock/pxa2xx-clock.h"
+#include "dt-bindings/clock/pxa-clock.h"
/ {
model = "Marvell PXA27x familiy SoC";
@@ -12,30 +12,58 @@
marvell,intc-nr-irqs = <34>;
};
+ gpio: gpio@40e0 {
+ compatible = "intel,pxa27x-gpio";
+ clocks = <_clks CLK_NONE>;
+ };
+
+ ffuart: uart@4010 {
+ clocks = <_clks CLK_FFUART>;
+ };
+
+ btuart: uart@4020 {
+ clocks = <_clks CLK_BTUART>;
+ };
+
+ stuart: uart@4070 {
+ clocks = <_clks CLK_STUART>;
+ };
+
pwm0: pwm@40b0 {
compatible = "marvell,pxa270-pwm", "marvell,pxa250-pwm";
reg = <0x40b0 0x10>;
#pwm-cells = <1>;
+ clocks = <_clks CLK_PWM0>;
};
pwm1: pwm@40b00010 {
compatible = "marvell,pxa270-pwm", "marvell,pxa250-pwm";
reg = <0x40b00010 0x10>;
#pwm-cells = <1>;
+ clocks = <_clks CLK_PWM1>;
};
pwm2: pwm@40c0 {
compatible = "marvell,pxa270-pwm", "marvell,pxa250-pwm";
reg = <0x40c0 0x10>;
#pwm-cells = <1>;
+ clocks = <_clks CLK_PWM0>;
};
pwm3: pwm@40c00010 {
compatible = "marvell,pxa270-pwm", "marvell,pxa250-pwm";
reg = <0x40c00010 0x10>;
#pwm-cells = <1>;
+ clocks = <_clks CLK_PWM1>;
+ };
+
+ pwri2c: i2c@40f000180 {
+ clocks = <_clks CLK_PWRI2C>;
+ };
+
+ pxai2c1: i2c@40301680 {
+ clocks = <_clks CLK_I2C>;
};
- };
clocks {
/*
@@ -47,10 +75,10 @@
ranges;
pxa2xx_clks: pxa2xx_clks@4134 {
- compatible = "marvell,pxa-clocks";
+ compatible = "marvell,pxa270-clocks";
#clock-cells = <1>;
status = "okay";
};
};
-
+ };
};
--
2.1.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/
[PATCH v2 1/5] ARM: dts: pxa: add pwri2c to pxa device-tree
Each pxa variant has 2 I2C busses on the SoC :
- the casual I2C
- the power I2C, normally driving power regulators, and capable of
receiving orders on core frequency modifications
Add the missing pwri2c to pxa description.
Signed-off-by: Robert Jarzmik
---
arch/arm/boot/dts/pxa2xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index c08f846..2371d9b 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -103,6 +103,15 @@
status = "disabled";
};
+ pwri2c: i2c@40f000180 {
+ compatible = "mrvl,pxa-i2c";
+ reg = <0x40f00180 0x24>;
+ interrupts = <6>;
+ #address-cells = <0x1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pxai2c1: i2c@40301680 {
compatible = "mrvl,pxa-i2c";
reg = <0x40301680 0x30>;
--
2.1.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/
[PATCH v2 5/5] ARM: dts: pxa: add pxa-timer to pxa27x
Each pxa has an embedded OS Timers IP. The kernel cannot work without a
valid clocksource, and this adds the OS Timers to the pxa device-tree
description.
Signed-off-by: Robert Jarzmik
---
Since v1: removed clocksource node, pxa-timer being directly under
pxabus (Rob's comment).
---
arch/arm/boot/dts/pxa27x.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 7f93828..473f9d8 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -97,5 +97,12 @@
status = "okay";
};
};
+
+ pxa-timer@40a0 {
+ compatible = "marvell,pxa-timer";
+ reg = <0x40a0 0x20>;
+ interrupts = <26>;
+ clocks = <_clks CLK_OSTIMER>;
+ status = "okay";
};
};
--
2.1.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: [v7,2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On Fri, Feb 6, 2015 at 2:31 PM, Kevin Cernekee wrote:
> On Mon, Jan 19, 2015 at 01:51:49PM -0800, Ray Jui wrote:
>> +
>> + dev_dbg(iproc_i2c->device, "xfer %c, addr=0x%02x, len=%d\n",
>> + (msg->flags & I2C_M_RD) ? 'R' : 'W', msg->addr,
>> + msg->len);
>> + dev_dbg(iproc_i2c->device, " data start \n");
>> + for (i = 0; i < msg->len; i++)
>> + dev_dbg(iproc_i2c->device, "0x%02x ", msg->buf[i]);
>> + dev_dbg(iproc_i2c->device, " data end \n");
>
> It might be simpler to just do:
>
> print_hex_dump_bytes("iproc_i2c:", DUMP_PREFIX_NONE, msg->buf, msg->len);
>
> although you'd lose the ability to see the I2C device name.
We can also do:
dev_dbg(iproc_i2c->device, "*** data: %*ph\n", msg->len, msg->buf);
if we are OK with limiting output to 64 bytes.
Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] perf/e6500: Create a sysfs format entry for e6500 events
Create a sysfs entry, '/sys/bus/event_source/devices/cpu/format/event'
which describes the format of the e6500 PMU events. e6500 has <= 512
events, so use the 9 lsb to specify the raw event code.
$ cat /sys/devices/cpu/format/event
config:0-8
Similar to commit 3bf7b07ece6e ("perf/POWER7: Create a sysfs format
entry for Power7 events").
Signed-off-by: Kim Phillips
Signed-off-by: Tom Huynh
---
arch/powerpc/perf/e6500-pmu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/perf/e6500-pmu.c b/arch/powerpc/perf/e6500-pmu.c
index abaa6d7..4bbdbb0 100644
--- a/arch/powerpc/perf/e6500-pmu.c
+++ b/arch/powerpc/perf/e6500-pmu.c
@@ -133,7 +133,20 @@ static struct attribute_group e6500_pmu_events_group = {
.attrs = e6500_events_attr,
};
+PMU_FORMAT_ATTR(event, "config:0-8");
+
+static struct attribute *e6500_pmu_format_attr[] = {
+ _attr_event.attr,
+ NULL,
+};
+
+struct attribute_group e6500_pmu_format_group = {
+ .name = "format",
+ .attrs = e6500_pmu_format_attr,
+};
+
static const struct attribute_group *e6500_pmu_attr_groups[] = {
+ _pmu_format_group,
_pmu_events_group,
NULL,
};
--
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] classmate-laptop: fix sparse warning
On Thu, Feb 05, 2015 at 02:57:44PM +, Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> this patch fixes following sparse warning:
>
> classmate-laptop.c:523:61: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Thadeu Lima de Souza Cascardo
> ---
> Found this issue on linux-next (gcc version 4.9.2,
> sparse version 0.4.5-rc1) and applies on top linux-next.
>
> drivers/platform/x86/classmate-laptop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/classmate-laptop.c
> b/drivers/platform/x86/classmate-laptop.c
> index 70d355a..55cf10b 100644
> --- a/drivers/platform/x86/classmate-laptop.c
> +++ b/drivers/platform/x86/classmate-laptop.c
> @@ -520,7 +520,7 @@ static acpi_status cmpc_get_accel(acpi_handle handle,
> {
> union acpi_object param[2];
> struct acpi_object_list input;
> - struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, 0 };
> + struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> unsigned char *locs;
> acpi_status status;
>
> --
> 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] llist: Fix missing memory barrier
On Fri, Feb 06, 2015 at 10:16:25PM +, Mathieu Desnoyers wrote: > - Original Message - > > From: "Greg Kroah-Hartman" > > To: "Mathieu Desnoyers" > > Cc: "Pranith Kumar" , "Huang Ying" > > , "LKML" > > , "Paul McKenney" > > , "David Howells" > > Sent: Friday, February 6, 2015 10:03:59 AM > > Subject: Re: [PATCH] llist: Fix missing memory barrier > > > > On Fri, Feb 06, 2015 at 02:12:32PM +, Mathieu Desnoyers wrote: > > > - Original Message - > > > > From: "Pranith Kumar" > > > > To: "Mathieu Desnoyers" > > > > Cc: "Huang Ying" , "LKML" > > > > , "Paul McKenney" > > > > , "David Howells" > > > > Sent: Thursday, February 5, 2015 10:44:07 PM > > > > Subject: Re: [PATCH] llist: Fix missing memory barrier > > > > > > > > Hi Mathieu, > > > > > > > > On Thu, Feb 5, 2015 at 10:06 PM, Mathieu Desnoyers > > > > wrote: > > > > > A smp_read_barrier_depends() appears to be missing in > > > > > llist_del_first(). > > > > > It should only matter for Alpha in practice. Adding it after the check > > > > > of entry against NULL allows skipping the barrier in a common case. > > > > > > > > We recently decided on using lockless_dereference() instead of > > > > hard-coding smp_read_barrier_depends()[1]. The advantage is that > > > > lockless_dereference() clearly shows what loads are being ordered. > > > > Could you resend the patch using that API? > > > > > > Since llist.h has been introduced prior to 3.18, I'm wondering if > > > it would be worthwhile to submit 2 patches for the purpose of > > > backporting to stable branches: > > > > > > 1) Fix introducing smp_read_barrier_depends() (for master and > > >stable branches) > > > 2) Move master from smp_read_barrier_depends() to > > >lockless_dereference(), > > > > > > Thoughts ? > > > > Yes, why? What code needs these new apis? > > The subsystems using llist.h in master: IRQ, smp core code, > vmalloc, scsi, the block layer, some filesystems... and more. > grep for "llist.h" to see the complete list of users. > > My question was mainly on how to do the fix process-wise: post-3.18, > it implies using the new lockless_dereference() API. pre-3.18, we > need to use smp_read_barrier_depends(). > > As Peter Hurley suggested, using the new API for master and 3.18 > seems like the right approach. Then the backports to stable branches > can, if needed, use smp_read_barrier_depends() instead. Is that > OK with you ? Sounds fine to me. 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 0/2] tracing/tlb/x85: Fix splat of calling RCU trace code on offline CPU
On Fri, 6 Feb 2015 23:13:02 +0100 Sedat Dilek wrote: > OK, so both patches go through Steve's tree. The second patch will require acks from those that maintain the files I touch. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] fbdev: ssd1307fb: Add module parameter to set update delay of the deffered io.
From: Thomas Niederprüm
This patch adds the module parameter "delaydivider" to set delay for the
deferred io. Effectively this is setting the refresh rate for mmap access
to the framebuffer. The delay for the deferred io is HZ/delaydivider.
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 1d81877..b38315d 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -44,10 +44,14 @@
#defineSSD1307FB_SET_VCOMH 0xdb
#define BITSPERPIXEL 1
+#define DELAYDIVIDER 20
static u_int bitsperpixel = BITSPERPIXEL;
module_param(bitsperpixel, uint, 0);
+static u_int delaydivider = DELAYDIVIDER;
+module_param(delaydivider, uint, 0);
+
struct ssd1307fb_par;
struct ssd1307fb_deviceinfo {
@@ -312,7 +316,7 @@ static void ssd1307fb_deferred_io(struct fb_info *info,
}
static struct fb_deferred_io ssd1307fb_defio = {
- .delay = HZ,
+ .delay = HZ/DELAYDIVIDER,
.deferred_io= ssd1307fb_deferred_io,
};
@@ -601,6 +605,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->fix = ssd1307fb_fix;
info->fix.line_length = par->width * bitsperpixel / 8;
info->fbdefio = _defio;
+ info->fbdefio->delay = HZ/delaydivider;
info->var = ssd1307fb_var;
info->var.bits_per_pixel = bitsperpixel;
--
2.1.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 3/8] fbdev: ssd1307fb: Add support for SSD1305
From: Thomas Niederprüm
This patch adds support for the SSD1305 OLED controller.
Signed-off-by: Thomas Niederprüm
---
Documentation/devicetree/bindings/video/ssd1307fb.txt | 2 +-
drivers/video/fbdev/ssd1307fb.c | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 1230f68..51fa263 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -2,7 +2,7 @@
Required properties:
- compatible: Should be "solomon,fb-". The only supported bus for
-now is i2c, and the supported chips are ssd1306 and ssd1307.
+now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 4f435aa..01cfb46 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -16,6 +16,7 @@
#include
#include
+#define DEVID_SSD1305 5
#define DEVID_SSD1306 6
#define DEVID_SSD1307 7
@@ -427,6 +428,13 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return 0;
}
+static struct ssd1307fb_deviceinfo ssd1307fb_ssd1305_deviceinfo = {
+ .device_id = DEVID_SSD1305,
+ .default_vcomh = 0x34,
+ .default_dclk_div = 0,
+ .default_dclk_frq = 7,
+};
+
static struct ssd1307fb_deviceinfo ssd1307fb_ssd1306_deviceinfo = {
.device_id = DEVID_SSD1306,
.default_vcomh = 0x20,
@@ -443,6 +451,10 @@ static struct ssd1307fb_deviceinfo
ssd1307fb_ssd1307_deviceinfo = {
static const struct of_device_id ssd1307fb_of_match[] = {
{
+ .compatible = "solomon,ssd1305fb-i2c",
+ .data = (void *)_ssd1305_deviceinfo,
+ },
+ {
.compatible = "solomon,ssd1306fb-i2c",
.data = (void *)_ssd1306_deviceinfo,
},
@@ -623,6 +635,7 @@ static int ssd1307fb_remove(struct i2c_client *client)
}
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+ { "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ }
--
2.1.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 1/8] Documentation: dts: add missing Solomon Systech vendor prefix.
From: Thomas Niederprüm This patch adds the solomon prefix for Solomon Systech Limited. Signed-off-by: Thomas Niederprüm --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a344ec2..b1d9470 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -143,6 +143,7 @@ sitronixSitronix Technology Corporation smsc Standard Microsystems Corporation snps Synopsys, Inc. solidrun SolidRun +solomonSolomon Systech Limited sony Sony Corporation spansion Spansion Inc. st STMicroelectronics -- 2.1.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 2/8] fbdev: ssd1307fb: Unify init code and make controller configurable from device tree
From: Thomas Niederprüm
This patches unifies the init code for the ssd130X chips and
adds device tree bindings to describe the hardware configuration
of the used controller. This gets rid of the magic bit values
used in the init code so far.
Signed-off-by: Thomas Niederprüm
---
.../devicetree/bindings/video/ssd1307fb.txt| 11 +
drivers/video/fbdev/ssd1307fb.c| 243 ++---
2 files changed, 174 insertions(+), 80 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 7a12542..1230f68 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -15,6 +15,17 @@ Required properties:
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
+ - solomon,segment-remap: Invert the order of data column to segment mapping
+ - solomon,offset: Map the display start line to one of COM0 - COM63
+ - solomon,contrast: Set initial contrast of the display
+ - solomon,prechargep1: Set the duration of the precharge period phase1
+ - solomon,prechargep2: Set the duration of the precharge period phase2
+ - solomon,com-alt: Enable/disable alternate COM pin configuration
+ - solomon,com-lrremap: Enable/disable left-right remap of COM pins
+ - solomon,com-invdir: Invert COM scan direction
+ - solomon,vcomh: Set VCOMH regulator voltage
+ - solomon,dclk-div: Set display clock divider
+ - solomon,dclk-frq: Set display clock frequency
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3d6611f..4f435aa 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -16,6 +16,9 @@
#include
#include
+#define DEVID_SSD1306 6
+#define DEVID_SSD1307 7
+
#define SSD1307FB_DATA 0x40
#define SSD1307FB_COMMAND 0x80
@@ -40,20 +43,33 @@
struct ssd1307fb_par;
-struct ssd1307fb_ops {
- int (*init)(struct ssd1307fb_par *);
- int (*remove)(struct ssd1307fb_par *);
+struct ssd1307fb_deviceinfo {
+ int device_id;
+ u32 default_vcomh;
+ u32 default_dclk_div;
+ u32 default_dclk_frq;
};
struct ssd1307fb_par {
+ u32 com_alt;
+ u32 com_invdir;
+ u32 com_lrremap;
+ u32 contrast;
+ u32 dclk_div;
+ u32 dclk_frq;
+ struct ssd1307fb_deviceinfo *device_info;
struct i2c_client *client;
u32 height;
struct fb_info *info;
- struct ssd1307fb_ops *ops;
+ u32 offset;
u32 page_offset;
+ u32 prechargep1;
+ u32 prechargep2;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 seg_remap;
+ u32 vcomh;
u32 width;
};
@@ -254,127 +270,151 @@ static struct fb_deferred_io ssd1307fb_defio = {
.deferred_io= ssd1307fb_deferred_io,
};
-static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par)
+static int ssd1307fb_init(struct ssd1307fb_par *par)
{
int ret;
+ u32 precharge, dclk, com_invdir, compins;
- par->pwm = pwm_get(>client->dev, NULL);
- if (IS_ERR(par->pwm)) {
- dev_err(>client->dev, "Could not get PWM from device
tree!\n");
- return PTR_ERR(par->pwm);
- }
-
- par->pwm_period = pwm_get_period(par->pwm);
- /* Enable the PWM */
- pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
- pwm_enable(par->pwm);
-
- dev_dbg(>client->dev, "Using PWM%d with a %dns period.\n",
- par->pwm->pwm, par->pwm_period);
-
- /* Map column 127 of the OLED to segment 0 */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
- if (ret < 0)
- return ret;
-
- /* Turn on the display */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
-static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par)
-{
- pwm_disable(par->pwm);
- pwm_put(par->pwm);
- return 0;
-}
+ if (par->device_info->device_id == DEVID_SSD1307) {
+ par->pwm = pwm_get(>client->dev, NULL);
+ if (IS_ERR(par->pwm)) {
+ dev_err(>client->dev, "Could not get PWM from
device tree!\n");
+ return PTR_ERR(par->pwm);
+ }
-static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
- .init = ssd1307fb_ssd1307_init,
- .remove = ssd1307fb_ssd1307_remove,
-};
+ par->pwm_period = pwm_get_period(par->pwm);
+ /* Enable the PWM */
+ pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+ pwm_enable(par->pwm);
-static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
-{
- int ret;
+
[PATCH 5/8] fbdev: ssd1307fb: Add module parameter bitsperpixel.
From: Thomas Niederprüm
This patch adds a module parameter 'bitsperpixel' to adjust the colordepth
of the framebuffer. All values >1 will result in memory map of the requested
color depth. However only the MSB of each pixel will be sent to the device.
The framebuffer identifies itself as a grayscale display with the specified
depth.
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 945ded9..1d81877 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -43,6 +43,11 @@
#defineSSD1307FB_SET_COM_PINS_CONFIG 0xda
#defineSSD1307FB_SET_VCOMH 0xdb
+#define BITSPERPIXEL 1
+
+static u_int bitsperpixel = BITSPERPIXEL;
+module_param(bitsperpixel, uint, 0);
+
struct ssd1307fb_par;
struct ssd1307fb_deviceinfo {
@@ -91,7 +96,8 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
};
static struct fb_var_screeninfo ssd1307fb_var = {
- .bits_per_pixel = 1,
+ .bits_per_pixel = BITSPERPIXEL,
+ .grayscale = 1,
};
static void *rvmalloc(unsigned long size)
@@ -223,10 +229,11 @@ static void ssd1307fb_update_display(struct ssd1307fb_par
*par)
array->data[array_idx] = 0;
for (k = 0; k < 8; k++) {
u32 page_length = par->width * i;
- u32 index = page_length + (par->width * k + j)
/ 8;
+ u32 index = page_length * bitsperpixel +
(par->width * k + j) * bitsperpixel / 8;
u8 byte = *(vmem + index);
- u8 bit = byte & (1 << (j % 8));
- bit = bit >> (j % 8);
+ u8 bit = byte & (((1 << (bitsperpixel))-1) <<
(j % 8/bitsperpixel));
+
+ bit = (bit >> (j % 8/bitsperpixel)) >>
(bitsperpixel-1);
array->data[array_idx] |= bit << k;
}
}
@@ -548,7 +555,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
if (of_property_read_u32(node, "solomon,page-offset",
>page_offset))
par->page_offset = 1;
- vmem_size = par->width * par->height / 8;
if (of_property_read_u32(node, "solomon,segment-remap",
>seg_remap))
par->seg_remap = 0;
@@ -582,6 +588,8 @@ static int ssd1307fb_probe(struct i2c_client *client,
if (of_property_read_u32(node, "solomon,dclk-frq", >dclk_frq))
par->dclk_frq = par->device_info->default_dclk_frq;
+ vmem_size = par->width * par->height * bitsperpixel / 8;
+
vmem = rvmalloc(vmem_size);
if (!vmem) {
dev_err(>dev, "Couldn't allocate graphical memory.\n");
@@ -591,20 +599,21 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->fbops = _ops;
info->fix = ssd1307fb_fix;
- info->fix.line_length = par->width / 8;
+ info->fix.line_length = par->width * bitsperpixel / 8;
info->fbdefio = _defio;
info->var = ssd1307fb_var;
+ info->var.bits_per_pixel = bitsperpixel;
info->var.xres = par->width;
info->var.xres_virtual = par->width;
info->var.yres = par->height;
info->var.yres_virtual = par->height;
- info->var.red.length = 1;
+ info->var.red.length = bitsperpixel;
info->var.red.offset = 0;
- info->var.green.length = 1;
+ info->var.green.length = bitsperpixel;
info->var.green.offset = 0;
- info->var.blue.length = 1;
+ info->var.blue.length = bitsperpixel;
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
--
2.1.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 0/8] Cleanup and add support for SSD1305
From: Thomas Niederprüm This patch series is the result of making the ssd1307fb driver work with a Newhaven OLED display using the Solomon SSD1305 controller. To achieve this the intialization code for the SSD1306 and the SSD1307 is merged and based on device tree configuration. This gets rid of the magic bit values that were used so far. Based on these changes it was straight forward to add support for the SSD1305 controller. While working with the driver I realized that it was not possible to correctly mmap the video memory from userspace since the memory reserved by kzalloc is not page aligned. This problem is fixed by using vmalloc as it is done inthe vfb driver. Furthermore module parameters are added to set the bits per pixel and the delay for the deferred io update. It makes sense to set the bits per pixel for the video memory to 8 bits since there is only very poor userspace support for 1 bit framebuffers. Also sysfs handles are added to make the contrast settings and dim mode setting available in userspace. Thomas Niederprüm (8): Documentation: dts: add missing Solomon Systech vendor prefix. fbdev: ssd1307fb: Unify init code and make controller configurable from device tree fbdev: ssd1307fb: Add support for SSD1305 fbdev: ssd1307fb: Use vmalloc to allocate video memory. fbdev: ssd1307fb: Add module parameter bitsperpixel. fbdev: ssd1307fb: Add module parameter to set update delay of the deffered io. fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting to userspace. fbdev: ssd1307fb: Turn off display on driver unload. .../devicetree/bindings/vendor-prefixes.txt| 1 + .../devicetree/bindings/video/ssd1307fb.txt| 13 +- drivers/video/fbdev/ssd1307fb.c| 426 - 3 files changed, 346 insertions(+), 94 deletions(-) -- 2.1.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 7/8] fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting to userspace.
From: Thomas Niederprüm
This patch adds sysfs handles to enable userspace control over the display
contrast as well as the dim mode. The handles are available as "contrast"
and "dim" in the framebuffers sysfs domain.
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 88 -
1 file changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index b38315d..02931c7 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -33,6 +33,7 @@
#define SSD1307FB_CONTRAST 0x81
#defineSSD1307FB_CHARGE_PUMP 0x8d
#define SSD1307FB_SEG_REMAP_ON 0xa1
+#define SSD1307FB_DISPLAY_DIM 0xac
#define SSD1307FB_DISPLAY_OFF 0xae
#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
#define SSD1307FB_DISPLAY_ON 0xaf
@@ -43,6 +44,9 @@
#defineSSD1307FB_SET_COM_PINS_CONFIG 0xda
#defineSSD1307FB_SET_VCOMH 0xdb
+#define MIN_CONTRAST 0
+#define MAX_CONTRAST 255
+
#define BITSPERPIXEL 1
#define DELAYDIVIDER 20
@@ -69,6 +73,7 @@ struct ssd1307fb_par {
u32 dclk_div;
u32 dclk_frq;
struct ssd1307fb_deviceinfo *device_info;
+ u32 dim;
struct i2c_client *client;
u32 height;
struct fb_info *info;
@@ -515,6 +520,79 @@ static const struct of_device_id ssd1307fb_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+static ssize_t show_contrast(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", par->contrast);
+}
+
+static ssize_t store_contrast(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+ unsigned long contrastval;
+ int ret;
+
+ ret = kstrtoul(buf, 0, );
+ if (ret < 0)
+ return ret;
+
+ par->contrast = max(min(contrastval,
+ (ulong)MAX_CONTRAST), (ulong)MIN_CONTRAST);
+
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
+ ret = ret & ssd1307fb_write_cmd(par->client, par->contrast);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+
+static ssize_t show_dim(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", par->dim);
+}
+
+static ssize_t store_dim(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+ unsigned long dimval;
+ int ret;
+
+ ret = kstrtoul(buf, 0, );
+ if (ret < 0)
+ return ret;
+
+ par->dim = max(min(dimval, (ulong)1), (ulong)0);
+ if (par->dim)
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_DIM);
+ else
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static struct device_attribute device_attrs[] = {
+ __ATTR(contrast, S_IRUGO|S_IWUSR, show_contrast, store_contrast),
+ __ATTR(dim, S_IRUGO|S_IWUSR, show_dim, store_dim),
+
+};
+
static int ssd1307fb_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -523,7 +601,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
u32 vmem_size;
struct ssd1307fb_par *par;
u8 *vmem;
- int ret;
+ int ret, i;
if (!node) {
dev_err(>dev, "No device tree data found!\n");
@@ -650,6 +728,14 @@ static int ssd1307fb_probe(struct i2c_client *client,
goto reset_oled_error;
ret = register_framebuffer(info);
+
+ for (i = 0; i < ARRAY_SIZE(device_attrs); i++)
+ ret = device_create_file(info->dev, _attrs[i]);
+
+ if (ret) {
+ dev_err(>dev, "Couldn't register sysfs nodes\n");
+ }
+
if (ret) {
dev_err(>dev, "Couldn't register the framebuffer\n");
goto panel_init_error;
--
2.1.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 8/8] fbdev: ssd1307fb: Turn off display on driver unload.
From: Thomas Niederprüm
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 02931c7..be91dfc 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -762,6 +762,11 @@ static int ssd1307fb_remove(struct i2c_client *client)
{
struct fb_info *info = i2c_get_clientdata(client);
struct ssd1307fb_par *par = info->par;
+ int ret = 0;
+
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_OFF);
+ if (ret < 0)
+ return ret;
unregister_framebuffer(info);
if (par->device_info->device_id == DEVID_SSD1307) {
--
2.1.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 4/8] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
From: Thomas Niederprüm
It makes sense to use vmalloc to allocate the video buffer since it has to be
page aligned memory for using it with
mmap. Also deffered io seems buggy in combination with kmalloc'ed memory (crash
on unloading the module).
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 43 +++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 01cfb46..945ded9 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -93,6 +94,43 @@ static struct fb_var_screeninfo ssd1307fb_var = {
.bits_per_pixel = 1,
};
+static void *rvmalloc(unsigned long size)
+{
+ void *mem;
+ unsigned long adr;
+
+ size = PAGE_ALIGN(size);
+ mem = vmalloc_32(size);
+ if (!mem)
+ return NULL;
+
+ memset(mem, 0, size); /* Clear the ram out, no junk to the user */
+ adr = (unsigned long) mem;
+ while (size > 0) {
+ SetPageReserved(vmalloc_to_page((void *)adr));
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
+ }
+
+ return mem;
+}
+
+static void rvfree(void *mem, unsigned long size)
+{
+ unsigned long adr;
+
+ if (!mem)
+ return;
+
+ adr = (unsigned long) mem;
+ while ((long) size > 0) {
+ ClearPageReserved(vmalloc_to_page((void *)adr));
+ adr += PAGE_SIZE;
+ size -= PAGE_SIZE;
+ }
+ vfree(mem);
+}
+
static struct ssd1307fb_array *ssd1307fb_alloc_array(u32 len, u8 type)
{
struct ssd1307fb_array *array;
@@ -538,13 +576,13 @@ static int ssd1307fb_probe(struct i2c_client *client,
if (of_property_read_u32(node, "solomon,vcomh", >vcomh))
par->vcomh = par->device_info->default_vcomh;
- vmem = devm_kzalloc(>dev, vmem_size, GFP_KERNEL);
if (of_property_read_u32(node, "solomon,dclk-div", >dclk_div))
par->dclk_div = par->device_info->default_dclk_div;
if (of_property_read_u32(node, "solomon,dclk-frq", >dclk_frq))
par->dclk_frq = par->device_info->default_dclk_frq;
+ vmem = rvmalloc(vmem_size);
if (!vmem) {
dev_err(>dev, "Couldn't allocate graphical memory.\n");
ret = -ENOMEM;
@@ -570,7 +608,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
- info->fix.smem_start = (unsigned long)vmem;
+ info->fix.smem_start = __pa(vmem);
info->fix.smem_len = vmem_size;
fb_deferred_io_init(info);
@@ -614,6 +652,7 @@ panel_init_error:
};
reset_oled_error:
fb_deferred_io_cleanup(info);
+ rvfree(vmem, vmem_size);
fb_alloc_error:
framebuffer_release(info);
return ret;
--
2.1.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] seccomp: cap SECCOMP_RET_ERRNO data to MAX_ERRNO
On Fri, Feb 06, 2015 at 01:03:09PM -0800, Kees Cook wrote: > The value resulting from the SECCOMP_RET_DATA mask could exceed MAX_ERRNO > when setting errno during a SECCOMP_RET_ERRNO filter action. This makes sure > we have a reliable value being set, so that an invalid errno will not be > ignored by userspace. Acked-by: Dmitry V. Levin -- ldv -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86/tbl/trace: Do not trace on CPU that is offline
On Fri, Feb 6, 2015 at 10:42 PM, Steven Rostedt wrote: > On Fri, 6 Feb 2015 22:39:52 +0100 > Sedat Dilek wrote: > >> Man man man you write and test your stuff still on ancient x85 arch. >> What's coming next... revive/reinclude i386 code? > > Real mode for Real men! Yeah Baby! > I hope you enjoyed your glass of bitter lemon. After Paul agreed that this one can also go through your tree I hope to see an refreshed version in your linux-trace tree. - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [v7,2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On Mon, Jan 19, 2015 at 01:51:49PM -0800, Ray Jui wrote: > Add initial support to the Broadcom iProc I2C controller found in the > iProc family of SoCs. > > The iProc I2C controller has separate internal TX and RX FIFOs, each has > a size of 64 bytes. The iProc I2C controller supports two bus speeds > including standard mode (100kHz) and fast mode (400kHz) > > Signed-off-by: Ray Jui broadcom.com> > Reviewed-by: Scott Branden broadcom.com> > --- > drivers/i2c/busses/Kconfig | 10 + > drivers/i2c/busses/Makefile|1 + > drivers/i2c/busses/i2c-bcm-iproc.c | 505 > > 3 files changed, 516 insertions(+) > create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 31e8308..af76d23 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > -372,6 +372,16 config I2C_BCM2835 > This support is also available as a module. If so, the module > will be called i2c-bcm2835. > > +config I2C_BCM_IPROC > + tristate "Broadcom iProc I2C controller" > + depends on ARCH_BCM_IPROC || COMPILE_TEST > + default ARCH_BCM_IPROC > + help > + If you say yes to this option, support will be included for the > + Broadcom iProc I2C controller. > + > + If you don't know what to do here, say N. > + > config I2C_BCM_KONA > tristate "BCM Kona I2C adapter" > depends on ARCH_BCM_MOBILE > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > index 56388f6..d93b509 100644 > --- a/drivers/i2c/busses/Makefile > +++ b/drivers/i2c/busses/Makefile > -33,6 +33,7 obj-$(CONFIG_I2C_AT91) += > i2c-at91.o > obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o > obj-$(CONFIG_I2C_AXXIA) += i2c-axxia.o > obj-$(CONFIG_I2C_BCM2835)+= i2c-bcm2835.o > +obj-$(CONFIG_I2C_BCM_IPROC) += i2c-bcm-iproc.o > obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o > obj-$(CONFIG_I2C_CADENCE)+= i2c-cadence.o > obj-$(CONFIG_I2C_CBUS_GPIO) += i2c-cbus-gpio.o > diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c > b/drivers/i2c/busses/i2c-bcm-iproc.c > new file mode 100644 > index 000..64c622f > --- /dev/null > +++ b/drivers/i2c/busses/i2c-bcm-iproc.c > -0,0 +1,505 > +/* > + * Copyright (C) 2014 Broadcom Corporation > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define CFG_OFFSET 0x00 > +#define CFG_RESET_SHIFT 31 > +#define CFG_EN_SHIFT 30 > +#define CFG_M_RETRY_CNT_SHIFT16 > +#define CFG_M_RETRY_CNT_MASK 0x0f > + > +#define TIM_CFG_OFFSET 0x04 > +#define TIM_CFG_MODE_400_SHIFT 31 > + > +#define M_FIFO_CTRL_OFFSET 0x0c > +#define M_FIFO_RX_FLUSH_SHIFT31 > +#define M_FIFO_TX_FLUSH_SHIFT30 > +#define M_FIFO_RX_CNT_SHIFT 16 > +#define M_FIFO_RX_CNT_MASK 0x7f > +#define M_FIFO_RX_THLD_SHIFT 8 > +#define M_FIFO_RX_THLD_MASK 0x3f > + > +#define M_CMD_OFFSET 0x30 > +#define M_CMD_START_BUSY_SHIFT 31 > +#define M_CMD_STATUS_SHIFT 25 > +#define M_CMD_STATUS_MASK0x07 > +#define M_CMD_STATUS_SUCCESS 0x0 > +#define M_CMD_STATUS_LOST_ARB0x1 > +#define M_CMD_STATUS_NACK_ADDR 0x2 > +#define M_CMD_STATUS_NACK_DATA 0x3 > +#define M_CMD_STATUS_TIMEOUT 0x4 > +#define M_CMD_PROTOCOL_SHIFT 9 > +#define M_CMD_PROTOCOL_MASK 0xf > +#define M_CMD_PROTOCOL_BLK_WR0x7 > +#define M_CMD_PROTOCOL_BLK_RD0x8 > +#define M_CMD_PEC_SHIFT 8 > +#define M_CMD_RD_CNT_SHIFT 0 > +#define M_CMD_RD_CNT_MASK0xff > + > +#define IE_OFFSET0x38 > +#define IE_M_RX_FIFO_FULL_SHIFT 31 > +#define IE_M_RX_THLD_SHIFT 30 > +#define IE_M_START_BUSY_SHIFT28 > + > +#define IS_OFFSET0x3c > +#define IS_M_RX_FIFO_FULL_SHIFT 31 > +#define IS_M_RX_THLD_SHIFT 30 > +#define IS_M_START_BUSY_SHIFT28 > + > +#define M_TX_OFFSET 0x40 > +#define M_TX_WR_STATUS_SHIFT 31 > +#define M_TX_DATA_SHIFT 0 > +#define M_TX_DATA_MASK 0xff > + > +#define M_RX_OFFSET 0x44 > +#define M_RX_STATUS_SHIFT30 > +#define M_RX_STATUS_MASK 0x03 > +#define
Re: [RFC][PATCH v2 2/7] implement memmem()
On Fri, Feb 06 2015, Al Viro wrote:
> +/**
> + * strnstr - Find the first substring in a length-limited string
> + * @s1: The string to be searched
> + * @s2: The string to search for
> + * @len: the maximum number of characters to search
> + */
> +char *strnstr(const char *s1, const char *s2, size_t len)
> +{
> + return memmem(s1, len, s2, strlen(s2));
> +}
Most strn* interfaces don't require the n to be at most the actual
string length, but it seems that this would happily search past the '\0'
of s1 if len is large enough, e.g.
strnstr("abc\0def", "def", 1000)
will not return NULL (unlike what the libbsd version does). So either
that restriction should be documented or len should be replaced by
min(len, strlen(s1)).
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] Mirrored memory support for boot time allocations
On Fri, Feb 6, 2015 at 1:54 PM, Tony Luck wrote: > Platforms that support a mix of mirrored and regular memory are coming. Obviously I don't do enough -mm work to remember where linux-mm mailing list is hosted :-( Let's see who finds this on the linux-kernel list (that I did spell right). When v2 happens I'll get it to the right places. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
formatting of this patch is still badly broken.
./scripts/checkpatch.pl ~/Downloads/patch.eml
ERROR: DOS line endings
#442: FILE: drivers/net/wireless/ath/ath9k/htc_drv_txrx.c:1170:
+^I^IAURFC_STAT_SET(aurfc_submit_delay, delay);^M$
total: 195 errors, 6 warnings, 1 checks, 310 lines checked
Am 06.02.2015 um 11:46 schrieb yuweizh...@139.com:
> From: Yuwei Zheng
>
> In the environment with heavy wifi traffic, set the ar9271 into monitor mode,
> will
> trigger a deadloop panic.
>
> The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
> ath9k_rx_tasklet excute
> on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
> chance to excute than
> ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
> always full,
> and the do {}while(true) loop will not be break. The kernel get a soft lockup
> panic.
>
> [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
> [kworker/0:0:30609]
> [59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.858522] Kernel panic - not syncing: softlockup: hung tasks
>
> [59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
> [59014.046834] bc20:
> de57b950 6113
> [59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
> df4bbcd0
> [59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
> 6133
> [59014.085233] [] (__irq_svc+0x3b/0x5c) from []
> (_raw_spin_unlock_irqrestore+0xc/0x10)
> [59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
> [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
> [59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
> [] (tasklet_action+0x3b/0x98)
> [59014.134132] [] (tasklet_action+0x3b/0x98) from []
> (__do_softirq+0x99/0x16c)
> [59014.147784] [] (__do_softirq+0x99/0x16c) from []
> (irq_exit+0x5b/0x5c)
> [59014.160653] [] (irq_exit+0x5b/0x5c) from []
> (handle_IRQ+0x37/0x78)
> [59014.173124] [] (handle_IRQ+0x37/0x78) from []
> (omap3_intc_handle_irq+0x5f/0x68)
> [59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
> [](__irq_svc+0x3b/0x5c)
>
> This bug can be see with low performance board, such as uniprocessor beagle
> bone board.
>
> Signed-off-by: Yuwei Zheng
>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 74
> +++---
> drivers/net/wireless/ath/ath9k/hif_usb.h | 9
> drivers/net/wireless/ath/ath9k/htc.h | 19 +++
> drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 ++
> drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 44 +++
> 5 files changed, 192 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
> b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 8e7153b..90ee568 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> struct hif_device_usb *hif_dev =
> usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
> int ret;
> + int delay;
>
> if (!skb)
> return;
> @@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> default:
> goto resubmit;
> }
> -
> if (likely(urb->actual_length != 0)) {
> skb_put(skb, urb->actual_length);
> ath9k_hif_usb_rx_stream(hif_dev, skb);
> @@ -667,12 +667,22 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> resubmit:
> skb_reset_tail_pointer(skb);
> skb_trim(skb, 0);
> -
> - usb_anchor_urb(urb, _dev->rx_submitted);
> - ret = usb_submit_urb(urb, GFP_ATOMIC);
> - if (ret) {
> - usb_unanchor_urb(urb);
> - goto free;
> + spin_lock(_dev->aurfc_lock);
> + if (atomic_read(_dev->aurfc_submit_delay) > 0 &&
> + hif_dev->aurfc_active == 1) {
> + usb_anchor_urb(urb, _dev->rx_delayed_submitted);
> + delay = atomic_read(_dev->aurfc_submit_delay);
> + schedule_delayed_work(_dev->aurfc_delayed_work,
> + msecs_to_jiffies(delay));
> + spin_unlock(_dev->aurfc_lock);
> + } else {
> + spin_unlock(_dev->aurfc_lock);
> + usb_anchor_urb(urb, _dev->rx_submitted);
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret) {
> + usb_unanchor_urb(urb);
> + goto free;
> + }
> }
>
> return;
> @@ -818,9 +828,50 @@ err:
> return -ENOMEM;
> }
>
> +static void aurfc_submit_handler(struct work_struct *work)
> +{
> + struct hif_device_usb *hif_dev =
> + container_of(work,
> + struct hif_device_usb,
> +
[RFC 3/3] x86, mirror: x86 enabling - find mirrored memory ranges and tell memblock
Can't post this part yet because it uses things in an upcoming[*] ACPI, UEFI,
or some
other four-letter-ending-in-I standard. So just imagine a call someplace early
in startup that reads information about mirrored address ranges and does:
+ for (...) {
+ start = ...;
+ size = ...;
+ if (it looks mirrored)
+ memblock_mark_mirror(start, size);
+ }
Whole patch is pretty tiny:
3 files changed, 19 insertions(+)
How much damage could I possibly do in just 19 lines?
-Tony
[*] very soon, I'm told
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/3] mm/memblock: Allocate boot time data structures from mirrored memory
Try to allocate all boot time kernel data structures from mirrored
memory. If we run out of mirrored memory print warnings, but fall
back to using non-mirrored memory to make sure that we still boot.
Signed-off-by: Tony Luck
---
include/linux/memblock.h | 8 ++
mm/memblock.c| 72 +---
mm/nobootmem.c | 10 ++-
3 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 8a036cc6cdd5..03c2b91db474 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -22,6 +22,7 @@
/* Definition of memblock flags. */
#define MEMBLOCK_HOTPLUG 0x1 /* hotpluggable region */
+#define MEMBLOCK_MIRROR0x2 /* mirrored region */
struct memblock_region {
phys_addr_t base;
@@ -75,6 +76,8 @@ int memblock_reserve(phys_addr_t base, phys_addr_t size);
void memblock_trim_memory(phys_addr_t align);
int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
+int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
+u32 memblock_has_mirror(void);
/* Low level functions */
int memblock_add_range(struct memblock_type *type,
@@ -155,6 +158,11 @@ static inline bool movable_node_is_enabled(void)
}
#endif
+static inline bool memblock_is_mirror(struct memblock_region *m)
+{
+ return m->flags & MEMBLOCK_MIRROR;
+}
+
#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
int memblock_search_pfn_nid(unsigned long pfn, unsigned long *start_pfn,
unsigned long *end_pfn);
diff --git a/mm/memblock.c b/mm/memblock.c
index 3c8db6d84a32..e0826ff5f59b 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -54,10 +54,16 @@ int memblock_debug __initdata_memblock;
#ifdef CONFIG_MOVABLE_NODE
bool movable_node_enabled __initdata_memblock = false;
#endif
+static bool memblock_have_mirror __initdata_memblock = false;
static int memblock_can_resize __initdata_memblock;
static int memblock_memory_in_slab __initdata_memblock = 0;
static int memblock_reserved_in_slab __initdata_memblock = 0;
+u32 __init_memblock memblock_has_mirror(void)
+{
+ return memblock_have_mirror ? MEMBLOCK_MIRROR : 0;
+}
+
/* inline so we don't get a warning when pr_debug is compiled out */
static __init_memblock const char *
memblock_type_name(struct memblock_type *type)
@@ -247,7 +253,6 @@ phys_addr_t __init_memblock
memblock_find_in_range_node(phys_addr_t size,
* @end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
* @size: size of free area to find
* @align: alignment of free area to find
- * @flag: pick from blocks based on memory attributes
*
* Find @size free area aligned to @align in the specified range.
*
@@ -258,8 +263,19 @@ phys_addr_t __init_memblock
memblock_find_in_range(phys_addr_t start,
phys_addr_t end, phys_addr_t size,
phys_addr_t align)
{
- return memblock_find_in_range_node(size, align, start, end,
+ phys_addr_t ret;
+ u32 flag = memblock_has_mirror();
+
+ ret = memblock_find_in_range_node(size, align, start, end,
+ NUMA_NO_NODE, flag);
+
+ if (!ret && flag) {
+ pr_warn("Could not allocate %lld bytes of mirrored memory\n",
size);
+ ret = memblock_find_in_range_node(size, align, start, end,
NUMA_NO_NODE, 0);
+ }
+
+ return ret;
}
static void __init_memblock memblock_remove_region(struct memblock_type *type,
unsigned long r)
@@ -771,6 +787,21 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t
base, phys_addr_t size)
}
/**
+ * memblock_mark_mirror - Mark mirrored memory with flag MEMBLOCK_MIRROR.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return 0 on succees, -errno on failure.
+ */
+int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
+{
+ memblock_have_mirror = true;
+
+ return memblock_setclr_flag(base, size, 1, MEMBLOCK_MIRROR);
+}
+
+
+/**
* __next__mem_range - next function for for_each_free_mem_range() etc.
* @idx: pointer to u64 loop variable
* @nid: node selector, %NUMA_NO_NODE for all nodes
@@ -824,6 +855,10 @@ void __init_memblock __next_mem_range(u64 *idx, int nid,
u32 flags,
if (movable_node_is_enabled() && memblock_is_hotpluggable(m))
continue;
+ /* if we want mirror memory skip non-mirror memory regions */
+ if ((flags & MEMBLOCK_MIRROR) && !memblock_is_mirror(m))
+ continue;
+
if (!type_b) {
if (out_start)
*out_start = m_start;
@@ -929,6 +964,10 @@ void __init_memblock __next_mem_range_rev(u64 *idx, int
nid, u32 flags,
