Re: [PATCH] kobject: avoid unnecessary assignment of kobj->parent
On Thu, Jun 04, 2015 at 10:13:50AM +0800, Wei Yang wrote:
> kobj->parent is changed only when it is NULL originally.
>
> This patch moves the assignment in the "if" to avoid unnecessary assignment.
>
> Signed-off-by: Wei Yang
> ---
> lib/kobject.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/kobject.c b/lib/kobject.c
> index 03d4ab3..37b10bb 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -216,9 +216,8 @@ static int kobject_add_internal(struct kobject *kobj)
> /* join kset if set, use it as parent if we do not already have one */
> if (kobj->kset) {
> if (!parent)
> - parent = kobject_get(>kset->kobj);
> + parent = kobj->parent = kobject_get(>kset->kobj);
> kobj_kset_join(kobj);
> - kobj->parent = parent;
What is this "fixing"? I hate multiple assignments on the same line,
it makes it harder to read and understand.
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] Staging: comedi: daqboard2000: fixed whitespace coding style issue
On Fri, Jun 05, 2015 at 04:27:48PM -0700, Dennis Chen wrote:
> From 843d038eec5ac2c59d3138f19ae52828098c7d50 Mon Sep 17 00:00:00 2001
> From: Dennis Chen
> Date: Fri, 5 Jun 2015 15:42:37 -0700
> Subject: [PATCH] Staging: comedi: daqboard2000: fixed whitespace coding style
> issue
>
> Fixed whitespace coding style issue.
this will not apply anymore. The comment has already been fixed by:
12cba5c9df23 ('staging: comedi: daqboard2000: Use preferred comment style')
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Interaction issue of intel wifi and broadcom bluetooth - it appears that nobody feels responsible for doing something
Hi Arend, >> thanks for responding! >> >> I did have my mobile phone very nearby also connected to the bluetooth >> headphones while my laptop was still using 11n wifi. I didn't have any >> noticeable issues with bluetooth there. >> >> But I got the feeling that my phone's android drivers + hardware for >> bluetooth are tuned better than the laptop ones, so maybe that just >> means the phone is just better at jumping frequencies to avoid. >> >> I guess the best test would be the same laptop model in direct >> proximity, but sadly I only own that laptop once. ;) >> >> I hope wireless interference wouldn't rule out that some driver work >> would be considered to make it work better - after all, both chips are >> in the same laptop and as per the intel comment, bluetooth is supposed >> to work despite of wifi activity. >> >> Regards, >> Jonas Thiem >> >> On 06/05/2015 06:45 AM, Jeremiah Mahler wrote: >>> Jonas, >>> >>> On Fri, Jun 05, 2015 at 01:00:32AM +0200, Jonas Thiem wrote: Hi *, this is my first post to this mailing list, sorry if it's not supposed to go here. (also CC in responses would be nice since I'm not subscribed) I filed a bug about an intel centrino wifi interaction with broadcom's BCM2045B: https://bugzilla.kernel.org/show_bug.cgi?id=97101 >>> Those are some unhelpful replies :-( > > Indeed. Now my reply maybe of a similar nature as my knowledge of the > bluetooth part is next to nil. > In short, the two seem to kinda fight over the wireless spectrum and both drop connections all the time - unless the 'iwlwifi' module is loaded with 11n_disabled=1. > > I guess you don't have a choice about the channel your access point is > operating on. If you can you might move wifi channel to 5GHz although that > will likely affect your range. > > To get more info on your setup here a couple of questions. > > What type of device are we talking about here? > Bugzilla mentions Thinkpad X220, is that correct? > Is your AP setup for 40MHz bandwidth? > > I suppose both wifi and bt have their own antennas. When sharing antennas it > needs to be coordinated who is using the antennas. This is called bt-coex. As > said I don't think this is the case for your device, but if so I think there > is still major development task needed as I saw email from Marcel about plans > to develop a bt-coex subsystem in the kernel. Not sure if that also covers > the case where bt and wifi do not share antennas. from the report, we have to make the assumption that in this design it is two independent antennas. Meaning Bluetooth is going to win the spectrum war. It should play nice due to AFH support in almost every 4.0 device in the market, but there are limits. If your spectrum is busy, then it becomes really hard for AFH to function properly. So in the case of two independent antennas, the rfres subsystem I am proposing would help indeed. We could tell the Bluetooth controller to block out the frequency that the WiFi chip is currently operating on. Main problem is that these design are so rare these days that nobody actually cared enough to add this subsystem. If Bluetooth and WiFi are sharing the same antenna, the coex issue is solved by a direct connection between both chips. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] m32r: Wire up all missing syscalls
On 6/6/15 07:39, Chen Gang wrote: > If some of syscalls are not implemented, they will be redirected to > sys_ni_call. > Oh, sorry, sys_ni_call -> sys_ni_syscall. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] frv: Wire up all missing syscalls
If some of syscalls are not implemented, they will be redirected to sys_ni_syscall. And the related warnings for all missing syscalls: :1187:2: warning: #warning syscall recvmmsg not implemented [-Wcpp] :1190:2: warning: #warning syscall fanotify_init not implemented [-Wcpp] :1193:2: warning: #warning syscall fanotify_mark not implemented [-Wcpp] :1196:2: warning: #warning syscall prlimit64 not implemented [-Wcpp] :1199:2: warning: #warning syscall name_to_handle_at not implemented [-Wcpp] :1202:2: warning: #warning syscall open_by_handle_at not implemented [-Wcpp] :1205:2: warning: #warning syscall clock_adjtime not implemented [-Wcpp] :1208:2: warning: #warning syscall syncfs not implemented [-Wcpp] :1211:2: warning: #warning syscall sendmmsg not implemented [-Wcpp] :1217:2: warning: #warning syscall process_vm_readv not implemented [-Wcpp] :1220:2: warning: #warning syscall process_vm_writev not implemented [-Wcpp] :1223:2: warning: #warning syscall kcmp not implemented [-Wcpp] :1226:2: warning: #warning syscall finit_module not implemented [-Wcpp] :1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp] :1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp] :1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp] :1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] :1241:2: warning: #warning syscall getrandom not implemented [-Wcpp] :1244:2: warning: #warning syscall memfd_create not implemented [-Wcpp] :1247:2: warning: #warning syscall bpf not implemented [-Wcpp] :1250:2: warning: #warning syscall execveat not implemented [-Wcpp] :1253:2: warning: #warning syscall userfaultfd not implemented [-Wcpp] Signed-off-by: Chen Gang --- arch/frv/include/asm/unistd.h | 3 +-- arch/frv/include/uapi/asm/unistd.h | 22 ++ arch/frv/kernel/entry.S| 22 ++ 3 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/frv/include/asm/unistd.h b/arch/frv/include/asm/unistd.h index 17b5df8..f2de552 100644 --- a/arch/frv/include/asm/unistd.h +++ b/arch/frv/include/asm/unistd.h @@ -3,8 +3,7 @@ #include - -#define NR_syscalls 338 +#define NR_syscalls 360 /* #define __ARCH_WANT_OLD_READDIR */ #define __ARCH_WANT_OLD_STAT diff --git a/arch/frv/include/uapi/asm/unistd.h b/arch/frv/include/uapi/asm/unistd.h index 9e2612f..61e4cc7 100644 --- a/arch/frv/include/uapi/asm/unistd.h +++ b/arch/frv/include/uapi/asm/unistd.h @@ -344,5 +344,27 @@ #define __NR_rt_tgsigqueueinfo 335 #define __NR_perf_event_open 336 #define __NR_setns 337 +#define __NR_recvmmsg 338 +#define __NR_fanotify_init 339 +#define __NR_fanotify_mark 340 +#define __NR_prlimit64 341 +#define __NR_name_to_handle_at 342 +#define __NR_open_by_handle_at 343 +#define __NR_clock_adjtime 344 +#define __NR_syncfs345 +#define __NR_sendmmsg 346 +#define __NR_process_vm_readv 347 +#define __NR_process_vm_writev 348 +#define __NR_kcmp 349 +#define __NR_finit_module 350 +#define __NR_sched_setattr 351 +#define __NR_sched_getattr 352 +#define __NR_renameat2 353 +#define __NR_seccomp 354 +#define __NR_getrandom 355 +#define __NR_memfd_create 356 +#define __NR_bpf 357 +#define __NR_execveat 358 +#define __NR_userfaultfd 359 #endif /* _UAPI_ASM_UNISTD_H_ */ diff --git a/arch/frv/kernel/entry.S b/arch/frv/kernel/entry.S index dfcd263..3bb1b97 100644 --- a/arch/frv/kernel/entry.S +++ b/arch/frv/kernel/entry.S @@ -1515,5 +1515,27 @@ sys_call_table: .long sys_rt_tgsigqueueinfo /* 335 */ .long sys_perf_event_open .long sys_setns + .long sys_recvmmsg + .long sys_fanotify_init + .long sys_fanotify_mark /* 340 */ + .long sys_prlimit64 + .long sys_name_to_handle_at + .long sys_open_by_handle_at + .long sys_clock_adjtime + .long sys_syncfs/* 345 */ + .long sys_sendmmsg + .long sys_process_vm_readv + .long sys_process_vm_writev + .long sys_kcmp + .long sys_finit_module /* 350 */ + .long sys_sched_setattr + .long sys_sched_getattr + .long sys_renameat2 + .long sys_seccomp + .long sys_getrandom /* 355 */ + .long sys_memfd_create + .long sys_bpf + .long sys_execveat + .long sys_userfaultfd syscall_table_size = (. - sys_call_table) -- 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 v2 3/3] gpio_wdt: Add option for early registration
On 06/05/2015 06:46 PM, Jean-Baptiste Theou wrote:
In some situation, mainly when it's not possible to disable a
watchdog, you may want the watchdog driver to be started as soon
as possible.
Adding GPIO_WATCHDOG_ARCH_INITCALL to raise initcall from
module_init to arch_initcall. This is only for a built-in
module.
This patch require watchdog registration deferral mechanism
Signed-off-by: Jean-Baptiste Theou
---
drivers/watchdog/Kconfig| 14 ++
drivers/watchdog/gpio_wdt.c | 13 +
2 files changed, 27 insertions(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5e7c55..a9655a9 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1,3 +1,4 @@
+
#
# Watchdog device configuration
#
@@ -114,6 +115,19 @@ config MENF21BMC_WATCHDOG
This driver can also be built as a module. If so the module
will be called menf21bmc_wdt.
+config GPIO_WATCHDOG_ARCH_INITCALL
+ bool "Register the watchdog as early as possible"
+ depends on GPIO_WATCHDOG
depends on GPIO_WATCHDOG=y
+ help
+ This option make sense only on a built-in situation.
+
and then you can drop this sentence.
+ In some situation, the default initcall level (module_init)
situations
+ in not early enough on the boot process to avoid the watchdog
in the boot process
+ to be trigger.
triggered.
+ If you say yes here, the initcall level would be raise to
will be raised to ...
+ arch_initcall.
+ "If in doubt, leave it out" - say N.
If in doubt, say N.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index cbc313d..07a39cd 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -267,8 +267,21 @@ static struct platform_driver gpio_wdt_driver = {
.probe = gpio_wdt_probe,
.remove = gpio_wdt_remove,
};
+#ifndef GPIO_WATCHDOG_ARCH_INITCALL
module_platform_driver(gpio_wdt_driver);
+#else
+static int __init gpio_wdt_init(void)
+{
+ return platform_driver_register(_wdt_driver);
+}
+arch_initcall(gpio_wdt_init);
+static void __exit gpio_wdt_exit(void)
+{
+ platform_driver_unregister(_wdt_driver);
+}
+module_exit(gpio_wdt_exit);
+#endif
If you change the dependency as suggested above, you don't need
the exit function at all, and you can simplify this code to
#ifdef GPIO_WATCHDOG_ARCH_INITCALL
arch_initcall(gpio_wdt_init);
#else
module_platform_driver(gpio_wdt_driver);
#endif
which would look much nicer.
Thanks,
Guenter
MODULE_AUTHOR("Alexander Shiyan ");
MODULE_DESCRIPTION("GPIO Watchdog");
MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] watchdog-kernel-api: Add registration deferral mechanism
On 06/05/2015 06:46 PM, Jean-Baptiste Theou wrote:
Add registration deferral mechanism capability information
Signed-off-by: Jean-Baptiste Theou
---
Documentation/watchdog/watchdog-kernel-api.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index a0438f3..11c988b 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -36,6 +36,10 @@ The watchdog_unregister_device routine deregisters a
registered watchdog timer
device. The parameter of this routine is the pointer to the registered
watchdog_device structure.
+The watchdog subsystem contain an registration deferral mechanism,
contains, or maybe better includes.
+which allow you to register an watchdog as early as you wish during
allows
+the boot process, in the situation of a built-in module.
Drop part after the , as irrelevant.
Please merge this patch into the first patch; no need to keep it separate.
Thanks,
Guenter
+
The watchdog device structure looks like this:
struct watchdog_device {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] watchdog_core: Add watchdog registration deferral mechanism
On 06/05/2015 06:46 PM, Jean-Baptiste Theou wrote:
Currently, watchdog subsystem require the misc subsystem to
register a watchdog. This may not be the case in case of an
early registration of a watchdog, which can be required when
the watchdog cannot be disabled.
This patch use deferral mechanism to remove this requirement.
... introduces a deferral ...
I think this is going into the right direction. Couple of comments below.
Guenter
Signed-off-by: Jean-Baptiste Theou
---
drivers/watchdog/watchdog_core.c | 92 ++--
include/linux/watchdog.h | 3 ++
2 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index cec9b55..edf6294 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -43,6 +43,41 @@
static DEFINE_IDA(watchdog_ida);
static struct class *watchdog_class;
+/*
+ * Deferred Registration infrastructure.
+ *
+ * Sometimes watchdog drivers need to be loaded as soon as possible,
+ * for example when it's impossible to disable it. To do so,
+ * raising the initcall level of the watchdog driver is a solution.
+ * But in such case, the miscdev is maybe not ready (subsys_initcall), and
+ * watchdog core need miscdev to be populate.
s/need/needs/
s/populate/populated/
watchdog_core needs miscdev to be populated for what ?
+ *
+ * The deferred registration infrastructure offer a way for the watchdog
+ * subsystem to register a watchdog properly, even before miscdev is ready
+ *
Add '.'.
+ * This is based on driver probe deferral mechanism.
I don't understand the last sentence, and I don't think it adds value.
+ */
+
+static DEFINE_MUTEX(watchdog_deferred_registration_mutex);
+static LIST_HEAD(watchdog_deferred_registration_pending_list);
+static bool watchdog_deferred_registration_done;
+
+static int watchdog_deferred_registration_add(struct watchdog_device *wdd)
+{
+ dev_dbg(wdd->dev, "Added to deferred list\n");
Did you try to run this code with debugging enabled ?
Presumably not, because it should result in a NULL pointer access,
since wdd->dev is only set during registration.
This leads to the question why you have this debug message
in the first place.
+ list_add(>deferred_registration,
+_deferred_registration_pending_list);
list_add_tail(). We want to register watchdog devices in the original order,
not in reverse order. The first caller gets /dev/watchdog.
+ return 0;
+}
+
+static void watchdog_deferred_registration_del(struct watchdog_device *wdd)
+{
+ if (!list_empty(>deferred_registration)) {
I don't think this check is necessary, even if the member is uninitialized.
Problem here is that is watchdog_register was never called, the list members
will be NULL, list->next will be NULL, and not point to the list itself.
So you'd end up with trouble (try calling watchdog_unregister_device
before calling watchdog_register_device just for fun to see what happens).
Not really sure how to handle this. The safe approach may be to walk the list
and remove the entry (only) if it is found.
+ dev_dbg(wdd->dev, "Removed from deferred list\n");
... and another crash ;-)
+ list_del_init(>deferred_registration);
+ }
+}
+
static void watchdog_check_min_max_timeout(struct watchdog_device *wdd)
{
/*
@@ -99,7 +134,7 @@ int watchdog_init_timeout(struct watchdog_device *wdd,
EXPORT_SYMBOL_GPL(watchdog_init_timeout);
/**
- * watchdog_register_device() - register a watchdog device
+ * __watchdog_register_device() - register a watchdog device
* @wdd: watchdog device
*
* Register a watchdog device with the kernel so that the
@@ -108,7 +143,7 @@ EXPORT_SYMBOL_GPL(watchdog_init_timeout);
* A zero is returned on success and a negative errno code for
* failure.
*/
-int watchdog_register_device(struct watchdog_device *wdd)
+int __watchdog_register_device(struct watchdog_device *wdd)
Why do you want to make this global (but unexported) ? I think it should be
static,
and the published API should remain the same.
{
int ret, id, devno;
@@ -164,16 +199,35 @@ int watchdog_register_device(struct watchdog_device *wdd)
return 0;
}
+
+/*
+ * watchdog_register_device use either the deferred approach,
+ * or directly register the watchdog, depending on the current
+ * initcall level.
+ */
+
Please move the API comment to here. The above comment doesn't really add
value unless it is part of the API documentation.
+int watchdog_register_device(struct watchdog_device *wdd)
+{
+ int ret;
+
+ mutex_lock(_deferred_registration_mutex);
+ if (watchdog_deferred_registration_done)
+ ret = __watchdog_register_device(wdd);
+ else
+ ret = watchdog_deferred_registration_add(wdd);
+ mutex_unlock(_deferred_registration_mutex);
+ return ret;
+}
[PATCH] net: rose: Use mod_timer
Use mod_timer instead of del_timer followed by add_timer to update
the expire field of the active timer.
The semantic patch that performs this transformation is as follows:
@change@
expression e1, e2, e3, e4;
@@
- del_timer();
... when != e1 = e3
- e1.expires = e2;
... when != e1 = e4
- add_timer ();
+ mod_timer (, e2);
Signed-off-by: Vaishali Thakkar
---
net/rose/rose_link.c | 16
net/rose/rose_loopback.c | 6 +-
net/rose/rose_timer.c| 30 +-
3 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index e873d7d..a2409bb 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -36,26 +36,18 @@ static void rose_transmit_restart_request(struct rose_neigh
*neigh);
void rose_start_ftimer(struct rose_neigh *neigh)
{
- del_timer(>ftimer);
-
neigh->ftimer.data = (unsigned long)neigh;
neigh->ftimer.function = _ftimer_expiry;
- neigh->ftimer.expires =
- jiffies + msecs_to_jiffies(sysctl_rose_link_fail_timeout);
-
- add_timer(>ftimer);
+ mod_timer(>ftimer,
+ jiffies + msecs_to_jiffies(sysctl_rose_link_fail_timeout));
}
static void rose_start_t0timer(struct rose_neigh *neigh)
{
- del_timer(>t0timer);
-
neigh->t0timer.data = (unsigned long)neigh;
neigh->t0timer.function = _t0timer_expiry;
- neigh->t0timer.expires =
- jiffies + msecs_to_jiffies(sysctl_rose_restart_request_timeout);
-
- add_timer(>t0timer);
+ mod_timer(>t0timer,
+ jiffies +
msecs_to_jiffies(sysctl_rose_restart_request_timeout));
}
void rose_stop_ftimer(struct rose_neigh *neigh)
diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 3444562..ed81864 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -54,13 +54,9 @@ static void rose_loopback_timer(unsigned long);
static void rose_set_loopback_timer(void)
{
- del_timer(_timer);
-
loopback_timer.data = 0;
loopback_timer.function = _loopback_timer;
- loopback_timer.expires = jiffies + 10;
-
- add_timer(_timer);
+ mod_timer(_timer, jiffies + 10);
}
static void rose_loopback_timer(unsigned long param)
diff --git a/net/rose/rose_timer.c b/net/rose/rose_timer.c
index bc5469d..7495730 100644
--- a/net/rose/rose_timer.c
+++ b/net/rose/rose_timer.c
@@ -34,65 +34,45 @@ static void rose_idletimer_expiry(unsigned long);
void rose_start_heartbeat(struct sock *sk)
{
- del_timer(>sk_timer);
-
sk->sk_timer.data = (unsigned long)sk;
sk->sk_timer.function = _heartbeat_expiry;
- sk->sk_timer.expires = jiffies + 5 * HZ;
-
- add_timer(>sk_timer);
+ mod_timer(>sk_timer, jiffies + 5 * HZ);
}
void rose_start_t1timer(struct sock *sk)
{
struct rose_sock *rose = rose_sk(sk);
- del_timer(>timer);
-
rose->timer.data = (unsigned long)sk;
rose->timer.function = _timer_expiry;
- rose->timer.expires = jiffies + rose->t1;
-
- add_timer(>timer);
+ mod_timer(>timer, jiffies + rose->t1);
}
void rose_start_t2timer(struct sock *sk)
{
struct rose_sock *rose = rose_sk(sk);
- del_timer(>timer);
-
rose->timer.data = (unsigned long)sk;
rose->timer.function = _timer_expiry;
- rose->timer.expires = jiffies + rose->t2;
-
- add_timer(>timer);
+ mod_timer(>timer, jiffies + rose->t2);
}
void rose_start_t3timer(struct sock *sk)
{
struct rose_sock *rose = rose_sk(sk);
- del_timer(>timer);
-
rose->timer.data = (unsigned long)sk;
rose->timer.function = _timer_expiry;
- rose->timer.expires = jiffies + rose->t3;
-
- add_timer(>timer);
+ mod_timer(>timer, jiffies + rose->t3);
}
void rose_start_hbtimer(struct sock *sk)
{
struct rose_sock *rose = rose_sk(sk);
- del_timer(>timer);
-
rose->timer.data = (unsigned long)sk;
rose->timer.function = _timer_expiry;
- rose->timer.expires = jiffies + rose->hb;
-
- add_timer(>timer);
+ mod_timer(>timer, jiffies + rose->hb);
}
void rose_start_idletimer(struct sock *sk)
--
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/
[PATCH 5/6] ARM:Gemini:use timer 1 as clockevent timer
This patch is based on openwrt patch found in
target/linux/gemini/patches-3.18/160-gemini-timers.patch
It removes usage of timer 2 as clockevent timer and uses
timer 1.
Also setup the needed register for interrupt handling missed in
the initial patch
Signed-off-by: Hans Ulli Kroll
---
arch/arm/mach-gemini/time.c | 106 ++--
1 file changed, 62 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c
index e919b96..29ec2c3 100644
--- a/arch/arm/mach-gemini/time.c
+++ b/arch/arm/mach-gemini/time.c
@@ -63,19 +63,11 @@ static int gemini_timer_set_next_event(unsigned long cycles,
{
u32 cr;
- cr = readl(TIMER_CR);
-
- /* This may be overdoing it, feel free to test without this */
- cr &= ~TIMER_2_CR_ENABLE;
- cr &= ~TIMER_2_CR_INT;
- writel(cr, TIMER_CR);
-
- /* Set next event */
- writel(cycles, TIMER_COUNT(GEMINI_TIMER2_BASE));
- writel(cycles, TIMER_LOAD(GEMINI_TIMER2_BASE));
- cr |= TIMER_2_CR_ENABLE;
- cr |= TIMER_2_CR_INT;
- writel(cr, TIMER_CR);
+ /* Setup the match register */
+ cr = readl(TIMER_COUNT(GEMINI_TIMER1_BASE));
+ writel(cr + cycles, TIMER_MATCH1(GEMINI_TIMER1_BASE));
+ if (readl(TIMER_COUNT(GEMINI_TIMER1_BASE)) - cr > cycles)
+ return -ETIME;
return 0;
}
@@ -87,32 +79,55 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
u32 cr;
switch (mode) {
-case CLOCK_EVT_MODE_PERIODIC:
- /* Start the timer */
- writel(period,
- TIMER_COUNT(GEMINI_TIMER2_BASE));
- writel(period,
- TIMER_LOAD(GEMINI_TIMER2_BASE));
+ case CLOCK_EVT_MODE_PERIODIC:
+ /* Stop timer and interrupt. */
+ cr = readl(TIMER_CR);
+ cr &= ~(TIMER_1_CR_ENABLE | TIMER_1_CR_INT);
+ writel(cr, TIMER_CR);
+
+ /* Setup timer to fire at 1/HZ intervals. */
+ cr = 0x - (period - 1);
+ writel(cr, TIMER_COUNT(GEMINI_TIMER1_BASE));
+ writel(cr, TIMER_LOAD(GEMINI_TIMER1_BASE));
+
+ /* enable interrupt on overflaw */
+ cr = readl(TIMER_INTR_MASK);
+ cr &= ~(TIMER_1_INT_MATCH1 | TIMER_1_INT_MATCH2);
+ cr |= TIMER_1_INT_OVERFLOW;
+ writel(cr, TIMER_INTR_MASK);
+
+ /* start the timer */
cr = readl(TIMER_CR);
- cr |= TIMER_2_CR_ENABLE;
- cr |= TIMER_2_CR_INT;
+ cr |= TIMER_1_CR_ENABLE | TIMER_1_CR_INT;
writel(cr, TIMER_CR);
break;
+
case CLOCK_EVT_MODE_ONESHOT:
case CLOCK_EVT_MODE_UNUSED:
-case CLOCK_EVT_MODE_SHUTDOWN:
- case CLOCK_EVT_MODE_RESUME:
- /*
-* Disable also for oneshot: the set_next() call will
-* arm the timer instead.
-*/
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ /* Stop timer and interrupt. */
+ cr = readl(TIMER_CR);
+ cr &= ~(TIMER_1_CR_ENABLE | TIMER_1_CR_INT);
+ writel(cr, TIMER_CR);
+
+ /* Setup counter start from 0 */
+ writel(0, TIMER_COUNT(GEMINI_TIMER1_BASE));
+ writel(0, TIMER_LOAD(GEMINI_TIMER1_BASE));
+
+ /* enable interrupt */
+ cr = readl(TIMER_INTR_MASK);
+ cr &= ~(TIMER_1_INT_OVERFLOW | TIMER_1_INT_MATCH2);
+ cr |= TIMER_1_INT_MATCH1;
+ writel(cr, TIMER_INTR_MASK);
+
+ /* start the timer */
cr = readl(TIMER_CR);
- cr &= ~TIMER_2_CR_ENABLE;
- cr &= ~TIMER_2_CR_INT;
+ cr |= TIMER_1_CR_ENABLE;
writel(cr, TIMER_CR);
break;
- default:
-break;
+
+ case CLOCK_EVT_MODE_RESUME:
+ break;
}
}
@@ -120,6 +135,7 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
static struct clock_event_device gemini_clockevent = {
.name = "TIMER2",
.rating = 300, /* Reasonably fast and accurate clock event */
+ .shift = 32,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.set_next_event = gemini_timer_set_next_event,
.set_mode = gemini_timer_set_mode,
@@ -172,20 +188,22 @@ void __init gemini_timer_init(void)
}
/*
-* Make irqs happen for the system timer
+* Reset the interrupt mask and status
+*/
+ writel(TIMER_INT_ALL_MASK, TIMER_INTR_MASK);
+ writel(0, TIMER_INTR_STATE);
+ writel(TIMER_1_CR_UPDOWN | TIMER_3_CR_ENABLE | TIMER_3_CR_UPDOWN,
+ TIMER_CR);
+
+ /*
+* Setup clockevent timer (interrupt-driven.)
*/
ARM:Gemini:fix/update timer clocksource
This patchset fixexs this and do some cosmetic cleanup in the clocksource driver for mach-gemini. timer1 is used for clockevent timer3 for free running timer, scheduler clock source. The work is based on a patch found on openwrt.org in target/linux/gemini/patches-3.18/160-gemini-timers.patch Hans Ulli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] ARM:Gemini:add timer3 as sched_clock_source
This patch is based on openwrt patch found in
target/linux/gemini/patches-3.18/160-gemini-timers.patch
It setups a free running timer (timer3) for scheduler clock
Signed-off-by: Hans Ulli Kroll
---
arch/arm/mach-gemini/time.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c
index 29ec2c3..e419dd4 100644
--- a/arch/arm/mach-gemini/time.c
+++ b/arch/arm/mach-gemini/time.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+
/*
* Register definitions for the timers
@@ -58,6 +60,11 @@
static unsigned int tick_rate;
+static u64 notrace gemini_read_sched_clock(void)
+{
+ return readl(TIMER_COUNT(GEMINI_TIMER3_BASE));
+}
+
static int gemini_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
@@ -196,6 +203,19 @@ void __init gemini_timer_init(void)
TIMER_CR);
/*
+* Setup free-running clocksource timer (interrupts
+* disabled.)
+*/
+ writel(0, TIMER_COUNT(GEMINI_TIMER3_BASE));
+ writel(0, TIMER_LOAD(GEMINI_TIMER3_BASE));
+ writel(0, TIMER_MATCH1(GEMINI_TIMER3_BASE));
+ writel(0, TIMER_MATCH2(GEMINI_TIMER3_BASE));
+ clocksource_mmio_init(TIMER_COUNT(GEMINI_TIMER3_BASE),
+ "gemini_clocksource", tick_rate,
+ 300, 32, clocksource_mmio_readl_up);
+ sched_clock_register(gemini_read_sched_clock, 32, tick_rate);
+
+ /*
* Setup clockevent timer (interrupt-driven.)
*/
writel(0, TIMER_COUNT(GEMINI_TIMER1_BASE));
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ARM:Gemini:move IOADDRESS() into #define's
For better code readability move IO_ADDRESS() into register definitions
Signed-off-by: Hans Ulli Kroll
---
arch/arm/mach-gemini/time.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c
index d0bbd2f..76e3ca7 100644
--- a/arch/arm/mach-gemini/time.c
+++ b/arch/arm/mach-gemini/time.c
@@ -23,11 +23,11 @@
#define GEMINI_TIMER2_BASE (GEMINI_TIMER_BASE + 0x10)
#define GEMINI_TIMER3_BASE (GEMINI_TIMER_BASE + 0x20)
-#define TIMER_COUNT(BASE_ADDR) (BASE_ADDR + 0x00)
-#define TIMER_LOAD(BASE_ADDR) (BASE_ADDR + 0x04)
-#define TIMER_MATCH1(BASE_ADDR)(BASE_ADDR + 0x08)
-#define TIMER_MATCH2(BASE_ADDR)(BASE_ADDR + 0x0C)
-#define TIMER_CR(BASE_ADDR)(BASE_ADDR + 0x30)
+#define TIMER_COUNT(BASE_ADDR) (IO_ADDRESS(BASE_ADDR) + 0x00)
+#define TIMER_LOAD(BASE_ADDR) (IO_ADDRESS(BASE_ADDR) + 0x04)
+#define TIMER_MATCH1(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x08)
+#define TIMER_MATCH2(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x0C)
+#define TIMER_CR(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x30)
#define TIMER_1_CR_ENABLE (1 << 0)
#define TIMER_1_CR_CLOCK (1 << 1)
@@ -46,19 +46,19 @@ static int gemini_timer_set_next_event(unsigned long cycles,
{
u32 cr;
- cr = readl(TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
/* This may be overdoing it, feel free to test without this */
cr &= ~TIMER_2_CR_ENABLE;
cr &= ~TIMER_2_CR_INT;
- writel(cr, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
/* Set next event */
- writel(cycles, TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER2_BASE)));
- writel(cycles, TIMER_LOAD(IO_ADDRESS(GEMINI_TIMER2_BASE)));
+ writel(cycles, TIMER_COUNT(GEMINI_TIMER2_BASE));
+ writel(cycles, TIMER_LOAD(GEMINI_TIMER2_BASE));
cr |= TIMER_2_CR_ENABLE;
cr |= TIMER_2_CR_INT;
- writel(cr, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
return 0;
}
@@ -73,13 +73,13 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
case CLOCK_EVT_MODE_PERIODIC:
/* Start the timer */
writel(period,
- TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER2_BASE)));
+ TIMER_COUNT(GEMINI_TIMER2_BASE));
writel(period,
- TIMER_LOAD(IO_ADDRESS(GEMINI_TIMER2_BASE)));
- cr = readl(TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ TIMER_LOAD(GEMINI_TIMER2_BASE));
+ cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
cr |= TIMER_2_CR_ENABLE;
cr |= TIMER_2_CR_INT;
- writel(cr, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
break;
case CLOCK_EVT_MODE_ONESHOT:
case CLOCK_EVT_MODE_UNUSED:
@@ -89,10 +89,10 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
* Disable also for oneshot: the set_next() call will
* arm the timer instead.
*/
- cr = readl(TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
cr &= ~TIMER_2_CR_ENABLE;
cr &= ~TIMER_2_CR_INT;
- writel(cr, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
+ writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
break;
default:
break;
@@ -160,10 +160,10 @@ void __init gemini_timer_init(void)
setup_irq(IRQ_TIMER2, _timer_irq);
/* Enable and use TIMER1 as clock source */
- writel(0x, TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER1_BASE)));
- writel(0x, TIMER_LOAD(IO_ADDRESS(GEMINI_TIMER1_BASE)));
- writel(TIMER_1_CR_ENABLE, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE)));
- if (clocksource_mmio_init(TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER1_BASE)),
+ writel(0x, TIMER_COUNT(GEMINI_TIMER1_BASE));
+ writel(0x, TIMER_LOAD(GEMINI_TIMER1_BASE));
+ writel(TIMER_1_CR_ENABLE, TIMER_CR(GEMINI_TIMER_BASE));
+ if (clocksource_mmio_init(TIMER_COUNT(GEMINI_TIMER1_BASE),
"TIMER1", tick_rate, 300, 32,
clocksource_mmio_readl_up))
pr_err("timer: failed to initialize gemini clock source\n");
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ARM:Gemini:add missing intr state and mask register
For earch timer function we have intr state and mask register. Add control bits up/down counting for each timer Signed-off-by: Hans Ulli Kroll --- arch/arm/mach-gemini/time.c | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c index 76e3ca7..a8604a3 100644 --- a/arch/arm/mach-gemini/time.c +++ b/arch/arm/mach-gemini/time.c @@ -28,6 +28,8 @@ #define TIMER_MATCH1(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x08) #define TIMER_MATCH2(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x0C) #define TIMER_CR(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x30) +#define TIMER_INTR_STATE (IO_ADDRESS(GEMINI_TIMER_BASE) + 0x34) +#define TIMER_INTR_MASK(IO_ADDRESS(GEMINI_TIMER_BASE) + 0x38) #define TIMER_1_CR_ENABLE (1 << 0) #define TIMER_1_CR_CLOCK (1 << 1) @@ -38,6 +40,21 @@ #define TIMER_3_CR_ENABLE (1 << 6) #define TIMER_3_CR_CLOCK (1 << 7) #define TIMER_3_CR_INT (1 << 8) +#define TIMER_1_CR_UPDOWN (1 << 9) +#define TIMER_2_CR_UPDOWN (1 << 10) +#define TIMER_3_CR_UPDOWN (1 << 11) + +#define TIMER_1_INT_MATCH1 (1 << 0) +#define TIMER_1_INT_MATCH2 (1 << 1) +#define TIMER_1_INT_OVERFLOW (1 << 2) +#define TIMER_2_INT_MATCH1 (1 << 3) +#define TIMER_2_INT_MATCH2 (1 << 4) +#define TIMER_2_INT_OVERFLOW (1 << 5) +#define TIMER_3_INT_MATCH1 (1 << 6) +#define TIMER_3_INT_MATCH2 (1 << 7) +#define TIMER_3_INT_OVERFLOW (1 << 8) +#define TIMER_INT_ALL_MASK 0x1ff + static unsigned int tick_rate; -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ARM:Gemini:move timer register definitions into the right place
We need the offset for the timer registers in driver only. So move this out of hardware.h Signed-off-by: Hans Ulli Kroll --- arch/arm/mach-gemini/include/mach/hardware.h | 3 --- arch/arm/mach-gemini/time.c | 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-gemini/include/mach/hardware.h b/arch/arm/mach-gemini/include/mach/hardware.h index 98e7b0f..f0390f1 100644 --- a/arch/arm/mach-gemini/include/mach/hardware.h +++ b/arch/arm/mach-gemini/include/mach/hardware.h @@ -57,9 +57,6 @@ #define GEMINI_USB1_BASE 0x6900 #define GEMINI_BIG_ENDIAN_BASE 0x8000 -#define GEMINI_TIMER1_BASE GEMINI_TIMER_BASE -#define GEMINI_TIMER2_BASE (GEMINI_TIMER_BASE + 0x10) -#define GEMINI_TIMER3_BASE (GEMINI_TIMER_BASE + 0x20) /* * UART Clock when System clk is 150MHz diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c index 0a63c4d2..d0bbd2f 100644 --- a/arch/arm/mach-gemini/time.c +++ b/arch/arm/mach-gemini/time.c @@ -19,6 +19,10 @@ /* * Register definitions for the timers */ +#define GEMINI_TIMER1_BASE GEMINI_TIMER_BASE +#define GEMINI_TIMER2_BASE (GEMINI_TIMER_BASE + 0x10) +#define GEMINI_TIMER3_BASE (GEMINI_TIMER_BASE + 0x20) + #define TIMER_COUNT(BASE_ADDR) (BASE_ADDR + 0x00) #define TIMER_LOAD(BASE_ADDR) (BASE_ADDR + 0x04) #define TIMER_MATCH1(BASE_ADDR)(BASE_ADDR + 0x08) -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ARM:Gemini:remove index for timer control register
The TIMER_CR register control all three timer. No need for a index.
Signed-off-by: Hans Ulli Kroll
---
arch/arm/mach-gemini/time.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-gemini/time.c b/arch/arm/mach-gemini/time.c
index a8604a3..e919b96 100644
--- a/arch/arm/mach-gemini/time.c
+++ b/arch/arm/mach-gemini/time.c
@@ -27,7 +27,7 @@
#define TIMER_LOAD(BASE_ADDR) (IO_ADDRESS(BASE_ADDR) + 0x04)
#define TIMER_MATCH1(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x08)
#define TIMER_MATCH2(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x0C)
-#define TIMER_CR(BASE_ADDR)(IO_ADDRESS(BASE_ADDR) + 0x30)
+#define TIMER_CR (IO_ADDRESS(GEMINI_TIMER_BASE) + 0x30)
#define TIMER_INTR_STATE (IO_ADDRESS(GEMINI_TIMER_BASE) + 0x34)
#define TIMER_INTR_MASK(IO_ADDRESS(GEMINI_TIMER_BASE)
+ 0x38)
@@ -63,19 +63,19 @@ static int gemini_timer_set_next_event(unsigned long cycles,
{
u32 cr;
- cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
+ cr = readl(TIMER_CR);
/* This may be overdoing it, feel free to test without this */
cr &= ~TIMER_2_CR_ENABLE;
cr &= ~TIMER_2_CR_INT;
- writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
+ writel(cr, TIMER_CR);
/* Set next event */
writel(cycles, TIMER_COUNT(GEMINI_TIMER2_BASE));
writel(cycles, TIMER_LOAD(GEMINI_TIMER2_BASE));
cr |= TIMER_2_CR_ENABLE;
cr |= TIMER_2_CR_INT;
- writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
+ writel(cr, TIMER_CR);
return 0;
}
@@ -93,10 +93,10 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
TIMER_COUNT(GEMINI_TIMER2_BASE));
writel(period,
TIMER_LOAD(GEMINI_TIMER2_BASE));
- cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
+ cr = readl(TIMER_CR);
cr |= TIMER_2_CR_ENABLE;
cr |= TIMER_2_CR_INT;
- writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
+ writel(cr, TIMER_CR);
break;
case CLOCK_EVT_MODE_ONESHOT:
case CLOCK_EVT_MODE_UNUSED:
@@ -106,10 +106,10 @@ static void gemini_timer_set_mode(enum clock_event_mode
mode,
* Disable also for oneshot: the set_next() call will
* arm the timer instead.
*/
- cr = readl(TIMER_CR(GEMINI_TIMER_BASE));
+ cr = readl(TIMER_CR);
cr &= ~TIMER_2_CR_ENABLE;
cr &= ~TIMER_2_CR_INT;
- writel(cr, TIMER_CR(GEMINI_TIMER_BASE));
+ writel(cr, TIMER_CR);
break;
default:
break;
@@ -179,7 +179,7 @@ void __init gemini_timer_init(void)
/* Enable and use TIMER1 as clock source */
writel(0x, TIMER_COUNT(GEMINI_TIMER1_BASE));
writel(0x, TIMER_LOAD(GEMINI_TIMER1_BASE));
- writel(TIMER_1_CR_ENABLE, TIMER_CR(GEMINI_TIMER_BASE));
+ writel(TIMER_1_CR_ENABLE, TIMER_CR);
if (clocksource_mmio_init(TIMER_COUNT(GEMINI_TIMER1_BASE),
"TIMER1", tick_rate, 300, 32,
clocksource_mmio_readl_up))
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock
On Sat, Jun 6, 2015 at 2:50 AM, Jeffrey Hugo wrote: > If you still wish to scope out a capability based alternative, would you > please provide some details about how you envision it working? An example > of the API, how it would be used, future usecases that might be covered by > it, etc. That would give us specifics we can discuss and weigh the merits > of. How about: - add a 'hwcaps' member to hwspinlock_device, and define single cap called HWL_CAP_ALLOW_RAW - add new 'hwcaps' parameter to hwspin_lock_register - omap_hwspinlock.c will pass NULL, qcom_hwspinlock will pass HWL_CAP_ALLOW_RAW - hwspin_lock_register will set hwcaps accordingly - before a lock is taken in RAW mode, the capabilities are checked - document everything nicely Unless I'm missing something, it should take 5 minutes or less. For reference, feel free to check out mmc_host's caps member and its usage. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] crypto: use list to stage async seeding requests
This patch uses a list to track the asynchronous seeding requests until
the nonblocking pool is fully initialized. The random.c is provided with
two API calls: the get_blocking_random_bytes_cb allows the caller to
provide a callback function that is triggered once the nonblocking pool
is initialized. If the nonblocking pool is already initialized at the
time of invocation, the function is a noop. The second API call of
get_blocking_random_bytes_cancel allows the caller to cancel an
outstanding request.
The previous approach used a waitqueue for maintaining the requests
until the nonblocking pool is initialized. In some circumstances, the
wait can be very long (in the orders of minutes) where the use of
waitqueues is not appropriate.
The patch also removes the entropy buffer registered with the DRBG
handle in favor of stack variables to hold the seed data.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 112 -
drivers/char/random.c | 99 +++
include/crypto/drbg.h | 4 --
include/linux/random.h | 4 +-
4 files changed, 149 insertions(+), 70 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 04836b4..7339cc5 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,25 +1056,31 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
-static void drbg_async_seed(struct work_struct *work)
+static void drbg_async_seed(void *private)
{
struct drbg_string data;
LIST_HEAD(seedlist);
- struct drbg_state *drbg = container_of(work, struct drbg_state,
- seed_work);
- int ret;
+ struct drbg_state *drbg = (struct drbg_state *)private;
+ unsigned char entropy[32];
+ size_t entropylen = drbg_sec_strength(drbg->core->flags);
+ int ret = 0;
- get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ BUG_ON(!entropylen);
+ BUG_ON(entropylen > sizeof(entropy));
+ get_random_bytes(entropy, entropylen);
- drbg_string_fill(, drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(, entropy, entropylen);
list_add_tail(, );
+
mutex_lock(>drbg_mutex);
ret = __drbg_seed(drbg, , true);
+
+ /* If nonblocking pool is initialized, deactivate Jitter RNG */
if (!ret && drbg->jent) {
crypto_free_rng(drbg->jent);
drbg->jent = NULL;
}
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(entropy, entropylen);
mutex_unlock(>drbg_mutex);
}
@@ -1093,6 +1099,8 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
+ unsigned char entropy[((32 + 16) * 2)];
+ size_t entropylen = drbg_sec_strength(drbg->core->flags);
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1108,23 +1116,51 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must be at least 1/2 of the security
+* strength of the DRBG in size. Thus, entropy + nonce is 3/2
+* of the strength. The consideration of a nonce is only
+* applicable during initial seeding.
+*/
+ BUG_ON(!entropylen);
+ if (!reseed)
+ entropylen = ((entropylen + 1) / 2) * 3;
+ BUG_ON((entropylen * 2) > sizeof(entropy));
+
+ /*
+* Trigger async seeding: This function may not trigger the
+* async callback in case the nonblocking is filled. To avoid
+* a race between get_random_bytes operating on a not yet
+* initialized nonblocking pool and get_blocking_random_bytes_cb
+* already operating on an initialized nonblocking pool and thus
+* not calling the async callback, invoke the async trigger
+* before get_random_bytes.
+*/
+ ret = get_blocking_random_bytes_cb(drbg, drbg_async_seed);
+
/* Get seed from in-kernel /dev/urandom */
- get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ get_random_bytes(entropy, entropylen);
/* Get seed from Jitter RNG */
if (!drbg->jent ||
crypto_rng_get_bytes(drbg->jent,
-drbg->seed_buf + drbg->seed_buf_len,
-
Re: [PATCH] block, cgroup: implement policy-specific per-blkcg data
Hello, On Fri, Jun 05, 2015 at 11:38:42PM +0200, Arianna Avanzini wrote: > The block IO (blkio) controller enables the block layer to provide service > guarantees in a hierarchical fashion. Specifically, service guarantees > are provided by registered request-accounting policies. As of now, a > proportional-share and a throttling policy are available. They are > implemented, respectively, by the CFQ I/O scheduler and the blk-throttle > subsystem. Unfortunately, as for adding new policies, the current > implementation of the block IO controller is only halfway ready to allow > new policies to be plugged in. This commit provides a solution to make > the block IO controller fully ready to handle new policies. > In what follows, we first describe briefly the current state, and then > list the changes made by this commit. > > The throttling policy does not need any per-cgroup information to perform > its task. In contrast, the proportional share policy uses, for each cgroup, > both the weight assigned by the user to the cgroup, and a set of dynamically- > computed weights, one for each device. > > The first, user-defined weight is stored in the blkcg data structure: the > block IO controller allocates a private blkcg data structure for each > cgroup in the blkio cgroups hierarchy (regardless of which policy is active). > In other words, the block IO controller internally mirrors the blkio cgroups > with private blkcg data structures. > > On the other hand, for each cgroup and device, the corresponding dynamically- > computed weight is maintained in the following, different way. For each > device, > the block IO controller keeps a private blkcg_gq structure for each cgroup in > blkio. In other words, block IO also keeps one private mirror copy of the > blkio > cgroups hierarchy for each device, made of blkcg_gq structures. > Each blkcg_gq structure keeps per-policy information in a generic array of > dynamically-allocated 'dedicated' data structures, one for each registered > policy (so currently the array contains two elements). To be inserted into the > generic array, each dedicated data structure embeds a generic blkg_policy_data > structure. Consider now the array contained in the blkcg_gq structure > corresponding to a given pair of cgroup and device: one of the elements > of the array contains the dedicated data structure for the proportional-share > policy, and this dedicated data structure contains the dynamically-computed > weight for that pair of cgroup and device. > > The generic strategy adopted for storing per-policy data in blkcg_gq > structures > is already capable of handling new policies, whereas the one adopted with > blkcg > structures is not, because per-policy data are hard-coded in the blkcg > structures themselves (currently only data related to the proportional- > share policy). > > This commit addresses the above issues through the following changes: > . It generalizes blkcg structures so that per-policy data are stored in the > same > way as in blkcg_gq structures. > Specifically, it lets also the blkcg structure store per-policy data in a > generic array of dynamically-allocated dedicated data structures. We will > refer to these data structures as blkcg dedicated data structures, to > distinguish them from the dedicated data structures inserted in the generic > arrays kept by blkcg_gq structures. > To allow blkcg dedicated data structures to be inserted in the generic array > inside a blkcg structure, this commit also introduces a new > blkcg_policy_data > structure, which is the equivalent of blkg_policy_data for blkcg dedicated > data structures. > . It adds to the blkcg_policy structure, i.e., to the descriptor of a policy, > a > cpd_size field and a cpd_init field, to be initialized by the policy with, > respectively, the size of the blkcg dedicated data structures, and the > address of a constructor function for blkcg dedicated data structures. > . It moves the CFQ-specific fields embedded in the blkcg data structure (i.e., > the fields related to the proportional-share policy), into a new blkcg > dedicated data structure called cfq_group_data. > > Signed-off-by: Paolo Valente > Signed-off-by: Arianna Avanzini > Cc: Tejun Heo > Cc: Jens Axboe Acked-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] s5k5baf: Convert use of __constant_cpu_to_be16 to cpu_to_be16
In little endian cases, macro cpu_to_be16 unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_cpu_to_be16 and cpu_to_be16 expand directly to the
same expression. So, replace __constant_cpu_to_be16 with
cpu_to_be16 with the goal of getting rid of the definition of
__constant_cpu_to_be16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_be16(x)
+ cpu_to_be16(x)
Signed-off-by: Vaishali Thakkar
---
drivers/media/i2c/s5k5baf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index 297ef04..7a43b55 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -491,7 +491,7 @@ static void s5k5baf_write_arr_seq(struct s5k5baf *state,
u16 addr,
v4l2_dbg(3, debug, c, "i2c_write_seq(count=%d): %*ph\n", count,
min(2 * count, 64), seq);
- buf[0] = __constant_cpu_to_be16(REG_CMD_BUF);
+ buf[0] = cpu_to_be16(REG_CMD_BUF);
while (count > 0) {
int n = min_t(int, count, ARRAY_SIZE(buf) - 1);
--
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/
[PATCH v2 1/3] watchdog_core: Add watchdog registration deferral mechanism
Currently, watchdog subsystem require the misc subsystem to
register a watchdog. This may not be the case in case of an
early registration of a watchdog, which can be required when
the watchdog cannot be disabled.
This patch use deferral mechanism to remove this requirement.
Signed-off-by: Jean-Baptiste Theou
---
drivers/watchdog/watchdog_core.c | 92 ++--
include/linux/watchdog.h | 3 ++
2 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index cec9b55..edf6294 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -43,6 +43,41 @@
static DEFINE_IDA(watchdog_ida);
static struct class *watchdog_class;
+/*
+ * Deferred Registration infrastructure.
+ *
+ * Sometimes watchdog drivers need to be loaded as soon as possible,
+ * for example when it's impossible to disable it. To do so,
+ * raising the initcall level of the watchdog driver is a solution.
+ * But in such case, the miscdev is maybe not ready (subsys_initcall), and
+ * watchdog core need miscdev to be populate.
+ *
+ * The deferred registration infrastructure offer a way for the watchdog
+ * subsystem to register a watchdog properly, even before miscdev is ready
+ *
+ * This is based on driver probe deferral mechanism.
+ */
+
+static DEFINE_MUTEX(watchdog_deferred_registration_mutex);
+static LIST_HEAD(watchdog_deferred_registration_pending_list);
+static bool watchdog_deferred_registration_done;
+
+static int watchdog_deferred_registration_add(struct watchdog_device *wdd)
+{
+ dev_dbg(wdd->dev, "Added to deferred list\n");
+ list_add(>deferred_registration,
+_deferred_registration_pending_list);
+ return 0;
+}
+
+static void watchdog_deferred_registration_del(struct watchdog_device *wdd)
+{
+ if (!list_empty(>deferred_registration)) {
+ dev_dbg(wdd->dev, "Removed from deferred list\n");
+ list_del_init(>deferred_registration);
+ }
+}
+
static void watchdog_check_min_max_timeout(struct watchdog_device *wdd)
{
/*
@@ -99,7 +134,7 @@ int watchdog_init_timeout(struct watchdog_device *wdd,
EXPORT_SYMBOL_GPL(watchdog_init_timeout);
/**
- * watchdog_register_device() - register a watchdog device
+ * __watchdog_register_device() - register a watchdog device
* @wdd: watchdog device
*
* Register a watchdog device with the kernel so that the
@@ -108,7 +143,7 @@ EXPORT_SYMBOL_GPL(watchdog_init_timeout);
* A zero is returned on success and a negative errno code for
* failure.
*/
-int watchdog_register_device(struct watchdog_device *wdd)
+int __watchdog_register_device(struct watchdog_device *wdd)
{
int ret, id, devno;
@@ -164,16 +199,35 @@ int watchdog_register_device(struct watchdog_device *wdd)
return 0;
}
+
+/*
+ * watchdog_register_device use either the deferred approach,
+ * or directly register the watchdog, depending on the current
+ * initcall level.
+ */
+
+int watchdog_register_device(struct watchdog_device *wdd)
+{
+ int ret;
+
+ mutex_lock(_deferred_registration_mutex);
+ if (watchdog_deferred_registration_done)
+ ret = __watchdog_register_device(wdd);
+ else
+ ret = watchdog_deferred_registration_add(wdd);
+ mutex_unlock(_deferred_registration_mutex);
+ return ret;
+}
EXPORT_SYMBOL_GPL(watchdog_register_device);
/**
- * watchdog_unregister_device() - unregister a watchdog device
+ * __watchdog_unregister_device() - unregister a watchdog device
* @wdd: watchdog device to unregister
*
* Unregister a watchdog device that was previously successfully
* registered with watchdog_register_device().
*/
-void watchdog_unregister_device(struct watchdog_device *wdd)
+void __watchdog_unregister_device(struct watchdog_device *wdd)
{
int ret;
int devno;
@@ -189,8 +243,37 @@ void watchdog_unregister_device(struct watchdog_device
*wdd)
ida_simple_remove(_ida, wdd->id);
wdd->dev = NULL;
}
+
+void watchdog_unregister_device(struct watchdog_device *wdd)
+{
+ mutex_lock(_deferred_registration_mutex);
+ if (watchdog_deferred_registration_done)
+ __watchdog_unregister_device(wdd);
+ else
+ watchdog_deferred_registration_del(wdd);
+ mutex_unlock(_deferred_registration_mutex);
+}
+
EXPORT_SYMBOL_GPL(watchdog_unregister_device);
+/**
+ * watchdog_deferred_registration_initcall() - Register queued watchdog
+ */
+static int watchdog_deferred_registration_initcall(void)
+{
+ mutex_lock(_deferred_registration_mutex);
+ watchdog_deferred_registration_done = true;
+ while (!list_empty(_deferred_registration_pending_list)) {
+ struct watchdog_device *wdd =
list_first_entry(_deferred_registration_pending_list,
+ struct
watchdog_device,
[PATCH v2 3/3] gpio_wdt: Add option for early registration
In some situation, mainly when it's not possible to disable a
watchdog, you may want the watchdog driver to be started as soon
as possible.
Adding GPIO_WATCHDOG_ARCH_INITCALL to raise initcall from
module_init to arch_initcall. This is only for a built-in
module.
This patch require watchdog registration deferral mechanism
Signed-off-by: Jean-Baptiste Theou
---
drivers/watchdog/Kconfig| 14 ++
drivers/watchdog/gpio_wdt.c | 13 +
2 files changed, 27 insertions(+)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5e7c55..a9655a9 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1,3 +1,4 @@
+
#
# Watchdog device configuration
#
@@ -114,6 +115,19 @@ config MENF21BMC_WATCHDOG
This driver can also be built as a module. If so the module
will be called menf21bmc_wdt.
+config GPIO_WATCHDOG_ARCH_INITCALL
+ bool "Register the watchdog as early as possible"
+ depends on GPIO_WATCHDOG
+ help
+ This option make sense only on a built-in situation.
+
+ In some situation, the default initcall level (module_init)
+ in not early enough on the boot process to avoid the watchdog
+ to be trigger.
+ If you say yes here, the initcall level would be raise to
+ arch_initcall.
+ "If in doubt, leave it out" - say N.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index cbc313d..07a39cd 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -267,8 +267,21 @@ static struct platform_driver gpio_wdt_driver = {
.probe = gpio_wdt_probe,
.remove = gpio_wdt_remove,
};
+#ifndef GPIO_WATCHDOG_ARCH_INITCALL
module_platform_driver(gpio_wdt_driver);
+#else
+static int __init gpio_wdt_init(void)
+{
+ return platform_driver_register(_wdt_driver);
+}
+arch_initcall(gpio_wdt_init);
+static void __exit gpio_wdt_exit(void)
+{
+ platform_driver_unregister(_wdt_driver);
+}
+module_exit(gpio_wdt_exit);
+#endif
MODULE_AUTHOR("Alexander Shiyan ");
MODULE_DESCRIPTION("GPIO Watchdog");
MODULE_LICENSE("GPL");
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] watchdog-kernel-api: Add registration deferral mechanism
Add registration deferral mechanism capability information
Signed-off-by: Jean-Baptiste Theou
---
Documentation/watchdog/watchdog-kernel-api.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index a0438f3..11c988b 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -36,6 +36,10 @@ The watchdog_unregister_device routine deregisters a
registered watchdog timer
device. The parameter of this routine is the pointer to the registered
watchdog_device structure.
+The watchdog subsystem contain an registration deferral mechanism,
+which allow you to register an watchdog as early as you wish during
+the boot process, in the situation of a built-in module.
+
The watchdog device structure looks like this:
struct watchdog_device {
--
2.4.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 v2 5/5] clk: qcom: Add MSM8916 audio clocks
On 06/05, Georgi Djakov wrote:
> @@ -190,6 +193,76 @@ static const char *gcc_xo_gpll0a_gpll1_gpll2[] = {
> "gpll2_vote",
> };
>
> +static const struct parent_map gcc_xo_gpll0_gpll1_sleep_map[] = {
> + { P_XO, 0 },
> + { P_GPLL0, 1 },
> + { P_GPLL1, 2 },
> + { P_SLEEP_CLK, 6 }
> +};
> +
> +static const char *gcc_xo_gpll0_gpll1_sleep[] = {
Please make these new ones const char * const now that we've
fixed that problem in the clk framework
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] clk: qcom: Add support for RCGs with shared branches
On 06/05, Georgi Djakov wrote:
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index cb17fd4b193f..60563adad21d 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -47,6 +47,8 @@
> #define N_REG0xc
> #define D_REG0x10
>
> +#define XO_FREQ 1920
Hm.. we don't know that XO is always going to be 19.2 MHz.
> +
> static int clk_rcg2_is_enabled(struct clk_hw *hw)
> {
> struct clk_rcg2 *rcg = to_clk_rcg2(hw);
> @@ -308,6 +310,68 @@ const struct clk_ops clk_rcg2_ro_ops = {
> };
> EXPORT_SYMBOL_GPL(clk_rcg2_ro_ops);
>
> +static int clk_rcg2_shared_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_rcg2 *rcg = to_clk_rcg2(hw);
> + const char *name = __clk_get_name(hw->clk);
> + int ret, count;
> + unsigned int cmd = CMD_ROOT_EN;
> +
> + /* force enable RCG */
> + ret = regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
> + cmd, cmd);
> + if (ret)
> + return ret;
> +
> + /* wait for RCG to turn ON */
> + for (count = 500; count > 0; count--) {
> + ret = clk_rcg2_is_enabled(hw);
> + if (ret)
> + break;
> + udelay(1);
> + }
> + if (!count)
> + pr_err("%s: RCG did not turn on\n", name);
> +
> + /* set clock rate */
> + ret = __clk_rcg2_set_rate(hw, rate);
> + if (ret)
> + return ret;
> +
> + /* clear force enable RCG */
> + ret = regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
> + cmd, ~cmd);
The last argument could just be 0, save an instruction.
> + if (ret)
> + return ret;
> +
> + return 0;
This function will become more complicated.
> +}
> +
> +static int clk_rcg2_shared_enable(struct clk_hw *hw)
> +{
> + unsigned long rate = __clk_get_rate(hw->clk);
> +
> + return clk_rcg2_shared_set_rate(hw, rate, 0);
And we shouldn't configure the clock to be at any rate besides XO
speed while the clock is off because the other processors may not
be requesting enough voltage to support the clock at whatever
rate we've chosen. So we need to make set_rate() into a caching
operation when the clock is disabled in software's view.
> +}
> +
> +static void clk_rcg2_shared_disable(struct clk_hw *hw)
> +{
> + /* switch to XO, which is always-on */
> + clk_rcg2_shared_set_rate(hw, XO_FREQ, 0);
Maybe here we should just "know" that the XO frequency is either
the lowest entry in the frequency table or that it's source 0 and
make up some fake frequency struct to pass around.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: gadget: Convert use of __constant_cpu_to_le16 to cpu_to_le16
In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar
---
drivers/usb/gadget/legacy/audio.c | 6 +++---
drivers/usb/gadget/legacy/dbgp.c | 10 +-
drivers/usb/gadget/legacy/gmidi.c | 6 +++---
drivers/usb/gadget/legacy/nokia.c | 6 +++---
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/legacy/audio.c
b/drivers/usb/gadget/legacy/audio.c
index f289caf..b8095bf 100644
--- a/drivers/usb/gadget/legacy/audio.c
+++ b/drivers/usb/gadget/legacy/audio.c
@@ -124,7 +124,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x200),
+ .bcdUSB = cpu_to_le16(0x200),
#ifdef CONFIG_GADGET_UAC1
.bDeviceClass = USB_CLASS_PER_INTERFACE,
@@ -141,8 +141,8 @@ static struct usb_device_descriptor device_desc = {
* we support. (As does bNumConfigurations.) These values can
* also be overridden by module parameters.
*/
- .idVendor = __constant_cpu_to_le16(AUDIO_VENDOR_NUM),
- .idProduct =__constant_cpu_to_le16(AUDIO_PRODUCT_NUM),
+ .idVendor = cpu_to_le16(AUDIO_VENDOR_NUM),
+ .idProduct =cpu_to_le16(AUDIO_PRODUCT_NUM),
/* .bcdDevice = f(hardware) */
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
diff --git a/drivers/usb/gadget/legacy/dbgp.c b/drivers/usb/gadget/legacy/dbgp.c
index 204b10b..5231a32 100644
--- a/drivers/usb/gadget/legacy/dbgp.c
+++ b/drivers/usb/gadget/legacy/dbgp.c
@@ -35,10 +35,10 @@ static struct dbgp {
static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x0200),
+ .bcdUSB = cpu_to_le16(0x0200),
.bDeviceClass = USB_CLASS_VENDOR_SPEC,
- .idVendor = __constant_cpu_to_le16(DRIVER_VENDOR_ID),
- .idProduct = __constant_cpu_to_le16(DRIVER_PRODUCT_ID),
+ .idVendor = cpu_to_le16(DRIVER_VENDOR_ID),
+ .idProduct = cpu_to_le16(DRIVER_PRODUCT_ID),
.bNumConfigurations = 1,
};
@@ -251,7 +251,7 @@ static int dbgp_configure_endpoints(struct usb_gadget
*gadget)
dbgp.i_ep->driver_data = gadget;
i_desc.wMaxPacketSize =
- __constant_cpu_to_le16(USB_DEBUG_MAX_PACKET_SIZE);
+ cpu_to_le16(USB_DEBUG_MAX_PACKET_SIZE);
dbgp.o_ep = usb_ep_autoconfig(gadget, _desc);
if (!dbgp.o_ep) {
@@ -262,7 +262,7 @@ static int dbgp_configure_endpoints(struct usb_gadget
*gadget)
dbgp.o_ep->driver_data = gadget;
o_desc.wMaxPacketSize =
- __constant_cpu_to_le16(USB_DEBUG_MAX_PACKET_SIZE);
+ cpu_to_le16(USB_DEBUG_MAX_PACKET_SIZE);
dbg_desc.bDebugInEndpoint = i_desc.bEndpointAddress;
dbg_desc.bDebugOutEndpoint = o_desc.bEndpointAddress;
diff --git a/drivers/usb/gadget/legacy/gmidi.c
b/drivers/usb/gadget/legacy/gmidi.c
index da19c48..650568d 100644
--- a/drivers/usb/gadget/legacy/gmidi.c
+++ b/drivers/usb/gadget/legacy/gmidi.c
@@ -88,10 +88,10 @@ MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
static struct usb_device_descriptor device_desc = {
.bLength = USB_DT_DEVICE_SIZE,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x0200),
+ .bcdUSB = cpu_to_le16(0x0200),
.bDeviceClass = USB_CLASS_PER_INTERFACE,
- .idVendor = __constant_cpu_to_le16(DRIVER_VENDOR_NUM),
- .idProduct =__constant_cpu_to_le16(DRIVER_PRODUCT_NUM),
+ .idVendor = cpu_to_le16(DRIVER_VENDOR_NUM),
+ .idProduct =cpu_to_le16(DRIVER_PRODUCT_NUM),
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
.bNumConfigurations = 1,
diff --git a/drivers/usb/gadget/legacy/nokia.c
b/drivers/usb/gadget/legacy/nokia.c
index 4bb498a..6757131 100644
--- a/drivers/usb/gadget/legacy/nokia.c
+++ b/drivers/usb/gadget/legacy/nokia.c
@@ -66,10 +66,10 @@ static struct usb_gadget_strings *dev_strings[] = {
static struct usb_device_descriptor device_desc = {
.bLength= USB_DT_DEVICE_SIZE,
.bDescriptorType= USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x0200),
+ .bcdUSB =
[GIT PULL] (swiotlb) stable/for-linus-4.1
Hey Linus, Please pull this tiny little fix (or if you prefer just delay till 4.2): git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git stable/for-linus-4.1 which just converts an function to be static. Really tiny. Alexandre Courbot (1): swiotlb: do not export map_single function lib/swiotlb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) pgpAmFE8k0MCB.pgp Description: PGP signature
[GIT PULL] (ibft) stable/for-linus-4.1 fixes
Hey Linus, One single fix from Chris to workaround UEFI platforms failing with iSCSI IBFT. Please pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft.git stable/for-linus-4.1 which has the following fix: Chris Leech (1): iscsi_ibft: filter null v4-mapped v6 addresses drivers/firmware/iscsi_ibft.c | 36 +--- 1 file changed, 21 insertions(+), 15 deletions(-) Thank you! pgpCWt213wOhf.pgp Description: PGP signature
Re: [PATCH] block: Make CFQ default to IOPS mode on SSDs
On 06/05/2015 04:58 PM, Tahsin Erdogan wrote: On Wed, May 27, 2015 at 1:14 PM, Tahsin Erdogan wrote: On Tue, May 19, 2015 at 1:55 PM, Tahsin Erdogan wrote: CFQ idling causes reduced IOPS throughput on non-rotational disks. Since disk head seeking is not applicable to SSDs, it doesn't really help performance by anticipating future near-by IO requests. By turning off idling (and switching to IOPS mode), we allow other processes to dispatch IO requests down to the driver and so increase IO throughput. Following FIO benchmark results were taken on a cloud SSD offering with idling on and off: Idling iopsavg-lat(ms)stddevbw -- On 705490.107 38.697 28217KB/s Off2925521.836 11.730117022KB/s fio --name=temp --size=100G --time_based --ioengine=libaio \ --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \ --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \ --filename=/dev/sdb --runtime=10 --iodepth=64 --numjobs=10 And the following is from a local SSD run: Idling iopsavg-lat(ms)stddevbw -- On1932033.043 14.068 77281KB/s Off2162629.465 12.662 86507KB/s fio --name=temp --size=5G --time_based --ioengine=libaio \ --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \ --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \ --filename=/fio_data --runtime=10 --iodepth=64 --numjobs=10 Reviewed-by: Nauman Rafique Signed-off-by: Tahsin Erdogan --- block/cfq-iosched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c index 5da8e6e..402be01 100644 --- a/block/cfq-iosched.c +++ b/block/cfq-iosched.c @@ -4460,7 +4460,7 @@ static int cfq_init_queue(struct request_queue *q, struct elevator_type *e) cfqd->cfq_slice[1] = cfq_slice_sync; cfqd->cfq_target_latency = cfq_target_latency; cfqd->cfq_slice_async_rq = cfq_slice_async_rq; - cfqd->cfq_slice_idle = cfq_slice_idle; + cfqd->cfq_slice_idle = blk_queue_nonrot(q) ? 0 : cfq_slice_idle; cfqd->cfq_group_idle = cfq_group_idle; cfqd->cfq_latency = 1; cfqd->hw_tag = -1; -- 2.2.0.rc0.207.ga3a616c Ping... Trying once more.. This one worked :-). I agree, it's probably the sane thing to do, I'll apply this for 4.2. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] clk: qcom: Add support for read-only rcg2 ops
On 06/05, Georgi Djakov wrote: > Some root clock generators can be controlled by other processors. In this > case modifying them is not recommended. By using the read-only operations, > the child clocks will be able to get information about their parent - like > rate etc. > > Suggested-by: Stephen Boyd > Signed-off-by: Georgi Djakov Do we actually need this? I think I wrote the clk ops for the RCG to make it skip doing anything if there isn't a frequency table. So to make a read-only RCG all we need to do is remove the frequency table? Sorry if I led you down the wrong path. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] isdn/hisax: Convert use of __constant_cpu_to_le16 to cpu_to_le16
In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar
---
drivers/isdn/hisax/st5481_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/st5481_usb.c b/drivers/isdn/hisax/st5481_usb.c
index ead0a4f..a0fdbc0 100644
--- a/drivers/isdn/hisax/st5481_usb.c
+++ b/drivers/isdn/hisax/st5481_usb.c
@@ -267,8 +267,8 @@ int st5481_setup_usb(struct st5481_adapter *adapter)
}
// The descriptor is wrong for some early samples of the ST5481 chip
- altsetting->endpoint[3].desc.wMaxPacketSize =
__constant_cpu_to_le16(32);
- altsetting->endpoint[4].desc.wMaxPacketSize =
__constant_cpu_to_le16(32);
+ altsetting->endpoint[3].desc.wMaxPacketSize = cpu_to_le16(32);
+ altsetting->endpoint[4].desc.wMaxPacketSize = cpu_to_le16(32);
// Use alternative setting 3 on interface 0 to have 2B+D
if ((status = usb_set_interface(dev, 0, 3)) < 0) {
--
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 v3 3/5] clk: add support for clocks provided by SCP(System Control Processor)
On 06/05, Sudeep Holla wrote:
>
>
> On 05/06/15 10:36, Sudeep Holla wrote:
> >
> >
> >On 04/06/15 21:20, Stephen Boyd wrote:
> >>On 05/27, Sudeep Holla wrote:
>
> [...]
>
> >>>+
> >>>+static unsigned long scpi_clk_recalc_rate(struct clk_hw *hw,
> >>>+unsigned long parent_rate)
> >>>+{
> >>>+ struct scpi_clk *clk = to_scpi_clk(hw);
> >>>+
> >>>+ return scpi_ops->clk_get_val(clk->id);
> >>>+}
> >>>+
> >>>+static long scpi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> >>>+ unsigned long *parent_rate)
> >>>+{
> >>>+ struct scpi_clk *clk = to_scpi_clk(hw);
> >>>+
> >>>+ if (WARN_ON(clk->rate_min && rate < clk->rate_min))
> >>>+ rate = clk->rate_min;
> >>>+ if (WARN_ON(clk->rate_max && rate > clk->rate_max))
> >>>+ rate = clk->rate_max;
> >>>+
> >>>+ return rate;
> >>>+}
> >>
> >>Hm.. this seems really generic. It might be better to support a
> >>way to tell the framework to limit the min/max rate that's
> >>accepted for a clk. That could be done later though.
> >>
> >
> >True, framework have some boundary checks in place. I will check if
> >I can use it with minimum changes to the core. If not, we can take this
> >up later as you suggested.
> >
>
> I found that the framework already provides clk_set_rate_range for this
> purpose. Sorry for missing this earlier(seems like that's added quite
> recently in v4.0). I think I still need to retain round_rate as the core
> framework insists.
Sure, or use determine_rate if you want to limit the min/max from
the clk provider itself.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 2/2] clk: socfpga: make use of of_clk_parent_fill helper function
On 06/05, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock's array. > > Signed-off-by: Dinh Nguyen > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv3 1/2] clk: of: helper for filling parent clock array and return num of parents
On 06/05, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Sprinkled all through the platform clock drivers are code like this to > fill the clock parent array: > > for (i = 0; i < num_parents; ++i) > parent_names[i] = of_clk_get_parent_name(np, i); > > The of_clk_parent_fill() will do the same as the code above, and while > at it, return the number of parents as well since the logic of the > function is to the walk the clock node to look for the parent. > > Signed-off-by: Dinh Nguyen > --- Applied to clk-next with some small kernel-doc fixes. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Add Mediatek MT8173 subsystem clocks support
On 06/05, James Liao wrote:
> Hi Stephen,
>
> On Thu, 2015-06-04 at 14:02 -0700, Stephen Boyd wrote:
> > On 05/29, Sascha Hauer wrote:
> > > Yes. I previously got the impression that the subsystem clocks are not
> > > directly associated to the larbs, but needed to be handled by the larb
> > > code due to some side effect. Now that I saw that the larbs are directly
> > > in the subsystem register space it all makes sense.
> > >
> > > Note that the way Mediatek SoCs are designed around sub modules is bit
> > > unusual and does not fit very well in the Linux directory structure.
> > > Normally SoCs have a single clocks controller which controls all clocks
> > > in the SoC. Then you often have a reset controller providing reset lines
> > > in the SoC. In this case it's clear that the clk driver goes to
> > > drivers/clk/, the reset controller driver to drivers/reset/. Mediatek
> > > SoCs instead have several blocks, each with its own clock and reset
> > > controller. Splitting each block up into parts in drivers/clk/ and
> > > drivers/reset/ leads to quite a code fragmentation.
> > > This is my opinion, it would be great to hear something from others.
> > > Matthias? I'd like to avoid running into a direction that is not
> > > acceptable in the end.
> >
> > We already have drivers registering clocks and resets under
> > drivers/clk, so it's not unheard of. An alternative solution is
> > to make child devices for the clock part and the reset part at
> > runtime in the toplevel driver for the vencsys device (don't do
> > any sort of DT description for this) and use regmap to mediate
> > the register accesses and locking. That way we can put the clk
> > driver in drivers/clk/, the reset driver in drivers/reset, etc.
> > so that logically related code is grouped.
>
> I have a question about the alternative way you mentioned. Currently
> clock providers and consumers describe what clocks they will provide /
> consume in device tree. If we don't describe vencsys clocks in device
> tree, how to get vencsys clocks for drivers that need to control them?
>
Perhaps an example would be best. In DT we would have:
vencsys: vencsys@1 {
compatible = "mtk,vencsys";
reg = <0x1 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
myconsumer@12000 {
compatible = "mtk,vencsys";
reg = <0x12000 0x100>;
clocks = < 10>;
clock-names = "core";
};
(Or are the consumers only children of the subsystem?
It's not clear to me)
And then in the mtk,vencsys driver we would create a platform
device named something like "mtk-vencsys-clk" and assign the
of_node of the device to be the of_node that is assigned to the
mtk,vencsys device.
static int vencsys_probe(struct platform_device *pdev)
{
int ret;
struct device_node *np = pdev->dev.of_node;
struct platform_device *clk_pdev;
clk_pdev = platform_device_alloc("mtk-vencsys-clk", -1);
clk_pdev->dev.of_node = of_node;
ret = platform_device_add(clk_pdev);
if (ret)
return ret;
}
Then we could put a mtk-vencsys-clk driver in drivers/clk/ that
does the clk driver part...
static int clk_vencsys_probe(struct platform_device *pdev)
{
int ret;
struct device_node *np = pdev->dev.of_node;
struct regmap *regmap;
ret = of_clk_add_provider(np, of_clk_src_onecell_get, ..);
if (ret)
return ret;
regmap = dev_get_regmap(pdev->dev.parent, NULL);
}
And similar things could be done for the reset driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/10] x86/intel_rapl: Modify hot cpu notification handling for RAPL
+ Andi, Stephan, Boris and Jacob for RAPL patch
On Thu, 4 Jun 2015, Vikas Shivappa wrote:
This patch modifies the hot cpu notification handling in
Intel Running Average Power Limit(RAPL) driver.
- to add a cpu reader to the rapl_cpumask(which has one cpu per package
set) it uses the existing package<->core map instead of looping
through all cpus in rapl_cpumask.
- to search for the next online sibling during hot cpu exit, it uses
the cpumask_any_online_but instead of looping all online cpus. In
large systems with large number of cpus the time taken to loop may be
expensive and also the time increase linearly.
Signed-off-by: Vikas Shivappa
---
arch/x86/kernel/cpu/perf_event_intel_rapl.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
index 358c54a..987383e 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
@@ -524,18 +524,14 @@ static struct pmu rapl_pmu_class = {
static void rapl_cpu_exit(int cpu)
{
struct rapl_pmu *pmu = per_cpu(rapl_pmu, cpu);
- int i, phys_id = topology_physical_package_id(cpu);
int target = -1;
+ int i;
/* find a new cpu on same package */
- for_each_online_cpu(i) {
- if (i == cpu)
- continue;
- if (phys_id == topology_physical_package_id(i)) {
- target = i;
- break;
- }
- }
+ i = cpumask_any_online_but(topology_core_cpumask(cpu), cpu);
+ if (i < nr_cpu_ids)
+ target = i;
+
/*
* clear cpu from cpumask
* if was set in cpumask and still some cpu on package,
@@ -557,15 +553,12 @@ static void rapl_cpu_exit(int cpu)
static void rapl_cpu_init(int cpu)
{
- int i, phys_id = topology_physical_package_id(cpu);
+ struct cpumask tmp;
- /* check if phys_is is already covered */
- for_each_cpu(i, _cpu_mask) {
- if (phys_id == topology_physical_package_id(i))
- return;
- }
- /* was not found, so add it */
- cpumask_set_cpu(cpu, _cpu_mask);
+ /* check if cpu's package is already covered.If not, add it.*/
+ cpumask_and(, _cpu_mask, topology_core_cpumask(cpu));
+ if (cpumask_empty())
+ cpumask_set_cpu(cpu, _cpu_mask);
}
static __init void rapl_hsw_server_quirk(void)
--
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/
[PATCH v2] [SCSI] qla4xxx: Replace __constant_cpu_to_le16 with cpu_to_le16
In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- Make subject more concise
---
drivers/scsi/qla4xxx/ql4_nx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
index 7c33658..06d6cce 100644
--- a/drivers/scsi/qla4xxx/ql4_nx.c
+++ b/drivers/scsi/qla4xxx/ql4_nx.c
@@ -3741,9 +3741,9 @@ qla4_8xxx_get_flt_info(struct scsi_qla_host *ha, uint32_t
flt_addr)
goto no_flash_data;
}
- if (*wptr == __constant_cpu_to_le16(0x))
+ if (*wptr == cpu_to_le16(0x))
goto no_flash_data;
- if (flt->version != __constant_cpu_to_le16(1)) {
+ if (flt->version != cpu_to_le16(1)) {
DEBUG2(ql4_printk(KERN_INFO, ha, "Unsupported FLT detected: "
"version=0x%x length=0x%x checksum=0x%x.\n",
le16_to_cpu(flt->version), le16_to_cpu(flt->length),
@@ -3846,7 +3846,7 @@ qla4_82xx_get_fdt_info(struct scsi_qla_host *ha)
qla4_82xx_read_optrom_data(ha, (uint8_t *)ha->request_ring,
hw->flt_region_fdt << 2, OPTROM_BURST_SIZE);
- if (*wptr == __constant_cpu_to_le16(0x))
+ if (*wptr == cpu_to_le16(0x))
goto no_flash_data;
if (fdt->sig[0] != 'Q' || fdt->sig[1] != 'L' || fdt->sig[2] != 'I' ||
--
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 v4 1/5] fs: kiocb: introduce IOCB_DONT_DIRTY_PAGE flag for direct IO
On Fri, Jun 5, 2015 at 11:03 PM, Christoph Hellwig wrote: > As mentioned last time a big fat NAK for this one. We generally > do not dirty kernel pages anywhere, so a flag that must alway be set > for default behavior just to prepare for a highy hypothetical user that > in the future might want to abuse the interface is a no-go. > > Just make the dirtying behavior dependent on the iov_iter type: > dirty for ITER_IOVEC and do nothing for ITER_KVEC and ITER_BVEC. Both ITER_KVEC and ITER_BVEC doesn't mean the pages are kernel page, for example of loop and swap. That is why this patch is more flexiable, and won't cause regression since the users may have different dirtying rules as you mentioned last time. http://marc.info/?t=14309322321=1=2 Thanks, Ming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: metag test failure in -next due to commit 'module: relocate module_init from init.h to module.h'
On 06/05/2015 02:39 PM, James Hogan wrote: [ ... ] From e12856c559d7dff2ad4f6497996610e12e7c7e2d Mon Sep 17 00:00:00 2001 From: James Hogan Date: Fri, 5 Jun 2015 22:17:18 +0100 Subject: [PATCH] tty/metag_da: Avoid module_init/module_exit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The metag_da TTY driver can't get built as a module at the moment, but it still uses module_init() and module_exit(). Those macros are moving to module.h which isn't included by metag_da.c, which will result in the following build warnings (remarkably no build errors) and an apparent failure to boot as the TTY driver won't be loaded. drivers/tty/metag_da.c:660: warning: data definition has no type or storage class drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’ drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration drivers/tty/metag_da.c:661: warning: data definition has no type or storage class drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’ drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used drivers/tty/metag_da.c In function ‘dash_console_write’: drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type Instead of just adding the module.h include, now would be a good time to remove the use of these macros, replacing the module_init with device_initcall, and removing the exit function altogether since it isn't needed. If module support is added later the code can always be resurrected. Reported-by: Guenter Roeck Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Paul Gortmaker Cc: linux-me...@vger.kernel.org Yes, that does the trick. Tested-by: Guenter Roeck Thanks, 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/
[PATCH] tty: Convert use of __constant_htons to htons
In little endian cases, macro htons unfolds to __swab16 which provides special case for constants. In big endian cases, __constant_htons and htons expand directly to the same expression. So, replace __constant_htons with htons with the goal of getting rid of the definition of __constant_htons completely. The semantic patch that performs this transformation is as follows: @@expression x;@@ - __constant_htons(x) + htons(x) Signed-off-by: Vaishali Thakkar --- drivers/tty/n_gsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 2c34c32..dc0f371 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2713,7 +2713,7 @@ static void gsm_mux_rx_netchar(struct gsm_dlci *dlci, memcpy(skb_put(skb, size), in_buf, size); skb->dev = net; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); /* Ship it off to the kernel */ netif_rx(skb); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] acpi: Fix acpi_map_pxm_to_node() to handle numa_off
On Tue, 2015-06-02 at 18:26 -0600, Toshi Kani wrote:
> When numa_off is set, NUMA is turned off and node 0 is the only
> valid node on the system. The kernel skips parsing ACPI SRAT
> table in this case.
>
> Change acpi_map_pxm_to_node() to always return 0 when numa_off
> is set. Also move the range check of a proximity ID from
> acpi_get_node() to acpi_map_pxm_to_node() after the numa_off
> check. This keeps the interfaces to return 0 regardless of
> proximity ID values.
>
> Signed-off-by: Toshi Kani
> ---
> drivers/acpi/numa.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index 1333cbdc..4898082 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -70,7 +70,15 @@ static void __acpi_map_pxm_to_node(int pxm, int node)
>
> int acpi_map_pxm_to_node(int pxm)
> {
> - int node = pxm_to_node_map[pxm];
> + int node;
> +
> + if (numa_off)
> + return 0;
I found an issue in this patch. numa_off is only defined in x86, but
this numa.c (ACPI_NUMA) can be enabled on x86 and IA64. I will fix or
drop it in the next version.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [SCSI] qla4xxx: Convert __constant_cpu_to_le16 to cpu_to_le16
In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar
---
drivers/scsi/qla4xxx/ql4_nx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
index 7c33658..06d6cce 100644
--- a/drivers/scsi/qla4xxx/ql4_nx.c
+++ b/drivers/scsi/qla4xxx/ql4_nx.c
@@ -3741,9 +3741,9 @@ qla4_8xxx_get_flt_info(struct scsi_qla_host *ha, uint32_t
flt_addr)
goto no_flash_data;
}
- if (*wptr == __constant_cpu_to_le16(0x))
+ if (*wptr == cpu_to_le16(0x))
goto no_flash_data;
- if (flt->version != __constant_cpu_to_le16(1)) {
+ if (flt->version != cpu_to_le16(1)) {
DEBUG2(ql4_printk(KERN_INFO, ha, "Unsupported FLT detected: "
"version=0x%x length=0x%x checksum=0x%x.\n",
le16_to_cpu(flt->version), le16_to_cpu(flt->length),
@@ -3846,7 +3846,7 @@ qla4_82xx_get_fdt_info(struct scsi_qla_host *ha)
qla4_82xx_read_optrom_data(ha, (uint8_t *)ha->request_ring,
hw->flt_region_fdt << 2, OPTROM_BURST_SIZE);
- if (*wptr == __constant_cpu_to_le16(0x))
+ if (*wptr == cpu_to_le16(0x))
goto no_flash_data;
if (fdt->sig[0] != 'Q' || fdt->sig[1] != 'L' || fdt->sig[2] != 'I' ||
--
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] cris: Wire up missing syscalls
On 6/3/15 23:23, Hans-Peter Nilsson wrote: > > Most people probably guessed correctly that this is related to > building the CRIS v10 kernel with the *-elf toolchain (which has > the convention that symbols are prefixed with underscores for > cris-*-elf and crisv32-*-elf) while (IIUC) the CRIS v32 kernel > is built with the *-linux-gnu toolchain (which does not have any > symbol prefix for cris-*-linux-gnu crisv32-*-linux-gnu). > What you said above is helpful to me. Originally I often use *-elf for cross compiling linux kernel, it is incorrect for some archs. After use *-linux, the upstream frv toolchain can work well (for me, it is the last arch which has missing syscalls). :-) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cris: Wire up missing syscalls
On 6/3/15 23:23, Hans-Peter Nilsson wrote: > > Most people probably guessed correctly that this is related to > building the CRIS v10 kernel with the *-elf toolchain (which has > the convention that symbols are prefixed with underscores for > cris-*-elf and crisv32-*-elf) while (IIUC) the CRIS v32 kernel > is built with the *-linux-gnu toolchain (which does not have any > symbol prefix for cris-*-linux-gnu crisv32-*-linux-gnu). > What you said above is helpful to me. Originally I often use *-elf for cross compiling linux kernel, it is incorrect for some archs (e.g. frv, m32r, and our cris). After use *-linux, the upstream frv toolchain can work well (for me, it is the last arch which has missing syscalls). :-) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices
On 06/05, Daniel Thompson wrote:
> On 04/06/15 23:07, Stephen Boyd wrote:
> >On 05/22, Daniel Thompson wrote:
> >>+#include
> >
> >Are you using this include?
>
> Not very much?
>
> Turns out I was relying on these to get kzalloc() defined but there
> are better headers for me to use for that!
Hah ok. We should delete some of those arch specific clkdev.h
files...
>
> >
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+#include
> >>+
> >>+#include
> >
> >Are you using this include?
>
> No (this is already gone in v2).
Oh hrm.. I must have missed v2.
>
> >>+
> >>+ if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
> >>+ unsigned long best_parent = rate / mult;
> >>+
> >>+ *prate =
> >>+ __clk_round_rate(__clk_get_parent(hw->clk), best_parent);
> >>+ }
> >>+
> >>+ return *prate * mult;
> >>+}
> >>+
> >>+static int clk_apb_mul_set_rate(struct clk_hw *hw, unsigned long rate,
> >>+unsigned long parent_rate)
> >>+{
> >
> >Why don't we need to do anything here?
>
> This clock cannot change its own rate. It is very nearly a fixed
> factor clock but with the additional quirk that the "fixed" factor
> changes depending upon the rate of the parent clock.
>
> This is the same implementation as clk-fixed-factor. I concluded
> that it returns success because round rate should always result in
> the set rate for this clock being a nop.
Ok. A comment here would be helpful in the future. We probably
ought to have a comment in clk-fixed-factor as well.
>
>
> >>+ return 0;
> >>+}
> >>+
> >>+static struct clk_ops clk_apb_mul_factor_ops = {
> >
> >const?
>
> Makes sense...
>
> You want a patch for clk-fixed-factor too?
Sure.
>
>
> >>+struct clk *clk_register_apb_mul(struct device *dev, const char *name,
> >>+const char *parent_name, unsigned long flags,
> >>+u8 bit_idx)
> >>+{
> >>+ struct clk_apb_mul *am;
> >>+ struct clk_init_data init;
> >>+ struct clk *clk;
> >>+
> >>+ am = kzalloc(sizeof(*am), GFP_KERNEL);
> >>+ if (!am)
> >>+ return ERR_PTR(-ENOMEM);
> >>+
> >>+ am->bit_idx = bit_idx;
> >>+ am->hw.init =
> >>+
> >>+ init.name = name;
> >>+ init.ops = _apb_mul_factor_ops;
> >>+ init.flags = flags | CLK_IS_BASIC;
> >
> >Is it basic?
>
> Tough question.
>
> The absence of this flag appears grants arch code permission to use
> secret backdoors to do "weird stuff" but making special assumptions
> about the type of the clock. This clock keeps its implementation
> private so noone outside the compilation unit can usefully cast it.
>
> However, it also looks like only omap2 is the only platform that
> makes these special assumptions so when this code is run on STM32
> there is nothing to actually consume the CLK_IS_BASIC flag at
> runtime.
>
> In other words the flag is useless but, I think, also correctly applied.
>
> I'd be happy to remove it if anyone disagrees with the guesswork above.
>
> Alternatively, I could write a patch to *invert* CLK_IS_BASIC and
> rename it CLK_CASTABLE on the grounds that only the people doing
> "weird stuff" should have to care about this flag at all. Any
> interest in that?
No I think we should delete CLK_IS_BASIC. So please remove it
unless you actually need it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 4.1-rc6
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a couple touchpad drivers fixups. Changelog: - Hans de Goede (2): Input: elantech - fix detection of touchpads where the revision matches a known rate Input: alps - do not reduce trackpoint speed by half 洪一竹 (1): Input: elantech - add new icbody type Diffstat: drivers/input/mouse/alps.c | 5 ++--- drivers/input/mouse/elantech.c | 8 +--- 2 files changed, 7 insertions(+), 6 deletions(-) -- 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 v13 4/5] cgroup: allow a cgroup subsystem to reject a fork
Add a new cgroup subsystem callback can_fork that conditionally
states whether or not the fork is accepted or rejected by a cgroup
policy. In addition, add a cancel_fork callback so that if an error
occurs later in the forking process, any state modified by can_fork can
be reverted.
Allow for a private opaque pointer to be passed from cgroup_can_fork to
cgroup_post_fork, allowing for the fork state to be stored by each
subsystem separately.
Also add a tagging system for cgroup_subsys.h to allow for CGROUP_
enumerations to be be defined and used. In addition, explicitly add a
CGROUP_CANFORK_COUNT macro to make arrays easier to define.
This is in preparation for implementing the pids cgroup subsystem.
Signed-off-by: Aleksa Sarai
---
include/linux/cgroup-defs.h | 10 +-
include/linux/cgroup.h| 16 +++--
include/linux/cgroup_subsys.h | 23 +
kernel/cgroup.c | 75 +--
kernel/cgroup_freezer.c | 2 +-
kernel/fork.c | 17 --
kernel/sched/core.c | 2 +-
7 files changed, 136 insertions(+), 9 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index c5588c4..2009ceb 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -34,12 +34,17 @@ struct seq_file;
/* define the enumeration of all cgroup subsystems */
#define SUBSYS(_x) _x ## _cgrp_id,
+#define SUBSYS_TAG(_t) CGROUP_ ## _t, \
+ __unused_tag_ ## _t = CGROUP_ ## _t - 1,
enum cgroup_subsys_id {
#include
CGROUP_SUBSYS_COUNT,
};
+#undef SUBSYS_TAG
#undef SUBSYS
+#define CGROUP_CANFORK_COUNT (CGROUP_CANFORK_END - CGROUP_CANFORK_START)
+
/* bits in struct cgroup_subsys_state flags field */
enum {
CSS_NO_REF = (1 << 0), /* no reference counting for this css */
@@ -405,7 +410,9 @@ struct cgroup_subsys {
struct cgroup_taskset *tset);
void (*attach)(struct cgroup_subsys_state *css,
struct cgroup_taskset *tset);
- void (*fork)(struct task_struct *task);
+ int (*can_fork)(struct task_struct *task, void **priv_p);
+ void (*cancel_fork)(struct task_struct *task, void *priv);
+ void (*fork)(struct task_struct *task, void *priv);
void (*exit)(struct cgroup_subsys_state *css,
struct cgroup_subsys_state *old_css,
struct task_struct *task);
@@ -490,6 +497,7 @@ static inline void cgroup_threadgroup_change_end(struct
task_struct *tsk)
#else /* CONFIG_CGROUPS */
+#define CGROUP_CANFORK_COUNT 0
#define CGROUP_SUBSYS_COUNT 0
static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) {}
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index a593e29..17d0046 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -62,9 +62,15 @@ int proc_cgroup_show(struct seq_file *m, struct
pid_namespace *ns,
struct pid *pid, struct task_struct *tsk);
void cgroup_fork(struct task_struct *p);
-void cgroup_post_fork(struct task_struct *p);
+extern int cgroup_can_fork(struct task_struct *p,
+ void *ss_priv[CGROUP_CANFORK_COUNT]);
+extern void cgroup_cancel_fork(struct task_struct *p,
+ void *ss_priv[CGROUP_CANFORK_COUNT]);
+extern void cgroup_post_fork(struct task_struct *p,
+void *old_ss_priv[CGROUP_CANFORK_COUNT]);
void cgroup_exit(struct task_struct *p);
+
int cgroup_init_early(void);
int cgroup_init(void);
@@ -524,7 +530,13 @@ static inline int cgroupstats_build(struct cgroupstats
*stats,
struct dentry *dentry) { return -EINVAL; }
static inline void cgroup_fork(struct task_struct *p) {}
-static inline void cgroup_post_fork(struct task_struct *p) {}
+static inline int cgroup_can_fork(struct task_struct *p,
+ void *ss_priv[CGROUP_CANFORK_COUNT])
+{ return 0; }
+static inline void cgroup_cancel_fork(struct task_struct *p,
+ void *ss_priv[CGROUP_CANFORK_COUNT]) {}
+static inline void cgroup_post_fork(struct task_struct *p,
+ void *ss_priv[CGROUP_CANFORK_COUNT]) {}
static inline void cgroup_exit(struct task_struct *p) {}
static inline int cgroup_init_early(void) { return 0; }
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index e4a96fb..ec43bce 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -3,6 +3,17 @@
*
* DO NOT ADD ANY SUBSYSTEM WITHOUT EXPLICIT ACKS FROM CGROUP MAINTAINERS.
*/
+
+/*
+ * This file *must* be included with SUBSYS() defined.
+ * SUBSYS_TAG() is a noop if undefined.
+ */
+
+#ifndef SUBSYS_TAG
+#define __TMP_SUBSYS_TAG
+#define SUBSYS_TAG(_x)
+#endif
+
#if IS_ENABLED(CONFIG_CPUSETS)
SUBSYS(cpuset)
#endif
@@ -48,11 +59,23 @@ SUBSYS(hugetlb)
#endif
/*
+ *
[PATCH v13 5/5] cgroup: implement the PIDs subsystem
Adds a new single-purpose PIDs subsystem to limit the number of tasks that can be forked inside a cgroup. Essentially this is an implementation of RLIMIT_NPROC that applies to a cgroup rather than a process tree. However, it should be noted that organisational operations (adding and removing tasks from a PIDs hierarchy) will *not* be prevented. Rather, the number of tasks in the hierarchy cannot exceed the limit through forking. This is due to the fact that, in the unified hierarchy, attach cannot fail (and it is not possible for a task to overcome its PIDs cgroup policy limit by attaching to a child cgroup -- even if migrating mid-fork it must be able to fork in the parent first). PIDs are fundamentally a global resource, and it is possible to reach PID exhaustion inside a cgroup without hitting any reasonable kmemcg policy. Once you've hit PID exhaustion, you're only in a marginally better state than OOM. This subsystem allows PID exhaustion inside a cgroup to be prevented. Signed-off-by: Aleksa Sarai --- CREDITS | 5 + include/linux/cgroup_subsys.h | 5 + init/Kconfig | 16 ++ kernel/Makefile | 1 + kernel/cgroup_pids.c | 377 ++ 5 files changed, 404 insertions(+) create mode 100644 kernel/cgroup_pids.c diff --git a/CREDITS b/CREDITS index 40cc4bf..0727426 100644 --- a/CREDITS +++ b/CREDITS @@ -3215,6 +3215,11 @@ S: 69 rue Dunois S: 75013 Paris S: France +N: Aleksa Sarai +E: cyp...@cyphar.com +W: https://www.cyphar.com/ +D: `pids` cgroup subsystem + N: Dipankar Sarma E: dipan...@in.ibm.com D: RCU diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h index ec43bce..1f36945 100644 --- a/include/linux/cgroup_subsys.h +++ b/include/linux/cgroup_subsys.h @@ -62,6 +62,11 @@ SUBSYS(hugetlb) * Subsystems that implement the can_fork() family of callbacks. */ SUBSYS_TAG(CANFORK_START) + +#if IS_ENABLED(CONFIG_CGROUP_PIDS) +SUBSYS(pids) +#endif + SUBSYS_TAG(CANFORK_END) /* diff --git a/init/Kconfig b/init/Kconfig index b9b824b..f4e4918 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -968,6 +968,22 @@ config CGROUP_FREEZER Provides a way to freeze and unfreeze all tasks in a cgroup. +config CGROUP_PIDS + bool "PIDs cgroup subsystem" + help + Provides enforcement of process number limits in the scope of a + cgroup. Any attempt to fork more processes than is allowed in the + cgroup will fail. PIDs are fundamentally a global resource because it + is fairly trivial to reach PID exhaustion before you reach even a + conservative kmemcg limit. As a result, it is possible to grind a + system to halt without being limited by other cgroup policies. The + PIDs cgroup subsystem is designed to stop this from happening. + + It should be noted that organisational operations (such as attaching + to a cgroup hierarchy will *not* be blocked by the PIDs subsystem), + since the PIDs limit only affects a process's ability to fork, not to + attach to a cgroup. + config CGROUP_DEVICE bool "Device controller for cgroups" help diff --git a/kernel/Makefile b/kernel/Makefile index 0f8f8b0..df5406c 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -55,6 +55,7 @@ obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o obj-$(CONFIG_COMPAT) += compat.o obj-$(CONFIG_CGROUPS) += cgroup.o obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o +obj-$(CONFIG_CGROUP_PIDS) += cgroup_pids.o obj-$(CONFIG_CPUSETS) += cpuset.o obj-$(CONFIG_UTS_NS) += utsname.o obj-$(CONFIG_USER_NS) += user_namespace.o diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c new file mode 100644 index 000..7965af2 --- /dev/null +++ b/kernel/cgroup_pids.c @@ -0,0 +1,377 @@ +/* + * Process number limiting controller for cgroups. + * + * Used to allow a cgroup hierarchy to stop any new processes from fork()ing + * after a certain limit is reached. + * + * Since it is trivial to hit the task limit without hitting any kmemcg limits + * in place, PIDs are a fundamental resource. As such, PID exhaustion must be + * preventable in the scope of a cgroup hierarchy by allowing resource limiting + * of the number of tasks in a cgroup. + * + * In order to use the `pids` controller, set the maximum number of tasks in + * pids.max (this is not available in the root cgroup for obvious reasons). The + * number of processes currently in the cgroup is given by pids.current. + * Organisational operations are not blocked by cgroup policies, so it is + * possible to have pids.current > pids.max. However, it is not possible to + * violate a cgroup policy through fork(). fork() will return -EAGAIN if forking + * would cause a cgroup policy to be violated. + * + * To set a cgroup to have no limit, set pids.max to "max". This is the default + * for all new cgroups (N.B. that PID limits are hierarchical, so
[PATCH v13 3/5] cgroup, block: implement task_get_css()
From: Tejun Heo
Implement task_get_css() which find and pins the css for the specified
task and subsys. As a task is always associated with an online css
for every subsystem except while the css_set update is propagating,
task_get_css() retries till css_tryget_online() succeeds.
Signed-off-by: Tejun Heo
Cc: Li Zefan
---
include/linux/cgroup.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 82319fb..a593e29 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -354,6 +354,31 @@ static inline struct cgroup_subsys_state *task_css(struct
task_struct *task,
}
/**
+ * task_get_css - find and get the css for (task, subsys)
+ * @task: the target task
+ * @subsys_id: the target subsystem ID
+ *
+ * Find the css for the (@task, @subsys_id) combination, increment a
+ * reference on and return it. This function is guaranteed to return a
+ * valid css.
+ */
+static inline struct cgroup_subsys_state *
+task_get_css(struct task_struct *task, int subsys_id)
+{
+ struct cgroup_subsys_state *css;
+
+ rcu_read_lock();
+ while (true) {
+ css = task_css(task, subsys_id);
+ if (likely(css_tryget_online(css)))
+ break;
+ cpu_relax();
+ }
+ rcu_read_unlock();
+ return css;
+}
+
+/**
* task_css_is_root - test whether a task belongs to the root css
* @task: the target task
* @subsys_id: the target subsystem ID
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v13 1/5] cgroup: use bitmask to filter for_each_subsys
Add a new macro for_each_subsys_which that allows all enabled cgroup
subsystems to be filtered by a bitmask, such that mask & (1 << ssid)
determines if the subsystem is to be processed in the loop body (where
ssid is the unique id of the subsystem).
Also replace the need_forkexit_callback with two separate bitmasks for
each callback to make (ss->{fork,exit}) checks unnecessary.
Signed-off-by: Aleksa Sarai
---
include/linux/cgroup-defs.h | 2 ++
kernel/cgroup.c | 54 -
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 26d1cea..c5588c4 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -490,6 +490,8 @@ static inline void cgroup_threadgroup_change_end(struct
task_struct *tsk)
#else /* CONFIG_CGROUPS */
+#define CGROUP_SUBSYS_COUNT 0
+
static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) {}
static inline void cgroup_threadgroup_change_end(struct task_struct *tsk) {}
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 0fd5227..5734717 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -178,12 +178,13 @@ static DEFINE_IDR(cgroup_hierarchy_idr);
*/
static u64 css_serial_nr_next = 1;
-/* This flag indicates whether tasks in the fork and exit paths should
- * check for fork/exit handlers to call. This avoids us having to do
- * extra work in the fork/exit path if none of the subsystems need to
- * be called.
+/*
+ * These bitmask flags indicate whether tasks in the fork and exit paths have
+ * fork/exit handlers to call. This avoids us having to do extra work in the
+ * fork/exit path to check which subsystems have fork/exit callbacks.
*/
-static int need_forkexit_callback __read_mostly;
+static unsigned long have_fork_callback __read_mostly;
+static unsigned long have_exit_callback __read_mostly;
static struct cftype cgroup_dfl_base_files[];
static struct cftype cgroup_legacy_base_files[];
@@ -412,6 +413,25 @@ static int notify_on_release(const struct cgroup *cgrp)
for ((ssid) = 0; (ssid) < CGROUP_SUBSYS_COUNT &&\
(((ss) = cgroup_subsys[ssid]) || true); (ssid)++)
+
+/**
+ * for_each_subsys_which - filter for_each_subsys with a bitmask
+ * @ss: the iteration cursor
+ * @ssid: the index of @ss, CGROUP_SUBSYS_COUNT after reaching the end
+ * @ss_maskp: a pointer to the bitmask
+ *
+ * The block will only run for cases where the ssid-th bit (1 << ssid) of
+ * mask is set to 1.
+ */
+#define for_each_subsys_which(ss, ssid, ss_maskp) \
+ if (!CGROUP_SUBSYS_COUNT) \
+ ; \
+ else\
+ for_each_set_bit(ssid, ss_maskp, CGROUP_SUBSYS_COUNT) \
+ if (((ss) = cgroup_subsys[ssid]) && false) \
+ break; \
+ else
+
/* iterate across the hierarchies */
#define for_each_root(root)\
list_for_each_entry((root), _roots, root_list)
@@ -4914,7 +4934,8 @@ static void __init cgroup_init_subsys(struct
cgroup_subsys *ss, bool early)
* init_css_set is in the subsystem's root cgroup. */
init_css_set.subsys[ss->id] = css;
- need_forkexit_callback |= ss->fork || ss->exit;
+ have_fork_callback |= (bool)ss->fork << ss->id;
+ have_exit_callback |= (bool)ss->exit << ss->id;
/* At system boot, before all subsystems have been
* registered, no tasks have been forked, so we don't
@@ -5225,11 +5246,8 @@ void cgroup_post_fork(struct task_struct *child)
* css_set; otherwise, @child might change state between ->fork()
* and addition to css_set.
*/
- if (need_forkexit_callback) {
- for_each_subsys(ss, i)
- if (ss->fork)
- ss->fork(child);
- }
+ for_each_subsys_which(ss, i, _fork_callback)
+ ss->fork(child);
}
/**
@@ -5273,16 +5291,12 @@ void cgroup_exit(struct task_struct *tsk)
cset = task_css_set(tsk);
RCU_INIT_POINTER(tsk->cgroups, _css_set);
- if (need_forkexit_callback) {
- /* see cgroup_post_fork() for details */
- for_each_subsys(ss, i) {
- if (ss->exit) {
- struct cgroup_subsys_state *old_css =
cset->subsys[i];
- struct cgroup_subsys_state *css = task_css(tsk,
i);
+ /* see cgroup_post_fork() for details */
+ for_each_subsys_which(ss, i, _exit_callback) {
+ struct cgroup_subsys_state *old_css = cset->subsys[i];
+ struct cgroup_subsys_state *css = task_css(tsk, i);
-
[PATCH v13 2/5] cgroup: replace explicit ss_mask checking with for_each_subsys_which
Replace the explicit checking against ss_masks inside a for_each_subsys
block with for_each_subsys_which(..., ss_mask), to take advantage of the
more readable (and more efficient) macro.
Signed-off-by: Aleksa Sarai
---
kernel/cgroup.c | 44
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 5734717..c5400d20 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1107,9 +1107,8 @@ static unsigned long cgroup_calc_child_subsys_mask(struct
cgroup *cgrp,
while (true) {
unsigned long new_ss_mask = cur_ss_mask;
- for_each_subsys(ss, ssid)
- if (cur_ss_mask & (1 << ssid))
- new_ss_mask |= ss->depends_on;
+ for_each_subsys_which(ss, ssid, _ss_mask)
+ new_ss_mask |= ss->depends_on;
/*
* Mask out subsystems which aren't available. This can
@@ -1247,10 +1246,7 @@ static int rebind_subsystems(struct cgroup_root
*dst_root,
lockdep_assert_held(_mutex);
- for_each_subsys(ss, ssid) {
- if (!(ss_mask & (1 << ssid)))
- continue;
-
+ for_each_subsys_which(ss, ssid, _mask) {
/* if @ss has non-root csses attached to it, can't move */
if (css_next_child(NULL, cgroup_css(>root->cgrp, ss)))
return -EBUSY;
@@ -1287,18 +1283,14 @@ static int rebind_subsystems(struct cgroup_root
*dst_root,
* Nothing can fail from this point on. Remove files for the
* removed subsystems and rebind each subsystem.
*/
- for_each_subsys(ss, ssid)
- if (ss_mask & (1 << ssid))
- cgroup_clear_dir(>root->cgrp, 1 << ssid);
+ for_each_subsys_which(ss, ssid, _mask)
+ cgroup_clear_dir(>root->cgrp, 1 << ssid);
- for_each_subsys(ss, ssid) {
+ for_each_subsys_which(ss, ssid, _mask) {
struct cgroup_root *src_root;
struct cgroup_subsys_state *css;
struct css_set *cset;
- if (!(ss_mask & (1 << ssid)))
- continue;
-
src_root = ss->root;
css = cgroup_css(_root->cgrp, ss);
@@ -2557,13 +2549,11 @@ static void cgroup_print_ss_mask(struct seq_file *seq,
unsigned long ss_mask)
bool printed = false;
int ssid;
- for_each_subsys(ss, ssid) {
- if (ss_mask & (1 << ssid)) {
- if (printed)
- seq_putc(seq, ' ');
- seq_printf(seq, "%s", ss->name);
- printed = true;
- }
+ for_each_subsys_which(ss, ssid, _mask) {
+ if (printed)
+ seq_putc(seq, ' ');
+ seq_printf(seq, "%s", ss->name);
+ printed = true;
}
if (printed)
seq_putc(seq, '\n');
@@ -2705,11 +2695,12 @@ static ssize_t cgroup_subtree_control_write(struct
kernfs_open_file *of,
*/
buf = strstrip(buf);
while ((tok = strsep(, " "))) {
+ unsigned long tmp_ss_mask = ~cgrp_dfl_root_inhibit_ss_mask;
+
if (tok[0] == '\0')
continue;
- for_each_subsys(ss, ssid) {
- if (ss->disabled || strcmp(tok + 1, ss->name) ||
- ((1 << ss->id) & cgrp_dfl_root_inhibit_ss_mask))
+ for_each_subsys_which(ss, ssid, _ss_mask) {
+ if (ss->disabled || strcmp(tok + 1, ss->name))
continue;
if (*tok == '+') {
@@ -2796,10 +2787,7 @@ static ssize_t cgroup_subtree_control_write(struct
kernfs_open_file *of,
* still around. In such cases, wait till it's gone using
* offline_waitq.
*/
- for_each_subsys(ss, ssid) {
- if (!(css_enable & (1 << ssid)))
- continue;
-
+ for_each_subsys_which(ss, ssid, _enable) {
cgroup_for_each_live_child(child, cgrp) {
DEFINE_WAIT(wait);
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock
On 6/4/2015 7:09 PM, Ohad Ben-Cohen wrote: On Tue, May 26, 2015 at 11:36 PM, Lina Iyer wrote: Just to make sure I understand, is this how your scenario is solved? - c1 goes down - c0 goes down, carries information about shared resources - c1 takes HWLOCK and calls into SCM, stuck handling FIQs - c0 wants to call into SCM but is waiting spinning on HWLOCK - c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor - c0 takes HWLOCK, calls into SCM, shared resources handled correctly, HWLOCK in this example is a single shared hwspinlock accessible by c0, c1 and secure monitor. That is correct. Ok, thanks. If we adopt the proposed approach in your patch, I'm thinking maybe we should restrict it only to hardware implementations that explicitly allow it, using some hardware capability flag published by the hwspinlock driver. In OMAP, e.g., it is prohibited to spin on this hwlock for a long period of time, so such a hw cap flag would allow you guys to enable this behaviour specifically for your driver. What do you think? Lina and I talked about this today. Lina's current approach of adding a flag (HWLOCK_NOLOCK) seems to flow with the current framework considering the framework already has several flags to control the software spinlock behavior. The NOLOCK flag is not a default option, so current OMAP code is not affected. If you like, we could label the option with comments in the header as an advanced option. Users better be aware of what they are doing when they use it. OMAP code should never use the option (based on what you appear to be saying above), and if someone attempts to use it in OMAP code, well there is plenty of rope around the kernel to get one into trouble. This doesn't seem to be an exception. The default behavior that 99% of clients will use remains the same simple interface as it is today, but "power users" who require more control are given that flexibility, along with additional responsibility. In short, Lina's solution is simple and uses an existing mechanism to satisfy the requirement. Your capability proposal could be made to work, but it seems to introduce additional questions. Can a capability be applied to a specific lock? Can a capability be applied to an entire bank of locks? Can capabilities be changed during the lifetime of the system? What would the API look like? Since this mechanism appears to require a new API, what other things would that API cover? Is it appropriate to put usecase specific logic into a driver that is responsible for managing the hardware? IE policy vs mechanism. From "prototyping" an implementation of this in my head, it seems more complicated and heavy handed for a very simple need that can be easily handled in another way. As far as I am aware, there is no other need at this point in time for such a mechanism, so it seems to be a lot of effort and work, for limited use. In the interest of keeping things simple, Lina and I think Lina's current proposal is the preferred way forward at this point in time given the information available today. If you still wish to scope out a capability based alternative, would you please provide some details about how you envision it working? An example of the API, how it would be used, future usecases that might be covered by it, etc. That would give us specifics we can discuss and weigh the merits of. Thanks. -- Jeffrey Hugo Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] seccomp: add ptrace options for suspend/resume
On 06/05, Tycho Andersen wrote: > > right thing to do, just leave out the definition of > may_suspend_seccomp all together, or add in another if defined() in > the header? Just declare it unconditionally in .h. The kernel relies on this kind of dead-code elimination anyway. For example, please look at "extern void __put_user_bad(void)" in uaccess.h. IOW, extern void undefined_func(void); if (0) undefined_func(); should be safe. > Maybe we will get rid of this pesky function all together though... Yes ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v13 0/5] cgroup: add PIDs subsystem
This is a small update to v12 of the pids patchset[1] (most of which was merged into Tejun's tree, but was later reverted due to some bogus GCC warnings). The main changes are: * Fix up include/linux/cgroup.h changes to take into account Tejun's refactoring of cgroup.h into cgroup-defs.h. * Move ->can_attach() and ->cancel_attach() charge/revert into ->attach(), since we can't fail and it's simpler to just charge there. * Remove tset_get_css(), because the premise of its existence is flawed and switch ->attach() code to just task_get_css() itself. * Remove a patch that was rendered uneccesary by the cgroup.h refactor. * Fix up the for_each_subsys_which patchset so that it doesn't trigger a GCC warning when CGROUP_SUBSYS_COUNT = 0, but cgroups are enabled. The warning is bogus anyway, since the whole block becomes a noop in that case. [1]: https://lkml.org/lkml/2015/5/18/439 Aleksa Sarai (4): cgroup: use bitmask to filter for_each_subsys cgroup: replace explicit ss_mask checking with for_each_subsys_which cgroup: allow a cgroup subsystem to reject a fork cgroup: implement the PIDs subsystem Tejun Heo (1): cgroup, block: implement task_get_css() CREDITS | 5 + include/linux/cgroup-defs.h | 12 +- include/linux/cgroup.h| 41 - include/linux/cgroup_subsys.h | 28 init/Kconfig | 16 ++ kernel/Makefile | 1 + kernel/cgroup.c | 171 +-- kernel/cgroup_freezer.c | 2 +- kernel/cgroup_pids.c | 377 ++ kernel/fork.c | 17 +- kernel/sched/core.c | 2 +- 11 files changed, 616 insertions(+), 56 deletions(-) create mode 100644 kernel/cgroup_pids.c -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m32r: Wire up all missing syscalls
If some of syscalls are not implemented, they will be redirected to sys_ni_call. The related warnings: :1142:2: warning: #warning syscall timerfd_create not implemented [-Wcpp] :1151:2: warning: #warning syscall timerfd_settime not implemented [-Wcpp] :1154:2: warning: #warning syscall timerfd_gettime not implemented [-Wcpp] :1157:2: warning: #warning syscall signalfd4 not implemented [-Wcpp] :1160:2: warning: #warning syscall eventfd2 not implemented [-Wcpp] :1163:2: warning: #warning syscall epoll_create1 not implemented [-Wcpp] :1166:2: warning: #warning syscall dup3 not implemented [-Wcpp] :1169:2: warning: #warning syscall pipe2 not implemented [-Wcpp] :1172:2: warning: #warning syscall inotify_init1 not implemented [-Wcpp] :1175:2: warning: #warning syscall preadv not implemented [-Wcpp] :1178:2: warning: #warning syscall pwritev not implemented [-Wcpp] :1181:2: warning: #warning syscall rt_tgsigqueueinfo not implemented [-Wcpp] :1184:2: warning: #warning syscall perf_event_open not implemented [-Wcpp] :1187:2: warning: #warning syscall recvmmsg not implemented [-Wcpp] :1190:2: warning: #warning syscall fanotify_init not implemented [-Wcpp] :1193:2: warning: #warning syscall fanotify_mark not implemented [-Wcpp] :1196:2: warning: #warning syscall prlimit64 not implemented [-Wcpp] :1199:2: warning: #warning syscall name_to_handle_at not implemented [-Wcpp] :1202:2: warning: #warning syscall open_by_handle_at not implemented [-Wcpp] :1205:2: warning: #warning syscall clock_adjtime not implemented [-Wcpp] :1208:2: warning: #warning syscall syncfs not implemented [-Wcpp] :1211:2: warning: #warning syscall sendmmsg not implemented [-Wcpp] :1217:2: warning: #warning syscall process_vm_readv not implemented [-Wcpp] :1220:2: warning: #warning syscall process_vm_writev not implemented [-Wcpp] :1223:2: warning: #warning syscall kcmp not implemented [-Wcpp] :1226:2: warning: #warning syscall finit_module not implemented [-Wcpp] :1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp] :1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp] :1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp] :1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] :1241:2: warning: #warning syscall getrandom not implemented [-Wcpp] :1244:2: warning: #warning syscall memfd_create not implemented [-Wcpp] :1247:2: warning: #warning syscall bpf not implemented [-Wcpp] :1250:2: warning: #warning syscall execveat not implemented [-Wcpp] :1253:2: warning: #warning syscall userfaultfd not implemented [-Wcpp] Signed-off-by: Chen Gang --- arch/m32r/include/asm/unistd.h | 3 +-- arch/m32r/include/uapi/asm/unistd.h | 35 +++ arch/m32r/kernel/syscall_table.S| 35 +++ 3 files changed, 71 insertions(+), 2 deletions(-) diff --git a/arch/m32r/include/asm/unistd.h b/arch/m32r/include/asm/unistd.h index 59db801..512207a 100644 --- a/arch/m32r/include/asm/unistd.h +++ b/arch/m32r/include/asm/unistd.h @@ -3,8 +3,7 @@ #include - -#define NR_syscalls 326 +#define NR_syscalls 361 #define __ARCH_WANT_STAT64 #define __ARCH_WANT_SYS_ALARM diff --git a/arch/m32r/include/uapi/asm/unistd.h b/arch/m32r/include/uapi/asm/unistd.h index 5a54f2a..f3d6264 100644 --- a/arch/m32r/include/uapi/asm/unistd.h +++ b/arch/m32r/include/uapi/asm/unistd.h @@ -331,5 +331,40 @@ #define __NR_eventfd 323 #define __NR_fallocate 324 #define __NR_setns 325 +#define __NR_timerfd_create326 +#define __NR_timerfd_settime 327 +#define __NR_timerfd_gettime 328 +#define __NR_signalfd4 329 +#define __NR_eventfd2 330 +#define __NR_epoll_create1 331 +#define __NR_dup3 332 +#define __NR_pipe2 333 +#define __NR_inotify_init1 334 +#define __NR_preadv335 +#define __NR_pwritev 336 +#define __NR_rt_tgsigqueueinfo 337 +#define __NR_perf_event_open 338 +#define __NR_recvmmsg 339 +#define __NR_fanotify_init 340 +#define __NR_fanotify_mark 341 +#define __NR_prlimit64 342 +#define __NR_name_to_handle_at 343 +#define __NR_open_by_handle_at 344 +#define __NR_clock_adjtime 345 +#define __NR_syncfs346 +#define __NR_sendmmsg 347 +#define __NR_process_vm_readv 348 +#define __NR_process_vm_writev 349 +#define __NR_kcmp 350 +#define __NR_finit_module 351 +#define __NR_sched_setattr 352 +#define __NR_sched_getattr 353 +#define __NR_renameat2 354 +#define __NR_seccomp 355 +#define __NR_getrandom 356 +#define __NR_memfd_create 357 +#define __NR_bpf 358 +#define __NR_execveat 359 +#define __NR_userfaultfd 360 #endif /* _UAPI_ASM_M32R_UNISTD_H */ diff --git a/arch/m32r/kernel/syscall_table.S b/arch/m32r/kernel/syscall_table.S index
Re: [RFC][PATCH 0/5] Optimize percpu-rwsem
On 06/05, Al Viro wrote:
>
> On Fri, Jun 05, 2015 at 11:08:57PM +0200, Oleg Nesterov wrote:
> > On 06/05, Al Viro wrote:
> > >
> > > FWIW, I hadn't really looked into stop_machine uses, but fs/locks.c one
> > > is really not all that great - there we have a large trashcan of a list
> > > (every file_lock on the system) and the only use of that list is
> > > /proc/locks
> > > output generation. Sure, additions take this CPU's spinlock. And
> > > removals
> > > take pretty much a random one - losing the timeslice and regaining it on
> > > a different CPU is quite likely with the uses there.
> > >
> > > Why do we need a global lock there, anyway? Why not hold only one for
> > > the chain currently being traversed? Sure, we'll need to get and drop
> > > them in ->next() that way; so what?
> >
> > And note that fs/seq_file.c:seq_hlist_next_percpu() has no other users.
> >
> > And given that locks_delete_global_locks() takes the random lock anyway,
> > perhaps the hashed lists/locking makes no sense, I dunno.
>
> It's not about making life easier for /proc/locks; it's about not screwing
> those who add/remove file_lock...
I meant, seq_hlist_next_percpu() could be "static" in fs/locks.c.
> And no, that "random lock" isn't held
> when modifying the (per-cpu) lists - it protects the list hanging off each
> element of the global list, and /proc/locks scans those lists, so rather
> than taking/dropping it in each ->show(), it's taken once in ->start()...
Sure, I understand. I meant that (perhaps) something like
struct {
spinlock_t lock;
struct list_head *head
} file_lock_list[];
locks_insert_global_locks(fl)
{
int idx = fl->idx = hash(fl);
spin_lock(_lock_list[idx].lock);
hlist_add_head(...);
spin_unlock(...);
}
seq_hlist_next_percpu() could scan file_lock_list[] and unlock/lock ->lock
when it changes the index.
But please forget, this is really minor. Just I think that file_lock_list
is not actually "per-cpu", exactly because every locks_delete_global_locks()
needs lg_local_lock_cpu(fl->fl_link_cpu) as you pointed out.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: comedi: daqboard2000: fixed whitespace coding style issue
>From 843d038eec5ac2c59d3138f19ae52828098c7d50 Mon Sep 17 00:00:00 2001 From: Dennis Chen Date: Fri, 5 Jun 2015 15:42:37 -0700 Subject: [PATCH] Staging: comedi: daqboard2000: fixed whitespace coding style issue Fixed whitespace coding style issue. Signed-off-by: Dennis Chen --- drivers/staging/comedi/drivers/daqboard2000.c | 112 +- 1 file changed, 56 insertions(+), 56 deletions(-) diff --git a/drivers/staging/comedi/drivers/daqboard2000.c b/drivers/staging/comedi/drivers/daqboard2000.c index f97d18d..b2c6bc6 100644 --- a/drivers/staging/comedi/drivers/daqboard2000.c +++ b/drivers/staging/comedi/drivers/daqboard2000.c @@ -32,72 +32,72 @@ http://www.comedi.org in the comedi_nonfree_firmware tarball. Configuration options: not applicable, uses PCI auto config */ /* - This card was obviously never intended to leave the Windows world, - since it lacked all kind of hardware documentation (except for cable - pinouts, plug and pray has something to catch up with yet). - - With some help from our swedish distributor, we got the Windows sourcecode - for the card, and here are the findings so far. - - 1. A good document that describes the PCI interface chip is 9080db-106.pdf - available from http://www.plxtech.com/products/io/pci9080 - - 2. The initialization done so far is: -a. program the FPGA (windows code sans a lot of error messages) - b. - - 3. Analog out seems to work OK with DAC's disabled, if DAC's are enabled, - you have to output values to all enabled DAC's until result appears, I - guess that it has something to do with pacer clocks, but the source - gives me no clues. I'll keep it simple so far. - - 4. Analog in. -Each channel in the scanlist seems to be controlled by four - control words: - -Word0: - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! | | | ! | | | ! | | | ! | | | ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -Word1: - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! | | | ! | | | ! | | | ! | | | ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + This card was obviously never intended to leave the Windows world, + since it lacked all kind of hardware documentation (except for cable + pinouts, plug and pray has something to catch up with yet). + + With some help from our swedish distributor, we got the Windows + sourcecode for the card, and here are the findings so far. + + 1. A good document that describes the PCI interface chip is + 9080db-106.pdf available from http://www.plxtech.com/products/io/pci9080 + + 2. The initialization done so far is: + a. program the FPGA (windows code sans a lot of error messages) + b. + + 3. Analog out seems to work OK with DAC's disabled, if DAC's are + enabled, you have to output values to all enabled DAC's until result + appears, I guess that it has something to do with pacer clocks, but the + source gives me no clues. I'll keep it simple so far. + + 4. Analog in. + Each channel in the scanlist seems to be controlled by four + control words: + + Word0: + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! | | | ! | | | ! | | | ! | | | ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Word1: + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! | | | ! | | | ! | | | ! | | | ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | - +--+--+ | | | | +-- Digital input (??) + +--+--+ | | | | +-- Digital input (??) | | | | + 10 us settling time | | | +-- Suspend acquisition (last to scan) | | + Simultaneous sample and hold | +-- Signed data format +- Correction offset low -Word2: - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! | | | ! | | | ! | | | ! | | | ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | | | | | | | | | - +-+ +--+--+ +++ +++ +--+--+ - | | | | +- Expansion channel + Word2: + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! | | | ! | | | ! | | | ! | | | ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | | | | | | | + +-+ +--+--+ +++ +++ +--+--+ + | | | | +- Expansion channel | | | +--- Expansion gain - | | +--- Channel (low) + | | +--- Channel (low) | +- Correction offset high +- Correction gain low -Word3: -
[PATCH v4 2/3] net/phy: micrel: Comment MMD address of extended registers
There are some defines for a few pad skew related extended registers. Specify for which MMD Address (dev_addr) they are for. Signed-off-by: Jaeden Amero --- drivers/net/phy/micrel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 59cc5d4..f23765e 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -366,6 +366,7 @@ static int ksz9021_config_init(struct phy_device *phydev) #define KSZ9031_PS_TO_REG 60 /* Extended registers */ +/* MMD Address 0x2 */ #define MII_KSZ9031RN_CONTROL_PAD_SKEW 4 #define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5 #define MII_KSZ9031RN_TX_DATA_PAD_SKEW 6 -- 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 v4 3/3] net/phy: micrel: Center FLP timing at 16ms
Link failures have been observed when using the KSZ9031 with HP 1810-8G
and HP 1910-8G network switches. Center the FLP timing at 16ms to help
avoid intermittent link failures.
>From the KSZ9031RNX and KSZ9031MNX data sheets revision 2.2, section
"Auto-Negotiation Timing":
The KSZ9031[RNX or MNX] Fast Link Pulse (FLP) burst-to-burst
transmit timing for Auto-Negotiation defaults to 8ms. IEEE 802.3
Standard specifies this timing to be 16ms +/-8ms. Some PHY link
partners need to receive the FLP with 16ms centered timing;
otherwise, there can be intermittent link failures and long
link-up times.
The PHY data sheet recommends configuring the FLP burst registers after
power-up/reset and immediately thereafter restarting auto-negotiation, so
we center the FLP timing at 16ms and then restart auto-negotiation in the
config_init for KSZ9031.
Signed-off-by: Jaeden Amero
---
drivers/net/phy/micrel.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f23765e..499185e 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -366,6 +366,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
#define KSZ9031_PS_TO_REG 60
/* Extended registers */
+/* MMD Address 0x0 */
+#define MII_KSZ9031RN_FLP_BURST_TX_LO 3
+#define MII_KSZ9031RN_FLP_BURST_TX_HI 4
+
/* MMD Address 0x2 */
#define MII_KSZ9031RN_CONTROL_PAD_SKEW 4
#define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5
@@ -427,6 +431,22 @@ static int ksz9031_of_load_skew_values(struct phy_device
*phydev,
return ksz9031_extended_write(phydev, OP_DATA, 2, reg, newval);
}
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ int result;
+
+ /* Center KSZ9031RNX FLP timing at 16ms. */
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_HI, 0x0006);
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_LO, 0x1A80);
+
+ if (result)
+ return result;
+
+ return genphy_restart_aneg(phydev);
+}
+
static int ksz9031_config_init(struct phy_device *phydev)
{
const struct device *dev = >dev;
@@ -462,7 +482,8 @@ static int ksz9031_config_init(struct phy_device *phydev)
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
}
- return 0;
+
+ return ksz9031_center_flp_timing(phydev);
}
#define KSZ8873MLL_GLOBAL_CONTROL_40x06
--
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 v4 1/3] net/phy: micrel: Be more const correct
In a few places in this driver, we weren't using const where we could
have. Use const more.
In addition, change the arrays of strings in ksz9031_config_init() to be
not only const, but also static.
Signed-off-by: Jaeden Amero
---
drivers/net/phy/micrel.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index ebdc357..59cc5d4 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -288,9 +288,10 @@ static int kszphy_config_init(struct phy_device *phydev)
}
static int ksz9021_load_values_from_of(struct phy_device *phydev,
- struct device_node *of_node, u16 reg,
- char *field1, char *field2,
- char *field3, char *field4)
+ const struct device_node *of_node,
+ u16 reg,
+ const char *field1, const char *field2,
+ const char *field3, const char *field4)
{
int val1 = -1;
int val2 = -2;
@@ -336,8 +337,8 @@ static int ksz9021_load_values_from_of(struct phy_device
*phydev,
static int ksz9021_config_init(struct phy_device *phydev)
{
- struct device *dev = >dev;
- struct device_node *of_node = dev->of_node;
+ const struct device *dev = >dev;
+ const struct device_node *of_node = dev->of_node;
if (!of_node && dev->parent->of_node)
of_node = dev->parent->of_node;
@@ -389,9 +390,9 @@ static int ksz9031_extended_read(struct phy_device *phydev,
}
static int ksz9031_of_load_skew_values(struct phy_device *phydev,
- struct device_node *of_node,
+ const struct device_node *of_node,
u16 reg, size_t field_sz,
- char *field[], u8 numfields)
+ const char *field[], u8 numfields)
{
int val[4] = {-1, -2, -3, -4};
int matches = 0;
@@ -427,18 +428,18 @@ static int ksz9031_of_load_skew_values(struct phy_device
*phydev,
static int ksz9031_config_init(struct phy_device *phydev)
{
- struct device *dev = >dev;
- struct device_node *of_node = dev->of_node;
- char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
- char *rx_data_skews[4] = {
+ const struct device *dev = >dev;
+ const struct device_node *of_node = dev->of_node;
+ static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
+ static const char *rx_data_skews[4] = {
"rxd0-skew-ps", "rxd1-skew-ps",
"rxd2-skew-ps", "rxd3-skew-ps"
};
- char *tx_data_skews[4] = {
+ static const char *tx_data_skews[4] = {
"txd0-skew-ps", "txd1-skew-ps",
"txd2-skew-ps", "txd3-skew-ps"
};
- char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
+ static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
if (!of_node && dev->parent->of_node)
of_node = dev->parent->of_node;
@@ -519,7 +520,7 @@ ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int ptrad,
int devnum,
static int kszphy_probe(struct phy_device *phydev)
{
const struct kszphy_type *type = phydev->drv->driver_data;
- struct device_node *np = phydev->dev.of_node;
+ const struct device_node *np = phydev->dev.of_node;
struct kszphy_priv *priv;
struct clk *clk;
int ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] net/phy: micrel: Center FLP timing at 16ms
In v2, we add an additional cleanup commit to make an array of strings static const and to improve const correctness generally. We also no longer unnecessarily initialize the result variable in ksz9031_center_flp_timing(). In v3, we remove the unnecessary result variable from ksz9031_config_init() introduced by a previous version of "net/phy: micrel: Center FLP timing at 16ms". In v4, we modify the commit message of "net/phy: micrel: Center FLP timing at 16ms" to replace the awkward quotation of the data sheet's programming procedure with an explanation of why we program the FLP burst registers and restart auto-negotiation where we do (config_init). Jaeden Amero (3): net/phy: micrel: Be more const correct net/phy: micrel: Comment MMD address of extended registers net/phy: micrel: Center FLP timing at 16ms drivers/net/phy/micrel.c | 53 ++-- 1 file changed, 38 insertions(+), 15 deletions(-) -- 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] block: Make CFQ default to IOPS mode on SSDs
On Wed, May 27, 2015 at 1:14 PM, Tahsin Erdogan wrote: > On Tue, May 19, 2015 at 1:55 PM, Tahsin Erdogan wrote: >> CFQ idling causes reduced IOPS throughput on non-rotational disks. >> Since disk head seeking is not applicable to SSDs, it doesn't really >> help performance by anticipating future near-by IO requests. >> >> By turning off idling (and switching to IOPS mode), we allow other >> processes to dispatch IO requests down to the driver and so increase IO >> throughput. >> >> Following FIO benchmark results were taken on a cloud SSD offering with >> idling on and off: >> >> Idling iopsavg-lat(ms)stddevbw >> -- >> On 705490.107 38.697 28217KB/s >>Off2925521.836 11.730117022KB/s >> >> fio --name=temp --size=100G --time_based --ioengine=libaio \ >> --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \ >> --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \ >> --filename=/dev/sdb --runtime=10 --iodepth=64 --numjobs=10 >> >> And the following is from a local SSD run: >> >> Idling iopsavg-lat(ms)stddevbw >> -- >> On1932033.043 14.068 77281KB/s >>Off2162629.465 12.662 86507KB/s >> >> fio --name=temp --size=5G --time_based --ioengine=libaio \ >> --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \ >> --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \ >> --filename=/fio_data --runtime=10 --iodepth=64 --numjobs=10 >> >> Reviewed-by: Nauman Rafique >> Signed-off-by: Tahsin Erdogan >> --- >> block/cfq-iosched.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c >> index 5da8e6e..402be01 100644 >> --- a/block/cfq-iosched.c >> +++ b/block/cfq-iosched.c >> @@ -4460,7 +4460,7 @@ static int cfq_init_queue(struct request_queue *q, >> struct elevator_type *e) >> cfqd->cfq_slice[1] = cfq_slice_sync; >> cfqd->cfq_target_latency = cfq_target_latency; >> cfqd->cfq_slice_async_rq = cfq_slice_async_rq; >> - cfqd->cfq_slice_idle = cfq_slice_idle; >> + cfqd->cfq_slice_idle = blk_queue_nonrot(q) ? 0 : cfq_slice_idle; >> cfqd->cfq_group_idle = cfq_group_idle; >> cfqd->cfq_latency = 1; >> cfqd->hw_tag = -1; >> -- >> 2.2.0.rc0.207.ga3a616c >> > > Ping... Trying once more.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] EDAC, mce_amd_inj: Include irq_vectors header to fix build errors
Even though !CONFIG_SMP and MCE injection are practically mutually exclusive, it's better to include irq_vectors.h just in case randconfig builders out there don't set CONFIG_SMP. When that happens, DEFERRED_ERROR_VECTOR and THRESHOLD_APIC_VECTOR macro definitions go out of scope and kernel build will fail. Tested the .config that broke the build against latest tip with changes in for-next branch of bp.git and it builds fine now. Reported-by: kbuild test robot Cc: kbuild-...@01.org Signed-off-by: Aravind Gopalakrishnan --- drivers/edac/mce_amd_inj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/edac/mce_amd_inj.c b/drivers/edac/mce_amd_inj.c index 3f7217f..3e1b53f 100644 --- a/drivers/edac/mce_amd_inj.c +++ b/drivers/edac/mce_amd_inj.c @@ -18,6 +18,7 @@ #include #include #include +#include #include "mce_amd.h" -- 2.4.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] Doc:nfc: Fix typo in nfc-hci.txt
On Fri, 5 Jun 2015 21:38:19 +0900 Masanari Iida wrote: > This patch fix a spelling typo in nfc-hci.txt Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl: dt-binding: Add DT binding documentation for MSM8660
Signed-off-by: Bjorn Andersson
---
.../bindings/pinctrl/qcom,msm8660-pinctrl.txt | 90 ++
1 file changed, 90 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
new file mode 100644
index ..77aa11790163
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
@@ -0,0 +1,90 @@
+Qualcomm MSM8660 TLMM block
+
+Required properties:
+- compatible: "qcom,msm8660-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+The first cell is the gpio pin number and the
+second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an arbitrary number
of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+
+Valid values for pins are:
+ gpio0-gpio172, sdc3_clk, sdc3_cmd, sdc3_data sdc4_clk, sdc4_cmd, sdc4_data
+
+Valid values for function are:
+ gpio, cam_mclk, dsub, ext_gps, gp_clk_0a, gp_clk_0b, gp_clk_1a, gp_clk_1b,
+ gp_clk_2a, gp_clk_2b, gp_mn, gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n,
+ gsbi1_spi_cs2b_n, gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n,
+ gsbi2_spi_cs3_n, gsbi3, gsbi3_spi_cs1_n, gsbi3_spi_cs2_n, gsbi3_spi_cs3_n,
+ gsbi4, gsbi5, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11, gsbi12, hdmi, i2s,
+ lcdc, mdp_vsync, mi2s, pcm, ps_hold, sdc1, sdc2, sdc5, tsif1, tsif2, usb_fs1,
+ usb_fs1_oe_n, usb_fs2, usb_fs2_oe_n, vfe, vsens_alarm,
+
+Example:
+
+ msmgpio: pinctrl@80 {
+ compatible = "qcom,msm8660-pinctrl";
+ reg = <0x80 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 16 0x4>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart>;
+
+ gsbi12_uart: gsbi12-uart {
+ mux {
+ pins = "gpio117", "gpio118";
+ function = "gsbi12";
+ };
+
+ tx {
+ pins = "gpio118";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ rx {
+ pins = "gpio117";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+ };
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] pinctrl: qcom: Add MSM8660 pinctrl definitions
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/qcom/Kconfig | 8 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-msm8660.c | 984 +
3 files changed, 993 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8660.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index ea575f60f001..58f5632b27f4 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -31,6 +31,14 @@ config PINCTRL_IPQ8064
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ8064 platform.
+config PINCTRL_MSM8660
+ tristate "Qualcomm 8660 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found in the Qualcomm 8660 platform.
+
config PINCTRL_MSM8960
tristate "Qualcomm 8960 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 68958702917d..3666c703ce88 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PINCTRL_MSM) += pinctrl-msm.o
obj-$(CONFIG_PINCTRL_APQ8064) += pinctrl-apq8064.o
obj-$(CONFIG_PINCTRL_APQ8084) += pinctrl-apq8084.o
obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
+obj-$(CONFIG_PINCTRL_MSM8660) += pinctrl-msm8660.o
obj-$(CONFIG_PINCTRL_MSM8960) += pinctrl-msm8960.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
obj-$(CONFIG_PINCTRL_MSM8916) += pinctrl-msm8916.o
diff --git a/drivers/pinctrl/qcom/pinctrl-msm8660.c
b/drivers/pinctrl/qcom/pinctrl-msm8660.c
new file mode 100644
index ..3e8f7ac2ac8a
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-msm8660.c
@@ -0,0 +1,984 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+static const struct pinctrl_pin_desc msm8660_pins[] = {
+ PINCTRL_PIN(0, "GPIO_0"),
+ PINCTRL_PIN(1, "GPIO_1"),
+ PINCTRL_PIN(2, "GPIO_2"),
+ PINCTRL_PIN(3, "GPIO_3"),
+ PINCTRL_PIN(4, "GPIO_4"),
+ PINCTRL_PIN(5, "GPIO_5"),
+ PINCTRL_PIN(6, "GPIO_6"),
+ PINCTRL_PIN(7, "GPIO_7"),
+ PINCTRL_PIN(8, "GPIO_8"),
+ PINCTRL_PIN(9, "GPIO_9"),
+ PINCTRL_PIN(10, "GPIO_10"),
+ PINCTRL_PIN(11, "GPIO_11"),
+ PINCTRL_PIN(12, "GPIO_12"),
+ PINCTRL_PIN(13, "GPIO_13"),
+ PINCTRL_PIN(14, "GPIO_14"),
+ PINCTRL_PIN(15, "GPIO_15"),
+ PINCTRL_PIN(16, "GPIO_16"),
+ PINCTRL_PIN(17, "GPIO_17"),
+ PINCTRL_PIN(18, "GPIO_18"),
+ PINCTRL_PIN(19, "GPIO_19"),
+ PINCTRL_PIN(20, "GPIO_20"),
+ PINCTRL_PIN(21, "GPIO_21"),
+ PINCTRL_PIN(22, "GPIO_22"),
+ PINCTRL_PIN(23, "GPIO_23"),
+ PINCTRL_PIN(24, "GPIO_24"),
+ PINCTRL_PIN(25, "GPIO_25"),
+ PINCTRL_PIN(26, "GPIO_26"),
+ PINCTRL_PIN(27, "GPIO_27"),
+ PINCTRL_PIN(28, "GPIO_28"),
+ PINCTRL_PIN(29, "GPIO_29"),
+ PINCTRL_PIN(30, "GPIO_30"),
+ PINCTRL_PIN(31, "GPIO_31"),
+ PINCTRL_PIN(32, "GPIO_32"),
+ PINCTRL_PIN(33, "GPIO_33"),
+ PINCTRL_PIN(34, "GPIO_34"),
+ PINCTRL_PIN(35, "GPIO_35"),
+ PINCTRL_PIN(36, "GPIO_36"),
+ PINCTRL_PIN(37, "GPIO_37"),
+ PINCTRL_PIN(38, "GPIO_38"),
+ PINCTRL_PIN(39, "GPIO_39"),
+ PINCTRL_PIN(40, "GPIO_40"),
+ PINCTRL_PIN(41, "GPIO_41"),
+ PINCTRL_PIN(42, "GPIO_42"),
+ PINCTRL_PIN(43, "GPIO_43"),
+ PINCTRL_PIN(44, "GPIO_44"),
+ PINCTRL_PIN(45, "GPIO_45"),
+ PINCTRL_PIN(46, "GPIO_46"),
+ PINCTRL_PIN(47, "GPIO_47"),
+ PINCTRL_PIN(48, "GPIO_48"),
+ PINCTRL_PIN(49, "GPIO_49"),
+ PINCTRL_PIN(50, "GPIO_50"),
+ PINCTRL_PIN(51, "GPIO_51"),
+ PINCTRL_PIN(52, "GPIO_52"),
+ PINCTRL_PIN(53, "GPIO_53"),
+ PINCTRL_PIN(54, "GPIO_54"),
+ PINCTRL_PIN(55, "GPIO_55"),
+ PINCTRL_PIN(56, "GPIO_56"),
+ PINCTRL_PIN(57, "GPIO_57"),
+ PINCTRL_PIN(58, "GPIO_58"),
+ PINCTRL_PIN(59, "GPIO_59"),
+ PINCTRL_PIN(60, "GPIO_60"),
+ PINCTRL_PIN(61, "GPIO_61"),
+ PINCTRL_PIN(62, "GPIO_62"),
+ PINCTRL_PIN(63, "GPIO_63"),
+ PINCTRL_PIN(64, "GPIO_64"),
+ PINCTRL_PIN(65, "GPIO_65"),
+ PINCTRL_PIN(66, "GPIO_66"),
+
[PATCH 3/3] ARM: dts: qcom: Replace gpio node with pinctrl node
Replace the standalone gpio driver with pinctrl-msm as we now have
msm8660 support there.
Signed-off-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-msm8660.dtsi | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi
b/arch/arm/boot/dts/qcom-msm8660.dtsi
index 20bbd19b996e..28bba8b09854 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -62,15 +62,16 @@
cpu-offset = <0x4>;
};
- msmgpio: gpio@80 {
- compatible = "qcom,msm-gpio";
- reg = <0x0080 0x4000>;
+ tlmm: pinctrl@80 {
+ compatible = "qcom,msm8660-pinctrl";
+ reg = <0x80 0x4000>;
+
gpio-controller;
#gpio-cells = <2>;
- ngpio = <173>;
interrupts = <0 16 0x4>;
interrupt-controller;
#interrupt-cells = <2>;
+
};
gcc: clock-controller@90 {
@@ -110,7 +111,7 @@
pmicintc: pmic@0 {
compatible = "qcom,pm8058";
- interrupt-parent = <>;
+ interrupt-parent = <>;
interrupts = <88 8>;
#interrupt-cells = <2>;
interrupt-controller;
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Pinctrl support for msm8660
Per your request Linus, happy birthday! Regards, Bjorn Bjorn Andersson (3): pinctrl: qcom: Add MSM8660 pinctrl definitions pinctrl: dt-binding: Add DT binding documentation for MSM8660 ARM: dts: qcom: Replace gpio node with pinctrl node .../bindings/pinctrl/qcom,msm8660-pinctrl.txt | 90 ++ arch/arm/boot/dts/qcom-msm8660.dtsi| 11 +- drivers/pinctrl/qcom/Kconfig | 8 + drivers/pinctrl/qcom/Makefile | 1 + drivers/pinctrl/qcom/pinctrl-msm8660.c | 984 + 5 files changed, 1089 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8660.c -- 1.8.2.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 v3 3/3] net/phy: micrel: Center FLP timing at 16ms
On 06/05/2015 05:43 PM, Florian Fainelli wrote: > On 05/06/15 15:40, Jaeden Amero wrote: >> Link failures have been observed when using the KSZ9031 with HP 1810-8G >> and HP 1910-8G network switches. Center the FLP timing at 16ms to help >> avoid intermittent link failures. >> >> From the KSZ9031RNX and KSZ9031MNX data sheets revision 2.2, section >> "Auto-Negotiation Timing": >> The KSZ9031[RNX or MNX] Fast Link Pulse (FLP) burst-to-burst >> transmit timing for Auto-Negotiation defaults to 8ms. IEEE 802.3 >> Standard specifies this timing to be 16ms +/-8ms. Some PHY link >> partners need to receive the FLP with 16ms centered timing; >> otherwise, there can be intermittent link failures and long >> link-up times. >> >> After KSZ9031[RNX or MNX] power-up/reset, program the following >> register sequence to set the FLP timing to 16ms >> >> Write Register Dh = 0x // Set up register address for MMD – Device >> Address 0h >> Write Register Eh = 0x0004 // Select Register 4h of MMD – Device >> Address 0h >> Write Register Dh = 0x4000 // Select register data for MMD – Device >> Address 0h, Register 4h >> Write Register Eh = 0x0006 // Write value 0x0006 to MMD – Device >> Address 0h, Register 4h >> Write Register Dh = 0x // Set up register address for MMD – Device >> Address 0h >> Write Register Eh = 0x0003 // Select Register 3h of MMD – Device >> Address 0h >> Write Register Dh = 0x4000 // Select register data for MMD – Device >> Address 0h, Register 3h >> Write Register Eh = 0x1A80 // Write value 0x1A80 to MMD – Device >> Address 0h, Register 3h >> Write Register 0h, Bit [9] = 1 // Restart Auto-Negotiation > > Quoting a portion of the data-sheet on how to do this programming is > very strange considering that the code is going to be the reference, not > the commit message. I included it for lack of something better to quote that explained which values to set when. I'd be happy to revise the message as this appears too strange. > Other than that, this looks reasonable. Thanks very much for the review. Cheers, Jaeden -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] net/phy: micrel: Center FLP timing at 16ms
On 05/06/15 15:40, Jaeden Amero wrote: > In v2, we add an additional cleanup commit to make an array of strings > static const and to improve const correctness generally. We also no longer > unnecessarily initialize the result variable in > ksz9031_center_flp_timing(). > > In v3, we remove the unnecessary result variable from ksz9031_config_init() > introduced by a previous version of "net/phy: micrel: Center FLP timing at > 16ms". Reviewed-by: Florian Fainelli > > Jaeden Amero (3): > net/phy: micrel: Be more const correct > net/phy: micrel: Comment MMD address of extended registers > net/phy: micrel: Center FLP timing at 16ms > > drivers/net/phy/micrel.c | 53 > ++-- > 1 file changed, 38 insertions(+), 15 deletions(-) > -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] net/phy: micrel: Center FLP timing at 16ms
On 05/06/15 15:40, Jaeden Amero wrote:
> Link failures have been observed when using the KSZ9031 with HP 1810-8G
> and HP 1910-8G network switches. Center the FLP timing at 16ms to help
> avoid intermittent link failures.
>
> From the KSZ9031RNX and KSZ9031MNX data sheets revision 2.2, section
> "Auto-Negotiation Timing":
> The KSZ9031[RNX or MNX] Fast Link Pulse (FLP) burst-to-burst
> transmit timing for Auto-Negotiation defaults to 8ms. IEEE 802.3
> Standard specifies this timing to be 16ms +/-8ms. Some PHY link
> partners need to receive the FLP with 16ms centered timing;
> otherwise, there can be intermittent link failures and long
> link-up times.
>
> After KSZ9031[RNX or MNX] power-up/reset, program the following
> register sequence to set the FLP timing to 16ms
>
> Write Register Dh = 0x // Set up register address for MMD – Device
> Address 0h
> Write Register Eh = 0x0004 // Select Register 4h of MMD – Device
> Address 0h
> Write Register Dh = 0x4000 // Select register data for MMD – Device
> Address 0h, Register 4h
> Write Register Eh = 0x0006 // Write value 0x0006 to MMD – Device
> Address 0h, Register 4h
> Write Register Dh = 0x // Set up register address for MMD – Device
> Address 0h
> Write Register Eh = 0x0003 // Select Register 3h of MMD – Device
> Address 0h
> Write Register Dh = 0x4000 // Select register data for MMD – Device
> Address 0h, Register 3h
> Write Register Eh = 0x1A80 // Write value 0x1A80 to MMD – Device
> Address 0h, Register 3h
> Write Register 0h, Bit [9] = 1 // Restart Auto-Negotiation
Quoting a portion of the data-sheet on how to do this programming is
very strange considering that the code is going to be the reference, not
the commit message.
Other than that, this looks reasonable.
>
> Signed-off-by: Jaeden Amero
> ---
> drivers/net/phy/micrel.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index f23765e..499185e 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -366,6 +366,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
> #define KSZ9031_PS_TO_REG60
>
> /* Extended registers */
> +/* MMD Address 0x0 */
> +#define MII_KSZ9031RN_FLP_BURST_TX_LO3
> +#define MII_KSZ9031RN_FLP_BURST_TX_HI4
> +
> /* MMD Address 0x2 */
> #define MII_KSZ9031RN_CONTROL_PAD_SKEW 4
> #define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5
> @@ -427,6 +431,22 @@ static int ksz9031_of_load_skew_values(struct phy_device
> *phydev,
> return ksz9031_extended_write(phydev, OP_DATA, 2, reg, newval);
> }
>
> +static int ksz9031_center_flp_timing(struct phy_device *phydev)
> +{
> + int result;
> +
> + /* Center KSZ9031RNX FLP timing at 16ms. */
> + result = ksz9031_extended_write(phydev, OP_DATA, 0,
> + MII_KSZ9031RN_FLP_BURST_TX_HI, 0x0006);
> + result = ksz9031_extended_write(phydev, OP_DATA, 0,
> + MII_KSZ9031RN_FLP_BURST_TX_LO, 0x1A80);
> +
> + if (result)
> + return result;
> +
> + return genphy_restart_aneg(phydev);
> +}
> +
> static int ksz9031_config_init(struct phy_device *phydev)
> {
> const struct device *dev = >dev;
> @@ -462,7 +482,8 @@ static int ksz9031_config_init(struct phy_device *phydev)
> MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
> tx_data_skews, 4);
> }
> - return 0;
> +
> + return ksz9031_center_flp_timing(phydev);
> }
>
> #define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] net/phy: micrel: Be more const correct
In a few places in this driver, we weren't using const where we could
have. Use const more.
In addition, change the arrays of strings in ksz9031_config_init() to be
not only const, but also static.
Signed-off-by: Jaeden Amero
---
drivers/net/phy/micrel.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index ebdc357..59cc5d4 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -288,9 +288,10 @@ static int kszphy_config_init(struct phy_device *phydev)
}
static int ksz9021_load_values_from_of(struct phy_device *phydev,
- struct device_node *of_node, u16 reg,
- char *field1, char *field2,
- char *field3, char *field4)
+ const struct device_node *of_node,
+ u16 reg,
+ const char *field1, const char *field2,
+ const char *field3, const char *field4)
{
int val1 = -1;
int val2 = -2;
@@ -336,8 +337,8 @@ static int ksz9021_load_values_from_of(struct phy_device
*phydev,
static int ksz9021_config_init(struct phy_device *phydev)
{
- struct device *dev = >dev;
- struct device_node *of_node = dev->of_node;
+ const struct device *dev = >dev;
+ const struct device_node *of_node = dev->of_node;
if (!of_node && dev->parent->of_node)
of_node = dev->parent->of_node;
@@ -389,9 +390,9 @@ static int ksz9031_extended_read(struct phy_device *phydev,
}
static int ksz9031_of_load_skew_values(struct phy_device *phydev,
- struct device_node *of_node,
+ const struct device_node *of_node,
u16 reg, size_t field_sz,
- char *field[], u8 numfields)
+ const char *field[], u8 numfields)
{
int val[4] = {-1, -2, -3, -4};
int matches = 0;
@@ -427,18 +428,18 @@ static int ksz9031_of_load_skew_values(struct phy_device
*phydev,
static int ksz9031_config_init(struct phy_device *phydev)
{
- struct device *dev = >dev;
- struct device_node *of_node = dev->of_node;
- char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
- char *rx_data_skews[4] = {
+ const struct device *dev = >dev;
+ const struct device_node *of_node = dev->of_node;
+ static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
+ static const char *rx_data_skews[4] = {
"rxd0-skew-ps", "rxd1-skew-ps",
"rxd2-skew-ps", "rxd3-skew-ps"
};
- char *tx_data_skews[4] = {
+ static const char *tx_data_skews[4] = {
"txd0-skew-ps", "txd1-skew-ps",
"txd2-skew-ps", "txd3-skew-ps"
};
- char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
+ static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
if (!of_node && dev->parent->of_node)
of_node = dev->parent->of_node;
@@ -519,7 +520,7 @@ ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int ptrad,
int devnum,
static int kszphy_probe(struct phy_device *phydev)
{
const struct kszphy_type *type = phydev->drv->driver_data;
- struct device_node *np = phydev->dev.of_node;
+ const struct device_node *np = phydev->dev.of_node;
struct kszphy_priv *priv;
struct clk *clk;
int ret;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] net/phy: micrel: Center FLP timing at 16ms
Link failures have been observed when using the KSZ9031 with HP 1810-8G
and HP 1910-8G network switches. Center the FLP timing at 16ms to help
avoid intermittent link failures.
>From the KSZ9031RNX and KSZ9031MNX data sheets revision 2.2, section
"Auto-Negotiation Timing":
The KSZ9031[RNX or MNX] Fast Link Pulse (FLP) burst-to-burst
transmit timing for Auto-Negotiation defaults to 8ms. IEEE 802.3
Standard specifies this timing to be 16ms +/-8ms. Some PHY link
partners need to receive the FLP with 16ms centered timing;
otherwise, there can be intermittent link failures and long
link-up times.
After KSZ9031[RNX or MNX] power-up/reset, program the following
register sequence to set the FLP timing to 16ms
Write Register Dh = 0x // Set up register address for MMD – Device
Address 0h
Write Register Eh = 0x0004 // Select Register 4h of MMD – Device
Address 0h
Write Register Dh = 0x4000 // Select register data for MMD – Device
Address 0h, Register 4h
Write Register Eh = 0x0006 // Write value 0x0006 to MMD – Device
Address 0h, Register 4h
Write Register Dh = 0x // Set up register address for MMD – Device
Address 0h
Write Register Eh = 0x0003 // Select Register 3h of MMD – Device
Address 0h
Write Register Dh = 0x4000 // Select register data for MMD – Device
Address 0h, Register 3h
Write Register Eh = 0x1A80 // Write value 0x1A80 to MMD – Device
Address 0h, Register 3h
Write Register 0h, Bit [9] = 1 // Restart Auto-Negotiation
Signed-off-by: Jaeden Amero
---
drivers/net/phy/micrel.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f23765e..499185e 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -366,6 +366,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
#define KSZ9031_PS_TO_REG 60
/* Extended registers */
+/* MMD Address 0x0 */
+#define MII_KSZ9031RN_FLP_BURST_TX_LO 3
+#define MII_KSZ9031RN_FLP_BURST_TX_HI 4
+
/* MMD Address 0x2 */
#define MII_KSZ9031RN_CONTROL_PAD_SKEW 4
#define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5
@@ -427,6 +431,22 @@ static int ksz9031_of_load_skew_values(struct phy_device
*phydev,
return ksz9031_extended_write(phydev, OP_DATA, 2, reg, newval);
}
+static int ksz9031_center_flp_timing(struct phy_device *phydev)
+{
+ int result;
+
+ /* Center KSZ9031RNX FLP timing at 16ms. */
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_HI, 0x0006);
+ result = ksz9031_extended_write(phydev, OP_DATA, 0,
+ MII_KSZ9031RN_FLP_BURST_TX_LO, 0x1A80);
+
+ if (result)
+ return result;
+
+ return genphy_restart_aneg(phydev);
+}
+
static int ksz9031_config_init(struct phy_device *phydev)
{
const struct device *dev = >dev;
@@ -462,7 +482,8 @@ static int ksz9031_config_init(struct phy_device *phydev)
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
}
- return 0;
+
+ return ksz9031_center_flp_timing(phydev);
}
#define KSZ8873MLL_GLOBAL_CONTROL_40x06
--
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 v3 2/3] net/phy: micrel: Comment MMD address of extended registers
There are some defines for a few pad skew related extended registers. Specify for which MMD Address (dev_addr) they are for. Signed-off-by: Jaeden Amero --- drivers/net/phy/micrel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 59cc5d4..f23765e 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -366,6 +366,7 @@ static int ksz9021_config_init(struct phy_device *phydev) #define KSZ9031_PS_TO_REG 60 /* Extended registers */ +/* MMD Address 0x2 */ #define MII_KSZ9031RN_CONTROL_PAD_SKEW 4 #define MII_KSZ9031RN_RX_DATA_PAD_SKEW 5 #define MII_KSZ9031RN_TX_DATA_PAD_SKEW 6 -- 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 v3 0/3] net/phy: micrel: Center FLP timing at 16ms
In v2, we add an additional cleanup commit to make an array of strings static const and to improve const correctness generally. We also no longer unnecessarily initialize the result variable in ksz9031_center_flp_timing(). In v3, we remove the unnecessary result variable from ksz9031_config_init() introduced by a previous version of "net/phy: micrel: Center FLP timing at 16ms". Jaeden Amero (3): net/phy: micrel: Be more const correct net/phy: micrel: Comment MMD address of extended registers net/phy: micrel: Center FLP timing at 16ms drivers/net/phy/micrel.c | 53 ++-- 1 file changed, 38 insertions(+), 15 deletions(-) -- 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 3/3] net/phy: micrel: Center FLP timing at 16ms
On 06/05/2015 04:09 PM, Sergei Shtylyov wrote:
>> @@ -441,6 +461,7 @@ static int ksz9031_config_init(struct phy_device
>> *phydev)
>> "txd2-skew-ps", "txd3-skew-ps"
>> };
>> static const char *control_skews[2] = {"txen-skew-ps",
>> "rxdv-skew-ps"};
>> +int result;
>
>You hardly need this variable...
>
>>
>> if (!of_node && dev->parent->of_node)
>> of_node = dev->parent->of_node;
>> @@ -462,7 +483,10 @@ static int ksz9031_config_init(struct phy_device
>> *phydev)
>> MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
>> tx_data_skews, 4);
>> }
>> -return 0;
>> +
>> +result = ksz9031_center_flp_timing(phydev);
>> +
>> +return result;
>
>Why not just return directly?
>
Genius.
Thanks for the feedback. I'll post a v3.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] timer: Remove FIFO guarantee
Two thoughts: 1) It's not clear that timer slack has violated the FIFO guarantee. Remember, the guarantee only applies when two timers have the same (absolute) timeout; i.e. are requested for the same time. For two entries with the same timeout, applying slack will produce the same adjusted timeout. That's the whole point of slack; to force the timeouts to collide more. Because the unadjusted timeouts aren't stored, timeout ordering can be violated; i.e. timers for time t and t+1, which round to the same time ater slack is applied, will expire in FIFO order rather than timeout order. This is non- But in the case where he FIFO guatantee used to exist, I don't think timer slack broke it. I'm not disagreeing with the change, but it's not clear to me that it's as safe as you think. 2) If you want to do some more in that area, one thing I've been meaning to get around to is eliminating the whole round_jiffies() system. It does basically the same thing as the slack system, although with less flexibility, and it would be wonderful to rip it out of the kernel completely. Additional rambling you should ignore. It exists because I haven't figured out why it's impractical yet. An interesting variant on the slack system would be to apply slack in the wakeup loop rather than before sleeping. It might permit more bundling and thus fewer wakeups. You have the timers in original order. But computing the next expiration is more complex. Each timer has a minimum and maximum wakeup time, and they're sorted by minimum time. You scan the list of pending timers, accumulating a "batch" which can all be woken up together. You keep intersecting each new timer's wakeup interval with the pending batch, until the batch maximum is less than the next timer's minimum. The final result is a range of permissible timeouts, from which one is chosen as the processor wakeup time. I'd be inclined to err on the low side, but whatever works. (It's also permissible to limit the size of a batch arbitrarily. After scanning N timers, just pick a wakeup time no later than the N+1st timer's minimum time and stop.) When a new timer is added, there are three cases: 1) (Common) Its minimum timeout is later than the current pending wakeup. Add it to the pending queue normally. 2) Its wakeup range includes the pending time. Add it to the batch. 3) Its maximum wakeup time is less than the pending time. Reschedule the hardware timer. When it goes off, scan the batch for additional timers that can be fired now, before building the new batch. The idea is that each timer would be scanned twice: once when building the batch, and a second time when running it. Except that's not true if the third case happens frequently, and batches keep getting preempted and re-scanned. But there's an easy workaround to avoid O(n^2): at the expense of possibly non-optimal wakeups, if what's left of the old batch is larger than reasonable to rescan, just remember the old wakeup range (the minimum will be accurate, because it's the minimum of the last timer in the batch, which is still pending, but the maximum might be wrong) and extend the batch without recomputing the maximum. There's probably some reason this can't be made to work, but I wanted to do a brain dump. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] net/bonding: fix propagation of user-specified bond MAC
Its possible for users to specify their own MAC address for a bonded link, and this used to work, until sometime in 2013... First, commit 409cc1f8a changed a condition to set the bond's mac to a slave device's, dropping the is_zero_ether_addr() check in favor of using bond->dev_addr_from_first. Next, commit 6c8c4e4c2 added a bond->slave_cnt == 0 condition. Then, commit 97a1e6396 removed dev_addr_from_first and keyed off of bond->dev->addr_assign_type. The other contitional in the check to call bond_set_dev_addr() has gone through some permutations, finally landing at the following check: if (!bond_has_slaves(bond) && bond->dev->addr_assign_type == NET_ADDR_RANDOM) bond_set_dev_addr(bond->dev, slave_dev); When the bond is initially brought up, with no active slaves, it gets assigned a random address, and addr_assign_type is set to NET_ADDR_RANDOM. Next up though, the user can provide their own MAC, which ultimately calls bond_set_mac_address(). However, because addr_assign_type isn't touched, the above conditions are still met, and the slave's MAC overwrites the user-provided MAC. The simple fix is to set addr_assign_type = NET_ADDR_SET at the tail end of bond_set_mac_address() doing its thing, and user-specified MAC addresses no longer get overwritten. Nb: this is slightly tricky to test on current Fedora, as nmcli seems to be braindead when it comes to setting a MAC address for a bond. I can do a "nmcli con edit bond0", set ethernet.mac-address "xx:yy:zz:aa:bb:cc", but it doesn't ever seem to do anything, and it doesn't persist to the next boot. Manual tinkering was required to verify the issue and the fix using ip link set commands. CC: Jay Vosburgh CC: Veaceslav Falico CC: Andy Gospodarek CC: net...@vger.kernel.org (open list:BONDING DRIVER) Signed-off-by: Jarod Wilson --- drivers/net/bonding/bond_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 19eb990..2aa5b5f 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3544,6 +3544,7 @@ static int bond_set_mac_address(struct net_device *bond_dev, void *addr) /* success */ memcpy(bond_dev->dev_addr, sa->sa_data, bond_dev->addr_len); + bond_dev->addr_assign_type = NET_ADDR_SET; return 0; unwind: -- 1.8.3.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 v4 1/9] introduce __pfn_t for scatterlists and pmem
On Fri, Jun 5, 2015 at 2:37 PM, Linus Torvalds
wrote:
> On Fri, Jun 5, 2015 at 2:19 PM, Dan Williams wrote:
>> +enum {
>> +#if BITS_PER_LONG == 64
>> + PFN_SHIFT = 3,
>> + /* device-pfn not covered by memmap */
>> + PFN_DEV = (1UL << 2),
>> +#else
>> + PFN_SHIFT = 2,
>> +#endif
>> + PFN_MASK = (1UL << PFN_SHIFT) - 1,
>> + PFN_SG_CHAIN = (1UL << 0),
>> + PFN_SG_LAST = (1UL << 1),
>> +};
>
> Ugh. Just make PFN_SHIFT unconditional. Make it 2, unconditionally.
> Or, if you want to have more bits, make it three unconditionally, and
> make 'struct page' just be at least 8-byte aligned even on 32-bit.
>
> Even on 32-bit architectures, there's plenty of bits. There's no
> reason to "pack" this optimally. Remember: it's a page frame number,
> so there's the page size shifting going on in physical memory, and
> even if you shift the PFN by 3 - or four of five - bits
> unconditionally (rather than try to shift it by some minimal number),
> you're covering a *lot* of physical memory.
It is a page frame number, but page_to_pfn_t() just stores the value
of the struct page pointer directly, so we really only have the
pointer alignment bits. I do this so that kmap_atomic_pfn_t() can
optionally call kmap_atomic() if the pfn is mapped.
>
> Say you're a 32-bit architecture with a 4k page size, and you lose
> three bits to "type" bits. You still have 32+12-3=41 bits of physical
> address space. Which is way more than realistic for a 32-bit
> architecture anyway, even with PAE (or PXE or whatever ARM calls it).
> Not that I see persistent memory being all that relevant on 32-bit
> hardware anyway.
>
> So I think if you actually do want that third bit, you're better off
> just marking "struct page" as being __aligned__((8)) and getting the
> three bits unconditionally. Just make the rule be that mem_map[] has
> to be 8-byte aligned.
>
> Even 16-byte alignment would probably be fine. No?
>
Ooh, that's great, I was already lamenting the fact that I had run out
of bits. One of the reasons to go to 16-byte alignment is to have
another bit to further qualify the pfn as persistent memory not just
un-mapped memory. The rationale would be to generate, and verify
proper usage of, __pmem annotated pointers.
...but I'm still waiting for someone to tell me I'm needlessly
complicating things with a __pmem annotation [1].
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-June/001087.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] fusion: remove dead MTRR code
On Fri, Jun 05, 2015 at 05:17:08PM +0530, Sreekanth Reddy wrote: > On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez wrote: > > On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote: > >> Hi Luis, > >> > >> Sorry for delay in response. Actually I was looking for the history of > >> this section of code but I couldn't find it. Anyway this is dead code > >> and we are fine with removing this dead code. > >> > >> James, > >> > >> Please consider this patch as: > >> > >> Acked-by: Sreekanth Reddy > > > > Great thanks, now who's tree should this patch go through? Last patch for > > this > > driver was in 2014 and went through Christoph, but if Christoph doesn't > > want to > > take it can it go through Andrew's tree? > > > > Sreekanth, can you also update the MAINTAINERS file to reflect recent > > changes > > at your company ? > > Sure I will do this. Christoph, do you mind this going through Andrew's tree? Or do you want to take it? 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][PATCH 0/5] Optimize percpu-rwsem
On Fri, Jun 05, 2015 at 11:08:57PM +0200, Oleg Nesterov wrote: > On 06/05, Al Viro wrote: > > > > FWIW, I hadn't really looked into stop_machine uses, but fs/locks.c one > > is really not all that great - there we have a large trashcan of a list > > (every file_lock on the system) and the only use of that list is /proc/locks > > output generation. Sure, additions take this CPU's spinlock. And removals > > take pretty much a random one - losing the timeslice and regaining it on > > a different CPU is quite likely with the uses there. > > > > Why do we need a global lock there, anyway? Why not hold only one for > > the chain currently being traversed? Sure, we'll need to get and drop > > them in ->next() that way; so what? > > And note that fs/seq_file.c:seq_hlist_next_percpu() has no other users. > > And given that locks_delete_global_locks() takes the random lock anyway, > perhaps the hashed lists/locking makes no sense, I dunno. It's not about making life easier for /proc/locks; it's about not screwing those who add/remove file_lock... And no, that "random lock" isn't held when modifying the (per-cpu) lists - it protects the list hanging off each element of the global list, and /proc/locks scans those lists, so rather than taking/dropping it in each ->show(), it's taken once in ->start()... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] seccomp: add ptrace options for suspend/resume
On Fri, Jun 05, 2015 at 11:52:08PM +0200, Oleg Nesterov wrote:
> Tycho,
>
> I hate myself, but I have another nit ;) again, it is not that I think
> you should updtate the patch, just fyi...
No worries :)
> On 06/05, Tycho Andersen wrote:
> >
> > --- a/include/linux/seccomp.h
> > +++ b/include/linux/seccomp.h
> > @@ -95,4 +95,14 @@ static inline void get_seccomp_filter(struct task_struct
> > *tsk)
> > return;
> > }
> > #endif /* CONFIG_SECCOMP_FILTER */
> > +
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > +extern bool may_suspend_seccomp(void);
> > +#else
> > +static inline bool may_suspend_seccomp(void)
> > +{
> > + return false;
> > +}
> > +#endif
>
> This looks wrong. There is no "extern may_suspend_seccomp()" if
> CONFIG_SECCOMP=n, kernel/seccomp.c is not compiled. So you need another
> ifdef(CONFIG_SECCOMP).
>
> At the same time this does not matter and you do not need the dummy
> "inline" version at all:
>
> > @@ -556,6 +557,15 @@ static int ptrace_setoptions(struct task_struct
> > *child, unsigned long data)
> > if (data & ~(unsigned long)PTRACE_O_MASK)
> > return -EINVAL;
> >
> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> > + !config_enabled(CONFIG_SECCOMP))
> > + return -EINVAL;
> > +
> > + if (!may_suspend_seccomp())
> > + return -EPERM;
>
> gcc will optimize out may_suspend_seccomp() unless both options are
> enabled.
Whoops, yes, you're right. I did build test in all the configurations
to catch stuff like this, but gcc was too smart for me. What's the
right thing to do, just leave out the definition of
may_suspend_seccomp all together, or add in another if defined() in
the header?
Maybe we will get rid of this pesky function all together though...
Tycho
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
On Tue, Apr 14, 2015 at 07:37:44AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Tuesday, March 31, 2015 7:56 AM
> > To: Wu, Feng
> > Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
> > g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> > j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> > eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> > io...@lists.linux-foundation.org; k...@vger.kernel.org
> > Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> > is blocked
> >
> > On Mon, Mar 30, 2015 at 04:46:55AM +, Wu, Feng wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > > > Sent: Saturday, March 28, 2015 3:30 AM
> > > > To: Wu, Feng
> > > > Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com;
> > x...@kernel.org;
> > > > g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> > > > j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> > > > eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> > > > io...@lists.linux-foundation.org; k...@vger.kernel.org
> > > > Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when
> > vCPU
> > > > is blocked
> > > >
> > > > On Fri, Mar 27, 2015 at 06:34:14AM +, Wu, Feng wrote:
> > > > > > > Currently, the following code is executed before
> > > > > > > local_irq_disable() is
> > > > called,
> > > > > > > so do you mean 1)moving local_irq_disable() to the place before
> > > > > > > it. 2)
> > after
> > > > > > interrupt
> > > > > > > is disabled, set KVM_REQ_EVENT in case the ON bit is set?
> > > > > >
> > > > > > 2) after interrupt is disabled, set KVM_REQ_EVENT in case the ON bit
> > > > > > is set.
> > > > >
> > > > > Here is my understanding about your comments here:
> > > > > - Disable interrupts
> > > > > - Check 'ON'
> > > > > - Set KVM_REQ_EVENT if 'ON' is set
> > > > >
> > > > > Then we can put the above code inside " if
> > > > (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) "
> > > > > just like it used to be. However, I still have some questions about
> > > > > this
> > > > comment:
> > > > >
> > > > > 1. Where should I set KVM_REQ_EVENT? In function vcpu_enter_guest(),
> > or
> > > > other places?
> > > >
> > > > See below:
> > > >
> > > > > If in vcpu_enter_guest(), since currently local_irq_disable() is
> > > > > called after
> > > > 'KVM_REQ_EVENT'
> > > > > is checked, is it helpful to set KVM_REQ_EVENT after
> > > > > local_irq_disable() is
> > > > called?
> > > >
> > > > local_irq_disable();
> > > >
> > > > *** add code here ***
> > >
> > > So we need add code like the following here, right?
> > >
> > > if ('ON' is set)
> > > kvm_make_request(KVM_REQ_EVENT, vcpu);
> >
>
> Hi Marcelo,
>
> I changed the code as above, then I found that the ping latency was extremely
> big, (70ms - 400ms).
> I digged into it and got the root cause. We cannot use "checking-on" as the
> judgment, since 'ON'
> can be cleared by hypervisor software in lots of places. In this case,
> KVM_REQ_EVENT cannot be
> set when we check 'ON' bit, hence the interrupts are not injected to the
> guest in time.
>
> Please refer to the following code, in which 'ON' bit can be cleared:
>
> apic_find_highest_irr () --> vmx_sync_pir_to_irr () --> pi_test_and_clear_on()
>
> Searching from the code step by step, apic_find_highest_irr() can be called
> by many other guys.
>
> Thanks,
Ok then, ignore my suggestion.
Can you resend the latest version please ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: Simplify and make the function sctp_assoc_lookup_laddr bool
Hi Neil, I would like to kindly ask you to always put full patch in reply when you are replying to Nicks patch. Because he's banned from vger and only people on cc are able to see his patches and this is only way for rest of us to see what is in his patch. Thanks. On 06/05/2015 03:16 PM, Neil Horman wrote: >> This makes the function sctp_assoc_lookup_laddr bool due to it >> only returning either one or zero as its return value. Further >> more this function can we simplified to return the if statement >> as part of this function directly and thus remove the no longer >> required if statement due to this function now being declared >> as bool. >> >> Signed-off-by: Nicholas Krause -- Kind regards, b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] seccomp: add ptrace options for suspend/resume
Tycho,
I hate myself, but I have another nit ;) again, it is not that I think
you should updtate the patch, just fyi...
On 06/05, Tycho Andersen wrote:
>
> --- a/include/linux/seccomp.h
> +++ b/include/linux/seccomp.h
> @@ -95,4 +95,14 @@ static inline void get_seccomp_filter(struct task_struct
> *tsk)
> return;
> }
> #endif /* CONFIG_SECCOMP_FILTER */
> +
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +extern bool may_suspend_seccomp(void);
> +#else
> +static inline bool may_suspend_seccomp(void)
> +{
> + return false;
> +}
> +#endif
This looks wrong. There is no "extern may_suspend_seccomp()" if
CONFIG_SECCOMP=n, kernel/seccomp.c is not compiled. So you need another
ifdef(CONFIG_SECCOMP).
At the same time this does not matter and you do not need the dummy
"inline" version at all:
> @@ -556,6 +557,15 @@ static int ptrace_setoptions(struct task_struct *child,
> unsigned long data)
> if (data & ~(unsigned long)PTRACE_O_MASK)
> return -EINVAL;
>
> + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> + !config_enabled(CONFIG_SECCOMP))
> + return -EINVAL;
> +
> + if (!may_suspend_seccomp())
> + return -EPERM;
gcc will optimize out may_suspend_seccomp() unless both options are
enabled.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] acpi, apei: use EFI memmap to map GHES memory
On 6/5/2015 10:12 AM, Borislav Petkov wrote: On Fri, Jun 05, 2015 at 10:05:13AM -0700, Zhang, Jonathan Zhixiong wrote: What is DDR? I think this needs to be clarified first before we go any further. I thought the word "memory" might be confusing, because there are So you mean normal RAM here? Yes, exactly. I should use this word RAM instead. memories on the system that is not accessible by Linux. In this context, the APEI error data is accessed (read and write) by both Linux and platform firmware; hence both sides should access the memory using same cache attribute. I wanted to emphasize the idea that even though normally DDR is cachable, but in this case when platform access it with un-cached attribute, Linux should do the same. Makes sense. Btw, do we need synchronization between firmware and Linux then? Does Linux need to know when it is ok to touch that memory? Good question. Linux zeros out error status code in the error data after the data is consumed, this is good; but it alone does not solve the synchronization concern. For interrupt notification type (SCI or NMI) error source, this may not be an issue since both sides can operate under the rule that the error data is only overwritten but never appended. But what about poll notification type? In this case, platform gathers error, updates the memory region as needed; Linux checks the same memory region periodically. An ACPI APEI proposal intended to solve this concern has been discussed in UEFI forum. The idea is to have OS to send platform a signal (through updating a designated register) after error data is consumed. Therefore, when OS is accessing the memory region, platform does not try to access the same memory region in the mean time. After this proposal is approved and published, I will submit a patch to implement it. -- Jonathan (Zhixiong) Zhang The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/10] uprobes: Change prepare_uretprobe() to (try to) flush the dead frames
On 05/04, Oleg Nesterov wrote:
>
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1522,6 +1522,16 @@ static unsigned long get_trampoline_vaddr(void)
> return trampoline_vaddr;
> }
>
> +static void cleanup_return_instances(struct uprobe_task *utask, struct
> pt_regs *regs)
> +{
> + struct return_instance *ri = utask->return_instances;
> + while (ri && !arch_uretprobe_is_alive(>auret, regs)) {
> + ri = free_ret_instance(ri);
> + utask->depth--;
> + }
> + utask->return_instances = ri;
> +}
> +
> static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs)
> {
> struct return_instance *ri;
> @@ -1576,6 +1586,9 @@ static void prepare_uretprobe(struct uprobe *uprobe,
> struct pt_regs *regs)
> ri->orig_ret_vaddr = orig_ret_vaddr;
> ri->chained = chained;
>
> + if (utask->depth) /* drop the entries invalidated by longjmp() */
> + cleanup_return_instances(utask, regs);
> +
Self nack ;)
Note that that prepare_uretprobe() does
if (orig_ret_vaddr == trampoline_vaddr) {
if (!utask->return_instances) {
/*
* This situation is not possible. Likely we have an
* attack from user-space.
*/
pr_warn("uprobe: unable to set uretprobe
pid/tgid=%d/%d\n",
current->pid, current->tgid);
goto fail;
_before_ we do cleanup_return_instances().
This is actually fine in a sense that ->return_instances == NULL after
cleanup_return_instances() is not possible if chained, there should be
another _alive() frame. But malicious user can obviously fool the kernel.
Easy to fix. But after discussion with Srikar and Pratyush (thanks!) I
decided to update 6-10.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block, cgroup: implement policy-specific per-blkcg data
The block IO (blkio) controller enables the block layer to provide service
guarantees in a hierarchical fashion. Specifically, service guarantees
are provided by registered request-accounting policies. As of now, a
proportional-share and a throttling policy are available. They are
implemented, respectively, by the CFQ I/O scheduler and the blk-throttle
subsystem. Unfortunately, as for adding new policies, the current
implementation of the block IO controller is only halfway ready to allow
new policies to be plugged in. This commit provides a solution to make
the block IO controller fully ready to handle new policies.
In what follows, we first describe briefly the current state, and then
list the changes made by this commit.
The throttling policy does not need any per-cgroup information to perform
its task. In contrast, the proportional share policy uses, for each cgroup,
both the weight assigned by the user to the cgroup, and a set of dynamically-
computed weights, one for each device.
The first, user-defined weight is stored in the blkcg data structure: the
block IO controller allocates a private blkcg data structure for each
cgroup in the blkio cgroups hierarchy (regardless of which policy is active).
In other words, the block IO controller internally mirrors the blkio cgroups
with private blkcg data structures.
On the other hand, for each cgroup and device, the corresponding dynamically-
computed weight is maintained in the following, different way. For each device,
the block IO controller keeps a private blkcg_gq structure for each cgroup in
blkio. In other words, block IO also keeps one private mirror copy of the blkio
cgroups hierarchy for each device, made of blkcg_gq structures.
Each blkcg_gq structure keeps per-policy information in a generic array of
dynamically-allocated 'dedicated' data structures, one for each registered
policy (so currently the array contains two elements). To be inserted into the
generic array, each dedicated data structure embeds a generic blkg_policy_data
structure. Consider now the array contained in the blkcg_gq structure
corresponding to a given pair of cgroup and device: one of the elements
of the array contains the dedicated data structure for the proportional-share
policy, and this dedicated data structure contains the dynamically-computed
weight for that pair of cgroup and device.
The generic strategy adopted for storing per-policy data in blkcg_gq structures
is already capable of handling new policies, whereas the one adopted with blkcg
structures is not, because per-policy data are hard-coded in the blkcg
structures themselves (currently only data related to the proportional-
share policy).
This commit addresses the above issues through the following changes:
. It generalizes blkcg structures so that per-policy data are stored in the same
way as in blkcg_gq structures.
Specifically, it lets also the blkcg structure store per-policy data in a
generic array of dynamically-allocated dedicated data structures. We will
refer to these data structures as blkcg dedicated data structures, to
distinguish them from the dedicated data structures inserted in the generic
arrays kept by blkcg_gq structures.
To allow blkcg dedicated data structures to be inserted in the generic array
inside a blkcg structure, this commit also introduces a new blkcg_policy_data
structure, which is the equivalent of blkg_policy_data for blkcg dedicated
data structures.
. It adds to the blkcg_policy structure, i.e., to the descriptor of a policy, a
cpd_size field and a cpd_init field, to be initialized by the policy with,
respectively, the size of the blkcg dedicated data structures, and the
address of a constructor function for blkcg dedicated data structures.
. It moves the CFQ-specific fields embedded in the blkcg data structure (i.e.,
the fields related to the proportional-share policy), into a new blkcg
dedicated data structure called cfq_group_data.
Signed-off-by: Paolo Valente
Signed-off-by: Arianna Avanzini
Cc: Tejun Heo
Cc: Jens Axboe
---
block/blk-cgroup.c | 92 ++---
block/blk-cgroup.h | 40 ++-
block/cfq-iosched.c | 70 ++--
3 files changed, 173 insertions(+), 29 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 0ac817b..6e43fa3 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -9,6 +9,10 @@
*
* Copyright (C) 2009 Vivek Goyal
* Nauman Rafique
+ *
+ * For policy-specific per-blkcg data:
+ * Copyright (C) 2015 Paolo Valente
+ *Arianna Avanzini
*/
#include
#include
@@ -26,8 +30,7 @@
static DEFINE_MUTEX(blkcg_pol_mutex);
-struct blkcg blkcg_root = { .cfq_weight = 2 * CFQ_WEIGHT_DEFAULT,
- .cfq_leaf_weight = 2 * CFQ_WEIGHT_DEFAULT, };
+struct blkcg blkcg_root;
EXPORT_SYMBOL_GPL(blkcg_root);
static struct blkcg_policy
Re: metag test failure in -next due to commit 'module: relocate module_init from init.h to module.h'
On Fri, Jun 05, 2015 at 01:40:55PM -0700, Guenter Roeck wrote:
> My qemu metag runtime test fails in -next due to commit 5ebbb3badaa8 ("module:
> relocate module_init from init.h to module.h"). Bisect log is as follows.
> A log of a failed test is available at
> http://server.roeck-us.net:8010/builders/qemu-metag-next/builds/173/steps/qemubuildcommand/logs/stdio
>
> Essentially the test just hangs in boot.
>
> Reverting the commit fixes the problem.
Thanks for finding and bisecting Guenter!
Some build warnings from the same commit caught my eye, which made it a
quick one to figure out. Paul, please consider applying the patch below
before the offending commit "module: relocate module_init from init.h to
module.h", so as not to break bisection.
Cheers
James
From e12856c559d7dff2ad4f6497996610e12e7c7e2d Mon Sep 17 00:00:00 2001
From: James Hogan
Date: Fri, 5 Jun 2015 22:17:18 +0100
Subject: [PATCH] tty/metag_da: Avoid module_init/module_exit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The metag_da TTY driver can't get built as a module at the moment, but
it still uses module_init() and module_exit(). Those macros are moving
to module.h which isn't included by metag_da.c, which will result in the
following build warnings (remarkably no build errors) and an apparent
failure to boot as the TTY driver won't be loaded.
drivers/tty/metag_da.c:660: warning: data definition has no type or storage
class
drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of
‘module_init’
drivers/tty/metag_da.c:660: warning: parameter names (without types) in
function declaration
drivers/tty/metag_da.c:661: warning: data definition has no type or storage
class
drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of
‘module_exit’
drivers/tty/metag_da.c:661: warning: parameter names (without types) in
function declaration
drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
drivers/tty/metag_da.c In function ‘dash_console_write’:
drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards
qualifiers from pointer target type
Instead of just adding the module.h include, now would be a good time to
remove the use of these macros, replacing the module_init with
device_initcall, and removing the exit function altogether since it
isn't needed. If module support is added later the code can always be
resurrected.
Reported-by: Guenter Roeck
Signed-off-by: James Hogan
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Paul Gortmaker
Cc: linux-me...@vger.kernel.org
---
drivers/tty/metag_da.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/tty/metag_da.c b/drivers/tty/metag_da.c
index 3774600741d8..9325262289f9 100644
--- a/drivers/tty/metag_da.c
+++ b/drivers/tty/metag_da.c
@@ -640,25 +640,7 @@ err_destroy_ports:
put_tty_driver(channel_driver);
return ret;
}
-
-static void dashtty_exit(void)
-{
- int nport;
- struct dashtty_port *dport;
-
- del_timer_sync(_timer);
- kthread_stop(dashtty_thread);
- del_timer_sync(_timer);
- tty_unregister_driver(channel_driver);
- for (nport = 0; nport < NUM_TTY_CHANNELS; nport++) {
- dport = _ports[nport];
- tty_port_destroy(>port);
- }
- put_tty_driver(channel_driver);
-}
-
-module_init(dashtty_init);
-module_exit(dashtty_exit);
+device_initcall(dashtty_init);
#ifdef CONFIG_DA_CONSOLE
--
2.3.6
signature.asc
Description: Digital signature
Re: [PATCH] EDAC, altera: wrap edac pm with a CONFIG_PM
Hi Boris, On 06/05/2015 10:15 AM, Borislav Petkov wrote: On Fri, Jun 05, 2015 at 08:49:15AM -0500, dingu...@opensource.altera.com wrote: From: Alan Tull Suspend-to-RAM and EDAC support are mutually exclusive on SOCFPGA. If the EDAC is enabled, it will prevent the platform from going into suspend. Btw, what is exactly the problem with EDAC being enabled and not being able to suspend? Is it a hardware issue? Because if it is sw one, we probably could change the EDAC core to accomodate power management. On x86 we don't need to do anything special to EDAC wrt PM though - we simply suspend. Thanks. Yes, in our case, it is a hardware issue but I'm still gathering information. The IRQ vectors for OCRAM reside on DDR and in Suspend-to-RAM mode we're executing out of OCRAM. If an ECC error occurs, we can't handle it so it was decided to make them mutually exclusive. Thor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/9] introduce __pfn_t for scatterlists and pmem
On Fri, Jun 5, 2015 at 2:19 PM, Dan Williams wrote:
> +enum {
> +#if BITS_PER_LONG == 64
> + PFN_SHIFT = 3,
> + /* device-pfn not covered by memmap */
> + PFN_DEV = (1UL << 2),
> +#else
> + PFN_SHIFT = 2,
> +#endif
> + PFN_MASK = (1UL << PFN_SHIFT) - 1,
> + PFN_SG_CHAIN = (1UL << 0),
> + PFN_SG_LAST = (1UL << 1),
> +};
Ugh. Just make PFN_SHIFT unconditional. Make it 2, unconditionally.
Or, if you want to have more bits, make it three unconditionally, and
make 'struct page' just be at least 8-byte aligned even on 32-bit.
Even on 32-bit architectures, there's plenty of bits. There's no
reason to "pack" this optimally. Remember: it's a page frame number,
so there's the page size shifting going on in physical memory, and
even if you shift the PFN by 3 - or four of five - bits
unconditionally (rather than try to shift it by some minimal number),
you're covering a *lot* of physical memory.
Say you're a 32-bit architecture with a 4k page size, and you lose
three bits to "type" bits. You still have 32+12-3=41 bits of physical
address space. Which is way more than realistic for a 32-bit
architecture anyway, even with PAE (or PXE or whatever ARM calls it).
Not that I see persistent memory being all that relevant on 32-bit
hardware anyway.
So I think if you actually do want that third bit, you're better off
just marking "struct page" as being __aligned__((8)) and getting the
three bits unconditionally. Just make the rule be that mem_map[] has
to be 8-byte aligned.
Even 16-byte alignment would probably be fine. No?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Rename ia32entry.S to entry_64_compat_32.S
On Fri, Jun 5, 2015 at 2:09 PM, H. Peter Anvin wrote: > Call it sys if it is now only the system call entry points. Agreed with > _64_compat too. > > Breaking up these snarls of spaghetti assembly will be a blessing. I'm not too picky about what we call it or whether we merge it with entry_64.S. *However*, I think the file name should end in _64.S. The whole arch/x86 tree is arranged such that files that end in _64.S or _64.c are build for 64-bit kernels and not for 32-bit kernels. I see no reason to deviate from that. FWIW, I'm eventually planning to completely rewrite the compat entry points to use the new (RFC patches coming in a week or two I hope!) C exit code with opportunistic sysretl at the end. I'm guessing the result will be about half the size of the current code, and it'll be comprehensible to mere mortals. --Andy > > On June 5, 2015 6:37:14 AM PDT, Borislav Petkov wrote: >>On Fri, Jun 05, 2015 at 03:00:29PM +0200, Ingo Molnar wrote: >>> I'm wondering what people think about this naming scheme: >>> >>> entry_32.S# 32-bit binaries on 32-bit >>kernels >>> entry_64.S# 64-bit binaries on 64-bit >>kernels >>> entry_64_compat_32.S # 32-bit binaries on 64-bit >>kernels >>> >>> Another option would be: >>> >>>arch/x86/entry/sys_32.S >>>arch/x86/entry/sys_64.S >>>arch/x86/entry/sys_64_compat.S >> >>I like this one better because entry_64_compat_32 kinda has both >>bitness in >>there and confuses me more. >> >>Just my 2 ¢. :) > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting. -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions
On Thu, Jun 4, 2015 at 11:36 AM, Johannes Weiner wrote: > On Thu, Jun 04, 2015 at 10:11:17AM -0700, John Stultz wrote: >> On Tue, Jun 2, 2015 at 10:50 PM, Tejun Heo wrote: >> > memcg usage came up a while ago and there wasn't anything major which >> > can't be achieved (usually better) by following more standard cgroup >> > usage - changing knobs rather than moving tasks around. >> >> Do you have a pointer to that discussion or maybe even just a sense of >> who was involved so I can trawl the list and better understand it? > > I wrote a lengthy explanation of why moving tasks between cgroups is > problematic from a memcg view: https://lkml.org/lkml/2014/12/19/358 And many thanks for the discussion pointer here! Its very enlightening! thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions
On Thu, Jun 4, 2015 at 11:36 AM, Johannes Weiner wrote: > On Thu, Jun 04, 2015 at 10:11:17AM -0700, John Stultz wrote: >> On Tue, Jun 2, 2015 at 10:50 PM, Tejun Heo wrote: >> > memcg usage came up a while ago and there wasn't anything major which >> > can't be achieved (usually better) by following more standard cgroup >> > usage - changing knobs rather than moving tasks around. >> >> Do you have a pointer to that discussion or maybe even just a sense of >> who was involved so I can trawl the list and better understand it? > > I wrote a lengthy explanation of why moving tasks between cgroups is > problematic from a memcg view: https://lkml.org/lkml/2014/12/19/358 > > Rather than creating super-cgroups as configuration domains and using > migration as a reconfiguration mechanism, it's much better to group > tasks per app and reconfigure the groups themselves using specific > presets for classes of apps, like foreground, background, audio. Hmm. So I've not heard from the Android guys on the viability of this, but one downside to this approach seems like that for cpu-scheduling at least, using a per-task allocation would make it harder to bound "background" cpu processing as a whole, no? For example, In order to keep all background tasks to less then 20% of the cputime, you'd have to set each process to get .2/nr_tasks (which you'd have to recalculate & re-assign every time a new task is launched). But that would end up being wasteful since each task gets limited by that amount and cannot make use of cputime not used by other background tasks. Or am I misunderstanding the suggestion? Or is your concern just limited to the memcg and this sort of cgroup migration ok for scheduling? And I guess, if its ok for scheduling, is it reasonable to consider the proposed patch to allow "privileged" but non-root tasks to migrate processes between cgroups? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] seccomp: add ptrace options for suspend/resume
On Fri, Jun 05, 2015 at 11:16:50PM +0200, Oleg Nesterov wrote:
> Hi Tycho,
>
> On 06/04, Tycho Andersen wrote:
> >
> > On Thu, Jun 04, 2015 at 08:31:49PM +0200, Oleg Nesterov wrote:
> > > Also. Suppose that the tracer sets SUSPEND_SECCOMP and then drops
> > > CAP_SYS_ADMIN. After that it can't set or clear other ptrace options.
> >
> > Is this a case we're concerned about? I think this should be ok (i.e.
> > "don't do that" :).
>
> Sure, I won't insist. Just this looks a bit confusing. I mean, if you
> read this code it is not clear why may_suspend_seccomp() is called even
> if the tracer changes other bits, and "data & PTRACE_O_SUSPEND" is true
> only because the tracer does _not_ change this option.
>
> IOW, imo the code will just look better if may_suspend_seccomp() is
> called only when PTRACE_O_SUSPEND is set. But this is minor, feel free
> to ignore.
Oh, I understand now. I think this is fixed in v3 that I just sent,
but may go away in any case if we remove the checks...
> > > > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > > > +bool may_suspend_seccomp(void)
> > > > +{
> > > > + if (!capable(CAP_SYS_ADMIN))
> > > > + return false;
> > > > +
> > > > + if (current->seccomp.mode != SECCOMP_MODE_DISABLED)
> > > > + return false;
> > >
> > > Heh. OK, I won't argue with the new check too ;)
> >
> > Actually now that I think about it I agree with you, these checks
> > don't seem necessary. Even inside a user namespace, if you can ptrace
> > a process you can make it do whatever you want irrespective of
> > seccomp, as long as it has the necessary capabilities. Once the
> > seccomp checks are run after ptrace, they'll be enforced so you
> > couldn't have it call whatever you want in the first place.
>
> Good ;)
>
> > Still, perhaps I'm missing something...
>
> Kees, Andy?
Doh, just sent v3. If you guys are convinced too, then I can send v4
with these checks removed.
Tycho
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/9] dax: fix mapping lifetime handling, convert to __pfn_t + kmap_atomic_pfn_t()
The primary source for non-page-backed page-frames to enter the system
is via the pmem driver's ->direct_access() method. The pfns returned by
the top-level bdev_direct_access() may be passed to any other subsystem
in the kernel and those sub-systems either need to assume that the pfn
is page backed (CONFIG_DEV_PFN=n) or be prepared to handle non-page
backed case (CONFIG_DEV_PFN=y). Currently the pfns returned by
->direct_access() are only ever used by vm_insert_mixed() which does not
care if the pfn is mapped. As we go to add more usages of these pfns
add the type-safety of __pfn_t.
This also simplifies the calling convention of ->direct_access() by not
returning the virtual address in the same call. This annotates cases
where the kernel is directly accessing pmem outside the driver, and
makes the valid lifetime of the reference explicit. This property may
be useful in the future for invalidating mappings to pmem, but for now
it provides some protection against the "pmem disable vs still-in-use"
race.
Note that axon_ram_direct_access and dcssblk_direct_access were
previously making potentially incorrect assumptions about the addresses
they passed to virt_to_phys().
Cc: Matthew Wilcox
Cc: Ross Zwisler
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Jens Axboe
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Boaz Harrosh
Signed-off-by: Dan Williams
---
arch/powerpc/sysdev/axonram.c | 26 -
drivers/block/brd.c |5 +--
drivers/block/pmem.c | 16 ---
drivers/s390/block/dcssblk.c | 26 ++---
fs/block_dev.c|4 +--
fs/dax.c | 62 -
include/asm-generic/pfn.h | 25 +
include/linux/blkdev.h|7 ++---
8 files changed, 132 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index e8657d3bc588..20725006592e 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -139,22 +139,23 @@ axon_ram_make_request(struct request_queue *queue, struct
bio *bio)
* axon_ram_direct_access - direct_access() method for block device
* @device, @sector, @data: see block_device_operations method
*/
-static long
+static __maybe_unused long
axon_ram_direct_access(struct block_device *device, sector_t sector,
- void **kaddr, unsigned long *pfn)
+ __pfn_t *pfn)
{
struct axon_ram_bank *bank = device->bd_disk->private_data;
loff_t offset = (loff_t)sector << AXON_RAM_SECTOR_SHIFT;
- *kaddr = (void *)(bank->ph_addr + offset);
- *pfn = virt_to_phys(*kaddr) >> PAGE_SHIFT;
+ *pfn = phys_to_pfn_t(bank->ph_addr + offset);
return bank->size - offset;
}
static const struct block_device_operations axon_ram_devops = {
.owner = THIS_MODULE,
+#ifdef HAVE_KMAP_PFN
.direct_access = axon_ram_direct_access
+#endif
};
/**
@@ -165,9 +166,13 @@ static int axon_ram_probe(struct platform_device *device)
{
static int axon_ram_bank_id = -1;
struct axon_ram_bank *bank;
- struct resource resource;
+ struct resource *resource;
int rc = 0;
+ resource = devm_kzalloc(>dev, sizeof(*resource), GFP_KERNEL);
+ if (!resource)
+ return -ENOMEM;
+
axon_ram_bank_id++;
dev_info(>dev, "Found memory controller on %s\n",
@@ -184,13 +189,13 @@ static int axon_ram_probe(struct platform_device *device)
bank->device = device;
- if (of_address_to_resource(device->dev.of_node, 0, ) != 0) {
+ if (of_address_to_resource(device->dev.of_node, 0, resource) != 0) {
dev_err(>dev, "Cannot access device tree\n");
rc = -EFAULT;
goto failed;
}
- bank->size = resource_size();
+ bank->size = resource_size(resource);
if (bank->size == 0) {
dev_err(>dev, "No DDR2 memory found for %s%d\n",
@@ -202,7 +207,7 @@ static int axon_ram_probe(struct platform_device *device)
dev_info(>dev, "Register DDR2 memory device %s%d with %luMB\n",
AXON_RAM_DEVICE_NAME, axon_ram_bank_id, bank->size >>
20);
- bank->ph_addr = resource.start;
+ bank->ph_addr = resource->start;
bank->io_addr = (unsigned long) ioremap_prot(
bank->ph_addr, bank->size, _PAGE_NO_CACHE);
if (bank->io_addr == 0) {
@@ -211,6 +216,11 @@ static int axon_ram_probe(struct platform_device *device)
goto failed;
}
+ rc = devm_register_kmap_pfn_range(>dev, resource,
+ (void *) bank->io_addr);
+ if (rc)
+ goto failed;
+
bank->disk = alloc_disk(AXON_RAM_MINORS_PER_DISK);
if (bank->disk == NULL) {
dev_err(>dev, "Cannot register disk\n");
diff --git a/drivers/block/brd.c
[PATCH v4 7/9] scatterlist: cleanup sg_chain() and sg_unmark_end()
Replace open coded sg_chain() and sg_unmark_end() instances with the
aforementioned helpers.
Signed-off-by: Dan Williams
---
block/blk-merge.c|2 +-
drivers/crypto/omap-sham.c |2 +-
drivers/dma/imx-dma.c|8 ++--
drivers/dma/ste_dma40.c |5 +
drivers/mmc/card/queue.c |4 ++--
include/crypto/scatterwalk.h |9 ++---
6 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 30a0d9f89017..f4a3e87623dc 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -266,7 +266,7 @@ int blk_rq_map_sg(struct request_queue *q, struct request
*rq,
if (rq->cmd_flags & REQ_WRITE)
memset(q->dma_drain_buffer, 0, q->dma_drain_size);
- sg->page_link &= ~0x02;
+ sg_unmark_end(sg);
sg = sg_next(sg);
sg_set_page(sg, virt_to_page(q->dma_drain_buffer),
q->dma_drain_size,
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 4d63e0d4da9a..df8b23e19b90 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -582,7 +582,7 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
* the dmaengine may try to DMA the incorrect amount of data.
*/
sg_init_table(>sgl, 1);
- ctx->sgl.page_link = ctx->sg->page_link;
+ sg_assign_page(>sgl, sg_page(ctx->sg));
ctx->sgl.offset = ctx->sg->offset;
sg_dma_len(>sgl) = len32;
sg_dma_address(>sgl) = sg_dma_address(ctx->sg);
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index eed405976ea9..081fbfc87f6b 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -886,18 +886,14 @@ static struct dma_async_tx_descriptor
*imxdma_prep_dma_cyclic(
sg_init_table(imxdmac->sg_list, periods);
for (i = 0; i < periods; i++) {
- imxdmac->sg_list[i].page_link = 0;
- imxdmac->sg_list[i].offset = 0;
+ sg_set_page(>sg_list[i], NULL, period_len, 0);
imxdmac->sg_list[i].dma_address = dma_addr;
sg_dma_len(>sg_list[i]) = period_len;
dma_addr += period_len;
}
/* close the loop */
- imxdmac->sg_list[periods].offset = 0;
- sg_dma_len(>sg_list[periods]) = 0;
- imxdmac->sg_list[periods].page_link =
- ((unsigned long)imxdmac->sg_list | 0x01) & ~0x02;
+ sg_chain(imxdmac->sg_list, periods + 1, imxdmac->sg_list);
desc->type = IMXDMA_DESC_CYCLIC;
desc->sg = imxdmac->sg_list;
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3c10f034d4b9..e8c00642cacb 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2562,10 +2562,7 @@ dma40_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t
dma_addr,
dma_addr += period_len;
}
- sg[periods].offset = 0;
- sg_dma_len([periods]) = 0;
- sg[periods].page_link =
- ((unsigned long)sg | 0x01) & ~0x02;
+ sg_chain(sg, periods + 1, sg);
txd = d40_prep_sg(chan, sg, sg, periods, direction,
DMA_PREP_INTERRUPT);
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 236d194c2883..127f76294e71 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -469,7 +469,7 @@ static unsigned int mmc_queue_packed_map_sg(struct
mmc_queue *mq,
sg_set_buf(__sg, buf + offset, len);
offset += len;
remain -= len;
- (__sg++)->page_link &= ~0x02;
+ sg_unmark_end(__sg++);
sg_len++;
} while (remain);
}
@@ -477,7 +477,7 @@ static unsigned int mmc_queue_packed_map_sg(struct
mmc_queue *mq,
list_for_each_entry(req, >list, queuelist) {
sg_len += blk_rq_map_sg(mq->queue, req, __sg);
__sg = sg + (sg_len - 1);
- (__sg++)->page_link &= ~0x02;
+ sg_unmark_end(__sg++);
}
sg_mark_end(sg + (sg_len - 1));
return sg_len;
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 20e4226a2e14..4529889b0f07 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -25,13 +25,8 @@
#include
#include
-static inline void scatterwalk_sg_chain(struct scatterlist *sg1, int num,
- struct scatterlist *sg2)
-{
- sg_set_page([num - 1], (void *)sg2, 0, 0);
- sg1[num - 1].page_link &= ~0x02;
- sg1[num - 1].page_link |= 0x01;
-}
+#define scatterwalk_sg_chain(prv, num, sgl)sg_chain(prv, num, sgl)
+#define scatterwalk_sg_next(sgl) sg_next(sgl)
static inline void scatterwalk_crypto_chain(struct
Re: [Patch v2 0/4] Introduce a mechanism to allocate PCI IRQ on demand
On Tue, Jun 02, 2015 at 10:49:15AM +0800, Jiang Liu wrote: > This patch set introduces a mechanism to allocate PCI IRQ on demand and > free it when not used anymore by hooking pci_device_probe() and > pci_device_remove(). > > It will be used to track IOAPIC pin usage on x86 so we could support > IOAPIC hot-removal. > > The patch set passes Fengguang's 0day test suite. > > V1->V2: > 1) Refine pci_device_probe() to optimize for mainline code as suggested >by Bjorn > 2) Reorder patch set to put optional patch as the last (Patch 4) > > Thanks! > Gerry > > > Jiang Liu (4): > PCI: Add hooks to allocate/free IRQ resources when binding/unbinding > driver > PCI, x86: Allocate PCI IRQ on demand and free it when not used > anymore > PCI: Introduce helpers to manage pci_dev->irq and > pci_dev->irq_managed > PCI, MSI: Optionally free legacy PCI IRQ when enabling MSI/MSI-X > > arch/x86/include/asm/pci_x86.h |2 -- > arch/x86/pci/common.c | 20 +--- > arch/x86/pci/intel_mid_pci.c |9 ++--- > arch/x86/pci/irq.c | 23 --- > drivers/acpi/pci_irq.c | 17 - > drivers/pci/msi.c |6 +- > drivers/pci/pci-driver.c | 26 -- > include/linux/pci.h| 19 +++ > 8 files changed, 67 insertions(+), 55 deletions(-) I'm fine with these patches, and I can merge them, but I would like an ack from Thomas. Or, if it makes more sense to route these along with other related patches through Thomas, here's my ack: Acked-by: Bjorn Helgaas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/9] introduce __pfn_t, evacuate struct page from sgls
On Fri, Jun 5, 2015 at 2:19 PM, Dan Williams wrote: > Introduce __pfn_t which: > > 1/ Allows kernel internal DAX mappings to adhere to the lifetime of the >the underlying block device. In general, it enables a mechanism to >allow any device driver to advertise "device memory" (CONFIG_DEV_PFN) >to other parts of the kernel. > > 2/ Replaces usage of struct page in struct scatterlist. A scatterlist >need only carry enough information to generate a dma address, and >removing struct page from scatterlists is a precursor to allowing DMA to >device memory. Some dma mapping implementations are not ready for a >scatterlist-pfn to reference unampped device memory, those >implementations are disabled by CONFIG_DEV_PFN=y. > > Changes since v4 [1]: v3: https://lists.01.org/pipermail/linux-nvdimm/2015-May/000749.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 9/9] x86: convert dma_map_ops to support mapping a __pfn_t.
As long as a dma_map_sg() implementation avoids sg_page() conversions it
can support scatterlists that carry "page-less" __pfn_t entries.
However, a couple implementations require that __pfn_t_has_page() is
always true. The Xen swiotlb implementation's entanglements with ARM and
the Calgary MMUs requirement to have a pre-existing virtual mapping make
them unable to support this conversion (i.e. these now have 'depends on
!HAVE_DMA_PFN').
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Dan Williams
---
arch/x86/Kconfig |2 ++
arch/x86/kernel/amd_gart_64.c| 22 +-
arch/x86/kernel/pci-nommu.c | 22 +-
arch/x86/kernel/pci-swiotlb.c|4
arch/x86/pci/sta2x11-fixup.c |4
drivers/iommu/amd_iommu.c| 21 -
drivers/iommu/intel-iommu.c | 22 +-
drivers/pci/Kconfig |2 +-
include/asm-generic/dma-mapping-common.h |4 ++--
include/linux/scatterlist.h |4 ++--
include/linux/swiotlb.h |4
lib/swiotlb.c| 20 +++-
12 files changed, 101 insertions(+), 30 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 130d1a4c2efc..2fd7690ed0e2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -796,6 +796,7 @@ config CALGARY_IOMMU
bool "IBM Calgary IOMMU support"
select SWIOTLB
depends on X86_64 && PCI
+ depends on !HAVE_DMA_PFN
---help---
Support for hardware IOMMUs in IBM's xSeries x366 and x460
systems. Needed to run systems with more than 3GB of memory
@@ -1436,6 +1437,7 @@ config X86_PMEM_DMA
depends on !HIGHMEM
def_bool DEV_PFN
select HAVE_KMAP_PFN
+ select HAVE_DMA_PFN
config HIGHPTE
bool "Allocate 3rd-level pagetables from highmem"
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 8e3842fc8bea..8fad83c8dfd2 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -239,13 +239,13 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
}
/* Map a single area into the IOMMU */
-static dma_addr_t gart_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir,
- struct dma_attrs *attrs)
+static dma_addr_t gart_map_pfn(struct device *dev, __pfn_t pfn,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
{
unsigned long bus;
- phys_addr_t paddr = page_to_phys(page) + offset;
+ phys_addr_t paddr = __pfn_t_to_phys(pfn) + offset;
if (!dev)
dev = _dma_fallback_dev;
@@ -259,6 +259,14 @@ static dma_addr_t gart_map_page(struct device *dev, struct
page *page,
return bus;
}
+static __maybe_unused dma_addr_t gart_map_page(struct device *dev,
+ struct page *page, unsigned long offset, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ return gart_map_pfn(dev, page_to_pfn_t(page), offset, size, dir,
+ attrs);
+}
+
/*
* Free a DMA mapping.
*/
@@ -699,7 +707,11 @@ static __init int init_amd_gatt(struct agp_kern_info *info)
static struct dma_map_ops gart_dma_ops = {
.map_sg = gart_map_sg,
.unmap_sg = gart_unmap_sg,
+#ifdef CONFIG_HAVE_DMA_PFN
+ .map_pfn= gart_map_pfn,
+#else
.map_page = gart_map_page,
+#endif
.unmap_page = gart_unmap_page,
.alloc = gart_alloc_coherent,
.free = gart_free_coherent,
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index da15918d1c81..876dacfbabf6 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/x86/kernel/pci-nommu.c
@@ -25,12 +25,12 @@ check_addr(char *name, struct device *hwdev, dma_addr_t
bus, size_t size)
return 1;
}
-static dma_addr_t nommu_map_page(struct device *dev, struct page *page,
-unsigned long offset, size_t size,
-enum dma_data_direction dir,
-struct dma_attrs *attrs)
+static dma_addr_t nommu_map_pfn(struct device *dev, __pfn_t pfn,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
{
- dma_addr_t bus = page_to_phys(page) + offset;
+ dma_addr_t bus = __pfn_t_to_phys(pfn) + offset;
