* Re: linux-next: manual merge of the xen-tip tree with the block tree
From: Stephen Rothwell @ 2016-07-26 4:57 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Stefano Stabellini, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Xen Devel, Jens Axboe, linux-next, linux-kernel, Jan Beulich,
Mike Christie, david.vrabel, Juergen Gross
In-Reply-To: <aac9ff10-ae0c-77fa-b1f1-dc12beafd8e6@oracle.com>
Hi Boris,
On Mon, 25 Jul 2016 18:25:00 -0400 Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>
> > Jeremy Fitzhardinge <jeremy@goop.org>
>
> Jeremy is no longer involved with Xen. However,
>
> Juergen Gross <jgross@suse.com>
>
> is also Linux Xen/x86 maintainer.
I have replaced Jeremy with Juergen.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the random tree with the kspp tree
From: Stephen Rothwell @ 2016-07-26 4:52 UTC (permalink / raw)
To: Theodore Ts'o, Kees Cook; +Cc: linux-next, linux-kernel, Emese Revfy
Hi Theodore,
Today's linux-next merge of the random tree got a conflict in:
drivers/char/random.c
between commit:
8c6a68e9eaa5 ("latent_entropy: Mark functions with __latent_entropy")
from the kspp tree and commit:
e192be9d9a30 ("random: replace non-blocking pool with a Chacha20-based CRNG")
from the random tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/char/random.c
index 6cca3ed45817,8d0af74f6569..000000000000
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@@ -442,10 -471,15 +471,15 @@@ struct entropy_store
__u8 last_data[EXTRACT_SIZE];
};
+ static ssize_t extract_entropy(struct entropy_store *r, void *buf,
+ size_t nbytes, int min, int rsvd);
+ static ssize_t _extract_entropy(struct entropy_store *r, void *buf,
+ size_t nbytes, int fips);
+
+ static void crng_reseed(struct crng_state *crng, struct entropy_store *r);
static void push_to_pool(struct work_struct *work);
-static __u32 input_pool_data[INPUT_POOL_WORDS];
-static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
+static __u32 input_pool_data[INPUT_POOL_WORDS] __latent_entropy;
+static __u32 blocking_pool_data[OUTPUT_POOL_WORDS] __latent_entropy;
- static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS] __latent_entropy;
static struct entropy_store input_pool = {
.poolinfo = &poolinfo_table[0],
^ permalink raw reply
* linux-next: manual merge of the xen-tip tree with the tip tree
From: Stephen Rothwell @ 2016-07-26 4:02 UTC (permalink / raw)
To: Juergen Gross, Konrad Rzeszutek Wilk, Stefano Stabellini,
boris.ostrovsky, david.vrabel, Xen Devel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Vitaly Kuznetsov
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/smp.c
between commit:
4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
from the tip tree and commit:
ad5475f9faf5 ("x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op")
from the xen-tip tree.
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/xen/smp.c
index 09d5cc062dbe,0b4d04c8ab4d..000000000000
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@@ -486,7 -495,11 +493,7 @@@ static int xen_cpu_up(unsigned int cpu
xen_pmu_init(cpu);
- rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
- rc = xen_smp_intr_init(cpu);
- if (rc)
- return rc;
-
+ rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL);
BUG_ON(rc);
while (cpu_report_state(cpu) != CPU_ONLINE)
^ permalink raw reply
* linux-next: manual merge of the xen-tip tree with the tip tree
From: Stephen Rothwell @ 2016-07-26 4:01 UTC (permalink / raw)
To: Juergen Gross, Konrad Rzeszutek Wilk, Stefano Stabellini,
boris.ostrovsky, david.vrabel, Xen Devel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Vitaly Kuznetsov
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/enlighten.c
between commit:
4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
from the tip tree and commit:
88e957d6e47f ("xen: introduce xen_vcpu_id mapping")
from the xen-tip tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/xen/enlighten.c
index dc96f939af88,85ef4c0442e0..000000000000
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@@ -1803,49 -1823,21 +1824,53 @@@ static void __init init_hvm_pv_info(voi
xen_domain_type = XEN_HVM_DOMAIN;
}
-static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long action,
- void *hcpu)
+static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
+ void *hcpu)
{
int cpu = (long)hcpu;
+ int rc;
+
switch (action) {
case CPU_UP_PREPARE:
- if (cpu_acpi_id(cpu) != U32_MAX)
- per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
- else
- per_cpu(xen_vcpu_id, cpu) = cpu;
- xen_vcpu_setup(cpu);
- if (xen_have_vector_callback) {
- if (xen_feature(XENFEAT_hvm_safe_pvclock))
- xen_setup_timer(cpu);
+ if (xen_hvm_domain()) {
+ /*
+ * This can happen if CPU was offlined earlier and
+ * offlining timed out in common_cpu_die().
+ */
+ if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+ xen_smp_intr_free(cpu);
+ xen_uninit_lock_cpu(cpu);
+ }
+
++ if (cpu_acpi_id(cpu) != U32_MAX)
++ per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
++ else
++ per_cpu(xen_vcpu_id, cpu) = cpu;
+ xen_vcpu_setup(cpu);
}
+
+ if (xen_pv_domain() ||
+ (xen_have_vector_callback &&
+ xen_feature(XENFEAT_hvm_safe_pvclock)))
+ xen_setup_timer(cpu);
+
+ rc = xen_smp_intr_init(cpu);
+ if (rc) {
+ WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
+ cpu, rc);
+ return NOTIFY_BAD;
+ }
+
+ break;
+ case CPU_ONLINE:
+ xen_init_lock_cpu(cpu);
+ break;
+ case CPU_UP_CANCELED:
+ xen_smp_intr_free(cpu);
+ if (xen_pv_domain() ||
+ (xen_have_vector_callback &&
+ xen_feature(XENFEAT_hvm_safe_pvclock)))
+ xen_teardown_timer(cpu);
break;
default:
break;
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the sh tree
From: Stephen Rothwell @ 2016-07-25 22:30 UTC (permalink / raw)
To: Rich Felker
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Linus
In-Reply-To: <20160724151342.32b35c80@canb.auug.org.au>
Hi all,
On Sun, 24 Jul 2016 15:13:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/sh/include/asm/spinlock.h
>
> between commit:
>
> 2da83dfce7df ("sh: add J2 atomics using the cas.l instruction")
>
> from the sh tree and commit:
>
> 726328d92a42 ("locking/spinlock, arch: Update and fix spin_unlock_wait() implementations")
>
> from the tip tree.
>
> I fixed it up (I used this file from the sh tree and then added the merge
> fix patch below) and can carry the fix as necessary. This is now fixed
> as far as linux-next is concerned, but any non trivial conflicts should
> be mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sun, 24 Jul 2016 15:09:57 +1000
> Subject: [PATCH] locking/spinlock, arch: merge fix for "sh: add J2 atomics
> using the cas.l instruction"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/sh/include/asm/spinlock-cas.h | 10 ++++++++--
> arch/sh/include/asm/spinlock-llsc.h | 10 ++++++++--
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/sh/include/asm/spinlock-cas.h b/arch/sh/include/asm/spinlock-cas.h
> index a2a7c10b30d9..c46e8cc7b515 100644
> --- a/arch/sh/include/asm/spinlock-cas.h
> +++ b/arch/sh/include/asm/spinlock-cas.h
> @@ -10,6 +10,9 @@
> #ifndef __ASM_SH_SPINLOCK_CAS_H
> #define __ASM_SH_SPINLOCK_CAS_H
>
> +#include <asm/barrier.h>
> +#include <asm/processor.h>
> +
> static inline unsigned __sl_cas(volatile unsigned *p, unsigned old, unsigned new)
> {
> __asm__ __volatile__("cas.l %1,%0,@r0"
> @@ -25,8 +28,11 @@ static inline unsigned __sl_cas(volatile unsigned *p, unsigned old, unsigned new
>
> #define arch_spin_is_locked(x) ((x)->lock <= 0)
> #define arch_spin_lock_flags(lock, flags) arch_spin_lock(lock)
> -#define arch_spin_unlock_wait(x) \
> - do { while (arch_spin_is_locked(x)) cpu_relax(); } while (0)
> +
> +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> +{
> + smp_cond_load_acquire(&lock->lock, VAL > 0);
> +}
>
> static inline void arch_spin_lock(arch_spinlock_t *lock)
> {
> diff --git a/arch/sh/include/asm/spinlock-llsc.h b/arch/sh/include/asm/spinlock-llsc.h
> index 238ef6f54dcc..cec78143fa83 100644
> --- a/arch/sh/include/asm/spinlock-llsc.h
> +++ b/arch/sh/include/asm/spinlock-llsc.h
> @@ -11,14 +11,20 @@
> #ifndef __ASM_SH_SPINLOCK_LLSC_H
> #define __ASM_SH_SPINLOCK_LLSC_H
>
> +#include <asm/barrier.h>
> +#include <asm/processor.h>
> +
> /*
> * Your basic SMP spinlocks, allowing only a single CPU anywhere
> */
>
> #define arch_spin_is_locked(x) ((x)->lock <= 0)
> #define arch_spin_lock_flags(lock, flags) arch_spin_lock(lock)
> -#define arch_spin_unlock_wait(x) \
> - do { while (arch_spin_is_locked(x)) cpu_relax(); } while (0)
> +
> +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> +{
> + smp_cond_load_acquire(&lock->lock, VAL > 0);
> +}
>
> /*
> * Simple spin lock operations. There are two variants, one clears IRQ's
> --
> 2.8.1
Since Linus has merged part of the tip tree, this conflict resolution
is now needed when the sh tree is merged with Linus' tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the block tree
From: Boris Ostrovsky @ 2016-07-25 22:25 UTC (permalink / raw)
To: Stephen Rothwell, Stefano Stabellini
Cc: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Xen Devel, Jens Axboe,
linux-next, linux-kernel, Jan Beulich, Mike Christie,
david.vrabel, Juergen Gross
In-Reply-To: <20160726081942.60487736@canb.auug.org.au>
On 07/25/2016 06:19 PM, Stephen Rothwell wrote:
> Hi Stefano,
>
> On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini <sstabellini@kernel.org> wrote:
>> The To and CC list for these emails is a bit outdated. I want to make
>> sure they reach the right people. Could you please add:
>>
>> boris.ostrovsky@oracle.com
>> david.vrabel@citrix.com
> OK, I have added them as contacts for the xen-tip tree. The complete list is now:
>
> Jeremy Fitzhardinge <jeremy@goop.org>
Jeremy is no longer involved with Xen. However,
Juergen Gross <jgross@suse.com>
is also Linux Xen/x86 maintainer.
-boris
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Stefano Stabellini <sstabellini@kernel.org>
> <boris.ostrovsky@oracle.com>
> <david.vrabel@citrix.com>
> Xen Devel <Xen-devel@lists.xensource.com>
>
> Please let me know if you need further changes.
>
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the block tree
From: Stefano Stabellini @ 2016-07-25 22:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Stefano Stabellini, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk,
Xen Devel, Jens Axboe, linux-next, linux-kernel, Jan Beulich,
Mike Christie, david.vrabel, boris.ostrovsky
In-Reply-To: <20160726081942.60487736@canb.auug.org.au>
On Tue, 26 Jul 2016, Stephen Rothwell wrote:
> Hi Stefano,
>
> On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini <sstabellini@kernel.org> wrote:
> >
> > The To and CC list for these emails is a bit outdated. I want to make
> > sure they reach the right people. Could you please add:
> >
> > boris.ostrovsky@oracle.com
> > david.vrabel@citrix.com
>
> OK, I have added them as contacts for the xen-tip tree. The complete list is now:
>
> Jeremy Fitzhardinge <jeremy@goop.org>
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Stefano Stabellini <sstabellini@kernel.org>
> <boris.ostrovsky@oracle.com>
> <david.vrabel@citrix.com>
> Xen Devel <Xen-devel@lists.xensource.com>
>
> Please let me know if you need further changes.
Thanks, I'll do!
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the block tree
From: Stephen Rothwell @ 2016-07-25 22:19 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Xen Devel, Jens Axboe,
linux-next, linux-kernel, Jan Beulich, Mike Christie,
david.vrabel, boris.ostrovsky
In-Reply-To: <alpine.DEB.2.10.1607251020130.12319@sstabellini-ThinkPad-X260>
Hi Stefano,
On Mon, 25 Jul 2016 10:29:11 -0700 (PDT) Stefano Stabellini <sstabellini@kernel.org> wrote:
>
> The To and CC list for these emails is a bit outdated. I want to make
> sure they reach the right people. Could you please add:
>
> boris.ostrovsky@oracle.com
> david.vrabel@citrix.com
OK, I have added them as contacts for the xen-tip tree. The complete list is now:
Jeremy Fitzhardinge <jeremy@goop.org>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Stefano Stabellini <sstabellini@kernel.org>
<boris.ostrovsky@oracle.com>
<david.vrabel@citrix.com>
Xen Devel <Xen-devel@lists.xensource.com>
Please let me know if you need further changes.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page
From: Tejun Heo @ 2016-07-25 18:30 UTC (permalink / raw)
To: Tom Yan
Cc: Hannes Reinecke, Sergei Shtylyov, Arnd Bergmann, Stephen Rothwell,
linux-ide, linux-scsi, linux-kernel, linux-next
In-Reply-To: <CAGnHSEnSQcxcaJopGnVusC9Q41qHKkdr4QQDmymFSxVEH6zvPQ@mail.gmail.com>
On Fri, Jul 22, 2016 at 05:50:18AM +0800, Tom Yan wrote:
> As I've mentioned in the comment/message, there is no ATA command
> needed to be sent to the device, since it only toggles a bit in
> dev->flags. See that there is no ata_taskfile constructed in
> ata_mselect_control().
But ata_mselect_caching() contructs a tf?
--
tejun
^ permalink raw reply
* Re: linux-next: Tree for Jul 24 (apparmor)
From: John Johansen @ 2016-07-25 18:00 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, linux-next
Cc: linux-kernel, apparmor, linux-security-module
In-Reply-To: <7a66a4c7-60cb-166d-2518-b7ba8de0033b@infradead.org>
On 07/24/2016 04:26 PM, Randy Dunlap wrote:
> On 07/24/16 01:20, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20160722:
>>
>
> on x86_64:
>
> CONFIG_SECURITY_APPARMOR=y
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
> # CONFIG_SECURITY_APPARMOR_HASH is not set
>
> ../security/apparmor/lsm.c:675:25: error: 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function)
> bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
> ^
>
>
yep thanks, its fixed by the following patch, and I have requested James pull it
The newly added Kconfig option could never work and just causes a build error
when disabled:
security/apparmor/lsm.c:675:25: error: 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function)
bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
The problem is that the macro undefined in this case, and we need to use the IS_ENABLED()
helper to turn it into a boolean constant.
Another minor problem with the original patch is that the option is even offered
in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides the option
in that case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 6059f71f1e94 ("apparmor: add parameter to control whether policy hashing is used")
---
security/apparmor/crypto.c | 3 +++
security/apparmor/lsm.c | 4 +++-
security/apparmor/policy_unpack.c | 3 +--
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/security/apparmor/crypto.c b/security/apparmor/crypto.c
index 532471d0b3a0..b75dab0df1cb 100644
--- a/security/apparmor/crypto.c
+++ b/security/apparmor/crypto.c
@@ -39,6 +39,9 @@ int aa_calc_profile_hash(struct aa_profile *profile, u32 version, void *start,
int error = -ENOMEM;
u32 le32_version = cpu_to_le32(version);
+ if (!aa_g_hash_policy)
+ return 0;
+
if (!apparmor_tfm)
return 0;
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 3be30c701bfa..41b8cb115801 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -671,9 +671,11 @@ enum profile_mode aa_g_profile_mode = APPARMOR_ENFORCE;
module_param_call(mode, param_set_mode, param_get_mode,
&aa_g_profile_mode, S_IRUSR | S_IWUSR);
+#ifdef CONFIG_SECURITY_APPARMOR_HASH
/* whether policy verification hashing is enabled */
-bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
+bool aa_g_hash_policy = IS_ENABLED(CONFIG_SECURITY_APPARMOR_HASH_DEFAULT);
module_param_named(hash_policy, aa_g_hash_policy, aabool, S_IRUSR | S_IWUSR);
+#endif
/* Debug mode */
bool aa_g_debug;
diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c
index b9b1c66a32a5..138120698f83 100644
--- a/security/apparmor/policy_unpack.c
+++ b/security/apparmor/policy_unpack.c
@@ -778,8 +778,7 @@ int aa_unpack(void *udata, size_t size, struct list_head *lh, const char **ns)
if (error)
goto fail_profile;
- if (aa_g_hash_policy)
- error = aa_calc_profile_hash(profile, e.version, start,
+ error = aa_calc_profile_hash(profile, e.version, start,
e.pos - start);
if (error)
goto fail_profile;
--
2.9.0
^ permalink raw reply related
* Re: linux-next: build warning after merge of the tip tree
From: Rich Felker @ 2016-07-25 17:54 UTC (permalink / raw)
To: Mark Brown
Cc: Daniel Lezcano, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Marc Zyngier
In-Reply-To: <20160725164209.GF11806@sirena.org.uk>
On Mon, Jul 25, 2016 at 05:42:09PM +0100, Mark Brown wrote:
> On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> > On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
>
> > > I don't know the goal of adding those patches in linux-next via your
> > > tree, may be you misunderstood how linux-next works and you should
> > > remove them. But if the purpose was to merge the patches, I remind you
> > > that being an arch maintainer does not give you the right to apply any
> > > patches, everywhere, at all cost, without review, because you want them
> > > in, you must follow the process, otherwise you take the risk to upset a
> > > lot of people and to be kicked out.
>
> > If this is upsetting people I can remove them. Last time I got
> > feedback from at least one (driver) subsystem maintainer that (if I
> > understood it correctly) indicated they would like to have seen the
> > patch in linux-next without problems before upstreaming it through
>
> I think that was me and you've very much misunderstood what I was
> saying. A that time you were sending new drivers during the merge
> window with the apparent expectation that they would be merged during
> that merge window. That's not going to happen, things need to go into
> -next before the merge window. This means that you need to submit your
> patches well in advance of the merge window so they can be reviewed and
> ideally applied to maintainer trees before the merge window opens.
>
> It does not mean that you should include unreviewed code for other trees
> in your -next tree, that's not the purpose of -next. What goes into
> -next from each maintainer tree should be what is currently intended to
> go to Linus for that tree in the next merge window.
OK, thanks for the clarification. I'll remove the drivers from my
for-next branch.
Rich
^ permalink raw reply
* Re: linux-next: manual merge of the xen-tip tree with the block tree
From: Stefano Stabellini @ 2016-07-25 17:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, Stefano Stabellini,
Xen Devel, Jens Axboe, linux-next, linux-kernel, Jan Beulich,
Mike Christie, david.vrabel, boris.ostrovsky
In-Reply-To: <20160724161432.0f5a4011@canb.auug.org.au>
On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
> drivers/block/xen-blkfront.c
>
> between commit:
>
> a418090aa88b ("block: do not use REQ_FLUSH for tracking flush support")
>
> from the block tree and commit:
>
> ff595325ed55 ("xen-blkfront: prefer xenbus_scanf() over xenbus_gather()")
>
> from the xen-tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Hello Stephen,
thanks for letting us know, the fix is good.
The To and CC list for these emails is a bit outdated. I want to make
sure they reach the right people. Could you please add:
boris.ostrovsky@oracle.com
david.vrabel@citrix.com
Thanks!
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/block/xen-blkfront.c
> index ab382c7997b8,ca0536eb7037..000000000000
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@@ -2298,11 -2308,9 +2297,10 @@@ static void blkfront_gather_backend_fea
> unsigned int indirect_segments;
>
> info->feature_flush = 0;
> + info->feature_fua = 0;
>
> - err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> - "feature-barrier", "%d", &barrier,
> - NULL);
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "feature-barrier", "%d", &barrier);
>
> /*
> * If there's no "feature-barrier" defined, then it means
> @@@ -2311,35 -2319,27 +2309,32 @@@
> *
> * If there are barriers, then we use flush.
> */
> - if (!err && barrier) {
> - if (err > 0 && barrier)
> - info->feature_flush = REQ_FLUSH | REQ_FUA;
> ++ if (err > 0 && barrier) {
> + info->feature_flush = 1;
> + info->feature_fua = 1;
> + }
> +
> /*
> * And if there is "feature-flush-cache" use that above
> * barriers.
> */
> - err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> - "feature-flush-cache", "%d", &flush,
> - NULL);
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "feature-flush-cache", "%d", &flush);
>
> - if (!err && flush) {
> - if (err > 0 && flush)
> - info->feature_flush = REQ_FLUSH;
> ++ if (err > 0 && flush) {
> + info->feature_flush = 1;
> + info->feature_fua = 0;
> + }
>
> - err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> - "feature-discard", "%d", &discard,
> - NULL);
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "feature-discard", "%d", &discard);
>
> - if (!err && discard)
> + if (err > 0 && discard)
> blkfront_setup_discard(info);
>
> - err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> - "feature-persistent", "%u", &persistent,
> - NULL);
> - if (err)
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "feature-persistent", "%d", &persistent);
> + if (err <= 0)
> info->feature_persistent = 0;
> else
> info->feature_persistent = persistent;
>
^ permalink raw reply
* Re: linux-next: build warning after merge of the tip tree
From: Mark Brown @ 2016-07-25 16:42 UTC (permalink / raw)
To: Rich Felker
Cc: Daniel Lezcano, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Marc Zyngier
In-Reply-To: <20160725145337.GT15995@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
On Mon, Jul 25, 2016 at 10:53:37AM -0400, Rich Felker wrote:
> On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> > I don't know the goal of adding those patches in linux-next via your
> > tree, may be you misunderstood how linux-next works and you should
> > remove them. But if the purpose was to merge the patches, I remind you
> > that being an arch maintainer does not give you the right to apply any
> > patches, everywhere, at all cost, without review, because you want them
> > in, you must follow the process, otherwise you take the risk to upset a
> > lot of people and to be kicked out.
> If this is upsetting people I can remove them. Last time I got
> feedback from at least one (driver) subsystem maintainer that (if I
> understood it correctly) indicated they would like to have seen the
> patch in linux-next without problems before upstreaming it through
I think that was me and you've very much misunderstood what I was
saying. A that time you were sending new drivers during the merge
window with the apparent expectation that they would be merged during
that merge window. That's not going to happen, things need to go into
-next before the merge window. This means that you need to submit your
patches well in advance of the merge window so they can be reviewed and
ideally applied to maintainer trees before the merge window opens.
It does not mean that you should include unreviewed code for other trees
in your -next tree, that's not the purpose of -next. What goes into
-next from each maintainer tree should be what is currently intended to
go to Linus for that tree in the next merge window.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Jul 25 (drm/udl without CONFIG_FB)
From: Randy Dunlap @ 2016-07-25 16:32 UTC (permalink / raw)
To: Stephen Rothwell, linux-next; +Cc: linux-kernel, dri-devel, Dave Airlie
In-Reply-To: <20160725161748.61523c10@canb.auug.org.au>
On 07/24/16 23:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160724:
>
on i386, when CONFIG_FB is not enabled:
../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_open':
../drivers/gpu/drm/udl/udl_fb.c:206:23: error: 'struct fb_info' has no member named 'fbdefio'
if (fb_defio && (info->fbdefio == NULL)) {
^
../drivers/gpu/drm/udl/udl_fb.c:211:28: error: invalid application of 'sizeof' to incomplete type 'struct fb_deferred_io'
fbdefio = kmalloc(sizeof(struct fb_deferred_io), GFP_KERNEL);
^
../drivers/gpu/drm/udl/udl_fb.c:214:11: error: dereferencing pointer to incomplete type
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
^
../drivers/gpu/drm/udl/udl_fb.c:215:11: error: dereferencing pointer to incomplete type
fbdefio->deferred_io = drm_fb_helper_deferred_io;
^
../drivers/gpu/drm/udl/udl_fb.c:218:7: error: 'struct fb_info' has no member named 'fbdefio'
info->fbdefio = fbdefio;
^
../drivers/gpu/drm/udl/udl_fb.c: In function 'udl_fb_release':
../drivers/gpu/drm/udl/udl_fb.c:238:38: error: 'struct fb_info' has no member named 'fbdefio'
if ((ufbdev->fb_count == 0) && (info->fbdefio)) {
^
../drivers/gpu/drm/udl/udl_fb.c:240:13: error: 'struct fb_info' has no member named 'fbdefio'
kfree(info->fbdefio);
^
../drivers/gpu/drm/udl/udl_fb.c:241:7: error: 'struct fb_info' has no member named 'fbdefio'
info->fbdefio = NULL;
^
--
~Randy
^ permalink raw reply
* Re: linux-next: build warning after merge of the tip tree
From: Rich Felker @ 2016-07-25 14:53 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Mark Brown,
Marc Zyngier
In-Reply-To: <57961014.7030902@linaro.org>
On Mon, Jul 25, 2016 at 03:11:48PM +0200, Daniel Lezcano wrote:
> On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> > On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> >> produced this warning:
> >>
> >> In file included from include/linux/clocksource.h:18:0,
> >> from include/linux/clockchips.h:13,
> >> from drivers/clocksource/jcore-pit.c:14:
> >> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> >> .data = (fn == (fn_type)NULL) ? fn : fn }
> >> ^
> >> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> >> _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> >> ^
> >> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> >> OF_DECLARE_1_RET(clksrc, name, compat, fn)
> >> ^
> >> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> >> CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> >> ^
> >>
> >> Introduced by commits
> >>
> >> b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> >> 177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> >>
> >> interacting with commit
> >>
> >> e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> >>
> >> from the sh tree.
> >
> > And why is that driver coming through the superh tree and not through the
> > clocksource maintainers? It's not only based on an old interface it's probably
> > unreviewed as well ...
>
> Rich,
>
> why are these changes in linux-next ?
>
> Except I am missing something, I don't see a new version sent for review
> on the mailing list. The interrupt controller driver is almost empty as
> stated by Marc Zyngier and there is no explanation / discussion about it.
>
> I don't know the goal of adding those patches in linux-next via your
> tree, may be you misunderstood how linux-next works and you should
> remove them. But if the purpose was to merge the patches, I remind you
> that being an arch maintainer does not give you the right to apply any
> patches, everywhere, at all cost, without review, because you want them
> in, you must follow the process, otherwise you take the risk to upset a
> lot of people and to be kicked out.
If this is upsetting people I can remove them. Last time I got
feedback from at least one (driver) subsystem maintainer that (if I
understood it correctly) indicated they would like to have seen the
patch in linux-next without problems before upstreaming it through
their tree. That was my motivation for including it here. I'm not
trying to bypass other maintainers to push patches upstream and I can
remove all non-arch/sh stuff from for-next if that would be better.
Rich
^ permalink raw reply
* Re: linux-next: build warning after merge of the tip tree
From: Rich Felker @ 2016-07-25 14:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Stephen Rothwell, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Daniel Lezcano
In-Reply-To: <alpine.DEB.2.11.1607250915160.5629@nanos>
On Mon, Jul 25, 2016 at 09:16:48AM +0200, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> >
> > In file included from include/linux/clocksource.h:18:0,
> > from include/linux/clockchips.h:13,
> > from drivers/clocksource/jcore-pit.c:14:
> > include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
> > .data = (fn == (fn_type)NULL) ? fn : fn }
> > ^
> > include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
> > _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
> > ^
> > include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
> > OF_DECLARE_1_RET(clksrc, name, compat, fn)
> > ^
> > drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
> > CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> > ^
> >
> > Introduced by commits
> >
> > b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
> > 177cf6e52b0a ("clocksources: Switch back to the clksrc table")
> >
> > interacting with commit
> >
> > e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> >
> > from the sh tree.
>
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...
Drivers will go upstream through their proper subsystem maintainers,
not from my tree, but last time I got feedback that these drivers had
not seen any testing in linux-next. I can refrain from including
patches that I can't upstream directly in my for-next branch in the
future if you'd prefer but this way seemed to make less work for
others.
Rich
^ permalink raw reply
* Re: linux-next: manual merge of the pwm tree with the regulator tree
From: Thierry Reding @ 2016-07-25 14:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Stephen Rothwell, Mark Brown, Liam Girdwood,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Boris Brezillon, Alexandre Courbot
In-Reply-To: <CAD=FV=Ufs+NBgSmMeJNUwGUnJZOC1Tvpt6PvSCQLAkxxLULhUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4109 bytes --]
On Mon, Jul 25, 2016 at 06:29:00AM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 1:29 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Jul 11, 2016 at 11:39:00PM +0200, Thierry Reding wrote:
> >> On Mon, Jul 11, 2016 at 11:30:59PM +0200, Thierry Reding wrote:
> >> > On Mon, Jul 11, 2016 at 09:47:34AM -0700, Doug Anderson wrote:
> >> > > Hi,
> >> > >
> >> > > On Sun, Jul 10, 2016 at 11:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> > > > Hi Thierry,
> >> > > >
> >> > > > Today's linux-next merge of the pwm tree got a conflict in:
> >> > > >
> >> > > > drivers/regulator/pwm-regulator.c
> >> > > >
> >> > > > between commit:
> >> > > >
> >> > > > 830583004e61 ("regulator: pwm: Drop unneeded pwm_enable() call")
> >> > > > 27bfa8893b15 ("regulator: pwm: Support for enable GPIO")
> >> > > > c2588393e631 ("regulator: pwm: Fix regulator ramp delay for continuous mode")
> >> > > >
> >> > > > from the regulator tree and commit:
> >> > > >
> >> > > > b0303deaa480 ("regulator: pwm: Adjust PWM config at probe time")
> >> > > > 8bd57ca236d0 ("regulator: pwm: Switch to the atomic PWM API")
> >> > > > 25d16595935b ("regulator: pwm: Retrieve correct voltage")
> >> > > > 53f239af4c14 ("regulator: pwm: Support extra continuous mode cases")
> >> > > >
> >> > > > from the pwm tree.
> >> > > >
> >> > > > I fixed it up (I think, please check - see below) and can carry the fix
> >> > > > as necessary. This is now fixed as far as linux-next is concerned, but
> >> > > > any non trivial conflicts should be mentioned to your upstream maintainer
> >> > > > when your tree is submitted for merging. You may also want to consider
> >> > > > cooperating with the maintainer of the conflicting tree to minimise any
> >> > > > particularly complex conflicts.
> >> > > >
> >> > > > --
> >> > > > Cheers,
> >> > > > Stephen Rothwell
> >> > >
> >> > > [ cut ]
> >> > >
> >> > > > - /* Delay required by PWM regulator to settle to the new voltage */
> >> > > > - usleep_range(ramp_delay, ramp_delay + 1000);
> >> > > > + /* Ramp delay is in uV/uS. Adjust to uS and delay */
> >> > > > + ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
> >> > >
> >> > > This was what I was worried about and why I originally sent my patch
> >> > > based upon Boris's series. The above should be:
> >> > >
> >> > > ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
> >> > >
> >> > > Specifically note the use of "req_min_uV" and not "min_uV".
> >> >
> >> > Okay, so this is something that needs to be fixed up in one of Boris'
> >> > patches? Can you help point out where exactly? The conflict should be
> >> > gone as of tomorrow's linux-next.
> >>
> >> Looks like the below should be squashed into commit:
> >>
> >> 4585082afab4 regulator: pwm: Support extra continuous mode cases
> >>
> >> Can you confirm?
> >>
> >> Thierry
> >>
> >> --- >8 ---
> >> diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
> >> index 263a2d16d909..c24524242da2 100644
> >> --- a/drivers/regulator/pwm-regulator.c
> >> +++ b/drivers/regulator/pwm-regulator.c
> >> @@ -237,7 +237,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
> >> return 0;
> >>
> >> /* Ramp delay is in uV/uS. Adjust to uS and delay */
> >> - ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
> >> + ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
> >> usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
> >>
> >> return 0;
> >
> > Doug? Can you confirm?
>
> Yes, right. Sorry, previous email got lost in the shuffle since I was
> on vacation.
>
> Right, commit 4585082afab4 ("regulator: pwm: Support extra continuous
> mode cases") is the one that renamed the parameters and so this use of
> one of the parameters needs to be part of that commit.
Squashed it into the above commit and pushed everything out.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the pwm tree with the regulator tree
From: Doug Anderson @ 2016-07-25 13:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Rothwell, Mark Brown, Liam Girdwood,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Boris Brezillon, Alexandre Courbot
In-Reply-To: <20160725082906.GA4667@ulmo.ba.sec>
Hi,
On Mon, Jul 25, 2016 at 1:29 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Jul 11, 2016 at 11:39:00PM +0200, Thierry Reding wrote:
>> On Mon, Jul 11, 2016 at 11:30:59PM +0200, Thierry Reding wrote:
>> > On Mon, Jul 11, 2016 at 09:47:34AM -0700, Doug Anderson wrote:
>> > > Hi,
>> > >
>> > > On Sun, Jul 10, 2016 at 11:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > > > Hi Thierry,
>> > > >
>> > > > Today's linux-next merge of the pwm tree got a conflict in:
>> > > >
>> > > > drivers/regulator/pwm-regulator.c
>> > > >
>> > > > between commit:
>> > > >
>> > > > 830583004e61 ("regulator: pwm: Drop unneeded pwm_enable() call")
>> > > > 27bfa8893b15 ("regulator: pwm: Support for enable GPIO")
>> > > > c2588393e631 ("regulator: pwm: Fix regulator ramp delay for continuous mode")
>> > > >
>> > > > from the regulator tree and commit:
>> > > >
>> > > > b0303deaa480 ("regulator: pwm: Adjust PWM config at probe time")
>> > > > 8bd57ca236d0 ("regulator: pwm: Switch to the atomic PWM API")
>> > > > 25d16595935b ("regulator: pwm: Retrieve correct voltage")
>> > > > 53f239af4c14 ("regulator: pwm: Support extra continuous mode cases")
>> > > >
>> > > > from the pwm tree.
>> > > >
>> > > > I fixed it up (I think, please check - see below) and can carry the fix
>> > > > as necessary. This is now fixed as far as linux-next is concerned, but
>> > > > any non trivial conflicts should be mentioned to your upstream maintainer
>> > > > when your tree is submitted for merging. You may also want to consider
>> > > > cooperating with the maintainer of the conflicting tree to minimise any
>> > > > particularly complex conflicts.
>> > > >
>> > > > --
>> > > > Cheers,
>> > > > Stephen Rothwell
>> > >
>> > > [ cut ]
>> > >
>> > > > - /* Delay required by PWM regulator to settle to the new voltage */
>> > > > - usleep_range(ramp_delay, ramp_delay + 1000);
>> > > > + /* Ramp delay is in uV/uS. Adjust to uS and delay */
>> > > > + ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
>> > >
>> > > This was what I was worried about and why I originally sent my patch
>> > > based upon Boris's series. The above should be:
>> > >
>> > > ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
>> > >
>> > > Specifically note the use of "req_min_uV" and not "min_uV".
>> >
>> > Okay, so this is something that needs to be fixed up in one of Boris'
>> > patches? Can you help point out where exactly? The conflict should be
>> > gone as of tomorrow's linux-next.
>>
>> Looks like the below should be squashed into commit:
>>
>> 4585082afab4 regulator: pwm: Support extra continuous mode cases
>>
>> Can you confirm?
>>
>> Thierry
>>
>> --- >8 ---
>> diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
>> index 263a2d16d909..c24524242da2 100644
>> --- a/drivers/regulator/pwm-regulator.c
>> +++ b/drivers/regulator/pwm-regulator.c
>> @@ -237,7 +237,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
>> return 0;
>>
>> /* Ramp delay is in uV/uS. Adjust to uS and delay */
>> - ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
>> + ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
>> usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
>>
>> return 0;
>
> Doug? Can you confirm?
Yes, right. Sorry, previous email got lost in the shuffle since I was
on vacation.
Right, commit 4585082afab4 ("regulator: pwm: Support extra continuous
mode cases") is the one that renamed the parameters and so this use of
one of the parameters needs to be part of that commit.
Thanks!
-Doug
^ permalink raw reply
* Re: linux-next: build warning after merge of the tip tree
From: Daniel Lezcano @ 2016-07-25 13:11 UTC (permalink / raw)
To: Stephen Rothwell, Rich Felker
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Mark Brown, Marc Zyngier
In-Reply-To: <alpine.DEB.2.11.1607250915160.5629@nanos>
On 07/25/2016 09:16 AM, Thomas Gleixner wrote:
> On Sun, 24 Jul 2016, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> produced this warning:
>>
>> In file included from include/linux/clocksource.h:18:0,
>> from include/linux/clockchips.h:13,
>> from drivers/clocksource/jcore-pit.c:14:
>> include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
>> .data = (fn == (fn_type)NULL) ? fn : fn }
>> ^
>> include/linux/of.h:1020:3: note: in expansion of macro '_OF_DECLARE'
>> _OF_DECLARE(table, name, compat, fn, of_init_fn_1_ret)
>> ^
>> include/linux/clocksource.h:247:2: note: in expansion of macro 'OF_DECLARE_1_RET'
>> OF_DECLARE_1_RET(clksrc, name, compat, fn)
>> ^
>> drivers/clocksource/jcore-pit.c:277:1: note: in expansion of macro 'CLOCKSOURCE_OF_DECLARE'
>> CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
>> ^
>>
>> Introduced by commits
>>
>> b7c4db861683 ("clocksource/drivers/clksrc-probe: Introduce init functions with return code")
>> 177cf6e52b0a ("clocksources: Switch back to the clksrc table")
>>
>> interacting with commit
>>
>> e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
>>
>> from the sh tree.
>
> And why is that driver coming through the superh tree and not through the
> clocksource maintainers? It's not only based on an old interface it's probably
> unreviewed as well ...
Rich,
why are these changes in linux-next ?
Except I am missing something, I don't see a new version sent for review
on the mailing list. The interrupt controller driver is almost empty as
stated by Marc Zyngier and there is no explanation / discussion about it.
I don't know the goal of adding those patches in linux-next via your
tree, may be you misunderstood how linux-next works and you should
remove them. But if the purpose was to merge the patches, I remind you
that being an arch maintainer does not give you the right to apply any
patches, everywhere, at all cost, without review, because you want them
in, you must follow the process, otherwise you take the risk to upset a
lot of people and to be kicked out.
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-25 12:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Josh Poimboeuf, Andy Lutomirski, Arnaldo Carvalho de Melo,
Peter Zijlstra, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20160723150845.3af8e452@canb.auug.org.au>
Em Sat, Jul 23, 2016 at 03:08:45PM +1000, Stephen Rothwell escreveu:
> On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > I applied your patch and will push it to Ingo, now we must cross our
> > fingers so that Stephen doesn't come back to us once more telling it is
> > still broken :o)
> Unfortunately, this is what I get when I just build perf/core:
> DESCEND objtool
> CC /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
Cool! objtool is fixed, we're not at a different tool using those
headers, and your patch fixes it, I see Andy acked it, I'll merge this
and push to Ingo,
Thanks,
- Arnaldo
> LD /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o
> Warning: objtool: x86 instruction decoder differs from kernel
> LINK /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool
> In file included from /home/sfr/next/next/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
> from /home/sfr/next/next/include/uapi/asm-generic/int-ll64.h:11,
> from /home/sfr/next/next/include/uapi/asm-generic/types.h:6,
> from /home/sfr/next/next/arch/x86/include/uapi/asm/types.h:4,
> from /home/sfr/next/next/tools/include/linux/types.h:9,
> from /home/sfr/next/next/include/uapi/linux/elf.h:4,
> from /home/sfr/next/next/arch/x86/entry/vdso/vdso2c.c:66:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
> #error Inconsistent word size. Check asm/bitsperlong.h
> ^
>
> The be clear: this is a ppc64le hosted, x86_64 target cross build.
>
> I than added the following patch, and the build finishes successfully.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 23 Jul 2016 14:35:40 +1000
> Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
> headers
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/x86/entry/vdso/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 253b72eaade6..25e88c030c47 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -55,7 +55,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
> $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
> $(call if_changed,vdso)
>
> -HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
> +HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi
> hostprogs-y += vdso2c
>
> quiet_cmd_vdso2c = VDSO2C $@
> --
> 2.8.1
>
> There may be a more correct way to do this ...
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the i2c tree
From: Andy Shevchenko @ 2016-07-25 12:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rafael J. Wysocki, Stephen Rothwell, linux-next,
linux-kernel@vger.kernel.org, Octavian Purdila, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg
In-Reply-To: <20160719034806.GA1640@katana>
On Tue, Jul 19, 2016 at 6:48 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > Well, not knowing much about ACPI, I just need the conflict resolution
>> > for my latest i2c/for-next and your above branch. If you want to do it,
>> > fine with me. But maybe Jarkko will be back to office on Monday, too.
>>
>> Unfortunately, I don't see how these branches can be merged in a sensible
>> way without adding too much new code into the merge itself.
>>
>> Something needs to be dropped and then rebased and applied again.
>
> Okay, I'll drop the I2C parts. Next to the core parts which I will drop,
> there was also a driver patch making use of the core changes for which I
> requested some updates. Since those did not happen yet (Jarkko on
> holiday?), the core patches alone are not important anyhow.
Jarkko and Mika are on holidays, I recently noticed this thread,
sorry. For now your solution seems okay, since we can't push broken
parts into v4.8-rc1.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: linux-next: the merge window has opened
From: Stephen Rothwell @ 2016-07-25 10:22 UTC (permalink / raw)
To: linux-next; +Cc: LKML
In-Reply-To: <20160725164148.4d79e928@canb.auug.org.au>
Hi all,
On Mon, 25 Jul 2016 16:41:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Please do not add material destined for v4.9 to your linux-next included
> branches until after v8.1-rc1 has been released.
^^^
4.8
I wonder where my wind has wandered off to :-)
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* next-20160725 build: 0 failures 6 warnings (next-20160725)
From: Build bot for Mark Brown @ 2016-07-25 10:09 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20160725
Git describe: next-20160725
Commit: f7d63d9920 Add linux-next specific files for 20160725
Build Time: 88 min 40 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 6
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
4 warnings 0 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
2 warnings 0 mismatches : x86_64-defconfig
6 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 6
6 ../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
6 ../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
2 ../include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
2 ../include/linux/dynamic_debug.h:134:3: warning: 'carrier_offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/tty/serial/8250/8250_fintek.c:34:0: warning: "IRQ_MODE" redefined
1 ../drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
../include/linux/dynamic_debug.h:134:3: warning: 'carrier_offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../include/linux/of.h:1004:20: warning: comparison of distinct pointer types lacks a cast
../drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used uninitialized in this function [-Wmaybe-uninitialized]
../include/linux/dynamic_debug.h:134:3: warning: 'carrier_offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/tty/serial/8250/8250_fintek.c:34:0: warning: "IRQ_MODE" redefined
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
../drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
^ permalink raw reply
* Re: linux-next: manual merge of the pwm tree with the regulator tree
From: Thierry Reding @ 2016-07-25 8:29 UTC (permalink / raw)
To: Doug Anderson
Cc: Stephen Rothwell, Mark Brown, Liam Girdwood,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Boris Brezillon, Alexandre Courbot
In-Reply-To: <20160711213900.GA12942@ulmo.ba.sec>
[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]
On Mon, Jul 11, 2016 at 11:39:00PM +0200, Thierry Reding wrote:
> On Mon, Jul 11, 2016 at 11:30:59PM +0200, Thierry Reding wrote:
> > On Mon, Jul 11, 2016 at 09:47:34AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Sun, Jul 10, 2016 at 11:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > Hi Thierry,
> > > >
> > > > Today's linux-next merge of the pwm tree got a conflict in:
> > > >
> > > > drivers/regulator/pwm-regulator.c
> > > >
> > > > between commit:
> > > >
> > > > 830583004e61 ("regulator: pwm: Drop unneeded pwm_enable() call")
> > > > 27bfa8893b15 ("regulator: pwm: Support for enable GPIO")
> > > > c2588393e631 ("regulator: pwm: Fix regulator ramp delay for continuous mode")
> > > >
> > > > from the regulator tree and commit:
> > > >
> > > > b0303deaa480 ("regulator: pwm: Adjust PWM config at probe time")
> > > > 8bd57ca236d0 ("regulator: pwm: Switch to the atomic PWM API")
> > > > 25d16595935b ("regulator: pwm: Retrieve correct voltage")
> > > > 53f239af4c14 ("regulator: pwm: Support extra continuous mode cases")
> > > >
> > > > from the pwm tree.
> > > >
> > > > I fixed it up (I think, please check - see below) and can carry the fix
> > > > as necessary. This is now fixed as far as linux-next is concerned, but
> > > > any non trivial conflicts should be mentioned to your upstream maintainer
> > > > when your tree is submitted for merging. You may also want to consider
> > > > cooperating with the maintainer of the conflicting tree to minimise any
> > > > particularly complex conflicts.
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> > >
> > > [ cut ]
> > >
> > > > - /* Delay required by PWM regulator to settle to the new voltage */
> > > > - usleep_range(ramp_delay, ramp_delay + 1000);
> > > > + /* Ramp delay is in uV/uS. Adjust to uS and delay */
> > > > + ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
> > >
> > > This was what I was worried about and why I originally sent my patch
> > > based upon Boris's series. The above should be:
> > >
> > > ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
> > >
> > > Specifically note the use of "req_min_uV" and not "min_uV".
> >
> > Okay, so this is something that needs to be fixed up in one of Boris'
> > patches? Can you help point out where exactly? The conflict should be
> > gone as of tomorrow's linux-next.
>
> Looks like the below should be squashed into commit:
>
> 4585082afab4 regulator: pwm: Support extra continuous mode cases
>
> Can you confirm?
>
> Thierry
>
> --- >8 ---
> diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
> index 263a2d16d909..c24524242da2 100644
> --- a/drivers/regulator/pwm-regulator.c
> +++ b/drivers/regulator/pwm-regulator.c
> @@ -237,7 +237,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
> return 0;
>
> /* Ramp delay is in uV/uS. Adjust to uS and delay */
> - ramp_delay = DIV_ROUND_UP(abs(min_uV - old_uV), ramp_delay);
> + ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
> usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
>
> return 0;
Doug? Can you confirm?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the vfs tree with the overlayfs tree
From: Miklos Szeredi @ 2016-07-25 8:09 UTC (permalink / raw)
To: Al Viro; +Cc: Stephen Rothwell, linux-next, linux-kernel, Miklos Szeredi
In-Reply-To: <20160725003028.GQ2356@ZenIV.linux.org.uk>
On Mon, Jul 25, 2016 at 2:30 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Jul 25, 2016 at 10:24:53AM +1000, Stephen Rothwell wrote:
>> Hi Al,
>>
>> Today's linux-next merge of the vfs tree got a conflict in:
>>
>> fs/overlayfs/super.c
>>
>> between commit:
>>
>> e2475b7276d0 ("ovl: check mounter creds on underlying lookup")
>>
>> from the overlayfs tree and commit:
>>
>> b3ac9a85b31c ("qstr: constify instances in overlayfs")
>>
>> from the vfs tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>
> FWIW, if Miklos could pick that one-liner into overlayfs tree, I'd be only
> happy to drop it from that queue.
OK, picked that one.
Thanks,
Miklos
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox