Re: [PATCH RFC v2 1/2] crypto: add PKE API
On Fri, May 22, 2015 at 11:37:49AM -0700, Tadeusz Struk wrote:
>
> /**
> * struct akcipher_request - public key request
> *
> * @base: Common attributes for async crypto requests
> * @inparams: scatterlist of input parameters (one ent per parameter)
> *for the operation as defined in RFC.
> *For instance for rsa encrypt only one input param is required,
> *(i.e. 'm' - message) as specified in RFC3447 sec 5.1.1
> *(Note: the key belongs to the tfm)
> * @outparams:scatterlist of output parameters (one ent per parameter)
> *for the operation as defined in RFC.
> *For instance for rsa encrypt only one output param will be
> *produced (i.e. 'c' - cipher text) as specified in
> *RFC3447 sec 5.1.1
> *
> * @__ctx:Start of private context data
> */
> struct akcipher_request {
> struct crypto_async_request base;
> struct scatterlist *inparams;
> struct scatterlist *outparams;
> void *__ctx[] CRYPTO_MINALIGN_ATTR;
> };
I think you should rename them to src/dst and add a length argument.
Limiting them to one entry also seems strange. When do you need more
one parameter?
> /**
> * struct akcipher_alg - generic public key algorithm
> *
> * @sign: Function performs a sign operation as defined by public key
> *algorithm
> * @verify: Function performs a sign operation as defined by public key
> *algorithm
> * @encrypt: Function performs an encrypt operation as defined by public key
> *algorithm
> * @decrypt: Function performs a decrypt operation as defined by public key
> *algorithm
> * @reqsize: Request context size required by algorithm implementation
> *
> * @base: Common crypto API algorithm data structure
> */
> struct akcipher_alg {
> int (*sign)(struct akcipher_request *req);
> int (*verify)(struct akcipher_request *req);
> int (*encrypt)(struct akcipher_request *req);
> int (*decrypt)(struct akcipher_request *req);
Looks good. You'll also need a setkey (or perhaps two) function.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm:cma - Fix for typos in comments.
Signed-off-by: Shailendra Verma --- mm/cma.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/cma.c b/mm/cma.c index 3a7a67b..6612780 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -182,7 +182,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, if (!size || !memblock_is_region_reserved(base, size)) return -EINVAL; - /* ensure minimal alignment requied by mm core */ + /* ensure minimal alignment required by mm core */ alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); /* alignment should be aligned with order_per_bit */ @@ -238,7 +238,7 @@ int __init cma_declare_contiguous(phys_addr_t base, /* * high_memory isn't direct mapped memory so retrieving its physical * address isn't appropriate. But it would be useful to check the -* physical address of the highmem boundary so it's justfiable to get +* physical address of the highmem boundary so it's justifiable to get * the physical address from it. On x86 there is a validation check for * this case, so the following workaround is needed to avoid it. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:audit - Fix for typo in comment to function audit_log_link_denied().
Signed-off-by: Shailendra Verma --- kernel/audit.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit.c b/kernel/audit.c index 1c13e42..f9e6065 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -1904,7 +1904,7 @@ EXPORT_SYMBOL(audit_log_task_info); /** * audit_log_link_denied - report a link restriction denial - * @operation: specific link opreation + * @operation: specific link operation * @link: the path that triggered the restriction */ void audit_log_link_denied(const char *operation, struct path *link) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:acct - Fix typos in comment to file header.
Signed-off-by: Shailendra Verma --- kernel/acct.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/acct.c b/kernel/acct.c index 74963d1..fa972fa 100644 --- a/kernel/acct.c +++ b/kernel/acct.c @@ -24,8 +24,8 @@ * Now we silently close acct_file on attempt to reopen. Cleaned sys_acct(). * XTerms and EMACS are manifestations of pure evil. 21/10/98, AV. * - * Fixed a nasty interaction with with sys_umount(). If the accointing - * was suspeneded we failed to stop it on umount(). Messy. + * Fixed a nasty interaction with with sys_umount(). If the accounting + * was suspended we failed to stop it on umount(). Messy. * Another one: remount to readonly didn't stop accounting. * Question: what should we do if we have CAP_SYS_ADMIN but not * CAP_SYS_PACCT? Current code does the following: umount returns -EBUSY -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:smp - Fix for typo in comment to function smp_call_function_single_async().
Signed-off-by: Shailendra Verma --- kernel/smp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index 0785447..9954d82 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -314,7 +314,7 @@ EXPORT_SYMBOL(smp_call_function_single); * @cpu: The CPU to run on. * @csd: Pre-allocated and setup data structure * - * Like smp_call_function_single(), but the call is asynchonous and + * Like smp_call_function_single(), but the call is asynchronous and * can thus be done from contexts with disabled interrupts. * * The caller passes his own pre-allocated data structure -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:signal - Fix for typos in comments.
Signed-off-by: Shailendra Verma
---
kernel/signal.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index d51c5dd..5c65e7c 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -342,7 +342,7 @@ static bool task_participate_group_stop(struct task_struct
*task)
sig->group_stop_count--;
/*
-* Tell the caller to notify completion iff we are entering into a
+* Tell the caller to notify completion if we are entering into a
* fresh group stop. Read comment in do_signal_stop() for details.
*/
if (!sig->group_stop_count && !(sig->flags & SIGNAL_STOP_STOPPED)) {
@@ -1864,7 +1864,7 @@ static void ptrace_stop(int exit_code, int why, int
clear_code, siginfo_t *info)
/*
* If @why is CLD_STOPPED, we're trapping to participate in a group
-* stop. Do the bookkeeping. Note that if SIGCONT was delievered
+* stop. Do the bookkeeping. Note that if SIGCONT was delivered
* across siglock relocks since INTERRUPT was scheduled, PENDING
* could be clear now. We act as if SIGCONT is received after
* TASK_TRACED is entered - ignore it.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:kexec - Fix for typo in comment in function sanity_check_segment_list().
Signed-off-by: Shailendra Verma --- kernel/kexec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kexec.c b/kernel/kexec.c index 7a36fdc..50dffdb 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -189,7 +189,7 @@ static int sanity_check_segment_list(struct kimage *image) } /* Verify our destination addresses do not overlap. -* If we alloed overlapping destination addresses +* If we allowed overlapping destination addresses * through very weird things can happen with no * easy explanation as one segment stops on another. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:ptrace - Fix typo in comment in function __ptrace_unlink().
Signed-off-by: Shailendra Verma --- kernel/ptrace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/ptrace.c b/kernel/ptrace.c index c8e0e05..46249f9 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -108,7 +108,7 @@ void __ptrace_unlink(struct task_struct *child) /* * If transition to TASK_STOPPED is pending or in TASK_TRACED, kick -* @child in the butt. Note that @resume should be used iff @child +* @child in the butt. Note that @resume should be used if @child * is in TASK_TRACED; otherwise, we might unduly disrupt * TASK_KILLABLE sleeps. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:watchdog - Fix for typo in comment in function watchdog_nmi_enable().
Signed-off-by: Shailendra Verma --- kernel/watchdog.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 581a68a..4cf0ff8 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -539,7 +539,7 @@ static int watchdog_nmi_enable(unsigned int cpu) /* Try to register using hardware perf events */ event = perf_event_create_kernel_counter(wd_attr, cpu, NULL, watchdog_overflow_callback, NULL); - /* save cpu0 error for future comparision */ + /* save cpu0 error for future comparison */ if (cpu == 0 && IS_ERR(event)) cpu0_err = PTR_ERR(event); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:workqueue - Fix typos in comments.
Signed-off-by: Shailendra Verma
---
kernel/workqueue.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 586ad91..17d3021 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -976,7 +976,7 @@ static struct worker *find_worker_executing_work(struct
worker_pool *pool,
* move_linked_works - move linked works to a list
* @work: start of series of works to be scheduled
* @head: target list to append @work to
- * @nextp: out paramter for nested worklist walking
+ * @nextp: out parameter for nested worklist walking
*
* Schedule linked works starting from @work to @head. Work series to
* be scheduled starts at @work and includes any consecutive work with
@@ -2616,7 +2616,7 @@ EXPORT_SYMBOL_GPL(flush_workqueue);
* Wait until the workqueue becomes empty. While draining is in progress,
* only chain queueing is allowed. IOW, only currently pending or running
* work items on @wq can queue further work items on it. @wq is flushed
- * repeatedly until it becomes empty. The number of flushing is detemined
+ * repeatedly until it becomes empty. The number of flushing is determined
* by the depth of chaining and should be relatively short. Whine if it
* takes too long.
*/
@@ -3081,7 +3081,7 @@ static bool wqattrs_equal(const struct workqueue_attrs *a,
* init_worker_pool - initialize a newly zalloc'd worker_pool
* @pool: worker_pool to initialize
*
- * Initiailize a newly zalloc'd @pool. It also allocates @pool->attrs.
+ * Initialize a newly zalloc'd @pool. It also allocates @pool->attrs.
*
* Return: 0 on success, -errno on failure. Even on failure, all fields
* inside @pool proper are initialized and put_unbound_pool() can be called
@@ -4385,7 +4385,7 @@ static void rebind_workers(struct worker_pool *pool)
/*
* Restore CPU affinity of all workers. As all idle workers should
* be on the run-queue of the associated CPU before any local
-* wake-ups for concurrency management happen, restore CPU affinty
+* wake-ups for concurrency management happen, restore CPU affinity
* of all workers first and then clear UNBOUND. As we're called
* from CPU_ONLINE, the following shouldn't fail.
*/
@@ -4948,7 +4948,7 @@ int workqueue_sysfs_register(struct workqueue_struct *wq)
int ret;
/*
-* Adjusting max_active or creating new pwqs by applyting
+* Adjusting max_active or creating new pwqs by applying
* attributes breaks ordering guarantee. Disallow exposing ordered
* workqueues.
*/
@@ -5047,7 +5047,7 @@ static void __init wq_numa_init(void)
node = cpu_to_node(cpu);
if (WARN_ON(node == NUMA_NO_NODE)) {
pr_warn("workqueue: NUMA node mapping not available for
cpu%d, disabling NUMA support\n", cpu);
- /* happens iff arch is bonkers, let's just proceed */
+ /* happens if arch is bonkers, let's just proceed */
return;
}
cpumask_set_cpu(cpu, tbl[node]);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel:user_namespace - Fix for typos in comments.
Signed-off-by: Shailendra Verma --- kernel/user_namespace.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index 4109f83..02a1197 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -69,7 +69,7 @@ int create_user_ns(struct cred *new) /* * Verify that we can not violate the policy of which files * may be accessed that is specified by the root directory, -* by verifing that the root directory is at the root of the +* by verifying that the root directory is at the root of the * mount namespace which allows all files to be accessed. */ if (current_chrooted()) @@ -617,7 +617,7 @@ static ssize_t map_write(struct file *file, const char __user *buf, * * There is a one time data dependency between reading the * count of the extents and the values of the extents. The -* desired behavior is to see the values of the extents that +* desired behaviour is to see the values of the extents that * were written before the count of the extents. * * To achieve this smp_wmb() is used on guarantee the write @@ -716,7 +716,7 @@ static ssize_t map_write(struct file *file, const char __user *buf, (next_line != NULL)) goto out; } - /* Be very certaint the new map actually exists */ + /* Be very certain the new map actually exists */ if (new_map.nr_extents == 0) goto out; @@ -841,7 +841,7 @@ static bool new_idmap_permitted(const struct file *file, /* Allow the specified ids if we have the appropriate capability * (CAP_SETUID or CAP_SETGID) over the parent user namespace. -* And the opener of the id file also had the approprpiate capability. +* And the opener of the id file also had the appropriate capability. */ if (ns_capable(ns->parent, cap_setid) && file_ns_capable(file, ns->parent, cap_setid)) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq:gx-suspmod - Fix two typos in two comments.
Signed-off-by: Shailendra Verma --- drivers/cpufreq/gx-suspmod.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c index 1d723dc..3488c9c 100644 --- a/drivers/cpufreq/gx-suspmod.c +++ b/drivers/cpufreq/gx-suspmod.c @@ -144,7 +144,7 @@ module_param(max_duration, int, 0444); /** - * we can detect a core multipiler from dir0_lsb + * we can detect a core multiplier from dir0_lsb * from GX1 datasheet p.56, * MULT[3:0]: * = SYSCLK multiplied by 4 (test only) @@ -346,7 +346,7 @@ static int cpufreq_gx_verify(struct cpufreq_policy *policy) /* it needs to be assured that at least one supported frequency is * within policy->min and policy->max. If it is not, policy->max -* needs to be increased until one freuqency is supported. +* needs to be increased until one frequency is supported. * policy->min may not be decreased, though. This way we guarantee a * specific processing capacity. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq:cpufreq-nforce2 - Fix typo in comment to function nforce2_init().
Signed-off-by: Shailendra Verma --- drivers/cpufreq/cpufreq-nforce2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c index a225809..db69eeb 100644 --- a/drivers/cpufreq/cpufreq-nforce2.c +++ b/drivers/cpufreq/cpufreq-nforce2.c @@ -414,7 +414,7 @@ static int nforce2_detect_chipset(void) * nforce2_init - initializes the nForce2 CPUFreq driver * * Initializes the nForce2 FSB support. Returns -ENODEV on unsupported - * devices, -EINVAL on problems during initiatization, and zero on + * devices, -EINVAL on problems during initialization, and zero on * success. */ static int __init nforce2_init(void) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8723au: fix sparse warning
change cast to __le16 to fix the following warning:
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c:1488:20: warning: cast to
restricted __le16
Signed-off-by: Juston Li
---
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
index 04d0183..e23af8e 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
@@ -1485,7 +1485,7 @@ void Hal_EfuseParseIDCode(struct rtw_adapter *padapter,
u8 *hwinfo)
u16 EEPROMId;
/* Checl 0x8129 again for making sure autoload status!! */
- EEPROMId = le16_to_cpu(*((u16 *) hwinfo));
+ EEPROMId = le16_to_cpu(*((__le16 *) hwinfo));
if (EEPROMId != RTL_EEPROM_ID) {
DBG_8723A("EEPROM ID(%#x) is invalid!!\n", EEPROMId);
pEEPROM->bautoload_fail_flag = true;
--
2.4.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] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
On 23-05-15, 08:32, Shailendra Verma wrote:
> During probe free the memory allocated to "exynos_info" in case of
> unknown SOC type.
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/cpufreq/exynos-cpufreq.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 82d2fbb..5b57a0f 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -182,20 +182,25 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> ret = exynos5250_cpufreq_init(exynos_info);
> } else {
> pr_err("%s: Unknown SoC type\n", __func__);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err_vdd_arm;
Because we are going to check ret again, don't add the goto here. The
below code will take care of this.
> }
>
> - if (ret)
> + if (ret) {
> + ret = -EINVAL;
Why update ret here ?
> goto err_vdd_arm;
> + }
>
> if (exynos_info->set_freq == NULL) {
> dev_err(>dev, "No set_freq function (ERR)\n");
> + ret = -EINVAL;
> goto err_vdd_arm;
> }
>
> arm_regulator = regulator_get(NULL, "vdd_arm");
> if (IS_ERR(arm_regulator)) {
> dev_err(>dev, "failed to get resource vdd_arm\n");
> + ret = -EINVAL;
> goto err_vdd_arm;
> }
>
> @@ -203,8 +208,10 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
>
> ret = cpufreq_register_driver(_driver);
> - if (ret)
> + if (ret) {
> + ret = -EINVAL;
Wrong again.
> goto err_cpufreq_reg;
> + }
>
> cpu0 = of_get_cpu_node(0, NULL);
> if (!cpu0) {
> @@ -227,7 +234,7 @@ err_cpufreq_reg:
> regulator_put(arm_regulator);
> err_vdd_arm:
> kfree(exynos_info);
> - return -EINVAL;
> + return ret;
> }
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for May 22 (build failure in i915_gem_gtt.c)
On Fri, May 22, 2015 at 06:09:40PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150521:
>
> The device-mapper tree gained a build failure so I used the version
> from next-20150521.
>
> The driver-core tree still had its build failure for which I applied a fix
> patch.
>
> Non-merge commits (relative to Linus' tree): 5332
> 4735 files changed, 245341 insertions(+), 114211 deletions(-)
>
>
>
i386 builds:
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init':
drivers/gpu/drm/i915/i915_gem_gtt.c:954:2: error: large integer implicitly
truncated to unsigned type [-Werror=overflow]
cc1: all warnings being treated as errors
make[4]: *** [drivers/gpu/drm/i915/i915_gem_gtt.o] Error 1
Caused by commit 5c5f645773b6d ("drm/i915: Unify aliasing ppgtt handling").
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 1/3] ARM: socfpga: use CPU_METHOD_OF_DECLARE for socfpga_cyclone5
From: Dinh Nguyen
Convert cyclone5/arria5 to use CPU_METHOD_OF_DECLARE for smp operations.
Signed-off-by: Dinh Nguyen
---
arch/arm/mach-socfpga/platsmp.c | 2 ++
arch/arm/mach-socfpga/socfpga.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 7886eae..08250c8 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -90,3 +90,5 @@ struct smp_operations socfpga_smp_ops __initdata = {
.cpu_die= socfpga_cpu_die,
#endif
};
+
+CPU_METHOD_OF_DECLARE(socfpga_smp, "altr,socfpga-smp", _smp_ops);
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index b63dec6..a154920 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -78,7 +78,6 @@ static const char *altera_dt_match[] = {
DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
.l2c_aux_val= 0,
.l2c_aux_mask = ~0,
- .smp= smp_ops(socfpga_smp_ops),
.init_irq = socfpga_init_irq,
.restart= socfpga_cyclone5_restart,
.dt_compat = altera_dt_match,
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: socfpga: add CPU_METHOD_OF_DECLARE for Arria 10
From: Dinh Nguyen
Add boot_secondary implementation for the Arria10 platform. Bringing up
the secondary core on the Arria 10 platform is pretty similar to the
Cyclone/Arria 5 platform, with the exception of the following differences:
- Register offset to bringup CPU1 out of reset is different.
- The cpu1-start-addr for Arria10 contains an additional nibble.
Signed-off-by: Dinh Nguyen
---
arch/arm/mach-socfpga/core.h| 2 ++
arch/arm/mach-socfpga/platsmp.c | 30 ++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 5913bbb..7637b7f 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -25,6 +25,8 @@
#define SOCFPGA_RSTMGR_MODPERRST 0x14
#define SOCFPGA_RSTMGR_BRGMODRST 0x1c
+#define SOCFPGA_A10_RSTMGR_MODMPURST 0x20
+
/* System Manager bits */
#define RSTMGR_CTRL_SWCOLDRSTREQ 0x1 /* Cold Reset */
#define RSTMGR_CTRL_SWWARMRSTREQ 0x2 /* Warm Reset */
diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index 08250c8..bcc7ce8 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -54,6 +54,27 @@ static int socfpga_boot_secondary(unsigned int cpu, struct
task_struct *idle)
return 0;
}
+static int socfpga_a10_boot_secondary(unsigned int cpu, struct task_struct
*idle)
+{
+ int trampoline_size = _trampoline_end - _trampoline;
+
+ if (socfpga_cpu1start_addr) {
+ memcpy(phys_to_virt(0), _trampoline, trampoline_size);
+
+ writel(virt_to_phys(socfpga_secondary_startup),
+ sys_manager_base_addr + (socfpga_cpu1start_addr &
0x0fff));
+
+ flush_cache_all();
+ smp_wmb();
+ outer_clean_range(0, trampoline_size);
+
+ /* This will release CPU #1 out of reset. */
+ writel(0, rst_manager_base_addr + SOCFPGA_A10_RSTMGR_MODMPURST);
+ }
+
+ return 0;
+}
+
static void __init socfpga_smp_prepare_cpus(unsigned int max_cpus)
{
struct device_node *np;
@@ -91,4 +112,13 @@ struct smp_operations socfpga_smp_ops __initdata = {
#endif
};
+struct smp_operations socfpga_a10_smp_ops __initdata = {
+ .smp_prepare_cpus = socfpga_smp_prepare_cpus,
+ .smp_boot_secondary = socfpga_a10_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_die= socfpga_cpu_die,
+#endif
+};
+
CPU_METHOD_OF_DECLARE(socfpga_smp, "altr,socfpga-smp", _smp_ops);
+CPU_METHOD_OF_DECLARE(socfpga_a10_smp, "altr,socfpga-a10-smp",
_a10_smp_ops);
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: socfpga: dts: add enable-method property for cpu nodes
From: Dinh Nguyen
Add the enable-method property for the cpu node on socfpga.dtsi and
socfpga_arria10.dtsi. This is for CPU_METHOD_OF_DECLARE to use to enable
the secondary core.
Signed-off-by: Dinh Nguyen
---
arch/arm/boot/dts/socfpga.dtsi | 1 +
arch/arm/boot/dts/socfpga_arria10.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 9b653ed..80f924d 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -36,6 +36,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "altr,socfpga-smp";
cpu@0 {
compatible = "arm,cortex-a9";
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index d025f77..6ceb26e 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -24,6 +24,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "altr,socfpga-a10-smp";
cpu@0 {
compatible = "arm,cortex-a9";
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: socfpga: enable SMP for Arria10
From: Dinh Nguyen Hi, The goal of these 3 patches is to enable SMP on the Arria10 platform. During the process, I found it would be much cleaner to convert the Cyclone5/Arria5 platform to use CPU_METHOD_OF_DECLARE instead of the machine descriptor. The procedure to enable SMP on the Arria10 platform is similar to the Cyclone5/ Arria5 with the exception of a few differences in the register offset of the reset manager designed to bring the secondary core out of reset. So instead of littering the code with machine lookups, just use CPU_METHOD_OF_DECLARE. Thanks, Dinh Nguyen (3): ARM: socfpga: use CPU_METHOD_OF_DECLARE for socfpga_cyclone5 ARM: socfpga: add CPU_METHOD_OF_DECLARE for Arria 10 ARM: socfpga: dts: add enable-method property for cpu nodes arch/arm/boot/dts/socfpga.dtsi | 1 + arch/arm/boot/dts/socfpga_arria10.dtsi | 1 + arch/arm/mach-socfpga/core.h | 2 ++ arch/arm/mach-socfpga/platsmp.c| 32 arch/arm/mach-socfpga/socfpga.c| 1 - 5 files changed, 36 insertions(+), 1 deletion(-) -- 2.2.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 resend 5/5] blackfin: Fix build error
ping
On 05/04/2015 03:30 PM, Guenter Roeck wrote:
Fix
include/asm-generic/io.h: In function 'readb':
include/asm-generic/io.h:113:2: error:
implicit declaration of function 'bfin_read8'
include/asm-generic/io.h: In function 'readw':
include/asm-generic/io.h:121:2: error:
implicit declaration of function 'bfin_read16'
include/asm-generic/io.h: In function 'readl':
include/asm-generic/io.h:129:2: error:
implicit declaration of function 'bfin_read32'
include/asm-generic/io.h: In function 'writeb':
include/asm-generic/io.h:147:2: error:
implicit declaration of function 'bfin_write8'
include/asm-generic/io.h: In function 'writew':
include/asm-generic/io.h:155:2: error:
implicit declaration of function 'bfin_write16'
include/asm-generic/io.h: In function 'writel':
include/asm-generic/io.h:163:2: error:
implicit declaration of function 'bfin_write32'
Reported-by: Geert Uytterhoeven
Fixes: 1a3372bc522ef ("blackfin: io: define __raw_readx/writex with
bfin_readx/writex")
Cc: Steven Miao
Signed-off-by: Guenter Roeck
---
Please consider pushing this patch into mainline, or provide feedback
on how to improve it to be acceptable.
arch/blackfin/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/blackfin/include/asm/io.h b/arch/blackfin/include/asm/io.h
index 4e8ad0523118..6abebe82d4e9 100644
--- a/arch/blackfin/include/asm/io.h
+++ b/arch/blackfin/include/asm/io.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#define __raw_readb bfin_read8
#define __raw_readw bfin_read16
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 4/5] score: Fix exception handler label
On 05/04/2015 03:30 PM, Guenter Roeck wrote: The latest version of modinfo fails to compile score architecture targets with the following error. FATAL: The relocation at __ex_table+0x634 references section "__ex_table" which is not executable, IOW the kernel will fault if it ever tries to jump to it. Something is seriously wrong and should be fixed. The probem is caused by a bad label in an __ex_table entry. Cc: Quentin Casasnovas Signed-off-by: Guenter Roeck --- Please consider pushing this patch into mainline, or provide feedback on how to improve it to be acceptable. ping ... still not in mainline. Thanks, Guenter arch/score/lib/string.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/score/lib/string.S b/arch/score/lib/string.S index 00b7d3a2fc60..16efa3ad037f 100644 --- a/arch/score/lib/string.S +++ b/arch/score/lib/string.S @@ -175,10 +175,10 @@ ENTRY(__clear_user) br r3 .section .fixup, "ax" +99: br r3 .previous .section __ex_table, "a" .align 2 -99: .word 0b, 99b .previous -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 3/5] xtensa: Provide dummy dma_alloc_attrs() and dma_free_attrs()
On 05/04/2015 03:35 PM, Chris Zankel wrote:
Hi Guenter,
Sorry for the delay. Will work on it later today or tomorrow.
Hi Chris,
I see this patch in -next, but still not in mainline.
Are you planning to send it to Linus anytime soon ?
Thanks,
Guenter
Thanks,
-Chris
On Mon, May 4, 2015 at 3:30 PM, Guenter Roeck wrote:
xtensa:allmodconfig fails to build with the following errors.
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:
In function ‘gk20a_instobj_dtor_dma’:
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:154:2: error:
implicit declaration of function ‘dma_free_attrs’
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:
In function ‘gk20a_instobj_ctor_dma’:
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:218:2: error:
implicit declaration of function ‘dma_alloc_attrs’
Xtensa does not provide those functions at this time.
Provide dummy implementations to avoid build errors.
Acked-by: Max Filippov
Signed-off-by: Guenter Roeck
---
Please consider pushing this patch into mainline, or provide feedback
on how to improve it to be acceptable.
arch/xtensa/include/asm/dma-mapping.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/xtensa/include/asm/dma-mapping.h
b/arch/xtensa/include/asm/dma-mapping.h
index 172a02a6ad14..ba78ccf651e7 100644
--- a/arch/xtensa/include/asm/dma-mapping.h
+++ b/arch/xtensa/include/asm/dma-mapping.h
@@ -185,4 +185,17 @@ static inline int dma_get_sgtable(struct device *dev,
struct sg_table *sgt,
return -EINVAL;
}
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
+{
+ return NULL;
+}
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
+{
+}
+
#endif /* _XTENSA_DMA_MAPPING_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Add --show-total-period for perf annotate
Martin Liška writes: > I've been working on a new feature for perf annotate, which should be able to > annotate > instructions with total spent time (compared to percentage usage). > > Let's consider following use-case. You want to compare two different compilers > on the same code base and let's assume 90% of wall-time is spent in a single > function. > Moreover, let's say that these compilers produce assembly of a totally > different size. > > In such case, it's very useful to get an approximation of spent time on a > bunch of instructions, > which can be compared among other compilers. Otherwise, one has to somehow > sum percentages and compare > it to size of a function. perf diff does not handle this? Especially with the differential profiling options it should. >> @@ -623,6 +624,8 @@ static int __cmd_record(struct record *rec, int argc, >> const char **argv) > if (!target__none(>target) && !opts->initial_delay) > perf_evlist__enable(rec->evlist); > > + t0 = rdclock(); > + > /* >* Let the child rip >*/ > @@ -692,6 +695,9 @@ static int __cmd_record(struct record *rec, int argc, > const char **argv) > goto out_child; > } > > + t1 = rdclock(); > + walltime_nsecs = t1 - t0; The walltime can be later computed by the difference of the first and the last time stamp after sorting the events. So you don't need the new header. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] ARM: dts: exynos5: labels for overriding nodes
On 05/17/15 17:26, Krzysztof Kozlowski wrote: > Hi, > > > Changes since v3 > > 1. Rebased on current Kukjin's for-next branch: >v4.1-rc3-34-gfcfae6b049cf > > Changes since v2 > > 1. New patch 8/8: ARM: dts: Use labels for overriding nodes >in exynos5422-odroidxu3 > 2. To avoid conflicts rebased on my "for-next" branch of >https://github.com/krzk/linux >The branch above contains some patches for Exynos5 boards >applied from LKML. > > Changes since v1 > > 1. Re-phrased the description (phandle->label). Suggested by Arnd. > > > Description > === > The label-based notation reduces possible mistakes when overriding > nodes by child DTSI and board files and reduces duplication > of addresses. > > The patchset refactors Exynos5 boards to use labels for overriding nodes. > > Tested by comparison of decompiled DTB for each commit. > Same, will sort out. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6 00/13] ARM: dts: exynos4: labels for overriding nodes
On 05/17/15 17:09, Krzysztof Kozlowski wrote: > Hi, > Hi, > > Changes since v5 > > 1. Rebased on current Kukjin's for-next branch: >v4.1-rc3-34-gfcfae6b049cf > > Changes since v4 > > 1. Patch 1: Don't add labels in exynos4210-pinctrl.dtsi because >these are already defined in exynos4210.dtsi. > 2. Patch 9: Add ack from Eduardo Valentin. > > Changes since v3 > > 1. New patches (12 and 13) for Exynos4412 Origen and Tiny4412. > 2. Rebased on top of my DTS-for-next branch: >repo: https://github.com/krzk/linux/ >tag: samsung-dt-for-next-4.2-2 > > Changes since v2 > > 1. Fix typo in commit msg (lablels -> labels). > > Changes since v1 > > 1. Re-phrased the description (phandle->label). Suggested by Arnd. > > Description > === > > The label-based notation reduces possible mistakes when overriding > nodes by child DTSI and board files and reduces duplication > of addresses. > > The patchset refactors Exynos4 boards to use labels for overriding nodes. > > Tested by comparison of decompiled DTB for each commit. The output DTB > is the same. > Thanks for your resending. Looks good to me and I'll sort them out in this weekend. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] alloc_huge_page/hugetlb_reserve_pages race
This updated patch set includes new documentation for the region/ reserve map routines. Since I am not the original author of this code, comments would be appreciated. While working on hugetlbfs fallocate support, I noticed the following race in the existing code. It is unlikely that this race is hit very often in the current code. However, if more functionality to add and remove pages to hugetlbfs mappings (such as fallocate) is added the likelihood of hitting this race will increase. alloc_huge_page and hugetlb_reserve_pages use information from the reserve map to determine if there are enough available huge pages to complete the operation, as well as adjust global reserve and subpool usage counts. The order of operations is as follows: - call region_chg() to determine the expected change based on reserve map - determine if enough resources are available for this operation - adjust global counts based on the expected change - call region_add() to update the reserve map The issue is that reserve map could change between the call to region_chg and region_add. In this case, the counters which were adjusted based on the output of region_chg will not be correct. In order to hit this race today, there must be an existing shared hugetlb mmap created with the MAP_NORESERVE flag. A page fault to allocate a huge page via this mapping must occur at the same another task is mapping the same region without the MAP_NORESERVE flag. The patch set does not prevent the race from happening. Rather, it adds simple functionality to detect when the race has occurred. If a race is detected, then the incorrect counts are adjusted. v2: Added documentation for the region/reserve map routines Created common routine for vma_commit_reservation and vma_commit_reservation to help prevent them from drifting apart in the future. Mike Kravetz (2): mm/hugetlb: compute/return the number of regions added by region_add() mm/hugetlb: handle races in alloc_huge_page and hugetlb_reserve_pages mm/hugetlb.c | 154 +++ 1 file changed, 124 insertions(+), 30 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] mm/hugetlb: compute/return the number of regions added by region_add()
Modify region_add() to keep track of regions(pages) added to the
reserve map and return this value. The return value can be
compared to the return value of region_chg() to determine if the
map was modified between calls.
Add documentation to the reserve/region map routines.
Make vma_commit_reservation() also pass along the return value of
region_add(). In the normal case, we want vma_commit_reservation
to return the same value as the preceding call to vma_needs_reservation.
Create a common __vma_reservation_common routine to help keep the
special case return values in sync
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 120 ++-
1 file changed, 94 insertions(+), 26 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 54f129d..3855889 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -212,8 +212,16 @@ static inline struct hugepage_subpool *subpool_vma(struct
vm_area_struct *vma)
* Region tracking -- allows tracking of reservations and instantiated pages
*across the pages in a mapping.
*
- * The region data structures are embedded into a resv_map and
- * protected by a resv_map's lock
+ * The region data structures are embedded into a resv_map and protected
+ * by a resv_map's lock. The set of regions within the resv_map represent
+ * reservations for huge pages, or huge pages that have already been
+ * instantiated within the map. The from and to elements are huge page
+ * indicies into the associated mapping. from indicates the starting index
+ * of the region. to represents the first index past the end of the region.
+ * For example, a file region structure with from == 0 and to == 4 represents
+ * four huge pages in a mapping. It is important to note that the to element
+ * represents the first element past the end of the region. This is used in
+ * arithmetic as 4(to) - 0(from) = 4 huge pages in the region.
*/
struct file_region {
struct list_head link;
@@ -221,10 +229,23 @@ struct file_region {
long to;
};
+/*
+ * Add the huge page range represented by indicies f (from)
+ * and t (to) to the reserve map. Existing regions will be
+ * expanded to accommodate the specified range. We know only
+ * existing regions need to be expanded, because region_add
+ * is only called after region_chg(with the same range). If
+ * a new file_region structure must be allocated, it is done
+ * in region_chg.
+ *
+ * Return the number of new huge pages added to the map. This
+ * number is greater than or equal to zero.
+ */
static long region_add(struct resv_map *resv, long f, long t)
{
struct list_head *head = >regions;
struct file_region *rg, *nrg, *trg;
+ long add = 0;
spin_lock(>lock);
/* Locate the region we are either in or before. */
@@ -250,16 +271,44 @@ static long region_add(struct resv_map *resv, long f,
long t)
if (rg->to > t)
t = rg->to;
if (rg != nrg) {
+ /* Decrement return value by the deleted range.
+* Another range will span this area so that by
+* end of routine add will be >= zero
+*/
+ add -= (rg->to - rg->from);
list_del(>link);
kfree(rg);
}
}
+
+ add += (nrg->from - f); /* Added to beginning of region */
nrg->from = f;
+ add += t - nrg->to; /* Added to end of region */
nrg->to = t;
+
spin_unlock(>lock);
- return 0;
+ return add;
}
+/*
+ * Examine the existing reserve map and determine how many
+ * huge pages in the specified range (f, t) are NOT currently
+ * represented. This routine is called before a subsequent
+ * call to region_add that will actually modify the reserve
+ * map to add the specified range (f, t). region_chg does
+ * not change the number of huge pages represented by the
+ * map. However, if the existing regions in the map can not
+ * be expanded to represent the new range, a new file_region
+ * structure is added to the map as a placeholder. This is
+ * so that the subsequent region_add call will have all
+ * regions it needs and will not fail.
+ *
+ * Returns the number of huge pages that need to be added
+ * to the existing reservation map for the range (f, t).
+ * This number is greater or equal to zero. -ENOMEM is
+ * returned if a new file_region structure can not be
+ * allocated.
+ */
static long region_chg(struct resv_map *resv, long f, long t)
{
struct list_head *head = >regions;
@@ -326,6 +375,11 @@ out_nrg:
return chg;
}
+/*
+ * Truncate the reserve map at index 'end'. Modify/truncate any
+ * region which contains end. Delete any regions past end.
+ * Return the number of huge pages removed from the map.
+ */
static long region_truncate(struct resv_map *resv, long
[PATCH v2 2/2] mm/hugetlb: handle races in alloc_huge_page and hugetlb_reserve_pages
alloc_huge_page and hugetlb_reserve_pages use region_chg to
calculate the number of pages which will be added to the reserve
map. Subpool and global reserve counts are adjusted based on
the output of region_chg. Before the pages are actually added
to the reserve map, these routines could race and add fewer
pages than expected. If this happens, the subpool and global
reserve counts are not correct.
Compare the number of pages actually added (region_add) to those
expected to added (region_chg). If fewer pages are actually added,
this indicates a race and adjust counters accordingly.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 34 ++
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3855889..9234163 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1540,7 +1540,7 @@ static struct page *alloc_huge_page(struct vm_area_struct
*vma,
struct hugepage_subpool *spool = subpool_vma(vma);
struct hstate *h = hstate_vma(vma);
struct page *page;
- long chg;
+ long chg, commit;
int ret, idx;
struct hugetlb_cgroup *h_cg;
@@ -1581,7 +1581,20 @@ static struct page *alloc_huge_page(struct
vm_area_struct *vma,
set_page_private(page, (unsigned long)spool);
- vma_commit_reservation(h, vma, addr);
+ commit = vma_commit_reservation(h, vma, addr);
+ if (unlikely(chg > commit)) {
+ /*
+* The page was added to the reservation map between
+* vma_needs_reservation and vma_commit_reservation.
+* This indicates a race with hugetlb_reserve_pages.
+* Adjust for the subpool count incremented above AND
+* in hugetlb_reserve_pages for the same page. Also,
+* the reservation count added in hugetlb_reserve_pages
+* no longer applies.
+*/
+ hugepage_subpool_put_pages(spool, 1);
+ hugetlb_acct_memory(h, -1);
+ }
return page;
out_uncharge_cgroup:
@@ -3695,8 +3708,21 @@ int hugetlb_reserve_pages(struct inode *inode,
* consumed reservations are stored in the map. Hence, nothing
* else has to be done for private mappings here
*/
- if (!vma || vma->vm_flags & VM_MAYSHARE)
- region_add(resv_map, from, to);
+ if (!vma || vma->vm_flags & VM_MAYSHARE) {
+ long add = region_add(resv_map, from, to);
+
+ if (unlikely(chg > add)) {
+ /*
+* pages in this range were added to the reserve
+* map between region_chg and region_add. This
+* indicates a race with alloc_huge_page. Adjust
+* the subpool and reserve counts modified above
+* based on the difference.
+*/
+ hugepage_subpool_put_pages(spool, chg - add);
+ hugetlb_acct_memory(h, -(chg - ret));
+ }
+ }
return 0;
out_err:
if (vma && is_vma_resv_set(vma, HPAGE_RESV_OWNER))
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Ceph fixes for -rc5
On Fri, 22 May 2015, Linus Torvalds wrote: > On Fri, May 22, 2015 at 5:13 PM, Sage Weil wrote: > > Hi Linus, > > > > Please pull the following fixes from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git > > Nothing there. > > Did you perhaps mean the "for-linus" branch? > > Please fix whatever script it is you use that generates bad pull requests. Bah, I forgot to push the for-linus branch--it's there now. Sorry! (BTW, git://git.kernel.org is going really slowly today... :/) Thanks- sage -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup
-- Daniel J Blueman Principal Software Engineer, Numascale On Sat, May 23, 2015 at 1:14 AM, Waiman Long wrote: On 05/22/2015 05:33 AM, Mel Gorman wrote: On Fri, May 22, 2015 at 02:30:01PM +0800, Daniel J Blueman wrote: On Thu, May 14, 2015 at 6:03 PM, Daniel J Blueman wrote: On Thu, May 14, 2015 at 12:31 AM, Mel Gorman wrote: On Wed, May 13, 2015 at 10:53:33AM -0500, nzimmer wrote: I am just noticed a hang on my largest box. I can only reproduce with large core counts, if I turn down the number of cpus it doesn't have an issue. Odd. The number of core counts should make little a difference as only one CPU per node should be in use. Does sysrq+t give any indication how or where it is hanging? I was seeing the same behaviour of 1000ms increasing to 5500ms [1]; this suggests either lock contention or O(n) behaviour. Nathan, can you check with this ordering of patches from Andrew's cache [2]? I was getting hanging until I a found them all. I'll follow up with timing data. 7TB over 216 NUMA nodes, 1728 cores, from kernel 4.0.4 load to login: 1. 2086s with patches 01-19 [1] 2. 2026s adding "Take into account that large system caches scale linearly with memory", which has: min(2UL<< (30 - PAGE_SHIFT), (pgdat->node_spanned_pages>> 3)); 3. 2442s fixing to: max(2UL<< (30 - PAGE_SHIFT), (pgdat->node_spanned_pages>> 3)); 4. 2064s adjusting minimum and shift to: max(512UL<< (20 - PAGE_SHIFT), (pgdat->node_spanned_pages>> 8)); 5. 1934s adjusting minimum and shift to: max(128UL<< (20 - PAGE_SHIFT), (pgdat->node_spanned_pages>> 8)); 6. 930s #5 with the non-temporal PMD init patch I had earlier proposed (I'll pursue separately) The scaling patch isn't in -mm. That patch was superceded by "mm: meminit: finish initialisation of struct pages before basic setup" and "mm-meminit-finish-initialisation-of-struct-pages-before-basic-setup-fix" so that's ok. FWIW, I think you should still go ahead with the non-temporal patches because there is potential benefit there other than the initialisation. If there was an arch-optional implementation of a non-termporal clear then it would also be worth considering if __GFP_ZERO should use non-temporal stores. At a greater stretch it would be worth considering if kswapd freeing should zero pages to avoid a zero on the allocation side in the general case as it would be more generally useful and a stepping stone towards what the series "Sanitizing freed pages" attempts. Good tip Mel; I'll take a look when time allows and get some data, though I guess it'll only be a win where the clearing is on a different node than the allocation. I think the non-temporal patch benefits mainly AMD systems. I have tried the patch on both DragonHawk and it actually made it boot up a little bit slower. I think the Intel optimized "rep stosb" instruction (used in memset) is performing well. I had done similar test on zero page code and the performance gain was non-conclusive. I suspect 'rep stosb' on modern Intel hardware can write whole cachelines atomically, avoiding the RMW, or that the read part of the RMW is optimally prefetched. Open-coding it just can't reach the same level of pipeline saturation that the microcode can. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Implementing a gpio based regulator with status pins
Hi all, I have a system with a gpio based regulator which does not only have an enable pin, but also a status pin to report the actual power status. In some cases there may be a secondary status pin, making it possible to report on/off/error. Some twist of this is that power activation time is not exactly well defined; activation can vary from board to board. I could of course use the existing (fixed) timeout supported by the regulator core, but it would be nice to be able to use an interrupt on the status pin(s), possibly with a timeout, to achieve a dynamic activation time. The gpio pin(s) support interrupts, making it possible to report status updates, which might be useful if the power source goes bad or to support a dynamic power enable time. As far as I can see, the existing gpio regulators don't implement status pins. What would be the best way to implement this ? - Add status support to the 'fixed' regulator - Add status support to gpio-regulator.c - Add (gpio) status support to the regulator core - Write a new regulator driver - Something else 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/
RE: [HPDD-discuss] [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
Since it is not actually doing a printk - at least, not necessarily - I like lustre_logmsg. lustre_output seems too vague. - Patrick From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Joe Perches [j...@perches.com] Sent: Friday, May 22, 2015 7:36 PM To: Drokin, Oleg Cc: ; ; ; ; Julia Lawall; ; Subject: Re: [HPDD-discuss] [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes On Sat, 2015-05-23 at 00:25 +, Drokin, Oleg wrote: > On May 22, 2015, at 8:18 PM, Joe Perches wrote: > I wonder what is more clear about that in your opinion ve > lustre_error/lustre_debug? > >>> > >>> The fact that you have to explain this shows that it's > >>> at least misleading unless you completely understand the > >>> code. > >> > >> Or you know, you might take the function name at the face value > >> and assume that CERROR means it's an error and CDEBUG means it's a debug > >> message? > > > > Maybe, but I think that it'd be better if the mechanism > > it uses was more plainly named something like lustre_log. > > While the idea seems good, the biggest obstacle here is such that > there's already a thing called lustre log (llog for short too) - > it's kind of a distributed journal of operations. > > Its there a different synonym, I wonder? Maybe: lustre_printk, lustre_logmsg, lustre_output ___ HPDD-discuss mailing list hpdd-disc...@lists.01.org https://lists.01.org/mailman/listinfo/hpdd-discuss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
During probe free the memory allocated to "exynos_info" in case of
unknown SOC type.
Signed-off-by: Shailendra Verma
---
drivers/cpufreq/exynos-cpufreq.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 82d2fbb..5b57a0f 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -182,20 +182,25 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
ret = exynos5250_cpufreq_init(exynos_info);
} else {
pr_err("%s: Unknown SoC type\n", __func__);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_vdd_arm;
}
- if (ret)
+ if (ret) {
+ ret = -EINVAL;
goto err_vdd_arm;
+ }
if (exynos_info->set_freq == NULL) {
dev_err(>dev, "No set_freq function (ERR)\n");
+ ret = -EINVAL;
goto err_vdd_arm;
}
arm_regulator = regulator_get(NULL, "vdd_arm");
if (IS_ERR(arm_regulator)) {
dev_err(>dev, "failed to get resource vdd_arm\n");
+ ret = -EINVAL;
goto err_vdd_arm;
}
@@ -203,8 +208,10 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
ret = cpufreq_register_driver(_driver);
- if (ret)
+ if (ret) {
+ ret = -EINVAL;
goto err_cpufreq_reg;
+ }
cpu0 = of_get_cpu_node(0, NULL);
if (!cpu0) {
@@ -227,7 +234,7 @@ err_cpufreq_reg:
regulator_put(arm_regulator);
err_vdd_arm:
kfree(exynos_info);
- return -EINVAL;
+ return ret;
}
static struct platform_driver exynos_cpufreq_platdrv = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v5 0/2] Adding support for Cavium ThunderX network controller
This patchset adds support for the Cavium ThunderX network controller. changes in v5: * __packed were removed. now we rely on C language ABI * nic_dbg() -> netdev_dbg() * fixes for a typo, constant spelling and using BIT_ULL * use print_hex_dump() * unnecessary conditions in a long if() chain were removed changes in v4: * the patch "pci: Add Cavium PCI vendor id" was attributed correctly * a note that Cavium id is used in many drivers was added * the license comments now match MODULE_LICENSE * a comment explaining usage of writeq_relaxed()/readq_relaxed() was added changes in v3: * code cleanup * issues discovered by reviewers were addressed changes in v2: * non-generic module parameters removed * ethtool support added (nicvf_set_rxnfc()) Sunil Goutham (2): pci: Add Cavium PCI vendor id net: Adding support for Cavium ThunderX network controller MAINTAINERS|7 + drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile |1 + drivers/net/ethernet/cavium/Kconfig| 40 + drivers/net/ethernet/cavium/Makefile |5 + drivers/net/ethernet/cavium/thunder/Makefile | 11 + drivers/net/ethernet/cavium/thunder/nic.h | 419 ++ drivers/net/ethernet/cavium/thunder/nic_main.c | 940 + drivers/net/ethernet/cavium/thunder/nic_reg.h | 213 +++ .../net/ethernet/cavium/thunder/nicvf_ethtool.c| 624 + drivers/net/ethernet/cavium/thunder/nicvf_main.c | 1324 ++ drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 1413 drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 375 ++ drivers/net/ethernet/cavium/thunder/q_struct.h | 701 ++ drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 966 + drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 223 +++ include/linux/pci_ids.h|2 + 17 files changed, 7265 insertions(+) create mode 100644 drivers/net/ethernet/cavium/Kconfig create mode 100644 drivers/net/ethernet/cavium/Makefile create mode 100644 drivers/net/ethernet/cavium/thunder/Makefile create mode 100644 drivers/net/ethernet/cavium/thunder/nic.h create mode 100644 drivers/net/ethernet/cavium/thunder/nic_main.c create mode 100644 drivers/net/ethernet/cavium/thunder/nic_reg.h create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_main.c create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_queues.c create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_queues.h create mode 100644 drivers/net/ethernet/cavium/thunder/q_struct.h create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_bgx.c create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_bgx.h -- 2.4.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] selftest, x86: fix incorrect comment
The current comment indicates it's checking for a 32-bit build environment, but it actually checks for a 64-bit environment. Fix this. Signed-off-by: Martin Kelly --- tools/testing/selftests/x86/trivial_64bit_program.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/x86/trivial_64bit_program.c b/tools/testing/selftests/x86/trivial_64bit_program.c index b994946..05c6a41 100644 --- a/tools/testing/selftests/x86/trivial_64bit_program.c +++ b/tools/testing/selftests/x86/trivial_64bit_program.c @@ -1,5 +1,5 @@ /* - * Trivial program to check that we have a valid 32-bit build environment. + * Trivial program to check that we have a valid 64-bit build environment. * Copyright (c) 2015 Andy Lutomirski * GPL v2 */ -- 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: [RFC v3 PATCH 00/10] hugetlbfs: add fallocate support
On 05/22/2015 02:50 PM, Davidlohr Bueso wrote: On Thu, 2015-05-21 at 08:47 -0700, Mike Kravetz wrote: This patch set adds fallocate functionality to hugetlbfs. It would be good to also have proper testcases in, say, libhugetlbfs. Makes sense. I have some functionality and stress tests I have been using during development. I'll start work on adding them to the libhugetlbfs test harness. -- Mike Kravetz Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: exynos4: Remove obsolete MIPI DPHY 'reg' property
On 05/21/15 16:23, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On Thu, May 21, 2015 at 4:18 AM, Krzysztof Kozlowski
> wrote:
>> Since e4b3d38088df ("phy: exynos-video-mipi: Fix regression by adding
>> support for PMU regmap") the Exynos PMU driver provides regmap to access
>> the MIPI DPHY registers. The MIPI DPHY node uses a phandle to syscon to
>> get this regmap. The 'reg' field is obsolete.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> arch/arm/boot/dts/exynos4.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index 1c74c1296ab7..6e7f0b4afa84 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -78,7 +78,6 @@
>>
>> mipi_phy: video-phy@10020710 {
>> compatible = "samsung,s5pv210-mipi-video-phy";
>> - reg = <0x10020710 8>;
>> #phy-cells = <1>;
>> syscon = <_system_controller>;
>> };
>
> Indeed, is even removed from the DT binding so this is clearly a left over.
>
> Reviewed-by: Javier Martinez Canillas
>
Thanks, applied this series.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: multi_v7_defconfig: Enable display on Trats2board
On 05/22/15 18:11, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/22/2015 02:48 AM, Krzysztof Kozlowski wrote: >> Enable the Exynos DSI and S6E8AA0 panel for full X11 display on Trats2. >> >> Signed-off-by: Krzysztof Kozlowski >> --- >> arch/arm/configs/multi_v7_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/configs/multi_v7_defconfig >> b/arch/arm/configs/multi_v7_defconfig >> index 0848337a2a01..e9785020aab1 100644 >> --- a/arch/arm/configs/multi_v7_defconfig >> +++ b/arch/arm/configs/multi_v7_defconfig >> @@ -413,10 +413,12 @@ CONFIG_DRM=y >> CONFIG_DRM_PTN3460=m >> CONFIG_DRM_PS8622=m >> CONFIG_DRM_EXYNOS=m >> +CONFIG_DRM_EXYNOS_DSI=y >> CONFIG_DRM_EXYNOS_FIMD=y >> CONFIG_DRM_EXYNOS_HDMI=y >> CONFIG_DRM_RCAR_DU=m >> CONFIG_DRM_TEGRA=y >> +CONFIG_DRM_PANEL_S6E8AA0=m >> CONFIG_DRM_PANEL_SIMPLE=y >> CONFIG_FB_ARMCLCD=y >> CONFIG_FB_WM8505=y >> > > Reviewed-by: Javier Martinez Canillas > Looks good to me and this would be handled by arm-soc guys directly :-) Acked-by: Kukjin Kim Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: exynos_defconfig: Enable display on Trats2 board
On 05/22/15 18:09, Javier Martinez Canillas wrote: > Hello Krzysztof, > Hi, > On 05/22/2015 02:48 AM, Krzysztof Kozlowski wrote: >> Enable the Exynos DSI and S6E8AA0 panel for full X11 display on Trats2. >> >> Signed-off-by: Krzysztof Kozlowski >> --- >> arch/arm/configs/exynos_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index d034c96c039b..e7ccec487422 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -135,9 +135,11 @@ CONFIG_DRM_BRIDGE=y >> CONFIG_DRM_PTN3460=y >> CONFIG_DRM_PS8622=y >> CONFIG_DRM_EXYNOS=y >> +CONFIG_DRM_EXYNOS_DSI=y >> CONFIG_DRM_EXYNOS_FIMD=y >> CONFIG_DRM_EXYNOS_DP=y >> CONFIG_DRM_PANEL=y >> +CONFIG_DRM_PANEL_S6E8AA0=y >> CONFIG_DRM_PANEL_SIMPLE=y >> CONFIG_FB=y >> CONFIG_FB_MODE_HELPERS=y >> > > Reviewed-by: Javier Martinez Canillas > Thanks, applied. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: stmmac: create one debugfs dir per net-device
stmmac DebugFS entries are currently global to the driver. As a result,
having more than one stmmac device in the system creates the following
error:
* ERROR stmmaceth, debugfs create directory failed
* stmmac_hw_setup: failed debugFS registration
This also results in being able to access the debugfs information for
the first registered device only.
This patch changes the debugfs structure to have one sub-directory per
net-device. Files under "/sys/kernel/debug/stmmaceth" will now show-up
under /sys/kernel/debug/stmmaceth/ethN/.
Signed-off-by: Mathieu Olivari
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 76 ---
2 files changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 9cbcae2..1f3b33a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -125,6 +125,12 @@ struct stmmac_priv {
int use_riwt;
int irq_wake;
spinlock_t ptp_lock;
+
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *dbgfs_dir;
+ struct dentry *dbgfs_rings_status;
+ struct dentry *dbgfs_dma_cap;
+#endif
};
int stmmac_mdio_unregister(struct net_device *ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c46178c..a515673 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -119,7 +119,7 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
#ifdef CONFIG_DEBUG_FS
static int stmmac_init_fs(struct net_device *dev);
-static void stmmac_exit_fs(void);
+static void stmmac_exit_fs(struct net_device *dev);
#endif
#define STMMAC_COAL_TIMER(x) (jiffies + usecs_to_jiffies(x))
@@ -1922,7 +1922,7 @@ static int stmmac_release(struct net_device *dev)
netif_carrier_off(dev);
#ifdef CONFIG_DEBUG_FS
- stmmac_exit_fs();
+ stmmac_exit_fs(dev);
#endif
stmmac_release_ptp(priv);
@@ -2514,8 +2514,6 @@ static int stmmac_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
#ifdef CONFIG_DEBUG_FS
static struct dentry *stmmac_fs_dir;
-static struct dentry *stmmac_rings_status;
-static struct dentry *stmmac_dma_cap;
static void sysfs_display_ring(void *head, int size, int extend_desc,
struct seq_file *seq)
@@ -2654,36 +2652,39 @@ static const struct file_operations stmmac_dma_cap_fops
= {
static int stmmac_init_fs(struct net_device *dev)
{
- /* Create debugfs entries */
- stmmac_fs_dir = debugfs_create_dir(STMMAC_RESOURCE_NAME, NULL);
+ struct stmmac_priv *priv = netdev_priv(dev);
+
+ /* Create per netdev entries */
+ priv->dbgfs_dir = debugfs_create_dir(dev->name, stmmac_fs_dir);
- if (!stmmac_fs_dir || IS_ERR(stmmac_fs_dir)) {
- pr_err("ERROR %s, debugfs create directory failed\n",
- STMMAC_RESOURCE_NAME);
+ if (!priv->dbgfs_dir || IS_ERR(priv->dbgfs_dir)) {
+ pr_err("ERROR %s/%s, debugfs create directory failed\n",
+ STMMAC_RESOURCE_NAME, dev->name);
return -ENOMEM;
}
/* Entry to report DMA RX/TX rings */
- stmmac_rings_status = debugfs_create_file("descriptors_status",
- S_IRUGO, stmmac_fs_dir, dev,
- _rings_status_fops);
+ priv->dbgfs_rings_status =
+ debugfs_create_file("descriptors_status", S_IRUGO,
+ priv->dbgfs_dir, dev,
+ _rings_status_fops);
- if (!stmmac_rings_status || IS_ERR(stmmac_rings_status)) {
+ if (!priv->dbgfs_rings_status || IS_ERR(priv->dbgfs_rings_status)) {
pr_info("ERROR creating stmmac ring debugfs file\n");
- debugfs_remove(stmmac_fs_dir);
+ debugfs_remove_recursive(priv->dbgfs_dir);
return -ENOMEM;
}
/* Entry to report the DMA HW features */
- stmmac_dma_cap = debugfs_create_file("dma_cap", S_IRUGO, stmmac_fs_dir,
-dev, _dma_cap_fops);
+ priv->dbgfs_dma_cap = debugfs_create_file("dma_cap", S_IRUGO,
+ priv->dbgfs_dir,
+ dev, _dma_cap_fops);
- if (!stmmac_dma_cap || IS_ERR(stmmac_dma_cap)) {
+ if (!priv->dbgfs_dma_cap || IS_ERR(priv->dbgfs_dma_cap)) {
pr_info("ERROR creating stmmac MMC debugfs file\n");
- debugfs_remove(stmmac_rings_status);
- debugfs_remove(stmmac_fs_dir);
+ debugfs_remove_recursive(priv->dbgfs_dir);
return -ENOMEM;
}
@@ -2691,11 +2692,11 @@
Re: [Xen-devel] Regression due to "device property: Make it possible to use secondary firmware nodes" Re: Xen-unstable + linux 4.1-mergewindow: problems with PV guest pci passthrough: pcifront pci-0:
On 05/22/2015 04:11 AM, Sander Eikelenboom wrote: Hello Sander, Friday, May 15, 2015, 12:47:27 AM, you wrote: Sorry for the resend, i messed up the to's en from's. Hi Konrad / David, One big snip on this thread, got some more debug info, hopefully this will lead to something: On a working kernel (with the two seemingly non related patches reverted) i get: [0.717796] pcifront pci-0: Allocated pdev @ 0x880019e11780 pdev->sh_info @ 0x880018f58000 [0.717848] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.717871] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.717892] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.717915] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.717984] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.721640] pcifront pci-0: publishing successful! [0.723684] usbcore: registered new interface driver udlfb [0.724664] xen:xen_evtchn: Event-channel device installed [0.726597] pcifront pci-0: Installing PCI frontend [0.726853] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.727059] pcifront pci-0: Creating PCI Frontend Bus :00 [0.727363] pcifront pci-0: PCI host bridge to bus :00 [0.727391] pci_bus :00: root bus resource [io 0x-0x] [0.727417] pci_bus :00: root bus resource [mem 0x-0x] [0.727452] pci_bus :00: root bus resource [bus 00-ff] [0.727475] pci_bus :00: scanning bus [0.727503] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.728253] Linux agpgart interface v0.103 [0.728387] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.728474] [drm] Initialized drm 1.1.0 20060810 [0.728551] [drm] radeon kernel modesetting enabled. [0.730319] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 143164178555170 ns_timeout: 1431641787541235000 evtchn:17 gnt_ref:8 [0.730319] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: read got back value 3f6 [0.738845] pcifront pci-0: read dev=:00:00.0 - offset e size 1 [0.744976] brd: module loaded [0.745204] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785562852000 ns_timeout: 143164178755258 evtchn:17 gnt_ref:8 [0.745204] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: read got back value 0 [0.749204] pcifront pci-0: read dev=:00:00.0 - offset 6 size 2 [0.750155] loop: module loaded [0.752527] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785570841000 ns_timeout: 1431641787562917000 evtchn:17 gnt_ref:8 [0.752527] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: read got back value 210 [0.757187] pcifront pci-0: read dev=:00:00.0 - offset 34 size 1 Were as in the non-working situation i get: [0.751244] pcifront pci-0: Allocated pdev @ 0x880019ec2e00 pdev->sh_info @ 0x88001aa51000 [0.751295] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.751315] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.751334] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.751355] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.751422] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.755215] pcifront pci-0: publishing successful! [0.757341] usbcore: registered new interface driver udlfb [0.758365] xen:xen_evtchn: Event-channel device installed [0.760419] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.760819] pcifront pci-0: Installing PCI frontend [0.761518] pcifront pci-0: Creating PCI Frontend Bus :00 [0.761684] pcifront pci-0: PCI host bridge to bus :00 [0.761710] pci_bus :00: root bus resource [io 0x-0x] [0.761733] pci_bus :00: root bus resource [mem 0x-0x] [0.761763] pci_bus :00: root bus resource [bus 00-ff] [0.761783] pci_bus :00: scanning bus [0.761805] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.767207] Linux agpgart interface v0.103 [0.767362] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.767439] [drm] Initialized drm 1.1.0 20060810 [0.767515] [drm] radeon kernel modesetting enabled. [0.766948] pcifront pci-0: pciback not responding!!! irq:31 irq_flags:880019ec0028 ns: 1431641983026498000 ns_timeout: 1431641983026497000 evtchn:0 gnt_ref:0 [0.766948] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:0 size:4 [
[PATCH net-next v5 1/2] pci: Add Cavium PCI vendor id
From: Sunil Goutham This vendor id will be used by network (vNIC), USB (xHCI), SATA (AHCI), GPIO, I2C, MMC and maybe other drivers for ThunderX SoC. Acked-by: Bjorn Helgaas Signed-off-by: Sunil Goutham Signed-off-by: Aleksey Makarov --- include/linux/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 1fa99a3..80bd333 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2324,6 +2324,8 @@ #define PCI_DEVICE_ID_ALTIMA_AC91000x03ea #define PCI_DEVICE_ID_ALTIMA_AC10030x03eb +#define PCI_VENDOR_ID_CAVIUM 0x177d + #define PCI_VENDOR_ID_BELKIN 0x1799 #define PCI_DEVICE_ID_BELKIN_F5D7010V7 0x701f -- 2.4.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] PCI / hotplug: Propagate the "ignore hotplug" setting to parent
On Mon, Apr 13, 2015 at 04:23:36PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Refine the mechanism introduced by commit f244d8b623da (ACPIPHP / radeon
> / nouveau: Fix VGA switcheroo problem related to hotplug) to propagate
> the ignore_hotplug setting of the device to its parent bridge in case
> hotplug notifications related to the graphics adapter switching are
> given for the bridge rather than for the device itself (the need to
> be ignored in both cases).
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
> Reported-and-tested-by: tiagdtd-lava
> Signed-off-by: Rafael J. Wysocki
Applied to pci/hotplug for v4.2, thanks!
I marked it for stable and added a note to connect it to b440bde74f04
("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
> ---
>
> "Stable" material AFAICS.
>
> ---
> drivers/pci/pci.c | 11 +++
> include/linux/pci.h |6 +-
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> Index: linux-pm/drivers/pci/pci.c
> ===
> --- linux-pm.orig/drivers/pci/pci.c
> +++ linux-pm/drivers/pci/pci.c
> @@ -4319,6 +4319,17 @@ bool pci_device_is_present(struct pci_de
> }
> EXPORT_SYMBOL_GPL(pci_device_is_present);
>
> +void pci_ignore_hotplug(struct pci_dev *dev)
> +{
> + struct pci_dev *bridge = dev->bus->self;
> +
> + dev->ignore_hotplug = 1;
> + /* Propagate the "ignore hotplug" setting to the parent bridge. */
> + if (bridge)
> + bridge->ignore_hotplug = 1;
> +}
> +EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
> +
> #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
> static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
> static DEFINE_SPINLOCK(resource_alignment_lock);
> Index: linux-pm/include/linux/pci.h
> ===
> --- linux-pm.orig/include/linux/pci.h
> +++ linux-pm/include/linux/pci.h
> @@ -1002,6 +1002,7 @@ int __must_check pci_assign_resource(str
> int __must_check pci_reassign_resource(struct pci_dev *dev, int i,
> resource_size_t add_size, resource_size_t align);
> int pci_select_bars(struct pci_dev *dev, unsigned long flags);
> bool pci_device_is_present(struct pci_dev *pdev);
> +void pci_ignore_hotplug(struct pci_dev *dev);
>
> /* ROM control related routines */
> int pci_enable_rom(struct pci_dev *pdev);
> @@ -1039,11 +1040,6 @@ bool pci_dev_run_wake(struct pci_dev *de
> bool pci_check_pme_status(struct pci_dev *dev);
> void pci_pme_wakeup_bus(struct pci_bus *bus);
>
> -static inline void pci_ignore_hotplug(struct pci_dev *dev)
> -{
> - dev->ignore_hotplug = 1;
> -}
> -
> static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state,
> bool enable)
> {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device
*acpi_dev)
struct list_head *physnode_list;
unsigned int node_id;
int retval = -EINVAL;
+ bool coherent;
if (has_acpi_companion(dev)) {
if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device
*acpi_dev)
if (!has_acpi_companion(dev))
ACPI_COMPANION_SET(dev, acpi_dev);
+ if (acpi_check_dma(acpi_dev, ))
+ arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+
Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
(patch 3/6 in V4) will be submitted separately. We are working on
cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
>
In this case, we would be going through the following call path:
--> pci_device_add()
|--> pci_dma_configure() ** 1 **
|--> device_add()
|--> platform_notify()
|--> acpi_platform_notify()
|--> acpi_bind_one() ** 2 **
At (1), we would be calling arch_setup_dma_ops() with the PCI host
bridge _CCA information. So, it should have already taken care of
setting up device coherency here.
At (2), if there is no acpi_dev for endpoint devices (which I believe
this is normally the case), it would return early and skip
arch_setup_dma_ops().
That's not correct. There may be ACPI companions for endpoint devices too.
Ok. Duly noted :)
At (2), if there is an acpi_dev, the coherent_dma flag should have
already been setup by the acpi_init_device_object during ACPI scan.
That one sets the flag for the *ACPI* *companion* of the device, which
I'm still thinking is pointless, isn't it?
When you say pointless, are you referring to the part where we are end
up calling arch_setup_dma_coherent() twice in this case? I am not quite
following your point.
However, I am not certain about this case since I don't have the DSDT
containing PCI endpoint devices to test with.
Every x86 PC has them (as far as I can say), but in that case there's no
_CCA and they are all coherent.
Ok.
Thanks,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
> On May 22, 2015, at 1:26 AM, Marc Zyngier wrote: > > On 20/05/15 13:48, Robert Richter wrote: >> Mark, >> >> thanks for review, also of the other patches of this series. >> >> See below >> >> On 20.05.15 13:11:38, Marc Zyngier wrote: - dev_alias->dev_id = alias; + dev_alias->dev_id = (pci_domain_nr(pdev->bus) << 16) | alias; >> >>> This feels very scary. We're now assuming that the domain number will >>> always be presented to the doorbell. What guarantee do we have that >>> this is always the case, irrespective of the platform? >>> >>> Also, domains have no PCI reality, they are a Linux thing. And they can >>> be "randomly" assigned, unless you force the domain in DT with a >>> linux,pci-domain property. This looks even more wrong, specially >>> considering ACPI. >> >> The main problem here is that device ids (32 bits) are system >> specific. Since we have more than one PCI root complex we need the >> upper 16 bits in the devid for mapping. Using pci_domain_nr for this >> fits our needs for now and shouldn't affect systems with a single RC >> only as the domain nr is zero then. >> >> The domain number is incremented during initialization beginnig with >> zero and the order of it is fixed since it is taken from DT or ACPI >> tables. So we have full controll of it. I don't see issues here. > > This may match what you have on ThunderX (as long as the kernel doesn't > adopt another behaviour when allocating the domain number). But other > platforms may have a completely different numbering, which will mess > them up entirely. > >>> It really feels like we need a way to describe how the BDF numbering is >>> augmented. We also need to guarantee that we get the actual bridge >>> number, as opposed to the domain number. >> >> But true, the obove is just intermediate. In the end we need some sort >> of handler that is setup during cpu initialization that registers a >> callback for the gic to determine the device id of that paricular >> system. > > I don't really like the idea of a callback from the GIC - I'd prefer it > to be standalone, and rely on the topology information to build the > DeviceID. Mark Rutland had some ideas for DT (he posted an RFC a while > ago), maybe it would be good to get back to that and find out what we > can do. ACPI should also have similar information (IORT?). > How can some one pass this from DT, especially in GIC entry. i still think it is bus owner responsibility and call back is better idea. but if some one has a better idea for DT and ACPI, we are fine as long as it works on ThunderX. Thanks, Tirumalesh. > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Btrfs
Hi Linus, My for-linus-4.1 branch has three more fixes: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.1 I fixed up a regression from 4.0 where conversion between different raid levels would sometimes bail out without converting. Filipe tracked down a race where it was possible to double allocate chunks on the drive. Mark has a fix for fiemap. All three will get bundled off for stable as well. Chris Mason (1) commits (+18/-0): Btrfs: fix regression in raid level conversion Filipe Manana (1) commits (+3/-0): Btrfs: fix racy system chunk allocation when setting block group ro Mark Fasheh (1) commits (+17/-0): btrfs: clear 'ret' in btrfs_check_shared() loop Total: (3) commits fs/btrfs/backref.c | 17 + fs/btrfs/extent-tree.c | 20 fs/btrfs/volumes.c | 1 + 3 files changed, 38 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 net-next] bridge: allow setting hash_max + multicast_router if interface is down
Network managers like netifd (used in OpenWRT for instance) try to
configure interface options after creation but before setting the
interface up.
Unfortunately the sysfs / bridge currently only allows to configure the
hash_max and multicast_router options when the bridge interface is up.
But since br_multicast_init() doesn't start any timers and only sets
default values and initializes timers it should be save to reconfigure
the default values after that, before things actually get active after
the bridge is set up.
Signed-off-by: Linus Lüssing
---
Changelog v3:
* Readded two breaks (cosmetic / for future safety reasons)
Changelog v2:
* remove another now unnecessary -ENOENT initialization
* consistently initialize to -EINVAL, allowing to shorten two switch-cases
net/bridge/br_multicast.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2d69d5c..28a87c2 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1772,11 +1772,9 @@ out:
int br_multicast_set_router(struct net_bridge *br, unsigned long val)
{
- int err = -ENOENT;
+ int err = -EINVAL;
spin_lock_bh(>multicast_lock);
- if (!netif_running(br->dev))
- goto unlock;
switch (val) {
case 0:
@@ -1787,13 +1785,8 @@ int br_multicast_set_router(struct net_bridge *br,
unsigned long val)
br->multicast_router = val;
err = 0;
break;
-
- default:
- err = -EINVAL;
- break;
}
-unlock:
spin_unlock_bh(>multicast_lock);
return err;
@@ -1802,11 +1795,9 @@ unlock:
int br_multicast_set_port_router(struct net_bridge_port *p, unsigned long val)
{
struct net_bridge *br = p->br;
- int err = -ENOENT;
+ int err = -EINVAL;
spin_lock(>multicast_lock);
- if (!netif_running(br->dev) || p->state == BR_STATE_DISABLED)
- goto unlock;
switch (val) {
case 0:
@@ -1828,13 +1819,8 @@ int br_multicast_set_port_router(struct net_bridge_port
*p, unsigned long val)
br_multicast_add_router(br, p);
break;
-
- default:
- err = -EINVAL;
- break;
}
-unlock:
spin_unlock(>multicast_lock);
return err;
@@ -1939,15 +1925,11 @@ unlock:
int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val)
{
- int err = -ENOENT;
+ int err = -EINVAL;
u32 old;
struct net_bridge_mdb_htable *mdb;
spin_lock_bh(>multicast_lock);
- if (!netif_running(br->dev))
- goto unlock;
-
- err = -EINVAL;
if (!is_power_of_2(val))
goto unlock;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] dell-rbtn: Export notifier for other kernel modules
On Saturday 23 May 2015 00:45:57 Dmitry Torokhov wrote:
> On Thu, May 14, 2015 at 3:54 AM, Pali Rohár
> wrote:
> > @@ -328,7 +408,9 @@ static void rbtn_notify(struct acpi_device
> > *device, u32 event)
> >
> > static int __init rbtn_init(void)
> > {
> >
> > - return acpi_bus_register_driver(_driver);
> > + /* ignore errors so module always loads and exports needed
> > functions */ + acpi_bus_register_driver(_driver);
> > + return 0;
>
> Ahem, and if it fails for some reason and you try to unload the
> module what will happen when you call
> acpi_bus_unregister_driver(_driver) in rbtn_exit()?\
>
> Thanks.
I'm thinking about using symbol_request() in dell-laptop.c (instead hard
dependency) and then not ignoring error here... It could fix this
problem.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: dell_rbtn - kernel panic at boot...
On Saturday 23 May 2015 00:53:16 Dmitry Torokhov wrote: > On Thu, May 21, 2015 at 7:06 PM, Valdis Kletnieks > > wrote: > > So after I made both config variables =y, the resulting kernel > > built, but died a glorious death at boot. > > I guess if both are built-in then, according to link order, > dell-laptop starts first, before dell-rbtn, and dies in > dell_rbtn_notifier_register() in call to > driver_for_each_device(_driver.drv, ...) because rbtn_driver has > not been registered yet and thus half-initlalized. > > Thanks. pr_debug() messages could be useful... but no idea if we can get them. Is there any way to fix that dependency race condition? Could driver_attach() function call help? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 22/23] userfaultfd: avoid mmap_sem read recursion in mcopy_atomic
On Fri, May 22, 2015 at 02:18:30PM -0700, Andrew Morton wrote:
>
> There's a more serious failure with i386 allmodconfig:
>
> fs/userfaultfd.c:145:2: note: in expansion of macro 'BUILD_BUG_ON'
> BUILD_BUG_ON(sizeof(struct uffd_msg) != 32);
>
> I'm surprised the feature is even reachable on i386 builds?
Unless we risk to run out of vma->vm_flags there's no particular
reason not to enable it on 32bit (even if we run out, making vm_flags
an unsigned long long is a few liner patch). Certainly it's less
useful on 32bit as there's a 3G limit but the max vmas per process are
still a small fraction of that. Especially if used for the volatile
pages on demand notification of page reclaim, it could end up useful
on arm32 (S6 is 64bit I think and latest snapdragon is too, so perhaps
it's too late anyway, but again it's not big deal).
Removing the BUILD_BUG_ON I think is not ok here because while I'm ok
to support 32bit archs, I don't want translation, the 64bit kernel
should talk with the 32bit app directly without a layer in between.
I tried to avoid using packet as without packed I could not get the
alignment wrong (and future union also couldn't get it wrong), and I
could avoid those reserved1/2/3, but it's more robust to use it in
combination with the BUILD_BUG_ON to detect right away problems like
this with 32bit builds that aligns things differently.
I'm actually surprised the buildbot that sends me email about all
archs didn't actually send me anything about it for 32bit x86?
Perhaps I'm overlooking something or x86 32bit (or any other 32bit
arch for that matter) isn't being checked? This is actually a fairly
recent change, perhaps the buildbot was shutdown recently? That
buildbot was very useful to detect for problems like this.
===
>From 2f0a48670dc515932dec8b983871ec35caeba553 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli
Date: Sat, 23 May 2015 02:26:32 +0200
Subject: [PATCH] userfaultfd: update the uffd_msg structure to be the same on
32/64bit
Avoiding to using packed allowed the code to be nicer and it avoided
the reserved1/2/3 but the structure must be the same for 32bit and
64bit archs so x86 applications built with the 32bit ABI can run on
the 64bit kernel without requiring translation of the data read
through the read syscall.
$ gcc -m64 p.c && ./a.out
32
0
16
8
8
16
24
$ gcc -m32 p.c && ./a.out
32
0
16
8
8
16
24
int main()
{
printf("%lu\n", sizeof(struct uffd_msg));
printf("%lu\n", (unsigned long) &((struct uffd_msg *) 0)->event);
printf("%lu\n", (unsigned long) &((struct uffd_msg *)
0)->arg.pagefault.address);
printf("%lu\n", (unsigned long) &((struct uffd_msg *)
0)->arg.pagefault.flags);
printf("%lu\n", (unsigned long) &((struct uffd_msg *)
0)->arg.reserved.reserved1);
printf("%lu\n", (unsigned long) &((struct uffd_msg *)
0)->arg.reserved.reserved2);
printf("%lu\n", (unsigned long) &((struct uffd_msg *)
0)->arg.reserved.reserved3);
}
Reported-by: Andrew Morton
Signed-off-by: Andrea Arcangeli
---
include/uapi/linux/userfaultfd.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index c8a543f..00d28e2 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -59,9 +59,13 @@
struct uffd_msg {
__u8event;
+ __u8reserved1;
+ __u16 reserved2;
+ __u32 reserved3;
+
union {
struct {
- __u32 flags;
+ __u64 flags;
__u64 address;
} pagefault;
@@ -72,7 +76,7 @@ struct uffd_msg {
__u64 reserved3;
} reserved;
} arg;
-};
+} __attribute__((packed));
/*
* Start at 0x12 and not at 0 to be more strict against bugs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 09/37] bpf tools: Open eBPF object file and do basic validation
On 5/22/15 10:23 AM, Jiri Olsa wrote:
+
+struct bpf_object *bpf_open_object(const char *path)
+{
another suggestion for the namespace.. Arnaldo forces us ;-)
to use the object name first plus '__(method name)' for
interface functions so that would be:
bpf_object__open
bpf_object__close
not sure we want to keep that standard in here though.. Arnaldo?
have been thinking back and forth on this one.
Finally convinced myself that we shouldn't be forcing it here.
object__method style would force the library to look like fake
object oriented whereas it's not. It's a normal C. Let's keep it
simple. Objects are not needed here. May be 'bpf_object' is an
unfortunate name, but it doesn't make the library to be 'ooo'.
libtraceevent doesn't use this style either...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
> On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
> > On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
> >> Not sure if this went out earlier. So I am resending.
> >>
> >> On 5/22/15 16:56, Rafael J. Wysocki wrote:
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> > index 39c485b..b9657af 100644
> > --- a/drivers/acpi/glue.c
> > +++ b/drivers/acpi/glue.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "internal.h"
> >
> > @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct
> > acpi_device *acpi_dev)
> > struct list_head *physnode_list;
> > unsigned int node_id;
> > int retval = -EINVAL;
> > + bool coherent;
> >
> > if (has_acpi_companion(dev)) {
> > if (acpi_dev) {
> > @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct
> > acpi_device *acpi_dev)
> > if (!has_acpi_companion(dev))
> > ACPI_COMPANION_SET(dev, acpi_dev);
> >
> > + if (acpi_check_dma(acpi_dev, ))
> > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> > +
> >>> Well, so is this going to work for PCI too after all?
> >>>
> >>
> >> No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
> >> (patch 3/6 in V4) will be submitted separately. We are working on
> >> cleaning up and up-streaming the PCI ACPI support for ARM64.
> >
> > OK, but acpi_bind_one() is called for PCI devices too. Won't that be a
> > problem?
> >
> >
> >
> In this case, we would be going through the following call path:
>
>--> pci_device_add()
> |--> pci_dma_configure() ** 1 **
> |--> device_add()
> |--> platform_notify()
> |--> acpi_platform_notify()
> |--> acpi_bind_one() ** 2 **
>
> At (1), we would be calling arch_setup_dma_ops() with the PCI host
> bridge _CCA information. So, it should have already taken care of
> setting up device coherency here.
>
> At (2), if there is no acpi_dev for endpoint devices (which I believe
> this is normally the case), it would return early and skip
> arch_setup_dma_ops().
That's not correct. There may be ACPI companions for endpoint devices too.
> At (2), if there is an acpi_dev, the coherent_dma flag should have
> already been setup by the acpi_init_device_object during ACPI scan.
That one sets the flag for the *ACPI* *companion* of the device, which
I'm still thinking is pointless, isn't it?
> However, I am not certain about this case since I don't have the DSDT
> containing PCI endpoint devices to test with.
Every x86 PC has them (as far as I can say), but in that case there's no
_CCA and they are all coherent.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: Only enable IO window if supported
The PCI subsystem always assumes that I/O is supported on PCIe bridges
and tries to assign an I/O window to each port even if that is not
the case.
This may result in messages such as
pcieport :02:00.0: res[7]=[io 0x1000-0x0fff]
get_res_add_size add_size 1000
pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
for each bridge port, even if a port or its parent does not support
I/O in the first place.
To avoid this message, check if a port supports I/O before trying to
enable it. Also check if port's parent supports I/O, and only modify
a port's I/O resource size if both the port and its parent support I/O.
If IO is disabled after the initial port scan, the IO base and size
registers are set to 0x00f0 to indicate that IO is disabled. A later
rescan interprets this as "IO supported" and enables the IO range,
even if the parent does not support IO. Handle this situation as well.
Signed-off-by: Guenter Roeck
---
drivers/pci/probe.c | 14 ++
drivers/pci/setup-bus.c | 4 ++--
include/linux/pci.h | 9 +
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6675a7a1b9fc..f4944ef45148 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -354,6 +354,20 @@ static void pci_read_bridge_io(struct pci_bus *child)
base = (io_base_lo & io_mask) << 8;
limit = (io_limit_lo & io_mask) << 8;
+ /* If necessary, check if the bridge supports an I/O aperture */
+ if (!io_base_lo && !io_limit_lo) {
+ u16 io;
+
+ if (!pci_parent_supports_io(child))
+ return;
+
+ pci_write_config_word(dev, PCI_IO_BASE, 0xe0f0);
+ pci_read_config_word(dev, PCI_IO_BASE, );
+ pci_write_config_word(dev, PCI_IO_BASE, 0x0);
+ if (!io)
+ return;
+ }
+
if ((io_base_lo & PCI_IO_RANGE_TYPE_MASK) == PCI_IO_RANGE_TYPE_32) {
u16 io_base_hi, io_limit_hi;
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 4fd0cacf7ca0..963b31a109a9 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -750,12 +750,12 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
b_res[1].flags |= IORESOURCE_MEM;
pci_read_config_word(bridge, PCI_IO_BASE, );
- if (!io) {
+ if (!io && pci_parent_supports_io(bus)) {
pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
pci_read_config_word(bridge, PCI_IO_BASE, );
pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
}
- if (io)
+ if (io && (io != 0x00f0 || pci_parent_supports_io(bus)))
b_res[0].flags |= IORESOURCE_IO;
/* DECchip 21050 pass 2 errata: the bridge may miss an address
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8dc4c6e..f3de9e24aab1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -489,6 +489,15 @@ static inline bool pci_is_root_bus(struct pci_bus *pbus)
return !(pbus->parent);
}
+/*
+ * Returns true if the parent bus supports an I/O aperture.
+ */
+static inline bool pci_parent_supports_io(struct pci_bus *pbus)
+{
+ return pci_is_root_bus(pbus) || pci_is_root_bus(pbus->parent) ||
+ (pbus->parent->resource[0]->flags & IORESOURCE_IO);
+}
+
/**
* pci_is_bridge - check if the PCI device is a bridge
* @dev: PCI device
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 6/7] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Hello Stephen,
2015-05-23 3:17 GMT+08:00 Stephen Boyd :
> On 05/22/15 11:57, Brent Wang wrote:
>> Hello Stephen,
>>
>> 2015-05-23 2:41 GMT+08:00 Stephen Boyd :
>>> On 05/22, Stephen Boyd wrote:
On 05/22/15 11:30, Brent Wang wrote:
> Hello Stephen,
>
> 2015-05-22 13:20 GMT+08:00 Bintian :
>>> Is pl011 the uart device? Does it have a node in DT somewhere? If it
>>> does, then we could put the assigned-parents properties in that node so
>>> that when the pl011 probes the uart1 clock has its parent set to
>>> clk_150m. See the "Assigned clock parents and rates" section of
>>> Documentation/devicetree/bindings/clock/clock-bindings.txt.
>>>
>> I will verify this.
> Currently the "assigned-clock*" doesn't work for pl011 UART device
> node, maybe we will
> do some fix for its driver later or other modules.
Why doesn't it work?
>>> Does this patch help?
>> Yes, it works!
>>
>> I also tested adding "of_clk_set_defaults" to "pl011_probe()", and
>> "assigned-clock*"
>> also works.
>>
>> So you will submit another patch to fix this problem and I can revove
>> the "clk_set_parent"
>> from my patch, right ?
>>
>>
>
> How about you take it as part of your series? Or if you're planning on
> splitting out the clk patch to go through clk-tree I can apply it before
> applying the clock driver patch.
It's better you take it and I split my patch :)
>
>
> 8<-
>
> From: Stephen Boyd
> Subject: [PATCH] amba: Support clk parents and rates assigned in DT
>
> Add the call to of_clk_set_defaults() into the amba probe path so
> that devices on the amba bus can use the assigned rates and
> parents feature of the common clock framework.
>
> Signed-off-by: Stephen Boyd
> ---
> drivers/amba/bus.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index f0099360039e..350ed93d4281 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -237,6 +238,10 @@ static int amba_probe(struct device *dev)
> int ret;
>
> do {
> + ret = of_clk_set_defaults(dev->of_node, false);
> + if (ret < 0)
> + break;
> +
> ret = dev_pm_domain_attach(dev, true);
> if (ret == -EPROBE_DEFER)
> break;
>
Tested-by: Bintian Wang
Thanks,
Bintian
> --
> 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/
Aw: [PATCH v2] ARM: dts: nitrogen6x: add CAN support
Hello Peter,
On 05/22/2015 12:30 PM, Peter Seiderer wrote:
> Hello Philipp,
>
>> Gesendet: Freitag, 22. Mai 2015 um 13:05 Uhr
>> Von: "Philipp Zabel"
>> Am Donnerstag, den 21.05.2015, 19:45 +0200 schrieb Peter Seiderer:
>>>
>>>
>>>
>>> +
>>> + reg_can_xcvr: regulator@3 {
>>> + compatible = "regulator-fixed";
>>> + reg = <3>;
>>> + regulator-name = "CAN XCVR";
>>> + regulator-min-microvolt = <330>;
>>> + regulator-max-microvolt = <330>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <_can_xcvr>;
>>> + gpio = < 2 GPIO_ACTIVE_HIGH>;
>>
>> According to
>> Documentation/devicetree/bindings/regulator/fixed-regulator.txt
>> this should have:
>> enable-active-high;
>>
>> instead of the gpio phandle flag (which is ignored). Otherwise an active
>> low GPIO is assumed.
>>
>
> Thanks for review...
>
> I was a bit confused from the original:
>
> imx6qdl-tx6.dtsi:103: reg_can_xcvr: regulator@3 {
> imx6qdl-tx6.dtsi-104- compatible = "regulator-fixed";
> imx6qdl-tx6.dtsi-105- reg = <3>;
> imx6qdl-tx6.dtsi-106- regulator-name = "CAN XCVR";
> imx6qdl-tx6.dtsi-107- regulator-min-microvolt = <330>;
> imx6qdl-tx6.dtsi-108- regulator-max-microvolt = <330>;
> imx6qdl-tx6.dtsi-109- pinctrl-names = "default";
> imx6qdl-tx6.dtsi:110: pinctrl-0 = <_flexcan_xcvr>;
> imx6qdl-tx6.dtsi-111- gpio = < 21 GPIO_ACTIVE_HIGH>;
> imx6qdl-tx6.dtsi-112- enable-active-low;
> imx6qdl-tx6.dtsi-113- };
>
> ...and removed the default 'enable-active-low'...
>
> Maybe GPIO_ACTIVE_LOW is the right thing?
>
No. The flags aren't read from the device tree and enable-active-low
is the default.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/regulator/fixed.c#n81
> From the other files:
>
So if this board really wants an "active high" enable pin, it's likely
not operating properly:
> imx28-tx28.dts:90: reg_can_xcvr: regulator@4 {
> imx28-tx28.dts-91- compatible = "regulator-fixed";
> imx28-tx28.dts-92- reg = <4>;
> imx28-tx28.dts-93- regulator-name = "CAN XCVR";
> imx28-tx28.dts-94- regulator-min-microvolt = <330>;
> imx28-tx28.dts-95- regulator-max-microvolt = <330>;
> imx28-tx28.dts-96- gpio = < 0 GPIO_ACTIVE_HIGH>;
> imx28-tx28.dts-97- pinctrl-names = "default";
> imx28-tx28.dts:98: pinctrl-0 = <_flexcan_xcvr_pins>;
> imx28-tx28.dts-99- };
>
>
>
> Any further advice from your side which solution is the right one?
>
> - GPIO_ACTIVE_HIGH/enable-active-high
> - GPIO_ACTIVE_LOW
>
The pad is active low on the TJA1040 transceiver on the Nitrogen6x,
so you don't want "enable-active-high" and could be more explicit with
GPIO_ACTIVE_LOW in the gpio reference, but it won't be parsed or
acted upon.
i.e.
reg_can_xcvr: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "CAN XCVR";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
pinctrl-names = "default";
pinctrl-0 = <_can_xcvr>;
gpio = < 2 0>;
}
Regards,
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 trivial] pinctrl: Spelling s/reseved/reserved/
Hi Geert, Thank you for the patch. On Thursday 21 May 2015 14:05:10 Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart > --- > drivers/pinctrl/nomadik/pinctrl-ab8505.c | 2 +- > drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 38 ++-- > 2 files changed, 20 insertions(+), 20 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization
On 05/22/2015 07:54 PM, Bandan Das wrote:
Boris Ostrovsky writes:
On 05/11/2015 10:55 AM, Xiao Guangrong wrote:
KVM may turn a user page to a kernel page when kernel writes a readonly
user page if CR0.WP = 1. This shadow page entry will be reused after
SMAP is enabled so that kernel is allowed to access this user page
Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu
once CR4.SMAP is updated
Signed-off-by: Xiao Guangrong
---
@@ -4208,12 +4211,18 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *new, int bytes)
{
gfn_t gfn = gpa >> PAGE_SHIFT;
- union kvm_mmu_page_role mask = { .word = 0 };
struct kvm_mmu_page *sp;
LIST_HEAD(invalid_list);
u64 entry, gentry, *spte;
int npte;
bool remote_flush, local_flush, zap_page;
+ union kvm_mmu_page_role mask = (union kvm_mmu_page_role) {
+ .cr0_wp = 1,
+ .cr4_pae = 1,
+ .nxe = 1,
+ .smep_andnot_wp = 1,
+ .smap_andnot_wp = 1,
+ };
This breaks older compilers that can't initialize anon structures.
How old ? Even gcc 3.1 says you can use unnamed struct/union fields and
3.2 is the minimum version required to compile the kernel as mentioned
in the README.
We could simply just name the structure, but I doubt this is the
only place in the kernel code where it's being used this way :)
You can use them but you can't use initializers. Unfortunately my build
system (F13) conveniently went down but this is an example from an old
email:
FC-64 cat anon.c
struct bar {
struct {
int i;
};
};
main()
{
struct bar a = {.i = 0};
}
FC-64 gcc --version|head -1
gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
FC-64 gcc anon.c
anon.c: In function ‘main’:
anon.c:9: error: unknown field ‘i’ specified in initializer
FC-64
but
build@build-mk2 bootstrap]$ gcc --version|head -1
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
[build@build-mk2 bootstrap]$ gcc anon.c
[build@build-mk2 bootstrap]$
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Ceph fixes for -rc5
On Fri, May 22, 2015 at 5:13 PM, Sage Weil wrote: > Hi Linus, > > Please pull the following fixes from > > git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git Nothing there. Did you perhaps mean the "for-linus" branch? Please fix whatever script it is you use that generates bad pull requests. 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: [git pull] drm fixes
On Fri, May 22, 2015 at 4:20 PM, Dave Airlie wrote: > > Really ^to^so Ahh. That simple one-letter substitution makes all the difference, now it's suddenly parseable. Thanks, 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: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
On Sat, 2015-05-23 at 00:25 +, Drokin, Oleg wrote: > On May 22, 2015, at 8:18 PM, Joe Perches wrote: > I wonder what is more clear about that in your opinion ve > lustre_error/lustre_debug? > >>> > >>> The fact that you have to explain this shows that it's > >>> at least misleading unless you completely understand the > >>> code. > >> > >> Or you know, you might take the function name at the face value > >> and assume that CERROR means it's an error and CDEBUG means it's a debug > >> message? > > > > Maybe, but I think that it'd be better if the mechanism > > it uses was more plainly named something like lustre_log. > > While the idea seems good, the biggest obstacle here is such that > there's already a thing called lustre log (llog for short too) - > it's kind of a distributed journal of operations. > > Its there a different synonym, I wonder? Maybe: lustre_printk, lustre_logmsg, lustre_output -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] crypto: move Kconfig 842 to end of list, default to N
On Fri, May 22, 2015 at 8:34 PM, Herbert Xu wrote: > On Fri, May 22, 2015 at 08:08:28PM -0400, Dan Streetman wrote: >> Move the 842 compression alg choice to last in the list, so it's >> not in the middle of LZO/LZ4/LZ4HC. Change its default to N, as it >> is a very slow alg, which generally should only be used with >> compression hardware that's capable of doing it much faster. >> >> Signed-off-by: Dan Streetman > > The default default is "n" so this is redundant. ah ok. never mind then! :-) > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] crypto: move Kconfig 842 to end of list, default to N
On Fri, May 22, 2015 at 08:08:28PM -0400, Dan Streetman wrote: > Move the 842 compression alg choice to last in the list, so it's > not in the middle of LZO/LZ4/LZ4HC. Change its default to N, as it > is a very slow alg, which generally should only be used with > compression hardware that's capable of doing it much faster. > > Signed-off-by: Dan Streetman The default default is "n" so this is redundant. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device
*acpi_dev)
struct list_head *physnode_list;
unsigned int node_id;
int retval = -EINVAL;
+ bool coherent;
if (has_acpi_companion(dev)) {
if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device
*acpi_dev)
if (!has_acpi_companion(dev))
ACPI_COMPANION_SET(dev, acpi_dev);
+ if (acpi_check_dma(acpi_dev, ))
+ arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+
Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
(patch 3/6 in V4) will be submitted separately. We are working on
cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
>
In this case, we would be going through the following call path:
--> pci_device_add()
|--> pci_dma_configure() ** 1 **
|--> device_add()
|--> platform_notify()
|--> acpi_platform_notify()
|--> acpi_bind_one() ** 2 **
At (1), we would be calling arch_setup_dma_ops() with the PCI host
bridge _CCA information. So, it should have already taken care of
setting up device coherency here.
At (2), if there is no acpi_dev for endpoint devices (which I believe
this is normally the case), it would return early and skip
arch_setup_dma_ops().
At (2), if there is an acpi_dev, the coherent_dma flag should have
already been setup by the acpi_init_device_object during ACPI scan.
However, I am not certain about this case since I don't have the DSDT
containing PCI endpoint devices to test with.
Thanks,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
On May 22, 2015, at 8:18 PM, Joe Perches wrote: I wonder what is more clear about that in your opinion ve lustre_error/lustre_debug? >>> >>> The fact that you have to explain this shows that it's >>> at least misleading unless you completely understand the >>> code. >> >> Or you know, you might take the function name at the face value >> and assume that CERROR means it's an error and CDEBUG means it's a debug >> message? > > Maybe, but I think that it'd be better if the mechanism > it uses was more plainly named something like lustre_log. While the idea seems good, the biggest obstacle here is such that there's already a thing called lustre log (llog for short too) - it's kind of a distributed journal of operations. Its there a different synonym, I wonder?-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
On Sat, 2015-05-23 at 00:07 +, Drokin, Oleg wrote: > On May 22, 2015, at 7:57 PM, Joe Perches wrote: > > On Fri, 2015-05-22 at 21:16 +, Drokin, Oleg wrote: > >> On May 22, 2015, at 11:42 AM, Joe Perches wrote: > >>> On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: > On May 22, 2015, at 1:06 AM, Julia Lawall wrote: > > On Thu, 21 May 2015, Michael Shuey wrote: > > > >> That's a task (of many) I've been putting on the back burner until the > >> code > >> is cleaner. It's also a HUGE change, since there are debug macros > >> everywhere, and they all check a #define'd mask to see if they should > >> fire, > >> and the behavior is likely governed by parts of the lustre user land > >> tools > >> as well. > >> > >> Suggestions are welcome. Do other parts of the linux kernel define > >> complex > >> debugging macros like these, or is this a lustre-ism? Any suggestions > >> on > >> how to handle this more in line with existing drivers? > > > > Once you decide what to do, you can use Coccinelle to make the changes > > for > > you. So you shouldn't be put off by the number of code sites to change. > > > > The normal functions are pr_err, pr_warn, etc. Perhaps you can follow > > Joe's suggestions if you really need something more complicated. > > Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my > perspective. > >>> > >>> My issue with CERROR is the name is little misleading. > >>> It's actually a debugging message. > >>> #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__) > >> > >> Except it's not a debugging message. > >> There is a clear distinction. > > > > Not really. If the first reading shows that the mechanism it > > goes through is called CDEBUG, a reasonable expectation should > > be that it's a debugging message. > > Well, various pr_err/pr_dbg for example, go through printk in the end too. > Do that make them the same? No, because each is labeled with the KERN_ that it uses. [] > >> I wonder what is more clear about that in your opinion ve > >> lustre_error/lustre_debug? > > > > The fact that you have to explain this shows that it's > > at least misleading unless you completely understand the > > code. > > Or you know, you might take the function name at the face value > and assume that CERROR means it's an error and CDEBUG means it's a debug > message? Maybe, but I think that it'd be better if the mechanism it uses was more plainly named something like lustre_log. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Ceph fixes for -rc5
Hi Linus, Please pull the following fixes from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git These fix an issue with the RBD notifications when there are topology changes in the cluster. Thanks! sage Ilya Dryomov (2): libceph: request a new osdmap if lingering request maps to no osd Revert "libceph: clear r_req_lru_item in __unregister_linger_request()" net/ceph/osd_client.c | 33 - 1 file changed, 20 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: move Kconfig 842 to end of list, default to N
Move the 842 compression alg choice to last in the list, so it's not in the middle of LZO/LZ4/LZ4HC. Change its default to N, as it is a very slow alg, which generally should only be used with compression hardware that's capable of doing it much faster. Signed-off-by: Dan Streetman --- crypto/Kconfig | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index 24df47b..62ced6f 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1419,14 +1419,6 @@ config CRYPTO_LZO help This is the LZO algorithm. -config CRYPTO_842 - tristate "842 compression algorithm" - select CRYPTO_ALGAPI - select 842_COMPRESS - select 842_DECOMPRESS - help - This is the 842 algorithm. - config CRYPTO_LZ4 tristate "LZ4 compression algorithm" select CRYPTO_ALGAPI @@ -1443,6 +1435,15 @@ config CRYPTO_LZ4HC help This is the LZ4 high compression mode algorithm. +config CRYPTO_842 + tristate "842 compression algorithm" + default n + select CRYPTO_ALGAPI + select 842_COMPRESS + select 842_DECOMPRESS + help + This is the 842 algorithm. + comment "Random Number Generation" config CRYPTO_ANSI_CPRNG -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
On May 22, 2015, at 7:57 PM, Joe Perches wrote: > On Fri, 2015-05-22 at 21:16 +, Drokin, Oleg wrote: >> On May 22, 2015, at 11:42 AM, Joe Perches wrote: >> >>> On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: On May 22, 2015, at 1:06 AM, Julia Lawall wrote: > On Thu, 21 May 2015, Michael Shuey wrote: > >> That's a task (of many) I've been putting on the back burner until the >> code >> is cleaner. It's also a HUGE change, since there are debug macros >> everywhere, and they all check a #define'd mask to see if they should >> fire, >> and the behavior is likely governed by parts of the lustre user land >> tools >> as well. >> >> Suggestions are welcome. Do other parts of the linux kernel define >> complex >> debugging macros like these, or is this a lustre-ism? Any suggestions on >> how to handle this more in line with existing drivers? > > Once you decide what to do, you can use Coccinelle to make the changes for > you. So you shouldn't be put off by the number of code sites to change. > > The normal functions are pr_err, pr_warn, etc. Perhaps you can follow > Joe's suggestions if you really need something more complicated. Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my perspective. >>> >>> My issue with CERROR is the name is little misleading. >>> It's actually a debugging message. >>> #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__) >> >> Except it's not a debugging message. >> There is a clear distinction. > > Not really. If the first reading sjows that the mechanism it > goes through is called CDEBUG, a reasonable expectation should > be that it's a debugging message. Well, various pr_err/pr_dbg for example, go through printk in the end too. Do that make them the same? > >> CERROR is something that get's printed on the console, because it's believed >> to be serious error (At least that's how the theory for it's usage goes). >> It also gets rate-limited so that the console does not get overflown. >> (but the debug buffer gets the full version). >> (there's also LCONSOLE that always get's printed, but it does not get the >> prefixes like line numbers and stuff). >> >> CDEBUG on the other hand is a debugging message (of which ERROR messages are >> sort of a subset (D_ERROR mask)). You can fine-tune those to be noops or >> to go into console or to debug buffer only. Most of those are doing nothing >> because they are off in the default debug mask, until actually enabled. >> >> That CERROR usees CDEBUG underneath is just to share some common >> infrastructure. >> >>> I think it'd be clearer as >>> lustre_debug(ERROR, ... >>> even if the name and use style is a little longer. >> >> I wonder what is more clear about that in your opinion ve >> lustre_error/lustre_debug? > > The fact that you have to explain this shows that it's > at least misleading unless you completely understand the > code. Or you know, you might take the function name at the face value and assume that CERROR means it's an error and CDEBUG means it's a debug message? > It'd be more intelligible if this CERROR became lustre_err > and the actual debugging uses were lustre_dbg But the actual underlying call is hidden by the macro anyway and you never get to see it. You see CDEBUG/CERROR and how is that different from lustre_debug/lustre_err? > Perhaps it needs a better explanation somewhere not in the > code but in some external documentation. I haven't looked. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 2/2] mailbox: Adding driver for Xilinx LogiCORE IP mailbox.
I apologize upfront for the double post, but I discovered and issue
with the v1 version I sent.
On Fri, May 22, 2015 at 11:03 AM, Moritz Fischer
wrote:
> The Xilinx LogiCORE IP mailbox is a FPGA core that allows for
> interprocessor communication via AXI4 memory mapped / AXI4 stream
> interfaces.
>
> It is single channel per core and allows for transmit and receive.
>
> Signed-off-by: Moritz Fischer
> ---
> MAINTAINERS | 7 +
> drivers/mailbox/Kconfig | 8 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mailbox-xilinx.c | 332 ++
> 4 files changed, 349 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8e0afb..f1f0d10 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10986,6 +10986,13 @@ M: John Linn
> S: Maintained
> F: drivers/net/ethernet/xilinx/xilinx_axienet*
>
> +XILINX MAILBOX DRIVER
> +M: Moritz Fischer
> +L: linux-kernel@vger.kernel.org
> +S: Maintained
> +F: drivers/mailbox/mailbox-xilinx.c
> +F: Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
> +
> XILINX UARTLITE SERIAL DRIVER
> M: Peter Korsgaard
> L: linux-ser...@vger.kernel.org
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 84b0a2d..e11e4b2 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -60,4 +60,12 @@ config ALTERA_MBOX
> An implementation of the Altera Mailbox soft core. It is used
> to send message between processors. Say Y here if you want to use
> the
> Altera mailbox support.
> +
> +config XILINX_MBOX
> + tristate "Xilinx Mailbox"
> + help
> + An implementation of the Xilinx Mailbox soft core. It is used
> + to send message between processors. Say Y here if you want to use
> the
> + Xilinx mailbox support.
> +
> endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index b18201e..d28a028 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
> obj-$(CONFIG_PCC) += pcc.o
>
> obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
> +
> +obj-$(CONFIG_XILINX_MBOX) += mailbox-xilinx.o
> diff --git a/drivers/mailbox/mailbox-xilinx.c
> b/drivers/mailbox/mailbox-xilinx.c
> new file mode 100644
> index 000..3c45854
> --- /dev/null
> +++ b/drivers/mailbox/mailbox-xilinx.c
> @@ -0,0 +1,332 @@
> +/*
> + * Copyright (c) 2015, National Instruments Corp. All rights reserved.
> + *
> + * Driver for the Xilinx LogiCORE mailbox IP block
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "xilinx-mailbox"
> +
> +/* register offsets */
> +#define MAILBOX_REG_WRDATA 0x00
> +#define MAILBOX_REG_RDDATA 0x08
> +#define MAILBOX_REG_STATUS 0x10
> +#define MAILBOX_REG_ERROR 0x14
> +#define MAILBOX_REG_SIT0x18
> +#define MAILBOX_REG_RIT0x1c
> +#define MAILBOX_REG_IS 0x20
> +#define MAILBOX_REG_IE 0x24
> +#define MAILBOX_REG_IP 0x28
> +
> +/* status register */
> +#define STS_RTABIT(3)
> +#define STS_STABIT(2)
> +#define STS_FULL BIT(1)
> +#define STS_EMPTY BIT(0)
> +
> +/* error register */
> +#define ERR_FULL BIT(1)
> +#define ERR_EMPTY BIT(0)
> +
> +/* mailbox interrupt status register */
> +#define INT_STATUS_ERR BIT(2)
> +#define INT_STATUS_RTI BIT(1)
> +#define INT_STATUS_STI BIT(0)
> +
> +/* mailbox interrupt enable register */
> +#define INT_ENABLE_ERR BIT(2)
> +#define INT_ENABLE_RTI BIT(1)
> +#define INT_ENABLE_STI BIT(0)
> +
> +#define MBOX_POLLING_MS5 /* polling interval 5ms */
> +
> +struct xilinx_mbox {
> + int irq;
> + void __iomem *mbox_base;
> + struct device *dev;
> + struct mbox_controller controller;
> +
> + /* if the controller supports only RX polling mode */
> + struct timer_list rxpoll_timer;
> +};
> +
> +static struct xilinx_mbox *mbox_chan_to_xilinx_mbox(struct mbox_chan *chan)
> +{
> + if (!chan || !chan->con_priv)
> + return NULL;
> +
> + return (struct xilinx_mbox *)chan->con_priv;
> +}
> +
> +static inline bool xilinx_mbox_full(struct xilinx_mbox *mbox)
> +{
> + u32 status;
> +
> + status = readl_relaxed(mbox->mbox_base + MAILBOX_REG_STATUS);
> +
> + return status & STS_FULL;
> +}
> +
> +static
Re: [PATCH 12/19] ACPICA: ACPI 6.0: Add changes for MADT table.
On 2015年05月22日 08:16, Zheng, Lv wrote:
Hi,
From: Hanjun Guo [mailto:hanjun@linaro.org]
Sent: Thursday, May 21, 2015 10:36 PM
Hi Lv,
On 2015年05月21日 10:31, Lv Zheng wrote:
From: Bob Moore
ACPICA commit 02cbb41232bccf7a91967140cab95d5f48291f21
New subtable type. Some additions to existing subtables.
Link: https://github.com/acpica/acpica/commit/02cbb412
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
[...]
/* Masks for Flags field above */
@@ -819,7 +822,7 @@ struct acpi_madt_generic_interrupt {
#define ACPI_MADT_PERFORMANCE_IRQ_MODE (1<<1) /* 01: Performance Interrupt
Mode */
#define ACPI_MADT_VGIC_IRQ_MODE (1<<2) /* 02: VGIC Maintenance
Interrupt mode */
-/* 12: Generic Distributor (ACPI 5.0) */
+/* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
struct acpi_madt_generic_distributor {
struct acpi_subtable_header header;
@@ -827,7 +830,8 @@ struct acpi_madt_generic_distributor {
u32 gic_id;
u64 base_address;
u32 global_irq_base;
- u32 reserved2; /* reserved - must be zero */
+ u8 version;
version filed in generic distributor has following values,
/* Values for gic_version in Generic Distributor (ACPI 6.0) */
enum acpi_madt_gic_ver_type
{
ACPI_MADT_GIC_VER_UNKNOWN = 0,
ACPI_MADT_GIC_VER_V1= 1,
ACPI_MADT_GIC_VER_V2= 2,
ACPI_MADT_GIC_VER_V3= 3,
ACPI_MADT_GIC_VER_V4= 4,
ACPI_MADT_GIC_VER_RESERVED = 5 /* 5 and greater are
reserved */
};
should we put it here, or locate it to ARM64 arch related head
file?
Yes, you can put it here.
And also please help to submit an ACPICA patch to .
OK, I think it is a fix to this patch too, I will
prepare a patch soon.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MIPS: MSA: bugfix - disable MSA during thread switch correctly
On 05/22/2015 04:20 PM, Ralf Baechle wrote: On Fri, May 22, 2015 at 11:37:34AM -0700, Leonid Yegoshin wrote: On 05/22/2015 02:38 AM, Ralf Baechle wrote: Just move the call to finish_arch_switch(). It might be a problem later, then a correct MSA partiton starts working. It should be tight to saving MSA registers in that case. Your rewrite also dropped the if (cpu_has_msa) condition from disable_msa() probably causing havoc on lots of CPUs which will likely not decode the set bits of the MFC0/MTC0 instructions thus end up accessing Config0. Ralf Right before this chunk of code there is a saving MSA registers. Does it causing a havoc or else? May I ask you to look into switch_to macro to figure out how "if (cpu_has_msa)" check works in this case? Ah sorry I now see that your added code is not executed for all CPUs but only those having MSA. So then it's safe. Still I don't stylistically like defining the register t4 in the middle of the code. Below my suggested patch. It's advantage is that for non-MSA platforms the call to disable_msa() will be removed entirely. Something like Paul's http://patchwork.linux-mips.org/patch/10111/ (assuming it's correct and tested) seems like a full cleanup but it's way too complex for 4.1 or the stable kernels. Ralf All 3 patches seems working (I tested), but if you don't like mine then I prefer Paul's patch more - it concentrates stuff more closely and removes some assembly stuff. Besides that, it introduces lose_fpu_inatomic() which is needed for me :) - Leonid. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes
On Fri, 2015-05-22 at 21:16 +, Drokin, Oleg wrote: > On May 22, 2015, at 11:42 AM, Joe Perches wrote: > > > On Fri, 2015-05-22 at 08:08 +, Drokin, Oleg wrote: > >> On May 22, 2015, at 1:06 AM, Julia Lawall wrote: > >> > >>> On Thu, 21 May 2015, Michael Shuey wrote: > >>> > That's a task (of many) I've been putting on the back burner until the > code > is cleaner. It's also a HUGE change, since there are debug macros > everywhere, and they all check a #define'd mask to see if they should > fire, > and the behavior is likely governed by parts of the lustre user land > tools > as well. > > Suggestions are welcome. Do other parts of the linux kernel define > complex > debugging macros like these, or is this a lustre-ism? Any suggestions on > how to handle this more in line with existing drivers? > >>> > >>> Once you decide what to do, you can use Coccinelle to make the changes for > >>> you. So you shouldn't be put off by the number of code sites to change. > >>> > >>> The normal functions are pr_err, pr_warn, etc. Perhaps you can follow > >>> Joe's suggestions if you really need something more complicated. > >> > >> Ideally leaving CERROR/CDEBUG in Lustre would be desirable from my > >> perspective. > > > > My issue with CERROR is the name is little misleading. > > It's actually a debugging message. > > #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__) > > Except it's not a debugging message. > There is a clear distinction. Not really. If the first reading sjows that the mechanism it goes through is called CDEBUG, a reasonable expectation should be that it's a debugging message. > CERROR is something that get's printed on the console, because it's believed > to be serious error (At least that's how the theory for it's usage goes). > It also gets rate-limited so that the console does not get overflown. > (but the debug buffer gets the full version). > (there's also LCONSOLE that always get's printed, but it does not get the > prefixes like line numbers and stuff). > > CDEBUG on the other hand is a debugging message (of which ERROR messages are > sort of a subset (D_ERROR mask)). You can fine-tune those to be noops or > to go into console or to debug buffer only. Most of those are doing nothing > because they are off in the default debug mask, until actually enabled. > > That CERROR usees CDEBUG underneath is just to share some common > infrastructure. > > > I think it'd be clearer as > > lustre_debug(ERROR, ... > > even if the name and use style is a little longer. > > I wonder what is more clear about that in your opinion ve > lustre_error/lustre_debug? The fact that you have to explain this shows that it's at least misleading unless you completely understand the code. It'd be more intelligible if this CERROR became lustre_err and the actual debugging uses were lustre_dbg Perhaps it needs a better explanation somewhere not in the code but in some external documentation. I haven't looked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, May 22, 2015 at 04:02:33PM -0700, Luis R. Rodriguez wrote: > On Fri, May 22, 2015 at 3:33 PM, Herbert Xu > wrote: > > On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote: > >> Kind of, the issue actually was a new component which depends on FW_LOADER > >> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER > >> but also has a set of crypto dependencies that creates a recursive > >> dependency > >> loop. > > > > Actually, how about making FW_SIG select FW_LOADER instead of > > depending on it? I think this should break the cycle. > > Indeed, it does. Kind of odd, but works - and well if others run into > the recursive issue then we have two diverging solutions now: > > a) Either swap all "select FOO" to "depends on FOO" or, > b) Change the offending "depends on FOO" to "select FOO" > > So sticking to one seems to make Kconfig happy for recursive > dependency solving for now... For simplicity and avoidance of massive tree-wide patches, (b) seems preferable in this case. Long-term, I think ideally we should have *every* visible Kconfig option always pulled in by "depends on" rather than "select", with visibility and recursion handled by smarter tools. That said, meddle not in the internals of Kconfig, for it has many unshorn yaks (and yaccs). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization
Boris Ostrovsky writes:
> On 05/11/2015 10:55 AM, Xiao Guangrong wrote:
>> KVM may turn a user page to a kernel page when kernel writes a readonly
>> user page if CR0.WP = 1. This shadow page entry will be reused after
>> SMAP is enabled so that kernel is allowed to access this user page
>>
>> Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu
>> once CR4.SMAP is updated
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>
>
>>
>> @@ -4208,12 +4211,18 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t
>> gpa,
>> const u8 *new, int bytes)
>> {
>> gfn_t gfn = gpa >> PAGE_SHIFT;
>> -union kvm_mmu_page_role mask = { .word = 0 };
>> struct kvm_mmu_page *sp;
>> LIST_HEAD(invalid_list);
>> u64 entry, gentry, *spte;
>> int npte;
>> bool remote_flush, local_flush, zap_page;
>> +union kvm_mmu_page_role mask = (union kvm_mmu_page_role) {
>> +.cr0_wp = 1,
>> +.cr4_pae = 1,
>> +.nxe = 1,
>> +.smep_andnot_wp = 1,
>> +.smap_andnot_wp = 1,
>> +};
>>
>>
>
>
> This breaks older compilers that can't initialize anon structures.
How old ? Even gcc 3.1 says you can use unnamed struct/union fields and
3.2 is the minimum version required to compile the kernel as mentioned
in the README.
We could simply just name the structure, but I doubt this is the
only place in the kernel code where it's being used this way :)
Bandan
> -boris
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 4/4] sched: cpufreq_cfs: pelt-based cpu frequency scaling
On Monday, May 11, 2015 07:13:15 PM Michael Turquette wrote:
> Scheduler-driven cpu frequency selection is desirable as part of the
> on-going effort to make the scheduler better aware of energy
> consumption. No piece of the Linux kernel has a better view of the
> factors that affect a cpu frequency selection policy than the
> scheduler[0], and this patch is an attempt to converge on an initial
> solution.
>
> This patch implements a cpufreq governor that directly accesses
> scheduler statistics, in particular per-runqueue capacity utilization
> data from cfs via cfs.utilization_load_avg.
>
> Put plainly, this governor selects the lowest cpu frequency that will
> prevent a runqueue from being over-utilized (until we hit the highest
> frequency of course). This is accomplished by requesting a frequency
> that matches the current capacity utilization, plus a margin.
>
> Unlike the previous posting from 2014[1] this governor implements a
> "follow the utilization" method, where utilization is defined as the
> frequency-invariant product of cfs.utilization_load_avg and
> cpu_capacity_orig.
>
> This governor is event-driven. There is no polling loop to check cpu
> idle time nor any other method which is unsynchronized with the
> scheduler. The entry points for this policy are in fair.c:
> enqueue_task_fair, dequeue_task_fair and task_tick_fair.
>
> This policy is implemented using the cpufreq governor interface for two
> main reasons:
>
> 1) re-using the cpufreq machine drivers without using the governor
> interface is hard.
>
> 2) using the cpufreq interface allows us to switch between the
> scheduler-driven policy and legacy cpufreq governors such as ondemand at
> run-time. This is very useful for comparative testing and tuning.
>
> Finally, it is worth mentioning that this approach neglects all
> scheduling classes except for cfs. It is possible to add support for
> deadline and other other classes here, but I also wonder if a
> multi-governor approach would be a more maintainable solution, where the
> cpufreq core aggregates the constraints set by multiple governors.
> Supporting such an approach in the cpufreq core would also allow for
> peripheral devices to place constraint on cpu frequency without having
> to hack such behavior in at the governor level.
>
> Thanks to Juri Lelli for contributing design ideas,
> code and test results.
>
> [0] http://article.gmane.org/gmane.linux.kernel/1499836
> [1] https://lkml.org/lkml/2014/10/22/22
>
> Signed-off-by: Juri Lelli
> Signed-off-by: Michael Turquette
> ---
[cut]
> +/**
> + * cpufreq_cfs_update_cpu - interface to scheduler for changing capacity
> values
> + * @cpu: cpu whose capacity utilization has recently changed
> + *
> + * cpufreq_cfs_update_cpu is an interface exposed to the scheduler so that
> the
> + * scheduler may inform the governor of updates to capacity utilization and
> + * make changes to cpu frequency. Currently this interface is designed around
> + * PELT values in CFS. It can be expanded to other scheduling classes in the
> + * future if needed.
> + *
> + * cpufreq_cfs_update_cpu raises an IPI. The irq_work handler for that IPI
> wakes up
> + * the thread that does the actual work, cpufreq_cfs_thread.
> + *
> + * This functions bails out early if either condition is true:
> + * 1) this cpu is not the new maximum utilization for its frequency domain
> + * 2) no change in cpu frequency is necessary to meet the new capacity
> request
> + *
> + * Returns the newly chosen capacity. Note that this may not reflect reality
> if
> + * the hardware fails to transition to this new capacity state.
> + */
> +unsigned long cpufreq_cfs_update_cpu(int cpu, unsigned long util)
> +{
> + unsigned long util_new, util_old, util_max, capacity_new;
> + unsigned int freq_new, freq_tmp, cpu_tmp;
> + struct cpufreq_policy *policy;
> + struct gov_data *gd;
> + struct cpufreq_frequency_table *pos;
> +
> + /* handle rounding errors */
> + util_new = util > SCHED_LOAD_SCALE ? SCHED_LOAD_SCALE : util;
> +
> + /* update per-cpu utilization */
> + util_old = __this_cpu_read(pcpu_util);
> + __this_cpu_write(pcpu_util, util_new);
> +
> + /* avoid locking policy for now; accessing .cpus only */
> + policy = per_cpu(pcpu_policy, cpu);
> +
> + /* find max utilization of cpus in this policy */
> + util_max = 0;
> + for_each_cpu(cpu_tmp, policy->cpus)
> + util_max = max(util_max, per_cpu(pcpu_util, cpu_tmp));
> +
> + /*
> + * We only change frequency if this cpu's utilization represents a new
> + * max. If another cpu has increased its utilization beyond the
> + * previous max then we rely on that cpu to hit this code path and make
> + * the change. IOW, the cpu with the new max utilization is responsible
> + * for setting the new capacity/frequency.
> + *
> + * If this cpu is not the new maximum then bail, returning the current
> + *
Re: [PATCH v3] Fix endian issues and remove the board specific codes
Hi Hn,
On Thu, May 21, 2015 at 03:43:08PM +0800, Hn Chen wrote:
> Hi, Dmitry,
>
> Thanks for your comments.
> Here are my replies for some comments.
>
> > + fw_id = ((fw_chunk_info.chunk_info.version_number >> 12) & 0xF);
> > + chip_id = (((dev_wdt87xx->sys_param.fw_id) >> 12) & 0xF);
> > +
> > + if (fw_id != chip_id) {
> > + wdt87xx_get_sysparam(client, dev_wdt87xx);
>
> >Why would it be different now?
> This driver is intend to support two controllers, WDT8753 & WDT8756.
> The chip_id and the the firmware are different for them, so we have to check
> if
> The firmware is suitable for this controller.
What I meant is as far as I understand dev_wdt87xx->sys_param.fw_id is
what we've read from the controller when we probed the device. What is
the point in trying to re-read it with wdt87xx_get_sysparam()? Do we
expect it to somehow change?
>
> > +
> > + return (unsigned short) y;
>
> >I think I might have asked this before, by anyway: are we sure that we don't
> >already have this checksum implementation in lib/? And if we don't maybe we
> >should?
> The MISR is a checksum function which the full name is "Multiple Input
> Signature Register".
> I checked the kernel library and not found any algorithm like this.
> You mean I have to submit the checksum function into kernel/lib ?
No, you do not have to. I just wanted to make sure we are not
duplicating something that already exists.
>
> > Can you tell me a bit more about the way device sends touch data? Does it
> > always send all 10 contacts regardless of data in
> > raw_buf[TOUCH_PK_OFFSET_FNGR_NUM]?
> Yes, it always send all 10 contacts data.
I see.
--
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/
Re: [PATCH 11/51] memcg: implement mem_cgroup_css_from_page()
On Fri, May 22, 2015 at 05:13:25PM -0400, Tejun Heo wrote:
> +/**
> + * mem_cgroup_css_from_page - css of the memcg associated with a page
> + * @page: page of interest
> + *
> + * This function is guaranteed to return a valid cgroup_subsys_state and
> + * the returned css remains accessible until @page is released.
> + */
> +struct cgroup_subsys_state *mem_cgroup_css_from_page(struct page *page)
> +{
> + if (page->mem_cgroup)
> + return >mem_cgroup->css;
> + return _mem_cgroup->css;
> +}
replace_page_cache() can clear page->mem_cgroup even when the page
still has references, so unfortunately you must hold the page lock
when calling this function.
I haven't checked how you use this - chances are you always have the
page locked anyways - but it probably needs a comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: nommu: avoid deprecated source register on mov
In Thumb2 mode, the stack register r13 is deprecated if the
destination register is the program counter (r15). Similar to
head.S, head-nommu.S uses r13 to store the return address used
after configuring the CPU's CP15 register. However, since we do
not enable a MMU, there will be no address switch and it is
possible to use branch with link instruction to call
__after_proc_init.
Avoid using r13 completely by using bl to call __after_proc_init
and get rid of __secondary_switched.
Beside removing unnecessary complexity, this also fixes a
compiler warning when compiling a !MMU kernel:
Warning: Use of r13 as a source register is deprecated when r15
is the destination register.
Suggested-by: Russell King
Signed-off-by: Stefan Agner
---
Changes in v2:
- Load r7 outside CONFIG_ARM_MPU since its used outside later on
arch/arm/kernel/head-nommu.S | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index c966016..9b8c5a1 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -77,13 +77,13 @@ ENTRY(stext)
orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit
bl __setup_mpu
#endif
- ldr r13, =__mmap_switched @ address to jump to after
- @ initialising sctlr
+
badrlr, 1f @ return (PIC) address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
ret r12
- 1:b __after_proc_init
+1: bl __after_proc_init
+ b __mmap_switched
ENDPROC(stext)
#ifdef CONFIG_SMP
@@ -106,8 +106,7 @@ ENTRY(secondary_startup)
movsr10, r5 @ invalid processor?
beq __error_p @ yes, error 'p'
- adr r4, __secondary_data
- ldmia r4, {r7, r12}
+ ldr r7, __secondary_data
#ifdef CONFIG_ARM_MPU
/* Use MPU region info supplied by __cpu_up */
@@ -115,23 +114,19 @@ ENTRY(secondary_startup)
bl __setup_mpu @ Initialize the MPU
#endif
- badrlr, __after_proc_init @ return address
- mov r13, r12@ __secondary_switched address
+ badrlr, 1f @ return (PIC) address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
ret r12
-ENDPROC(secondary_startup)
-
-ENTRY(__secondary_switched)
+1: bl __after_proc_init
ldr sp, [r7, #12] @ set up the stack pointer
mov fp, #0
b secondary_start_kernel
-ENDPROC(__secondary_switched)
+ENDPROC(secondary_startup)
.type __secondary_data, %object
__secondary_data:
.long secondary_data
- .long __secondary_switched
#endif /* CONFIG_SMP */
/*
@@ -164,7 +159,7 @@ __after_proc_init:
#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
#endif /* CONFIG_CPU_CP15 */
- ret r13
+ ret lr
ENDPROC(__after_proc_init)
.ltorg
--
2.4.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/2] MIPS: MSA: bugfix - disable MSA during thread switch correctly
On Fri, May 22, 2015 at 11:37:34AM -0700, Leonid Yegoshin wrote:
> On 05/22/2015 02:38 AM, Ralf Baechle wrote:
> >Just move the call to finish_arch_switch().
>
> It might be a problem later, then a correct MSA partiton starts working. It
> should be tight to saving MSA registers in that case.
>
> >Your rewrite also dropped the if (cpu_has_msa) condition from
> >disable_msa() probably causing havoc on lots of CPUs which will likely not
> >decode the set bits of the MFC0/MTC0 instructions thus end up accessing
> >Config0. Ralf
>
> Right before this chunk of code there is a saving MSA registers. Does it
> causing a havoc or else?
>
> May I ask you to look into switch_to macro to figure out how "if
> (cpu_has_msa)" check works in this case?
Ah sorry I now see that your added code is not executed for all CPUs but
only those having MSA. So then it's safe.
Still I don't stylistically like defining the register t4 in the middle
of the code.
Below my suggested patch. It's advantage is that for non-MSA platforms
the call to disable_msa() will be removed entirely.
Something like Paul's http://patchwork.linux-mips.org/patch/10111/ (assuming
it's correct and tested) seems like a full cleanup but it's way too
complex for 4.1 or the stable kernels.
Ralf
Signed-off-by: Ralf Baechle
arch/mips/include/asm/switch_to.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/switch_to.h
b/arch/mips/include/asm/switch_to.h
index e92d6c4b..7163cd7 100644
--- a/arch/mips/include/asm/switch_to.h
+++ b/arch/mips/include/asm/switch_to.h
@@ -104,7 +104,6 @@ do {
\
if (test_and_clear_tsk_thread_flag(prev, TIF_USEDMSA)) \
__fpsave = FP_SAVE_VECTOR; \
(last) = resume(prev, next, task_thread_info(next), __fpsave); \
- disable_msa(); \
} while (0)
#define finish_arch_switch(prev) \
@@ -122,6 +121,7 @@ do {
\
if (cpu_has_userlocal) \
write_c0_userlocal(current_thread_info()->tp_value);\
__restore_watch(); \
+ disable_msa(); \
} while (0)
#endif /* _ASM_SWITCH_TO_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: [git pull] drm fixes
On 23 May 2015 at 07:34, Linus Torvalds wrote: > On Thu, May 21, 2015 at 8:39 PM, Dave Airlie wrote: >> >> radeon has two displayport fixes, one for a regressions, >> i915 regression flicker fix needed to 4.0 can get fixed. > > Ok, I'm used to fixing up your whitespace and lack of capitalization, > but you're getting so incoherent that I can no longer even parse it > well enough to fix it up. > > English *is* your first language, right? Could you please re-phrase > > "i915 regression flicker fix needed to 4.0 can get fixed" > > because it's not really making sense to me, and I want my commit > messages to make sense. Really ^to^so i915: fix flicker regression from 4.0, patch required so 4.0 can get fix backported. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/4] arm: Frequency invariant scheduler load-tracking support
On Monday, May 11, 2015 07:13:12 PM Michael Turquette wrote:
> From: Morten Rasmussen
>
> Implements arch-specific function to provide the scheduler with a
> frequency scaling correction factor for more accurate load-tracking. The
> factor is:
>
> current_freq(cpu) << SCHED_CAPACITY_SHIFT / max_freq(cpu)
>
> This implementation only provides frequency invariance. No
> micro-architecture invariance yet.
>
> Cc: Russell King
> Signed-off-by: Morten Rasmussen
> ---
> Changes in v2:
> none
>
> arch/arm/include/asm/topology.h | 7 ++
> arch/arm/kernel/smp.c | 53
> +++--
> arch/arm/kernel/topology.c | 17 +
> 3 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index 2fe85ff..4b985dc 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -24,6 +24,13 @@ void init_cpu_topology(void);
> void store_cpu_topology(unsigned int cpuid);
> const struct cpumask *cpu_coregroup_mask(int cpu);
>
> +#define arch_scale_freq_capacity arm_arch_scale_freq_capacity
> +struct sched_domain;
> +extern
> +unsigned long arm_arch_scale_freq_capacity(struct sched_domain *sd, int cpu);
> +
> +DECLARE_PER_CPU(atomic_long_t, cpu_freq_capacity);
> +
> #else
>
> static inline void init_cpu_topology(void) { }
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 86ef244..297ce1b 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -672,12 +672,34 @@ static DEFINE_PER_CPU(unsigned long, l_p_j_ref);
> static DEFINE_PER_CPU(unsigned long, l_p_j_ref_freq);
> static unsigned long global_l_p_j_ref;
> static unsigned long global_l_p_j_ref_freq;
> +static DEFINE_PER_CPU(atomic_long_t, cpu_max_freq);
> +DEFINE_PER_CPU(atomic_long_t, cpu_freq_capacity);
> +
> +/*
> + * Scheduler load-tracking scale-invariance
> + *
> + * Provides the scheduler with a scale-invariance correction factor that
> + * compensates for frequency scaling through arch_scale_freq_capacity()
> + * (implemented in topology.c).
> + */
> +static inline
> +void scale_freq_capacity(int cpu, unsigned long curr, unsigned long max)
> +{
> + unsigned long capacity;
> +
> + if (!max)
> + return;
> +
> + capacity = (curr << SCHED_CAPACITY_SHIFT) / max;
> + atomic_long_set(_cpu(cpu_freq_capacity, cpu), capacity);
> +}
>
> static int cpufreq_callback(struct notifier_block *nb,
> unsigned long val, void *data)
> {
> struct cpufreq_freqs *freq = data;
> int cpu = freq->cpu;
> + unsigned long max = atomic_long_read(_cpu(cpu_max_freq, cpu));
>
> if (freq->flags & CPUFREQ_CONST_LOOPS)
> return NOTIFY_OK;
> @@ -702,6 +724,9 @@ static int cpufreq_callback(struct notifier_block *nb,
> per_cpu(l_p_j_ref_freq, cpu),
> freq->new);
> }
> +
> + scale_freq_capacity(cpu, freq->new, max);
> +
> return NOTIFY_OK;
> }
>
> @@ -709,11 +734,35 @@ static struct notifier_block cpufreq_notifier = {
> .notifier_call = cpufreq_callback,
> };
>
> +static int cpufreq_policy_callback(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + struct cpufreq_policy *policy = data;
> + int i;
> +
> + for_each_cpu(i, policy->cpus) {
> + scale_freq_capacity(i, policy->cur, policy->max);
> + atomic_long_set(_cpu(cpu_max_freq, i), policy->max);
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block cpufreq_policy_notifier = {
> + .notifier_call = cpufreq_policy_callback,
> +};
> +
> static int __init register_cpufreq_notifier(void)
> {
> - return cpufreq_register_notifier(_notifier,
> + int ret;
> +
> + ret = cpufreq_register_notifier(_notifier,
> CPUFREQ_TRANSITION_NOTIFIER);
> + if (ret)
> + return ret;
> +
> + return cpufreq_register_notifier(_policy_notifier,
> + CPUFREQ_POLICY_NOTIFIER);
> }
> core_initcall(register_cpufreq_notifier);
> -
> #endif
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index 08b7847..9c09e6e 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -169,6 +169,23 @@ static void update_cpu_capacity(unsigned int cpu)
> cpu, arch_scale_cpu_capacity(NULL, cpu));
> }
>
> +/*
> + * Scheduler load-tracking scale-invariance
> + *
> + * Provides the scheduler with a scale-invariance correction factor that
> + * compensates for frequency scaling (arch_scale_freq_capacity()). The
> scaling
> + * factor is updated in smp.c
> + */
> +unsigned long arm_arch_scale_freq_capacity(struct sched_domain *sd, int cpu)
> +{
> + unsigned long curr
[PATCH v3] x86: Stop relying on magic jmp behavior for early_idt_handlers
The early_idt_handlers asm code generates an array of entry points spaced nine bytes apart. It's not really clear from that code or from the places that reference it what's going on, and the code only works in the first place because gas never generates two-byte jmp instructions when jumping to global labels. Clean up the code to generate the correct array stride explicitly. This should be considerably more robust against screw-ups, as gas will warn if a .fill directive has a negative count. Using '. =' to advance would have been even more robust (it would generate an actual error if it tried to move backwards), but it would pad with nulls, confusing anyone who tries to disassemble the code. The new scheme should be much clearer to future readers. While we're at it, improve the comments and rename the array and common code. Binutils may start relaxing jumps to non-weak labels. If so, this change will fix our build, and we may need to backport this change. Before, on x86_64: : 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 00 00 00 00 jmpq 9 5: R_X86_64_PC32early_idt_handler-0x4 ... 48: 66 90 xchg %ax,%ax 4a: 6a 08 pushq $0x8 4c: e9 00 00 00 00 jmpq 51 4d: R_X86_64_PC32 early_idt_handler-0x4 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: e9 00 00 00 00 jmpq 120 11c: R_X86_64_PC32 early_idt_handler-0x4 After: : 0: 6a 00 pushq $0x0 2: 6a 00 pushq $0x0 4: e9 14 01 00 00 jmpq 11d ... 48: 6a 08 pushq $0x8 4a: e9 d1 00 00 00 jmpq 120 4f: cc int3 50: cc int3 ... 117: 6a 00 pushq $0x0 119: 6a 1f pushq $0x1f 11b: eb 03 jmp120 11d: cc int3 11e: cc int3 11f: cc int3 Acked-by: H. Peter Anvin Signed-off-by: Andy Lutomirski --- Changes from v2: - Further improve comments. - Rename early_idt_handlers to early_idt_handler_array and early_idt_handler to early_idt_handler_common. - Combine the .fill directives in the array loop. (I'm not sure why I missed this simplification the first time around.) Changes from v1: - Changed .globl to ENTRY. - Removed superfluous endif and ifdef arch/x86/include/asm/segment.h | 14 -- arch/x86/kernel/head64.c | 2 +- arch/x86/kernel/head_32.S | 33 ++--- arch/x86/kernel/head_64.S | 20 +++- 4 files changed, 42 insertions(+), 27 deletions(-) diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h index 5a9856eb12ba..3a0dcb7b114f 100644 --- a/arch/x86/include/asm/segment.h +++ b/arch/x86/include/asm/segment.h @@ -231,11 +231,21 @@ #define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES* 8) #ifdef __KERNEL__ + +/* + * early_idt_handler_array is an array of entry points referenced in the + * early IDT. For simplicity, it's a real array with one entry point + * every nine bytes. That leaves room for an optional 'push $0' if the + * vector has no error code (two bytes), a 'push $vector_number' (two + * bytes), and a jump to the common entry code (up to five bytes). + */ +#define EARLY_IDT_HANDLER_STRIDE 9 + #ifndef __ASSEMBLY__ -extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][2+2+5]; +extern const char early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_STRIDE]; #ifdef CONFIG_TRACING -# define trace_early_idt_handlers early_idt_handlers +# define trace_early_idt_handler_array early_idt_handler_array #endif /* diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 2b55ee6db053..5a4668136e98 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -167,7 +167,7 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data) clear_bss(); for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) - set_intr_gate(i, early_idt_handlers[i]); + set_intr_gate(i, early_idt_handler_array[i]); load_idt((const struct desc_ptr *)_descr); copy_bootdata(__va(real_mode_data)); diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index d031bad9e07e..0c7ca05a8855 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -478,21 +478,22 @@ is486: __INIT setup_once: /* -* Set up a idt with 256 entries pointing to ignore_int, -* interrupt gates. It doesn't actually load idt - that needs -* to be done on each CPU. Interrupts are enabled elsewhere, -* when we can be relatively sure
[PATCH] mlx4_core: Fix fallback from MSI-X to INTx
The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.
Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.
Fixes: f5aef5a ("net/mlx4_core: Activate reset flow upon fatal command cases")
Signed-off-by: Benjamin Poirier
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 4f7dc04..529ef05 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -714,8 +714,13 @@ static int mlx4_cmd_wait(struct mlx4_dev *dev, u64
in_param, u64 *out_param,
msecs_to_jiffies(timeout))) {
mlx4_warn(dev, "command 0x%x timed out (go bit not cleared)\n",
op);
- err = -EIO;
- goto out_reset;
+ if (op == MLX4_CMD_NOP) {
+ err = -EBUSY;
+ goto out;
+ } else {
+ err = -EIO;
+ goto out_reset;
+ }
}
err = context->result;
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/19] memcg: make mem_cgroup_read_{stat|event}() iterate possible cpus instead of online
On Fri, May 22, 2015 at 06:23:18PM -0400, Tejun Heo wrote: > cpu_possible_mask represents the CPUs which are actually possible > during that boot instance. For systems which don't support CPU > hotplug, this will match cpu_online_mask exactly in most cases. Even > for systems which support CPU hotplug, the number of possible CPU > slots is highly unlikely to diverge greatly from the number of online > CPUs. The only cases where the difference between possible and online > caused problems were when the boot code failed to initialize the > possible mask and left it fully set at NR_CPUS - 1. > > As such, most per-cpu constructs allocate for all possible CPUs and > often iterate over the possibles, which also has the benefit of > avoiding the blocking CPU hotplug synchronization. > > memcg open codes per-cpu stat counting for mem_cgroup_read_stat() and > mem_cgroup_read_events(), which iterates over online CPUs and handles > CPU hotplug operations explicitly. This complexity doesn't actually > buy anything. Switch to iterating over the possibles and drop the > explicit CPU hotplug handling. > > Eventually, we want to convert memcg to use percpu_counter instead of > its own custom implementation which also benefits from quick access > w/o summing for cases where larger error margin is acceptable. > > This will allow mem_cgroup_read_stat() to be called from non-sleepable > contexts which will be used by cgroup writeback. > > Signed-off-by: Tejun Heo > Cc: Johannes Weiner > Cc: Michal Hocko Acked-by: Johannes Weiner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: nommu: avoid deprecated source register on mov
On Sat, May 23, 2015 at 12:46:52AM +0200, Stefan Agner wrote:
> @@ -106,32 +106,26 @@ ENTRY(secondary_startup)
> movsr10, r5 @ invalid processor?
> beq __error_p @ yes, error 'p'
>
> - adr r4, __secondary_data
> - ldmia r4, {r7, r12}
> -
> #ifdef CONFIG_ARM_MPU
> /* Use MPU region info supplied by __cpu_up */
> + ldr r7, __secondary_data
Almost, you want this above the #ifdef though, as r7 is used below.
("set up the stack pointer"). Apart from that, I don't see any
obvious problems, thanks.
> ldr r6, [r7]@ get secondary_data.mpu_szr
> bl __setup_mpu @ Initialize the MPU
> #endif
>
> - badrlr, __after_proc_init @ return address
> - mov r13, r12@ __secondary_switched address
> + badrlr, 1f @ return (PIC) address
> ldr r12, [r10, #PROCINFO_INITFUNC]
> add r12, r12, r10
> ret r12
> -ENDPROC(secondary_startup)
> -
> -ENTRY(__secondary_switched)
> +1: bl __after_proc_init
> ldr sp, [r7, #12] @ set up the stack pointer
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, May 22, 2015 at 3:33 PM, Herbert Xu wrote: > On Sat, May 23, 2015 at 12:22:00AM +0200, Luis R. Rodriguez wrote: >> Kind of, the issue actually was a new component which depends on FW_LOADER >> and has crypto dependencies. Since the qat crypto driver selects FW_LOADER >> but also has a set of crypto dependencies that creates a recursive dependency >> loop. > > Actually, how about making FW_SIG select FW_LOADER instead of > depending on it? I think this should break the cycle. Indeed, it does. Kind of odd, but works - and well if others run into the recursive issue then we have two diverging solutions now: a) Either swap all "select FOO" to "depends on FOO" or, b) Change the offending "depends on FOO" to "select FOO" So sticking to one seems to make Kconfig happy for recursive dependency solving for now... 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/
[PATCH] Input: stmpe-ts - enforce device tree only mode
The STMPE MFD is only used with device tree configured systems (and STMPE
MFD core depends on OF), so force the configuration to come from device
tree only.
Signed-off-by: Dmitry Torokhov
---
Not tested as no device, please give it a spin.
drivers/input/touchscreen/Kconfig| 1 +
drivers/input/touchscreen/stmpe-ts.c | 29
include/linux/mfd/stmpe.h| 44
3 files changed, 6 insertions(+), 68 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 80f6386..7afa6a2 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -958,6 +958,7 @@ config TOUCHSCREEN_ST1232
config TOUCHSCREEN_STMPE
tristate "STMicroelectronics STMPE touchscreens"
depends on MFD_STMPE
+ depends on (OF || COMPILE_TEST)
help
Say Y here if you want support for STMicroelectronics
STMPE touchscreen controllers.
diff --git a/drivers/input/touchscreen/stmpe-ts.c
b/drivers/input/touchscreen/stmpe-ts.c
index e4977c6..e414d43 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -267,27 +267,10 @@ static void stmpe_ts_close(struct input_dev *dev)
static void stmpe_ts_get_platform_info(struct platform_device *pdev,
struct stmpe_touch *ts)
{
- struct stmpe *stmpe = dev_get_drvdata(pdev->dev.parent);
struct device_node *np = pdev->dev.of_node;
- struct stmpe_ts_platform_data *ts_pdata = NULL;
-
- ts->stmpe = stmpe;
-
- if (stmpe->pdata && stmpe->pdata->ts) {
- ts_pdata = stmpe->pdata->ts;
-
- ts->sample_time = ts_pdata->sample_time;
- ts->mod_12b = ts_pdata->mod_12b;
- ts->ref_sel = ts_pdata->ref_sel;
- ts->adc_freq = ts_pdata->adc_freq;
- ts->ave_ctrl = ts_pdata->ave_ctrl;
- ts->touch_det_delay = ts_pdata->touch_det_delay;
- ts->settling = ts_pdata->settling;
- ts->fraction_z = ts_pdata->fraction_z;
- ts->i_drive = ts_pdata->i_drive;
- } else if (np) {
- u32 val;
+ u32 val;
+ if (np) {
if (!of_property_read_u32(np, "st,sample-time", ))
ts->sample_time = val;
if (!of_property_read_u32(np, "st,mod-12b", ))
@@ -311,6 +294,7 @@ static void stmpe_ts_get_platform_info(struct
platform_device *pdev,
static int stmpe_input_probe(struct platform_device *pdev)
{
+ struct stmpe *stmpe = dev_get_drvdata(pdev->dev.parent);
struct stmpe_touch *ts;
struct input_dev *idev;
int error;
@@ -329,6 +313,7 @@ static int stmpe_input_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, ts);
+ ts->stmpe = stmpe;
ts->idev = idev;
ts->dev = >dev;
@@ -351,14 +336,13 @@ static int stmpe_input_probe(struct platform_device *pdev)
idev->name = STMPE_TS_NAME;
idev->phys = STMPE_TS_NAME"/input0";
idev->id.bustype = BUS_I2C;
- idev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
- idev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
idev->open = stmpe_ts_open;
idev->close = stmpe_ts_close;
input_set_drvdata(idev, ts);
+ input_set_capability(idev, EV_KEY, BTN_TOUCH);
input_set_abs_params(idev, ABS_X, 0, XY_MASK, 0, 0);
input_set_abs_params(idev, ABS_Y, 0, XY_MASK, 0, 0);
input_set_abs_params(idev, ABS_PRESSURE, 0x0, 0xff, 0, 0);
@@ -390,15 +374,12 @@ static struct platform_driver stmpe_ts_driver = {
};
module_platform_driver(stmpe_ts_driver);
-#ifdef CONFIG_OF
static const struct of_device_id stmpe_ts_ids[] = {
{ .compatible = "st,stmpe-ts", },
{ },
};
MODULE_DEVICE_TABLE(of, stmpe_ts_ids);
-#endif
MODULE_AUTHOR("Luotao Fu ");
MODULE_DESCRIPTION("STMPEXXX touchscreen driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:" STMPE_TS_NAME);
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index c9d8690..cb83883 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -118,47 +118,6 @@ extern int stmpe_disable(struct stmpe *stmpe, unsigned int
blocks);
#define STMPE_GPIO_NOREQ_811_TOUCH (0xf0)
/**
- * struct stmpe_ts_platform_data - stmpe811 touch screen controller platform
- * data
- * @sample_time: ADC converstion time in number of clock.
- * (0 -> 36 clocks, 1 -> 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks,
- * 4 -> 80 clocks, 5 -> 96 clocks, 6 -> 144 clocks),
- * recommended is 4.
- * @mod_12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
- * @ref_sel: ADC reference source
- * (0 -> internal reference, 1 -> external reference)
- * @adc_freq: ADC Clock speed
- * (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
- * @ave_ctrl: Sample average control
- * (0
Re: [PATCH 4/7] tracing: timer: Add deferrable flag to timer_start
On Thu, 21 May 2015, Ingo Molnar wrote: > * John Stultz wrote: > > - TP_PROTO(struct timer_list *timer, unsigned long expires), > > + TP_PROTO(struct timer_list *timer, > > + unsigned long expires, > > This isn't compat safe, should any tooling rely on this. I can't see how that matters. The binary trace tells you from which machine (32 or 64 bit) it comes. So the field size is available for the tool. If the tool blindly applies the format string, it's hardly a fault of the kernel. And there is no point to bloat 32bit tracing with 64bit entries just because some random tool might be stupid. Just for the record: We have 539 'unsigned long' and 62 'long' event fields in include/trace/events/. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: dell_rbtn - kernel panic at boot...
On Thu, May 21, 2015 at 7:06 PM, Valdis Kletnieks wrote: > So after I made both config variables =y, the resulting kernel built, but > died a glorious death at boot. I guess if both are built-in then, according to link order, dell-laptop starts first, before dell-rbtn, and dies in dell_rbtn_notifier_register() in call to driver_for_each_device(_driver.drv, ...) because rbtn_driver has not been registered yet and thus half-initlalized. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3 v3] drivers: hwspinlock: add CSR atlas7 implementation
Hi Barry,
On 05/19/2015 01:41 AM, Barry Song wrote:
> From: Wei Chen
>
> Add hwspinlock support for the CSR atlas7 SoC.
>
> The Hardware Spinlock device on atlas7 provides hardware assistance
> for synchronization between the multiple processors in the system
> (dual Cortex-A7, CAN bus Cortex-M3 and audio DSP).
>
> Cc: Suman Anna
> Cc: Bjorn Andersson
> Signed-off-by: Wei Chen
> Signed-off-by: Barry Song
> ---
> -v3:
> use #hwlock-cells and general hwspinlock dt-binding;
> drop relax();
> drop num-spinlocks in dts;
> re-order Kconfig and Makefile;
> other codingstyle issues.
> Thanks Suman, Bjorn and Ohad
>
> drivers/hwspinlock/Kconfig | 12
> drivers/hwspinlock/Makefile | 1 +
> drivers/hwspinlock/sirf_hwspinlock.c | 135
> +++
> 3 files changed, 148 insertions(+)
> create mode 100644 drivers/hwspinlock/sirf_hwspinlock.c
>
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index b5b4f52..73a4016 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -30,6 +30,18 @@ config HWSPINLOCK_QCOM
>
> If unsure, say N.
>
> +config HWSPINLOCK_SIRF
> + tristate "SIRF Hardware Spinlock device"
> + depends on ARCH_SIRF
> + select HWSPINLOCK
> + help
> + Say y here to support the SIRF Hardware Spinlock device, which
> + provides a synchronisation mechanism for the various processors
> + on the SoC.
> +
> + It's safe to say n here if you're not interested in SIRF hardware
> + spinlock or just want a bare minimum kernel.
> +
> config HSEM_U8500
> tristate "STE Hardware Semaphore functionality"
> depends on ARCH_U8500
> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> index 68f95d9..6b59cb5a 100644
> --- a/drivers/hwspinlock/Makefile
> +++ b/drivers/hwspinlock/Makefile
> @@ -5,4 +5,5 @@
> obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
> obj-$(CONFIG_HWSPINLOCK_OMAP)+= omap_hwspinlock.o
> obj-$(CONFIG_HWSPINLOCK_QCOM)+= qcom_hwspinlock.o
> +obj-$(CONFIG_HWSPINLOCK_SIRF)+= sirf_hwspinlock.o
> obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
> diff --git a/drivers/hwspinlock/sirf_hwspinlock.c
> b/drivers/hwspinlock/sirf_hwspinlock.c
> new file mode 100644
> index 000..e7e5ba6
> --- /dev/null
> +++ b/drivers/hwspinlock/sirf_hwspinlock.c
> @@ -0,0 +1,135 @@
> +/*
> + * SIRF hardware spinlock driver
> + *
> + * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR plc group
> company.
Not sure on this, but 2015 is here and now..
> + *
> + * Licensed under GPLv2.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "hwspinlock_internal.h"
> +
> +struct sirf_hwspinlock {
> + void __iomem *io_base;
> + struct hwspinlock_device bank;
> +};
> +
> +/* Number of Hardware Spinlocks*/
> +#define HW_SPINLOCK_NUMBER 30
> +
> +/* Hardware spinlock register offsets */
> +#define HW_SPINLOCK_BASE 0x404
> +#define HW_SPINLOCK_OFFSET(x)(HW_SPINLOCK_BASE + 0x4 * (x))
> +
> +static int sirf_hwspinlock_trylock(struct hwspinlock *lock)
> +{
> + void __iomem *lock_addr = lock->priv;
> +
> + /* attempt to acquire the lock by reading value == 1 from it */
> + return !!readl(lock_addr);
> +}
> +
> +static void sirf_hwspinlock_unlock(struct hwspinlock *lock)
> +{
> + void __iomem *lock_addr = lock->priv;
> +
> + /* release the lock by writing 0 to it */
> + writel(0, lock_addr);
> +}
> +
> +static const struct hwspinlock_ops sirf_hwspinlock_ops = {
> + .trylock = sirf_hwspinlock_trylock,
> + .unlock = sirf_hwspinlock_unlock,
> +};
> +
> +static int sirf_hwspinlock_probe(struct platform_device *pdev)
> +{
> + struct sirf_hwspinlock *hwspin;
> + struct hwspinlock *hwlock;
> + int idx, ret;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + hwspin = devm_kzalloc(>dev, sizeof(*hwspin) +
> + sizeof(*hwlock) * HW_SPINLOCK_NUMBER, GFP_KERNEL);
> + if (!hwspin)
> + return -ENOMEM;
> +
> + /* retrieve io base */
> + hwspin->io_base = of_iomap(pdev->dev.of_node, 0);
> + if (!hwspin->io_base)
> + ret = -ENOMEM;
You are missing the bail out here.
> +
> + for (idx = 0; idx < HW_SPINLOCK_NUMBER; idx++) {
> + hwlock = >bank.lock[idx];
> + hwlock->priv = hwspin->io_base + HW_SPINLOCK_OFFSET(idx);
> + }
> +
> + platform_set_drvdata(pdev, hwspin);
> +
> + pm_runtime_enable(>dev);
> +
> + ret = hwspin_lock_register(>bank, >dev,
> + _hwspinlock_ops, 0, HW_SPINLOCK_NUMBER);
this is a checkpatch warning with the --strict option, not sure what
convention Ohad is following though. Rest looks good.
regards
Suman
--
To unsubscribe
[PATCH] ARM: nommu: avoid deprecated source register on mov
In Thumb2 mode, the stack register r13 is deprecated if the
destination register is the program counter (r15). Similar to
head.S, head-nommu.S uses r13 to store the return address used
after configuring the CPU's CP15 register. However, since we do
not enable a MMU, there will be no address switch and it is
possible to use branch with link instruction to call
__after_proc_init.
Avoid using r13 completely by using bl to call __after_proc_init
and get rid of __secondary_switched.
Beside removing unnecessary complexity, this also fixes a
compiler warning when compiling a !MMU kernel:
Warning: Use of r13 as a source register is deprecated when r15
is the destination register.
Suggested-by: Russell King
Signed-off-by: Stefan Agner
---
The patch takes the BSYM() to badr change into account and hence
applies cleanly on Russell's for-next branch. Tested using a
single core Cortex-M4 configuration.
arch/arm/kernel/head-nommu.S | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index c966016..570d89a 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -77,13 +77,13 @@ ENTRY(stext)
orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit
bl __setup_mpu
#endif
- ldr r13, =__mmap_switched @ address to jump to after
- @ initialising sctlr
+
badrlr, 1f @ return (PIC) address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
ret r12
- 1:b __after_proc_init
+1: bl __after_proc_init
+ b __mmap_switched
ENDPROC(stext)
#ifdef CONFIG_SMP
@@ -106,32 +106,26 @@ ENTRY(secondary_startup)
movsr10, r5 @ invalid processor?
beq __error_p @ yes, error 'p'
- adr r4, __secondary_data
- ldmia r4, {r7, r12}
-
#ifdef CONFIG_ARM_MPU
/* Use MPU region info supplied by __cpu_up */
+ ldr r7, __secondary_data
ldr r6, [r7]@ get secondary_data.mpu_szr
bl __setup_mpu @ Initialize the MPU
#endif
- badrlr, __after_proc_init @ return address
- mov r13, r12@ __secondary_switched address
+ badrlr, 1f @ return (PIC) address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
ret r12
-ENDPROC(secondary_startup)
-
-ENTRY(__secondary_switched)
+1: bl __after_proc_init
ldr sp, [r7, #12] @ set up the stack pointer
mov fp, #0
b secondary_start_kernel
-ENDPROC(__secondary_switched)
+ENDPROC(secondary_startup)
.type __secondary_data, %object
__secondary_data:
.long secondary_data
- .long __secondary_switched
#endif /* CONFIG_SMP */
/*
@@ -164,7 +158,7 @@ __after_proc_init:
#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
#endif /* CONFIG_CPU_CP15 */
- ret r13
+ ret lr
ENDPROC(__after_proc_init)
.ltorg
--
2.4.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 2/3] dell-rbtn: Export notifier for other kernel modules
On Thu, May 14, 2015 at 3:54 AM, Pali Rohár wrote:
> @@ -328,7 +408,9 @@ static void rbtn_notify(struct acpi_device *device, u32
> event)
>
> static int __init rbtn_init(void)
> {
> - return acpi_bus_register_driver(_driver);
> + /* ignore errors so module always loads and exports needed functions
> */
> + acpi_bus_register_driver(_driver);
> + return 0;
Ahem, and if it fails for some reason and you try to unload the module
what will happen when you call
acpi_bus_unregister_driver(_driver) in rbtn_exit()?\
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 v3] Documentation: dt: add the CSR atlas7 hwspinlock bindings document
Hi Barry, On 05/19/2015 01:41 AM, Barry Song wrote: > From: Wei Chen > > The Hardware Spinlock device on atlas7 provides hardware assistance > for synchronization between the multiple processors in the system > (dual Cortex-A7, CAN bus Cortex-M3 and audio DSP). > This patch adds the DT bindings information for this hwspinlock > module. > > Cc: Suman Anna > Cc: Bjorn Andersson > Signed-off-by: Wei Chen > Signed-off-by: Barry Song > --- > .../devicetree/bindings/hwlock/sirf,hwspinlock.txt | 25 > ++ > 1 file changed, 25 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt > > diff --git a/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt > b/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt > new file mode 100644 > index 000..cc6d351 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt > @@ -0,0 +1,25 @@ > +SIRF Hardware spinlock device Binding > +--- > + > +Required properties : > +- compatible : shall contain only one of the following: > + "sirf,hwspinlock" > + > +- reg : the register address of hwspinlock Also suggest to document the value to be used for #hwlock-cells, the generic hwlock binding does not mention that. > + > +Please look at the generic hwlock binding for usage information for > consumers, > +"Documentation/devicetree/bindings/hwlock/hwlock.txt" > + regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
> Not sure if this went out earlier. So I am resending.
>
> On 5/22/15 16:56, Rafael J. Wysocki wrote:
> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> >> >index 39c485b..b9657af 100644
> >> >--- a/drivers/acpi/glue.c
> >> >+++ b/drivers/acpi/glue.c
> >> >@@ -13,6 +13,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> >+#include
> >> >
> >> > #include "internal.h"
> >> >
> >> >@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct
> >> >acpi_device *acpi_dev)
> >> > struct list_head *physnode_list;
> >> > unsigned int node_id;
> >> > int retval = -EINVAL;
> >> >+ bool coherent;
> >> >
> >> > if (has_acpi_companion(dev)) {
> >> > if (acpi_dev) {
> >> >@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct
> >> >acpi_device *acpi_dev)
> >> > if (!has_acpi_companion(dev))
> >> > ACPI_COMPANION_SET(dev, acpi_dev);
> >> >
> >> >+ if (acpi_check_dma(acpi_dev, ))
> >> >+ arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> >> >+
> > Well, so is this going to work for PCI too after all?
> >
>
> No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
> (patch 3/6 in V4) will be submitted separately. We are working on
> cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCIe / hotplug: Drop pointless label from pciehp_probe()
On Sat, May 23, 2015 at 12:38:57AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The err_out_none label in pciehp_probe() only leads to a return
> statement, so use return statements instead of jumps to it and
> drop it.
>
> Signed-off-by: Rafael J. Wysocki
Applied to pci/hotplug for v4.2, thanks!
> ---
>
> On top of https://patchwork.kernel.org/patch/6436921/ .
>
> ---
> drivers/pci/hotplug/pciehp_core.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> Index: linux-pm/drivers/pci/hotplug/pciehp_core.c
> ===
> --- linux-pm.orig/drivers/pci/hotplug/pciehp_core.c
> +++ linux-pm/drivers/pci/hotplug/pciehp_core.c
> @@ -256,13 +256,13 @@ static int pciehp_probe(struct pcie_devi
> /* Can happen if we run out of bus numbers during probe */
> dev_err(>device,
> "Hotplug bridge without secondary bus, ignoring\n");
> - goto err_out_none;
> + return -ENODEV;
> }
>
> ctrl = pcie_init(dev);
> if (!ctrl) {
> dev_err(>device, "Controller initialization failed\n");
> - goto err_out_none;
> + return -ENODEV;
> }
> set_service_data(dev, ctrl);
>
> @@ -302,7 +302,6 @@ err_out_free_ctrl_slot:
> cleanup_slot(ctrl);
> err_out_release_ctlr:
> pciehp_release_ctrl(ctrl);
> -err_out_none:
> return -ENODEV;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] writeback: implement foreign cgroup inode detection
As concurrent write sharing of an inode is expected to be very rare
and memcg only tracks page ownership on first-use basis severely
confining the usefulness of such sharing, cgroup writeback tracks
ownership per-inode. While the support for concurrent write sharing
of an inode is deemed unnecessary, an inode being written to by
different cgroups at different points in time is a lot more common,
and, more importantly, charging only by first-use can too readily lead
to grossly incorrect behaviors (single foreign page can lead to
gigabytes of writeback to be incorrectly attributed).
To resolve this issue, cgroup writeback detects the majority dirtier
of an inode and will transfer the ownership to it. To avoid
unnnecessary oscillation, the detection mechanism keeps track of
history and gives out the switch verdict only if the foreign usage
pattern is stable over a certain amount of time and/or writeback
attempts.
The detection mechanism has fairly low space and computation overhead.
It adds 8 bytes to struct inode (one int and two u16's) and minimal
amount of calculation per IO. The detection mechanism converges to
the correct answer usually in several seconds of IO time when there's
a clear majority dirtier. Even when there isn't, it can reach an
acceptable answer fairly quickly under most circumstances.
Please see wb_detach_inode() for more details.
This patch only implements detection. Following patches will
implement actual switching.
Signed-off-by: Tejun Heo
Cc: Jens Axboe
Cc: Jan Kara
Cc: Wu Fengguang
Cc: Greg Thelen
---
fs/buffer.c | 4 +-
fs/fs-writeback.c | 168 +-
fs/mpage.c| 1 +
include/linux/fs.h| 5 ++
include/linux/writeback.h | 16 +
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 8140923..32d33b7 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3040,8 +3040,10 @@ static int submit_bh_wbc(int rw, struct buffer_head *bh,
*/
bio = bio_alloc(GFP_NOIO, 1);
- if (wbc)
+ if (wbc) {
wbc_init_bio(wbc, bio);
+ wbc_account_io(wbc, bh->b_page, bh->b_size);
+ }
bio->bi_iter.bi_sector = bh->b_blocknr * (bh->b_size >> 9);
bio->bi_bdev = bh->b_bdev;
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 755e8ef..8fb5edd 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -214,6 +214,20 @@ static void wb_wait_for_completion(struct backing_dev_info
*bdi,
#ifdef CONFIG_CGROUP_WRITEBACK
+/* parameters for foreign inode detection, see wb_detach_inode() */
+#define WB_FRN_TIME_SHIFT 13 /* 1s = 2^13, upto 8 secs w/ 16bit */
+#define WB_FRN_TIME_AVG_SHIFT 3 /* avg = avg * 7/8 + new * 1/8 */
+#define WB_FRN_TIME_CUT_DIV2 /* ignore rounds < avg / 2 */
+#define WB_FRN_TIME_PERIOD (2 * (1 << WB_FRN_TIME_SHIFT)) /* 2s */
+
+#define WB_FRN_HIST_SLOTS 16 /* inode->i_wb_frn_history is 16bit */
+#define WB_FRN_HIST_UNIT (WB_FRN_TIME_PERIOD / WB_FRN_HIST_SLOTS)
+ /* each slot's duration is 2s / 16 */
+#define WB_FRN_HIST_THR_SLOTS (WB_FRN_HIST_SLOTS / 2)
+ /* if foreign slots >= 8, switch */
+#define WB_FRN_HIST_MAX_SLOTS (WB_FRN_HIST_THR_SLOTS / 2 + 1)
+ /* one round can affect upto 5 slots */
+
void __inode_attach_wb(struct inode *inode, struct page *page)
{
struct backing_dev_info *bdi = inode_to_bdi(inode);
@@ -258,24 +272,174 @@ void wbc_attach_and_unlock_inode(struct
writeback_control *wbc,
struct inode *inode)
{
wbc->wb = inode_to_wb(inode);
+ wbc->inode = inode;
+
+ wbc->wb_id = wbc->wb->memcg_css->id;
+ wbc->wb_lcand_id = inode->i_wb_frn_winner;
+ wbc->wb_tcand_id = 0;
+ wbc->wb_bytes = 0;
+ wbc->wb_lcand_bytes = 0;
+ wbc->wb_tcand_bytes = 0;
+
wb_get(wbc->wb);
spin_unlock(>i_lock);
}
/**
- * wbc_detach_inode - disassociate wbc from its target inode
- * @wbc: writeback_control of interest
+ * wbc_detach_inode - disassociate wbc from inode and perform foreign detection
+ * @wbc: writeback_control of the just finished writeback
*
* To be called after a writeback attempt of an inode finishes and undoes
* wbc_attach_and_unlock_inode(). Can be called under any context.
+ *
+ * As concurrent write sharing of an inode is expected to be very rare and
+ * memcg only tracks page ownership on first-use basis severely confining
+ * the usefulness of such sharing, cgroup writeback tracks ownership
+ * per-inode. While the support for concurrent write sharing of an inode
+ * is deemed unnecessary, an inode being written to by different cgroups at
+ * different points in time is a lot more common, and, more importantly,
+ * charging only by first-use can too readily lead to grossly incorrect
[PATCH 1/9] writeback: relocate wb[_try]_get(), wb_put(), inode_{attach|detach}_wb()
Currently, majority of cgroup writeback support including all the
above functions are implemented in include/linux/backing-dev.h and
mm/backing-dev.c; however, the portion closely related to writeback
logic implemented in include/linux/writeback.h and mm/page-writeback.c
will expand to support foreign writeback detection and correction.
This patch moves wb[_try]_get() and wb_put() to
include/linux/backing-dev-defs.h so that they can be used from
writeback.h and inode_{attach|detach}_wb() to writeback.h and
page-writeback.c.
This is pure reorganization and doesn't introduce any functional
changes.
Signed-off-by: Tejun Heo
Cc: Jens Axboe
Cc: Jan Kara
Cc: Wu Fengguang
Cc: Greg Thelen
---
fs/fs-writeback.c| 31 +++
include/linux/backing-dev-defs.h | 50
include/linux/backing-dev.h | 82
include/linux/writeback.h| 46 ++
mm/backing-dev.c | 30 ---
5 files changed, 127 insertions(+), 112 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index da35587..cf6ccfb 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "internal.h"
/*
@@ -213,6 +214,36 @@ static void wb_wait_for_completion(struct backing_dev_info
*bdi,
#ifdef CONFIG_CGROUP_WRITEBACK
+void __inode_attach_wb(struct inode *inode, struct page *page)
+{
+ struct backing_dev_info *bdi = inode_to_bdi(inode);
+ struct bdi_writeback *wb = NULL;
+
+ if (inode_cgwb_enabled(inode)) {
+ struct cgroup_subsys_state *memcg_css;
+
+ if (page) {
+ memcg_css = mem_cgroup_css_from_page(page);
+ wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC);
+ } else {
+ /* must pin memcg_css, see wb_get_create() */
+ memcg_css = task_get_css(current, memory_cgrp_id);
+ wb = wb_get_create(bdi, memcg_css, GFP_ATOMIC);
+ css_put(memcg_css);
+ }
+ }
+
+ if (!wb)
+ wb = >wb;
+
+ /*
+* There may be multiple instances of this function racing to
+* update the same inode. Use cmpxchg() to tell the winner.
+*/
+ if (unlikely(cmpxchg(>i_wb, NULL, wb)))
+ wb_put(wb);
+}
+
/**
* inode_congested - test whether an inode is congested
* @inode: inode to test for congestion
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index 8d470b7..e047b49 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -186,4 +186,54 @@ static inline void set_bdi_congested(struct
backing_dev_info *bdi, int sync)
set_wb_congested(bdi->wb.congested, sync);
}
+#ifdef CONFIG_CGROUP_WRITEBACK
+
+/**
+ * wb_tryget - try to increment a wb's refcount
+ * @wb: bdi_writeback to get
+ */
+static inline bool wb_tryget(struct bdi_writeback *wb)
+{
+ if (wb != >bdi->wb)
+ return percpu_ref_tryget(>refcnt);
+ return true;
+}
+
+/**
+ * wb_get - increment a wb's refcount
+ * @wb: bdi_writeback to get
+ */
+static inline void wb_get(struct bdi_writeback *wb)
+{
+ if (wb != >bdi->wb)
+ percpu_ref_get(>refcnt);
+}
+
+/**
+ * wb_put - decrement a wb's refcount
+ * @wb: bdi_writeback to put
+ */
+static inline void wb_put(struct bdi_writeback *wb)
+{
+ if (wb != >bdi->wb)
+ percpu_ref_put(>refcnt);
+}
+
+#else /* CONFIG_CGROUP_WRITEBACK */
+
+static inline bool wb_tryget(struct bdi_writeback *wb)
+{
+ return true;
+}
+
+static inline void wb_get(struct bdi_writeback *wb)
+{
+}
+
+static inline void wb_put(struct bdi_writeback *wb)
+{
+}
+
+#endif /* CONFIG_CGROUP_WRITEBACK */
+
#endif /* __LINUX_BACKING_DEV_DEFS_H */
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index e9d7373..5c978a9 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -243,7 +243,6 @@ void wb_congested_put(struct bdi_writeback_congested
*congested);
struct bdi_writeback *wb_get_create(struct backing_dev_info *bdi,
struct cgroup_subsys_state *memcg_css,
gfp_t gfp);
-void __inode_attach_wb(struct inode *inode, struct page *page);
void wb_memcg_offline(struct mem_cgroup *memcg);
void wb_blkcg_offline(struct blkcg *blkcg);
int inode_congested(struct inode *inode, int cong_bits);
@@ -265,37 +264,6 @@ static inline bool inode_cgwb_enabled(struct inode *inode)
}
/**
- * wb_tryget - try to increment a wb's refcount
- * @wb: bdi_writeback to get
- */
-static inline bool wb_tryget(struct bdi_writeback *wb)
-{
- if (wb != >bdi->wb)
- return percpu_ref_tryget(>refcnt);
- return true;
-}
-
-/**
- * wb_get - increment a wb's refcount
- * @wb:
[PATCHSET 3/3 v3 block/for-4.2/core] writeback: implement foreign cgroup inode bdi_writeback switching
Hello,
The changes from the last take[L] are
* Rebased on top of block/for-4.2/core.
* 0004-truncate-swap-the-order-of-conditionals-in-cancel_di.patch
became unnecessary due to recent changes to cancel_page_dirty().
Dropped.
* unlocked_inode_to_wb_begin/end() usages were using the wrong locking
order when used in combination with memcg stat transactions. Orders
reversed and might_lock() added to
0007-writeback-add-lockdep-annotation-to-inode_to_wb.patch so that
bugs like this can be caught reliably.
The previous two patchsets [2][3] implemented cgroup writeback support
and backpressure propagation through dirty throttling mechanism;
however, the inode is assigned to the wb (bdi_writeback) matching the
first dirtied page and stays there until released. This first-use
policy can easily lead to gross misbehaviors - a single stray dirty
page can cause gigatbytes to be written by the wrong cgroup. Also,
while concurrently write sharing an inode is extremely rare and
unsupported, inodes jumping cgroups over time are more common.
This patchset implements foreign cgroup inode detection and wb
switching. Each writeback run tracks the majority wb being written
using a simple but fairly robust algorithm and when an inode
persistently writes out more foreign cgroup pages than local ones, the
inode is transferred to the majority winner.
This patchset adds 8 bytes to inode making the total per-inode space
overhead of cgroup writeback support 16 bytes on 64bit systems. The
computational overhead should be negligible. If the writer changes
from one cgroup to another entirely, the mechanism can render the
correct switch verdict in several seconds of IO time in most cases and
it can converge on the correct answer in reasonable amount of time
even in more ambiguous cases.
This patchset contains the following 8 patches.
0001-writeback-relocate-wb-_try-_get-wb_put-inode_-attach.patch
0002-writeback-make-writeback_control-track-the-inode-bei.patch
0003-writeback-implement-foreign-cgroup-inode-detection.patch
0004-writeback-implement-locked_-inode_to_wb_and_lock_lis.patch
0005-writeback-implement-unlocked_inode_to_wb-transaction.patch
0006-writeback-use-unlocked_inode_to_wb-transaction-in-in.patch
0007-writeback-add-lockdep-annotation-to-inode_to_wb.patch
0008-writeback-implement-foreign-cgroup-inode-bdi_writeba.patch
0009-writeback-disassociate-inodes-from-dying-bdi_writeba.patch
This patchset is on top of
block/for-4.2/core b04a5636a665 ("block: replace trylock with mutex_lock in
blkdev_reread_part()")
+ [1] [PATCHSET 1/3 v4 block/for-4.2/core] writeback: cgroup writeback support
+ [2] [PATCHSET 2/3 v3 block/for-4.2/core] writeback: cgroup writeback
backpressure propagation
and available in the following git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
review-cgroup-writeback-switch-20150522
diffstat follows. Thanks.
fs/buffer.c | 26 -
fs/fs-writeback.c| 523 ++-
fs/mpage.c |3
include/linux/backing-dev-defs.h | 66
include/linux/backing-dev.h | 144 +-
include/linux/fs.h | 11
include/linux/mm.h |3
include/linux/writeback.h| 123 +
mm/backing-dev.c | 30 --
mm/filemap.c |5
mm/page-writeback.c | 27 +-
11 files changed, 822 insertions(+), 139 deletions(-)
--
tejun
[L] http://lkml.kernel.org/g/1428351508-8399-1-git-send-email...@kernel.org
[1] http://lkml.kernel.org/g/1432329245-5844-1-git-send-email...@kernel.org
[2] http://lkml.kernel.org/g/1428350674-8303-1-git-send-email...@kernel.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] writeback: make writeback_control track the inode being written back
Currently, for cgroup writeback, the IO submission paths directly
associate the bio's with the blkcg from inode_to_wb_blkcg_css();
however, it'd be necessary to keep more writeback context to implement
foreign inode writeback detection. wbc (writeback_control) is the
natural fit for the extra context - it persists throughout the
writeback of each inode and is passed all the way down to IO
submission paths.
This patch adds wbc_attach_and_unlock_inode(), wbc_detach_inode(), and
wbc_attach_fdatawrite_inode() which are used to associate wbc with the
inode being written back. IO submission paths now use wbc_init_bio()
instead of directly associating bio's with blkcg themselves. This
leaves inode_to_wb_blkcg_css() w/o any user. The function is removed.
wbc currently only tracks the associated wb (bdi_writeback). Future
patches will add more for foreign inode detection. The association is
established under i_lock which will be depended upon when migrating
foreign inodes to other wb's.
As currently, once established, inode to wb association never changes,
going through wbc when initializing bio's doesn't cause any behavior
changes.
Signed-off-by: Tejun Heo
Cc: Jens Axboe
Cc: Jan Kara
Cc: Wu Fengguang
Cc: Greg Thelen
---
fs/buffer.c | 24 --
fs/fs-writeback.c | 37 +--
fs/mpage.c | 2 +-
include/linux/backing-dev.h | 12 -
include/linux/writeback.h | 61 +
mm/filemap.c| 2 ++
6 files changed, 110 insertions(+), 28 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 18cd378..8140923 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -45,9 +45,9 @@
#include
static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
-static int submit_bh_blkcg(int rw, struct buffer_head *bh,
- unsigned long bio_flags,
- struct cgroup_subsys_state *blkcg_css);
+static int submit_bh_wbc(int rw, struct buffer_head *bh,
+unsigned long bio_flags,
+struct writeback_control *wbc);
#define BH_ENTRY(list) list_entry((list), struct buffer_head, b_assoc_buffers)
@@ -1709,7 +1709,6 @@ static int __block_write_full_page(struct inode *inode,
struct page *page,
unsigned int blocksize, bbits;
int nr_underway = 0;
int write_op = (wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE);
- struct cgroup_subsys_state *blkcg_css = inode_to_wb_blkcg_css(inode);
head = create_page_buffers(page, inode,
(1 << BH_Dirty)|(1 << BH_Uptodate));
@@ -1798,7 +1797,7 @@ static int __block_write_full_page(struct inode *inode,
struct page *page,
do {
struct buffer_head *next = bh->b_this_page;
if (buffer_async_write(bh)) {
- submit_bh_blkcg(write_op, bh, 0, blkcg_css);
+ submit_bh_wbc(write_op, bh, 0, wbc);
nr_underway++;
}
bh = next;
@@ -1852,7 +1851,7 @@ static int __block_write_full_page(struct inode *inode,
struct page *page,
struct buffer_head *next = bh->b_this_page;
if (buffer_async_write(bh)) {
clear_buffer_dirty(bh);
- submit_bh_blkcg(write_op, bh, 0, blkcg_css);
+ submit_bh_wbc(write_op, bh, 0, wbc);
nr_underway++;
}
bh = next;
@@ -3017,9 +3016,8 @@ void guard_bio_eod(int rw, struct bio *bio)
}
}
-static int submit_bh_blkcg(int rw, struct buffer_head *bh,
- unsigned long bio_flags,
- struct cgroup_subsys_state *blkcg_css)
+static int submit_bh_wbc(int rw, struct buffer_head *bh,
+unsigned long bio_flags, struct writeback_control *wbc)
{
struct bio *bio;
int ret = 0;
@@ -3042,8 +3040,8 @@ static int submit_bh_blkcg(int rw, struct buffer_head *bh,
*/
bio = bio_alloc(GFP_NOIO, 1);
- if (blkcg_css)
- bio_associate_blkcg(bio, blkcg_css);
+ if (wbc)
+ wbc_init_bio(wbc, bio);
bio->bi_iter.bi_sector = bh->b_blocknr * (bh->b_size >> 9);
bio->bi_bdev = bh->b_bdev;
@@ -3072,13 +3070,13 @@ static int submit_bh_blkcg(int rw, struct buffer_head
*bh,
int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
{
- return submit_bh_blkcg(rw, bh, bio_flags, NULL);
+ return submit_bh_wbc(rw, bh, bio_flags, NULL);
}
EXPORT_SYMBOL_GPL(_submit_bh);
int submit_bh(int rw, struct buffer_head *bh)
{
- return submit_bh_blkcg(rw, bh, 0, NULL);
+ return submit_bh_wbc(rw, bh, 0, NULL);
}
EXPORT_SYMBOL(submit_bh);
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index cf6ccfb..755e8ef 100644
---
