Re: [PATCH] md: don't use flush_signals in userspace processes
On Wed, Jun 07 2017, Mikulas Patocka wrote:
> The function flush_signals clears all pending signals for the process. It
> may be used by kernel threads when we need to prepare a kernel thread for
> responding to signals. However using this function for an userspaces
> processes is incorrect - clearing signals without the program expecting it
> can cause misbehavior.
>
> The raid1 and raid5 code uses flush_signals in its request routine because
> it wants to prepare for an interruptible wait. This patch drops
> flush_signals and uses sigprocmask instead to block all signals (including
> SIGKILL) around the schedule() call. The signals are not lost, but the
> schedule() call won't respond to them.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org
Thanks for catching that!
Acked-by: NeilBrown
NeilBrown
>
> ---
> drivers/md/raid1.c |5 -
> drivers/md/raid5.c |5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> Index: linux-4.12-rc4/drivers/md/raid1.c
> ===
> --- linux-4.12-rc4.orig/drivers/md/raid1.c
> +++ linux-4.12-rc4/drivers/md/raid1.c
> @@ -1335,7 +1335,7 @@ static void raid1_write_request(struct m
>*/
> DEFINE_WAIT(w);
> for (;;) {
> - flush_signals(current);
> + sigset_t full, old;
> prepare_to_wait(&conf->wait_barrier,
> &w, TASK_INTERRUPTIBLE);
> if (bio_end_sector(bio) <= mddev->suspend_lo ||
> @@ -1345,7 +1345,10 @@ static void raid1_write_request(struct m
>bio->bi_iter.bi_sector,
>bio_end_sector(bio
> break;
> + sigfillset(&full);
> + sigprocmask(SIG_BLOCK, &full, &old);
> schedule();
> + sigprocmask(SIG_SETMASK, &old, NULL);
> }
> finish_wait(&conf->wait_barrier, &w);
> }
> Index: linux-4.12-rc4/drivers/md/raid5.c
> ===
> --- linux-4.12-rc4.orig/drivers/md/raid5.c
> +++ linux-4.12-rc4/drivers/md/raid5.c
> @@ -5693,12 +5693,15 @@ static void raid5_make_request(struct md
>* userspace, we want an interruptible
>* wait.
>*/
> - flush_signals(current);
> prepare_to_wait(&conf->wait_for_overlap,
> &w, TASK_INTERRUPTIBLE);
> if (logical_sector >= mddev->suspend_lo &&
> logical_sector < mddev->suspend_hi) {
> + sigset_t full, old;
> + sigfillset(&full);
> + sigprocmask(SIG_BLOCK, &full, &old);
> schedule();
> + sigprocmask(SIG_SETMASK, &old, NULL);
> do_prepare = true;
> }
> goto retry;
signature.asc
Description: PGP signature
Re: [PATCH 7/8] blk-mq: create hctx for each present CPU
On Wed, Jun 07, 2017 at 03:04:11PM -0700, Omar Sandoval wrote: > On Sat, Jun 03, 2017 at 04:04:02PM +0200, Christoph Hellwig wrote: > > Currently we only create hctx for online CPUs, which can lead to a lot > > of churn due to frequent soft offline / online operations. Instead > > allocate one for each present CPU to avoid this and dramatically simplify > > the code. > > > > Signed-off-by: Christoph Hellwig > > Oh man, this cleanup is great. Did you run blktests on this? block/008 > does a bunch of hotplugging while I/O is running. I haven't run blktests yet, in fact when I did the work blktests didn't exist yet. But thanks for the reminder, I'll run it now.
Re: [PATCH v2] refcount: Create unchecked atomic_t implementation
On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote: > Many subsystems will not use refcount_t unless there is a way to build the > kernel so that there is no regression in speed compared to atomic_t. This > adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation > which has the validation but is slightly slower. When not enabled, > refcount_t uses the basic unchecked atomic_t routines, which results in > no code changes compared to just using atomic_t directly. > > Signed-off-by: Kees Cook > --- > This is v2 of this patch, which I've split from the arch-specific > alternative implementation for x86. Getting this patch in will unblock > atomic_t -> refcount_t conversion, and the x86 alternative implementation > can be developed in parallel. Changes from v1: use better atomic ops, > thanks to Elena and Peter. Yeah, can we get this in ASAP? Without having to always incur the over this will allow us to convert subsystems to refcount_t broadly.
Re: [PATCH] Fix loop device flush before configure
On Thu, Jun 08, 2017 at 08:45:31AM +0800, James Wang wrote: > Ok I got it blktests is a suite. I'd like to contribute something. If you > need, we adapt you,;-)! > But I have to learn some how to do that, need time. I haven't added test myself to blktests yet either, so I'd have to learn it as well. Omar can probably help you though.
Re: [RFC][PATCH 5/5] powerpc: Remove SYNC from _switch
On Thu, Jun 08, 2017 at 10:32:44AM +1000, Nicholas Piggin wrote: > On Wed, 07 Jun 2017 18:15:06 +0200 > Peter Zijlstra wrote: > > > Now that the scheduler's rq->lock is RCsc and thus provides full > > transitivity between scheduling actions. And since we cannot migrate > > current, a task needs a switch-out and a switch-in in order to > > migrate, in which case the RCsc provides all the ordering we need. > > Hi Peter, > > I'm actually just working on removing this right now too, so > good timing. > > I think we can't "just" remove it, because it is required to order > MMIO on powerpc as well. How is MMIO special? That is, there is only MMIO before we call into schedule() right? So the rq->lock should be sufficient to order that too. > > But what I have done is to comment that some other primitives are > already providing the hwsync for other, so we don't have to add > another one in _switch. Right, so this patch relies on the smp_mb__before_spinlock -> smp_mb__after_spinlock conversion that makes the rq->lock RCsc and should thus provide the required SYNC for migrations. That said, I think you can already use the smp_mb__before_spinlock() as that is done with IRQs disabled, but its a more difficult argument. The rq->lock RCsc property should be more obvious.
[PATCH] Fix loop device flush before configure v3
While installing SLES-12 (based on v4.4), I found that the installer
will stall for 60+ seconds during LVM disk scan. The root cause was
determined to be the removal of a bound device check in loop_flush()
by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
Restoring this check, examining ->lo_state as set by loop_set_fd()
eliminates the bad behavior.
Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K
for((i=0;i<4;i++))do losetup -f disk; done
mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
for f in `ls /dev/loop[0-9]*|sort`; do \
echo $f; dd if=$f of=/dev/null bs=512 count=1; \
done
Test output: stock patched
/dev/loop018.1217e-058.3842e-05
/dev/loop1 6.1114e-050.000147979
/dev/loop100.414701 0.000116564
/dev/loop110.74746.7942e-05
/dev/loop120.747986 8.9082e-05
/dev/loop130.746532 7.4799e-05
/dev/loop140.480041 9.3926e-05
/dev/loop151.26453 7.2522e-05
Note that from loop10 onward, the device is not mounted, yet the
stock kernel consumes several orders of magnitude more wall time
than it does for a mounted device.
(Thanks for Mike Galbraith , give a changelog review.)
Reviewed-by: Hannes Reinecke
Reviewed-by: Ming Lei
Signed-off-by: James Wang
Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
---
drivers/block/loop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 48f6fa6f810e..2e5b8538760c 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -625,6 +625,9 @@ static int loop_switch(struct loop_device *lo, struct file
*file)
*/
static int loop_flush(struct loop_device *lo)
{
+ /* loop not yet configured, no running thread, nothing to flush */
+ if (lo->lo_state != Lo_bound)
+ return 0;
return loop_switch(lo, NULL);
}
--
2.12.3
Re: [PATCH 2/4] KVM: VMX: avoid double list add with VT-d posted interrupts
On Thu, Jun 08, 2017 at 02:50:57PM +0800, Peter Xu wrote:
> On Tue, Jun 06, 2017 at 12:57:05PM +0200, Paolo Bonzini wrote:
> > In some cases, for example involving hot-unplug of assigned
> > devices, pi_post_block can forget to remove the vCPU from the
> > blocked_vcpu_list. When this happens, the next call to
> > pi_pre_block corrupts the list.
> >
> > Fix this in two ways. First, check vcpu->pre_pcpu in pi_pre_block
> > and WARN instead of adding the element twice in the list. Second,
> > always do the list removal in pi_post_block if vcpu->pre_pcpu is
> > set (not -1).
> >
> > The new code keeps interrupts disabled for the whole duration of
> > pi_pre_block/pi_post_block. This is not strictly necessary, but
> > easier to follow. For the same reason, PI.ON is checked only
> > after the cmpxchg, and to handle it we just call the post-block
> > code. This removes duplication of the list removal code.
> >
> > Cc: Longpeng (Mike)
> > Cc: Huangweidong
> > Cc: Gonglei
> > Cc: wangxin
> > Cc: Radim Krčmář
> > Signed-off-by: Paolo Bonzini
> > ---
> > arch/x86/kvm/vmx.c | 62
> > ++
> > 1 file changed, 25 insertions(+), 37 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index 747d16525b45..0f4714fe4908 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -11236,10 +11236,11 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> > struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > struct pi_desc old, new;
> > unsigned int dest;
> > - unsigned long flags;
> >
> > do {
> > old.control = new.control = pi_desc->control;
> > + WARN(old.nv != POSTED_INTR_WAKEUP_VECTOR,
> > +"Wakeup handler not enabled while the VCPU is blocked\n");
> >
> > dest = cpu_physical_id(vcpu->cpu);
> >
> > @@ -11256,14 +11257,10 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> > } while (cmpxchg(&pi_desc->control, old.control,
> > new.control) != old.control);
> >
> > - if(vcpu->pre_pcpu != -1) {
> > - spin_lock_irqsave(
> > - &per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > + if (!WARN_ON_ONCE(vcpu->pre_pcpu == -1)) {
> > + spin_lock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> > list_del(&vcpu->blocked_vcpu_list);
> > - spin_unlock_irqrestore(
> > - &per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > + spin_unlock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> > vcpu->pre_pcpu = -1;
> > }
> > }
> > @@ -11283,7 +11280,6 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> > */
> > static int pi_pre_block(struct kvm_vcpu *vcpu)
> > {
> > - unsigned long flags;
> > unsigned int dest;
> > struct pi_desc old, new;
> > struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > @@ -11293,34 +11289,20 @@ static int pi_pre_block(struct kvm_vcpu *vcpu)
> > !kvm_vcpu_apicv_active(vcpu))
> > return 0;
> >
> > - vcpu->pre_pcpu = vcpu->cpu;
> > - spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > - list_add_tail(&vcpu->blocked_vcpu_list,
> > - &per_cpu(blocked_vcpu_on_cpu,
> > - vcpu->pre_pcpu));
> > - spin_unlock_irqrestore(&per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > + WARN_ON(irqs_disabled());
> > + local_irq_disable();
> > + if (!WARN_ON_ONCE(vcpu->pre_pcpu != -1)) {
> > + vcpu->pre_pcpu = vcpu->cpu;
> > + spin_lock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> > + list_add_tail(&vcpu->blocked_vcpu_list,
> > + &per_cpu(blocked_vcpu_on_cpu,
> > + vcpu->pre_pcpu));
> > + spin_unlock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> > + }
> >
> > do {
> > old.control = new.control = pi_desc->control;
> >
> > - /*
> > -* We should not block the vCPU if
> > -* an interrupt is posted for it.
> > -*/
> > - if (pi_test_on(pi_desc) == 1) {
> > - spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > - list_del(&vcpu->blocked_vcpu_list);
> > - spin_unlock_irqrestore(
> > - &per_cpu(blocked_vcpu_on_cpu_lock,
> > - vcpu->pre_pcpu), flags);
> > - vcpu->pre_pcpu = -1;
> > -
> > - return 1;
>
> [1]
>
> > - }
> > -
> > WARN((pi_desc->sn == 1),
> > "Warning: SN field of posted-interrupts "
> >
Re: [PATCH 46/58] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks
Le Wed, 7 Jun 2017 23:38:10 +0200,
Daniel Lezcano a écrit :
> On Wed, Jun 07, 2017 at 05:09:08PM +0200, Alexandre Belloni wrote:
> > On 07/06/2017 at 16:17:35 +0200, Daniel Lezcano wrote:
> > > > > > This driver uses regmap and syscon to be able to probe early in the
> > > > > > boot
> > > > > > and avoid having to switch on the TCB clocksource later. Using
> > > > > > regmap also
> > > > > > means that unused TCB channels may be used by other drivers (PWM for
> > > > > > example).
> > > > >
> > > > > Can you give more details, I fail to understand how regmap and syscon
> > > > > help to
> > > > > probe sooner than timer_init()?
> > > >
> > > >
> > > > Because before that, the tcb driver relied on atmel_tclib to share the
> > > > TCBs and it happened way too late, at arch_initcall() time.
> > >
> > > So is it still necesary to use regmap? I would like to take the
> > > opportunity to
> > > move the init routine to the common init routine if possible:
> > >
> > > https://patchwork.kernel.org/patch/9768845/
> > >
> >
> > It is still necessary because we want to be able to share the timer
> > between multiple drivers. For example, you can have the clocksource on
> > channel 0, clockevent on channel 1 and a pwm on channel 2
>
> The hardware timer can be shared, the channels used in different subsystem.
>
> Each channel are used exclusively.
Yes, that's correct, but some registers are shared, and we need locking
to control accesses to these registers. There's one register in
particular that has to be protected against concurrent accesses:
TC_BMR. But this register is only written at init time, not in the hot
path.
>
> What is the benefit of regmap? It has a cost, and takes a lock at each read.
>
> For instance:
>
> +static u64 tc_get_cycles(struct clocksource *cs)
> +{
> + u32 lower, upper, tmp;
> +
> + do {
> + regmap_read(tc.regmap, ATMEL_TC_CV(1), &upper);
> + regmap_read(tc.regmap, ATMEL_TC_CV(0), &lower);
> + regmap_read(tc.regmap, ATMEL_TC_CV(1), &tmp);
> + } while (upper != tmp);
> +
> + return (upper << 16) | lower;
> +}
>
> Is:
>
> +static u64 tc_get_cycles(struct clocksource *cs)
> +{
> + u32 lower, upper, tmp;
> +
> + do {
> + regmap_read(tc.regmap, ATMEL_TC_CV(1), &upper);
> lock();
> lot-of-things();
> unlock();
> + regmap_read(tc.regmap, ATMEL_TC_CV(0), &lower);
> lock();
> lot-of-things();
> unlock();
> + regmap_read(tc.regmap, ATMEL_TC_CV(1), &tmp);
> lock();
> lot-of-things();
> unlock();
> + } while (upper != tmp);
> +
> + return (upper << 16) | lower;
> +}
>
> I suggest to look what is in 'lot-of-things()' and especially what is doing
> regcache_read().
>
> May be you can reconsider the regmap? This driver is the only one use the
> regmap AFAICT and I don't think it is adequate.
Alexandre, maybe we could of_ioremap() the TCB region in this driver
and use regular readl to read TC_CV regs: those are attached to a
specific channel, so we shouldn't have concurrency issues here.
Re: [PATCH] external references for device tree overlays
On Wed, 2017-06-07 at 17:19 -0500, Rob Herring wrote:
> On Wed, Jun 7, 2017 at 3:11 AM, Pantelis Antoniou
> wrote:
> > Hi Stefani,
> >
> > On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > > Hi Pantelis,
> > >
> > > thanks for the suggestion. This feature is not very well
> > > documented. I
> > > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > > source is:
> > >
> > > // rapsi example
> > > /dts-v1/;
> > > /plugin/;
> > >
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > >
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <&{/soc/timer@7e003}>;
> > > };
> > > };
> > > };
> > >
> > >
> > > The resulting overlay is (decompiled with fdtdump):
> > >
> > > /dts-v1/;
> > > // magic: 0xd00dfeed
> > > // totalsize: 0x19a (410)
> > > // off_dt_struct: 0x38
> > > // off_dt_strings:0x148
> > > // off_mem_rsvmap:0x28
> > > // version: 17
> > > // last_comp_version: 16
> > > // boot_cpuid_phys: 0x0
> > > // size_dt_strings: 0x52
> > > // size_dt_struct:0x110
> > >
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <0xdeadbeef>;
> > > };
> > > };
> > > __fixups__ {
> > > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > > };
> > > };
> > >
> > > But this will not apply:
> > >
> > > OF: resolver: overlay phandle fixup failed: -22
> > > create_overlay: Failed to resolve tree
> > >
> > >
> >
> > Yes, it will not work as it is; my point is that you don't need the
> > magic __*__ node.
> >
> > You will need to modify the overlay application code to live insert
> > a
> > phandle (if it doesn't exist) when it encounters a /path fixup.
>
> phandles only exist if something in the base tree refers to that
> node.
> Adding them when they don't exist should definitely be something we
> support for overlays. But don't call that a broken DT. That would be
> a
> separate issue.
>
Believe me it is broken. Due a NDA i am not able to give you more
details about the vendor. But there forgot do provide an device node
which must refer to the attached network and interrupt controller.
- Stefani
Re: [PATCH 2/3] fs/locks: Remove fl_nspid
Hi Benjamin,
[auto build test WARNING on jlayton/linux-next]
[also build test WARNING on next-20170607]
[cannot apply to linus/master linux/master v4.12-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Benjamin-Coddington/fs-locks-Use-allocation-rather-than-the-stack-in-fcntl_getlk/20170608-015328
base: git://git.samba.org/jlayton/linux linux-next
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
fs/inode.c:1664: warning: No description found for parameter 'rcu'
>> fs/locks.c:2052: warning: No description found for parameter 'init_nr'
>> fs/locks.c:2052: warning: Excess function parameter 'nr' description in
>> 'locks_translate_pid'
>> fs/locks.c:2052: warning: No description found for parameter 'init_nr'
>> fs/locks.c:2052: warning: Excess function parameter 'nr' description in
>> 'locks_translate_pid'
include/linux/jbd2.h:442: warning: No description found for parameter
'i_transaction'
include/linux/jbd2.h:442: warning: No description found for parameter
'i_next_transaction'
include/linux/jbd2.h:442: warning: No description found for parameter
'i_list'
include/linux/jbd2.h:442: warning: No description found for parameter
'i_vfs_inode'
include/linux/jbd2.h:442: warning: No description found for parameter
'i_flags'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_rsv_handle'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_reserved'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_type'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_line_no'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_start_jiffies'
include/linux/jbd2.h:496: warning: No description found for parameter
'h_requested_credits'
include/linux/jbd2.h:496: warning: No description found for parameter
'saved_alloc_context'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_chkpt_bhs'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_devname'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_average_commit_time'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_min_batch_time'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_max_batch_time'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_commit_callback'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_failed_commit'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_chksum_driver'
include/linux/jbd2.h:1049: warning: No description found for parameter
'j_csum_seed'
fs/jbd2/transaction.c:434: warning: No description found for parameter
'rsv_blocks'
fs/jbd2/transaction.c:434: warning: No description found for parameter
'gfp_mask'
fs/jbd2/transaction.c:434: warning: No description found for parameter 'type'
fs/jbd2/transaction.c:434: warning: No description found for parameter
'line_no'
fs/jbd2/transaction.c:511: warning: No description found for parameter 'type'
fs/jbd2/transaction.c:511: warning: No description found for parameter
'line_no'
fs/jbd2/transaction.c:641: warning: No description found for parameter
'gfp_mask'
vim +/init_nr +2052 fs/locks.c
2036 {
2037 if (filp->f_op->lock && is_remote_lock(filp))
2038 return filp->f_op->lock(filp, F_GETLK, fl);
2039 posix_test_lock(filp, fl);
2040 return 0;
2041 }
2042 EXPORT_SYMBOL_GPL(vfs_test_lock);
2043
2044 /**
2045 * locks_translate_pid - translate a pid number into a namespace
2046 * @nr: The pid number in the init_pid_ns
2047 * @ns: The namespace into which the pid should be translated
2048 *
2049 * Used to tranlate a fl_pid into a namespace virtual pid number
2050 */
2051 static pid_t locks_translate_pid(int init_nr, struct pid_namespace *ns)
> 2052 {
2053 pid_t vnr = 0;
2054 struct task_struct *task;
2055
2056 rcu_read_lock();
2057 task = find_task_by_pid_ns(init_nr, &init_pid_ns);
2058 if (task)
2059 get_task_struct(task);
2060 rcu_read_unlock();
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 2/4] KVM: VMX: avoid double list add with VT-d posted interrupts
On Tue, Jun 06, 2017 at 12:57:05PM +0200, Paolo Bonzini wrote:
> In some cases, for example involving hot-unplug of assigned
> devices, pi_post_block can forget to remove the vCPU from the
> blocked_vcpu_list. When this happens, the next call to
> pi_pre_block corrupts the list.
>
> Fix this in two ways. First, check vcpu->pre_pcpu in pi_pre_block
> and WARN instead of adding the element twice in the list. Second,
> always do the list removal in pi_post_block if vcpu->pre_pcpu is
> set (not -1).
>
> The new code keeps interrupts disabled for the whole duration of
> pi_pre_block/pi_post_block. This is not strictly necessary, but
> easier to follow. For the same reason, PI.ON is checked only
> after the cmpxchg, and to handle it we just call the post-block
> code. This removes duplication of the list removal code.
>
> Cc: Longpeng (Mike)
> Cc: Huangweidong
> Cc: Gonglei
> Cc: wangxin
> Cc: Radim Krčmář
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/vmx.c | 62
> ++
> 1 file changed, 25 insertions(+), 37 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 747d16525b45..0f4714fe4908 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -11236,10 +11236,11 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> struct pi_desc old, new;
> unsigned int dest;
> - unsigned long flags;
>
> do {
> old.control = new.control = pi_desc->control;
> + WARN(old.nv != POSTED_INTR_WAKEUP_VECTOR,
> + "Wakeup handler not enabled while the VCPU is blocked\n");
>
> dest = cpu_physical_id(vcpu->cpu);
>
> @@ -11256,14 +11257,10 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> } while (cmpxchg(&pi_desc->control, old.control,
> new.control) != old.control);
>
> - if(vcpu->pre_pcpu != -1) {
> - spin_lock_irqsave(
> - &per_cpu(blocked_vcpu_on_cpu_lock,
> - vcpu->pre_pcpu), flags);
> + if (!WARN_ON_ONCE(vcpu->pre_pcpu == -1)) {
> + spin_lock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> list_del(&vcpu->blocked_vcpu_list);
> - spin_unlock_irqrestore(
> - &per_cpu(blocked_vcpu_on_cpu_lock,
> - vcpu->pre_pcpu), flags);
> + spin_unlock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> vcpu->pre_pcpu = -1;
> }
> }
> @@ -11283,7 +11280,6 @@ static void __pi_post_block(struct kvm_vcpu *vcpu)
> */
> static int pi_pre_block(struct kvm_vcpu *vcpu)
> {
> - unsigned long flags;
> unsigned int dest;
> struct pi_desc old, new;
> struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> @@ -11293,34 +11289,20 @@ static int pi_pre_block(struct kvm_vcpu *vcpu)
> !kvm_vcpu_apicv_active(vcpu))
> return 0;
>
> - vcpu->pre_pcpu = vcpu->cpu;
> - spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
> - vcpu->pre_pcpu), flags);
> - list_add_tail(&vcpu->blocked_vcpu_list,
> - &per_cpu(blocked_vcpu_on_cpu,
> - vcpu->pre_pcpu));
> - spin_unlock_irqrestore(&per_cpu(blocked_vcpu_on_cpu_lock,
> -vcpu->pre_pcpu), flags);
> + WARN_ON(irqs_disabled());
> + local_irq_disable();
> + if (!WARN_ON_ONCE(vcpu->pre_pcpu != -1)) {
> + vcpu->pre_pcpu = vcpu->cpu;
> + spin_lock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> + list_add_tail(&vcpu->blocked_vcpu_list,
> + &per_cpu(blocked_vcpu_on_cpu,
> +vcpu->pre_pcpu));
> + spin_unlock(&per_cpu(blocked_vcpu_on_cpu_lock, vcpu->pre_pcpu));
> + }
>
> do {
> old.control = new.control = pi_desc->control;
>
> - /*
> - * We should not block the vCPU if
> - * an interrupt is posted for it.
> - */
> - if (pi_test_on(pi_desc) == 1) {
> - spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
> - vcpu->pre_pcpu), flags);
> - list_del(&vcpu->blocked_vcpu_list);
> - spin_unlock_irqrestore(
> - &per_cpu(blocked_vcpu_on_cpu_lock,
> - vcpu->pre_pcpu), flags);
> - vcpu->pre_pcpu = -1;
> -
> - return 1;
[1]
> - }
> -
> WARN((pi_desc->sn == 1),
>"Warning: SN field of posted-interrupts "
>"is set before blocking\n");
> @@ -11345,7 +11327,12 @@ static int pi_pre_block(struct kvm_vcpu *vcpu)
> } while (cmpxchg(&pi_desc->control, old.control,
Re: [PATCH] external references for device tree overlays
Hi Pantelis,
On Wed, 2017-06-07 at 11:11 +0300, Pantelis Antoniou wrote:
> Hi Stefani,
>
> On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > Hi Pantelis,
> >
> > thanks for the suggestion. This feature is not very well
> > documented. I
> > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > source is:
> >
> > // rapsi example
> > /dts-v1/;
> > /plugin/;
> >
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> >
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <&{/soc/timer@7e003}>;
> > };
> > };
> > };
> >
> >
> > The resulting overlay is (decompiled with fdtdump):
> >
> > /dts-v1/;
> > // magic: 0xd00dfeed
> > // totalsize: 0x19a (410)
> > // off_dt_struct: 0x38
> > // off_dt_strings: 0x148
> > // off_mem_rsvmap: 0x28
> > // version: 17
> > // last_comp_version: 16
> > // boot_cpuid_phys: 0x0
> > // size_dt_strings: 0x52
> > // size_dt_struct: 0x110
> >
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <0xdeadbeef>;
> > };
> > };
> > __fixups__ {
> > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > };
> > };
> >
> > But this will not apply:
> >
> > OF: resolver: overlay phandle fixup failed: -22
> > create_overlay: Failed to resolve tree
> >
> >
>
> Yes, it will not work as it is; my point is that you don't need the
> magic __*__ node.
>
The magic __fixups__ node was inserted by the device tree compiler. I
use the dtc from https://github.com/pantoniou/dtc at commit
d990b8013889b816ec054c7e07a77db59c56c400.
> You will need to modify the overlay application code to live insert a
> phandle (if it doesn't exist) when it encounters a /path fixup.
>
That is part of my patch!
> > Anyway, the reason for my patch is that i can reference to nodes
> > which
> > lacks a phandle. The phandle will be created on the fly and also
> > destroyed when the overlay is unloaded.
> >
> > I have a real use case for this patch:
> >
> > I have a BIOS on some ARM64 servers which provides broken device
> > tree.
> > It also lacks some devices in this tree which needs references to
> > other
> > devices which lacks a phandle.
> >
> > Since the BIOSes are closed source i need a way to work arround
> > this
> > problem without patching all the drivers involved to this devices.
> >
> > Hope this helps to understand the reason for this patch.
> >
>
> FWIW your problem seems like something that would happen on the
> field.
> We can berate the vendor of not providing the correct device tree,
> but
> in the end workarounds for broken vendor things are common in the
> kernel.
>
Yes, that is the way how linux do the things. Linux has a long history
to bypassing bugs of BIOSes, ACPI or broken devices.
Greetings,
Stefani
Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages
On Wed, Jun 07, 2017 at 04:31:06PM +0800, zhongjiang wrote:
> The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on
> underflow") declare that reclaimed pages exceed the scanned pages due
> to the thp reclaim. it is incorrect because THP will be spilt to normal
> page and loop again. which will result in the scanned pages increment.
>
> Signed-off-by: zhongjiang
> ---
> mm/vmpressure.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> index 6063581..0e91ba3 100644
> --- a/mm/vmpressure.c
> +++ b/mm/vmpressure.c
> @@ -116,8 +116,9 @@ static enum vmpressure_levels
> vmpressure_calc_level(unsigned long scanned,
>
> /*
>* reclaimed can be greater than scanned in cases
> - * like THP, where the scanned is 1 and reclaimed
> - * could be 512
> + * like reclaimed slab pages, shrink_node just add
> + * reclaimed page without a related increment to
> + * scanned pages.
>*/
> if (reclaimed >= scanned)
> goto out;
Thanks for the fixing my fault!
Acked-by: Minchan Kim
Frankly speaking, I'm not sure we need such comment in there at the cost
of maintainance because it would be fragile but easy to fix by above simple
condition so I think it would be better to remove that comment but others
might be different. So, don't have any objection.
Re: [PATCH 2/2] xen/input: add multi-touch support
Hi, Dmitry!
On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 142 +-
1 file changed, 140 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 01c27b4c3288..e5d064aaa237 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,11 +35,14 @@
struct xenkbd_info {
struct input_dev *kbd;
struct input_dev *ptr;
+ struct input_dev *mtouch;
struct xenkbd_page *page;
int gref;
int irq;
struct xenbus_device *xbdev;
char phys[32];
+ /* current MT slot/contact ID we are injecting events in */
+ int mtouch_cur_contact_id;
};
enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
MODULE_PARM_DESC(ptr_size,
"Pointing device width, height in pixels (default 800,600)");
+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(mtouch_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+ "Multi-touch device width, height in pixels (default 800,600)");
+
Why do you need separate module parameters for multi-touch device?
please see below
static int xenkbd_remove(struct xenbus_device *);
static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info
*);
static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
input_report_rel(dev, REL_WHEEL,
-event->pos.rel_z);
break;
+ case XENKBD_TYPE_MTOUCH:
+ dev = info->mtouch;
+ if (unlikely(!dev))
+ break;
+ if (unlikely(event->mtouch.contact_id !=
+ info->mtouch_cur_contact_id)) {
Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?
Mu assumption was that regardless of the fact that we are multi-touch
device still single touches will come in more frequently
But I can remove *unlikely* if my assumption is not correct
I think the normal expectation is that "unlikely" is supposed for
something that happens once in a blue moon, so I'd rather remove it.
agree, removed "unlikely"
+ info->mtouch_cur_contact_id =
+ event->mtouch.contact_id;
+ input_mt_slot(dev, event->mtouch.contact_id);
+ }
+ switch (event->mtouch.event_type) {
+ case XENKBD_MT_EV_DOWN:
+ input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+ true);
Should we establish tool event? We have MT_TOOL_PEN, etc.
I think that for multi-touch MT_TOOL_FINGER is enough
any reason we would also want MT_TOOL_PEN here?
Why would not you? Let's say you have a drawing application running in
guest that can make use of tool types. Why would not you want to tell it
that the tool user is currently using is in fact a pen and not finger?
But it is a finger :) we are multi-touch, not multi pen
So for tablets that support both touch and stylus you would export them
as 2 separate devices?
this could be done in different ways, but please see on
pen support below
Besides, that, if I am about to implement pen support
(which I still not convinced we really need), how will I
do that?
I do not know what you have on the backend side, but roughly speaking if
you detect a pen/stylus you let your guest know that the contact is not
a finger, but pen. How you plumb it through is up to you.
we do not detect pen, only finger at the moment
and the existing protocol has no means to tell
type of the tool used, everything is supposed to
be "finger", so front-end has no possibility to
tell one tool from another
My understanding is that I need 2 different slots to report
the same coordinates for finger and p
Re: [PATCH] ARM: samsung: Save defconfig for Exynos, S3C and S5P configs
On Wed, Jun 07, 2017 at 09:49:58PM +0200, Arnd Bergmann wrote: > On Wed, Jun 7, 2017 at 8:18 PM, Krzysztof Kozlowski wrote: > > Some configs for Samsung ARM SoCs were not updated for some time and > > they still contain obsolete Kconfig entries. Generate new defconfig for > > all Samsung ARM architectures (Exynos, S3C24xx, S3C64xx, S5Pv210). > > > > Signed-off-by: Krzysztof Kozlowski > > Hi Krzysztof, > > Updating the defconfig files is good, but I'm always a little unsure > about loss of > information when we do that. Would it be possible for you to split this patch > into two halves, with one of them just reordering the entries that moved, > and the second one removing the entries that have disappeared, with an > explanation for why they are no longer there? That would let us see whether > the change was intentional and avoid problems from renamed Kconfig > symbols that are no longer enabled afterwards. Splitting the change into two commits (reorder and removal) makes sense. However getting the information why some things were removed, will require more effort. I'll see what I can do. Best regards, Krzysztof
Re: [PATCH v3] f2fs: dax: implement direct access
Hi Qiuyang,
[auto build test ERROR on f2fs/dev]
[also build test ERROR on v4.12-rc4 next-20170607]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/sunqiuyang/f2fs-dax-implement-direct-access/20170608-140734
base: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev
config: x86_64-randconfig-x010-201723 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs/f2fs/file.c: In function 'f2fs_dax_huge_fault':
>> fs/f2fs/file.c:124:26: error: 'struct f2fs_inode_info' has no member named
>> 'i_mmap_sem'; did you mean 'i_sem'?
down_read(&F2FS_I(inode)->i_mmap_sem);
^~
fs/f2fs/file.c:126:24: error: 'struct f2fs_inode_info' has no member named
'i_mmap_sem'; did you mean 'i_sem'?
up_read(&F2FS_I(inode)->i_mmap_sem);
^~
fs/f2fs/file.c: In function 'f2fs_dax_pfn_mkwrite':
fs/f2fs/file.c:147:26: error: 'struct f2fs_inode_info' has no member named
'i_mmap_sem'; did you mean 'i_sem'?
down_read(&F2FS_I(inode)->i_mmap_sem);
^~
fs/f2fs/file.c:153:24: error: 'struct f2fs_inode_info' has no member named
'i_mmap_sem'; did you mean 'i_sem'?
up_read(&F2FS_I(inode)->i_mmap_sem);
^~
--
fs/f2fs/gc.c: In function 'dax_move_data_page':
>> fs/f2fs/gc.c:731:40: error: 'struct f2fs_inode_info' has no member named
>> 'i_mmap_sem'; did you mean 'i_sem'?
if (!down_write_trylock(&F2FS_I(inode)->i_mmap_sem))
^~
fs/f2fs/gc.c:783:25: error: 'struct f2fs_inode_info' has no member named
'i_mmap_sem'; did you mean 'i_sem'?
up_write(&F2FS_I(inode)->i_mmap_sem);
^~
vim +124 fs/f2fs/file.c
118 bool write = vmf->flags & FAULT_FLAG_WRITE;
119
120 if (write) {
121 sb_start_pagefault(sb);
122 file_update_time(vmf->vma->vm_file);
123 }
> 124 down_read(&F2FS_I(inode)->i_mmap_sem);
125 result = dax_iomap_fault(vmf, pe_size, &f2fs_iomap_ops);
126 up_read(&F2FS_I(inode)->i_mmap_sem);
127 if (write)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v2] tick/broadcast: tick_broadcast_setup_oneshot() isn't exported
This function isn't used outside of tick-broadcast.c, so let's
mark it static.
Signed-off-by: Stephen Boyd
---
Changes from v1:
* Fixed the kbuild issue by moving into ifdef CONFIG_TICK_ONESHOT
kernel/time/tick-broadcast.c | 4 +++-
kernel/time/tick-internal.h | 2 --
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 987e496bb51a..b398c2ea69b2 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -37,9 +37,11 @@ static int tick_broadcast_forced;
static __cacheline_aligned_in_smp DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
#ifdef CONFIG_TICK_ONESHOT
+static void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
static void tick_broadcast_clear_oneshot(int cpu);
static void tick_resume_broadcast_oneshot(struct clock_event_device *bc);
#else
+static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
{ BUG(); }
static inline void tick_broadcast_clear_oneshot(int cpu) { }
static inline void tick_resume_broadcast_oneshot(struct clock_event_device
*bc) { }
#endif
@@ -867,7 +869,7 @@ static void tick_broadcast_init_next_event(struct cpumask
*mask,
/**
* tick_broadcast_setup_oneshot - setup the broadcast device
*/
-void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
+static void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
{
int cpu = smp_processor_id();
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index f738251000fe..be0ac01f2e12 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -126,7 +126,6 @@ static inline int tick_check_oneshot_change(int allow_nohz)
{ return 0; }
/* Functions related to oneshot broadcasting */
#if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) &&
defined(CONFIG_TICK_ONESHOT)
-extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
extern void tick_broadcast_switch_to_oneshot(void);
extern void tick_shutdown_broadcast_oneshot(unsigned int cpu);
extern int tick_broadcast_oneshot_active(void);
@@ -134,7 +133,6 @@ extern void tick_check_oneshot_broadcast_this_cpu(void);
bool tick_broadcast_oneshot_available(void);
extern struct cpumask *tick_get_broadcast_oneshot_mask(void);
#else /* !(BROADCAST && ONESHOT): */
-static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
{ BUG(); }
static inline void tick_broadcast_switch_to_oneshot(void) { }
static inline void tick_shutdown_broadcast_oneshot(unsigned int cpu) { }
static inline int tick_broadcast_oneshot_active(void) { return 0; }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/3] nvmem: core: remove member users from struct nvmem_device
On 07/06/17 22:51, Heiner Kallweit wrote:
Am 07.06.2017 um 17:30 schrieb Srinivas Kandagatla:
On 04/06/17 12:01, Heiner Kallweit wrote:
Member users is used only to check whether we're allowed to remove
the module. So in case of built-in it's not used at all and in case
nvmem providers doesn't have to be independent drivers, providers could be part
of the other driver which can dynamically register and unregister nvmem
providers. For example at24 and at25 drivers.
This patch will break such cases !!
Thanks for the quick review.
I don't think this patch breaks e.g. at24 / at25. Let me try to explain:
at24 / at25 set themself as owner in struct nvmem_device and nvmem_unregister
is called from at24/25_remove only. These remove callbacks are called only if
all references to the respective module have been released.
In current kernel code I don't see any nvmem use broken by the proposed patch.
However in general you're right, there may be future use cases where
nvmem_unregister isn't called only from a remove callback.
Yes, the patch would not break the exiting code, but as said it would
break a feature which was considered while writing the code.
If the refcount isn't zero when calling nvmem_unregister then there's a bigger
problem, I don't think there's any normal use case where this can happen.
Yes I understand chances of this error path is slim but it would crash
the system if it hits this path, so this safety check is in place.
Instead of just returning -EBUSY I think a WARN() would be appropriate.
Currently no caller of nvmem_unregister checks the return code anyway.
My opinion would be that the refcount here is more a debug feature.
Whilst we're talking about nvmem_unregister:
I think the device_del() at the end should be a device_unregister().
Else we miss put_device as second part of destroying a device.
These issues have already been addressed in
https://patchwork.kernel.org/patch/9685559/
https://patchwork.kernel.org/patch/9685561/
https://patchwork.kernel.org/patch/9729235/
--srini
Rgds, Heiner
that owner is a module we have the module refcount for the same
purpose already. Whenever users is incremented the owner's refcount
is incremented too. Therefore users isn't needed.
Signed-off-by: Heiner Kallweit
---
drivers/nvmem/core.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 8c830a80..4e07f3f8 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -33,7 +33,6 @@ struct nvmem_device {
intword_size;
intncells;
intid;
-intusers;
size_tsize;
boolread_only;
intflags;
@@ -517,13 +516,6 @@ EXPORT_SYMBOL_GPL(nvmem_register);
*/
int nvmem_unregister(struct nvmem_device *nvmem)
{
-mutex_lock(&nvmem_mutex);
-if (nvmem->users) {
-mutex_unlock(&nvmem_mutex);
-return -EBUSY;
-}
-mutex_unlock(&nvmem_mutex);
-
if (nvmem->flags & FLAG_COMPAT)
device_remove_bin_file(nvmem->base_dev, &nvmem->eeprom);
@@ -562,7 +554,6 @@ static struct nvmem_device *__nvmem_device_get(struct
device_node *np,
}
}
-nvmem->users++;
mutex_unlock(&nvmem_mutex);
if (!try_module_get(nvmem->owner)) {
@@ -570,10 +561,6 @@ static struct nvmem_device *__nvmem_device_get(struct
device_node *np,
"could not increase module refcount for cell %s\n",
nvmem->name);
-mutex_lock(&nvmem_mutex);
-nvmem->users--;
-mutex_unlock(&nvmem_mutex);
-
return ERR_PTR(-EINVAL);
}
@@ -583,9 +570,6 @@ static struct nvmem_device *__nvmem_device_get(struct
device_node *np,
static void __nvmem_device_put(struct nvmem_device *nvmem)
{
module_put(nvmem->owner);
-mutex_lock(&nvmem_mutex);
-nvmem->users--;
-mutex_unlock(&nvmem_mutex);
}
static int nvmem_match(struct device *dev, void *data)
RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
Hi,
> Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
>
> Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid,
> which gives 16 possible values for tid.
> This is problematic because IWL_MAX_TID_COUNT is 8, so indexing
> iwl_priv::tid_data can go very wrong.
True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
that we don't index tid_data with this. Hence I think the proper fix is:
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index 06ac3f1..16a8646 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct
iwl_rx_cmd_buffer *rxb)
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
next_reclaimed);
+ iwlagn_check_ratid_empty(priv, sta_id, tid);
}
iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
- iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;
/* process frames */
Clearly calling iwlagn_check_ratid_empty with tid = IWL_TID_NON_QOS is a bad
idea.
>
> With UBSAN I can it happening while establishing the first connection
> after module load.
>
> [ 272.143440] UBSAN: Undefined behaviour in
> drivers/net/wireless/intel/iwlwifi/dvm/tx.c:777:32
> [ 272.143447] index 8 is out of range for type 'iwl_tid_data [8]'
> [ 272.143457] CPU: 0 PID: 4605 Comm: irq/32-iwlwifi Not tainted 4.12.0-dirty
> #2
> [ 272.143460] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B,
> BIOS 68SSU Ver. F.02 07/26/2011
> [ 272.143462] Call Trace:
> [ 272.143472] dump_stack+0x9c/0x10b
> [ 272.143477] ? _atomic_dec_and_lock+0x285/0x285
> [ 272.143486] ubsan_epilogue+0xd/0x4e
> [ 272.143493] __ubsan_handle_out_of_bounds+0xef/0x118
> [ 272.143498] ? __ubsan_handle_shift_out_of_bounds+0x221/0x221
> [ 272.143519] ? iwl_trans_pcie_reclaim+0x153/0xc90 [iwlwifi]
> [ 272.143539] iwlagn_check_ratid_empty+0x337/0x410 [iwldvm]
> [ 272.143556] ? iwl_hcmd_names_cmp+0x2f/0x60 [iwlwifi]
> [ 272.143571] iwlagn_rx_reply_tx+0x8a4/0x1820 [iwldvm]
>
> Signed-off-by: Seraphime Kirkovski
> ---
>I'm currently running this patch on my machines and I have wifi.
>The patch presumes а cleanup patch, I sent yesterday:
> https://www.spinics.net/lists/kernel/msg2526314.html
>
> drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> index 37d2ba5ae852..e5994df9ea4c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> @@ -1448,7 +1448,7 @@ struct agg_tx_status {
> */
> /* refer to ra_tid */
> #define IWLAGN_TX_RES_TID_POS0
> -#define IWLAGN_TX_RES_TID_MSK0x0f
> +#define IWLAGN_TX_RES_TID_MSK0x07
> #define IWLAGN_TX_RES_RA_POS 4
> #define IWLAGN_TX_RES_RA_MSK 0xf0
>
> --
> 2.11.0
>
> -
> linuxw...@eclists.intel.com
> https://eclists.intel.com/sympa/info/linuxwifi
> Unsubscribe by sending email to sy...@eclists.intel.com with subject
> "Unsubscribe linuxwifi"
linux-next: manual merge of the akpm-current tree with the random tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/random.h
between commit:
60473a13020f ("random: add get_random_{bytes,u32,u64,int,long,once}_wait
family")
from the random tree and commit:
d7802aa82f66 ("random,stackprotect: introduce get_random_canary function")
from the akpm-current 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 include/linux/random.h
index 4aecc339558d,1fa0dc880bd7..
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@@ -58,31 -57,27 +58,52 @@@ static inline unsigned long get_random_
#endif
}
+/* Calls wait_for_random_bytes() and then calls get_random_bytes(buf, nbytes).
+ * Returns the result of the call to wait_for_random_bytes. */
+static inline int get_random_bytes_wait(void *buf, int nbytes)
+{
+ int ret = wait_for_random_bytes();
+ if (unlikely(ret))
+ return ret;
+ get_random_bytes(buf, nbytes);
+ return 0;
+}
+
+#define declare_get_random_var_wait(var) \
+ static inline int get_random_ ## var ## _wait(var *out) { \
+ int ret = wait_for_random_bytes(); \
+ if (unlikely(ret)) \
+ return ret; \
+ *out = get_random_ ## var(); \
+ return 0; \
+ }
+declare_get_random_var_wait(u32)
+declare_get_random_var_wait(u64)
+declare_get_random_var_wait(int)
+declare_get_random_var_wait(long)
+#undef declare_get_random_var
+
+ /*
+ * On 64-bit architectures, protect against non-terminated C string overflows
+ * by zeroing out the first byte of the canary; this leaves 56 bits of
entropy.
+ */
+ #ifdef CONFIG_64BIT
+ # ifdef __LITTLE_ENDIAN
+ # define CANARY_MASK 0xff00UL
+ # else /* big endian, 64 bits: */
+ # define CANARY_MASK 0x00ffUL
+ # endif
+ #else /* 32 bits: */
+ # define CANARY_MASK 0xUL
+ #endif
+
+ static inline unsigned long get_random_canary(void)
+ {
+ unsigned long val = get_random_long();
+
+ return val & CANARY_MASK;
+ }
+
unsigned long randomize_page(unsigned long start, unsigned long range);
u32 prandom_u32(void);
Re: [PATCH v3] hwmon: Add support for MAX31785 intelligent fan controller
On Wed, 2017-06-07 at 10:37 -0700, Guenter Roeck wrote: > On Wed, Jun 07, 2017 at 04:15:06PM +0930, Andrew Jeffery wrote: > > On Wed, 2017-06-07 at 12:18 +0930, Joel Stanley wrote: > > > On Wed, Jun 7, 2017 at 1:50 AM, Matthew Barth > > > > > > > > wrote: > > > > > > > > On 06/06/17 8:33 AM, Guenter Roeck wrote: > > > > > > > > > > On 06/06/2017 12:02 AM, Andrew Jeffery wrote: > > > > > > Over and above the features of the original patch is support for a > > > > > > secondary > > > > > > rotor measurement value that is provided by MAX31785 chips with a > > > > > > revised > > > > > > firmware. The feature(s) of the firmware are determined at probe > > > > > > time and > > > > > > extra > > > > > > attributes exposed accordingly. Specifically, the MFR_REVISION > > > > > > 0x3040 of > > > > > > the > > > > > > firmware supports 'slow' and 'fast' rotor reads. The feature is > > > > > > implemented by > > > > > > command 0x90 (READ_FAN_SPEED_1) providing a 4-byte response (with > > > > > > the > > > > > > 'fast' > > > > > > measurement in the second word) rather than the 2-bytes response in > > > > > > the > > > > > > original firmware (MFR_REVISION 0x3030). > > > > > > > > > > > > > > > > Taking the pmbus driver question out, why would this warrant another > > > > > non-standard > > > > > attribute outside the ABI ? I could see the desire to replace the > > > > > 'slow' > > > > > access > > > > > with the 'fast' one, but provide two attributes ? No, I don't see the > > > > > point, sorry, > > > > > even more so without detailed explanation why the second attribute in > > > > > addition > > > > > to the first one would add any value. > > > > > > > > In the case of counter-rotating(CR) fans which contain two rotors to > > > > provide > > > > more airflow there are then two tach feedbacks. These CR fans take a > > > > single > > > > target speed and provide individual feedbacks for each rotor contained > > > > within the fan enclosure. Providing these individual feedbacks assists > > > > in > > > > fan fault driven speed changes, improved thermal characterization among > > > > other things. > > > > > > > > Maxim provided this as a 'slow' / 'fast' set of bytes to be user > > > > compatible(so the 'slow' rotor speed, regardless of which rotor, is in > > > > the > > > > first 2 bytes with the 'slow' version of firmware as well). In some > > > > cases, > > > > mfg systems could have a mix of these revisions. > > > > > > Andrew, instead of creating the _fast sysfs nodes, I think you could > > > expose the extra rotors are separate fan devices in sysfs. This would > > > not introduce new ABI. > > > > I considered this approach: I debated whether to consider the fan unit > > as a single entity with two inputs, or just separate fans, and ended up > > leaning towards the former. To go the latter path we need to consider > > whether or not to expose the writeable properties for the second input > > (given they also affect the first) and how to sensibly arrange the > > pairs given the functionality is determined at probe-time. Not rocket > > science but decisions we need to make. > > > > There are many other examples with one writeable and multiple readable > attributes. Temperature offset attributes are an excellent example. > Next question would be what exactly would be writable. pwm attributes are > commonly completely independent of fan attributes. pwm1 output doesn't > mean that fan1 is the matching input; in fact, most of the time it isn't. > The only question would be numbering (is the pair numbered fan1/2 or > fan1/fan(1+X) ?) which is just a matter of personal preference. However, > everything is better than coming up with non-standard attributes which > can not be used with any standard application beyond the application of the > person submitting the driver. It is bad enough if a non-standard attribute > describes something really driver specific. But a non-standard attribute > for a fan speed reading ? Please no. Yes, I've received loud and clear that I made the wrong choice :) Apologies. Thanks again for your feedback. Andrew signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Thu, Jun 08, 2017 at 07:35:28AM +0200, Martin Schwidefsky wrote:
> On Wed, 7 Jun 2017 22:47:56 +0200
> Heiko Carstens wrote:
> > On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> > > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \
> > > +({ \
> > > + struct elf64_hdr *_ehdr = (void *) ehdr;\
> > > + struct elf64_phdr *_phdr = (void *) phdr; \
> > > + int _rc = 0;\
> > > + if (_ehdr->e_ident[EI_CLASS] == ELFCLASS64 && \
> > > + _phdr->p_type == PT_S390_REQUEST_PGSTE && \
> > > + !page_table_allocate_pgste && \
> > > + !test_thread_flag(TIF_REQUEST_PGSTE)) { \
> > > + set_thread_flag(TIF_REQUEST_PGSTE); \
> > > + set_pt_regs_flag(task_pt_regs(current), \
> > > + PIF_SYSCALL_RESTART); \
> > > + _rc = -EAGAIN; \
> > > + } \
> > > + _rc;\
> > > +})
> >
> > I'm wondering if this should simply fail, if a PT_S390_REQUEST_PGSTE type
> > segment exists, but it is not ELFCLASS64?
> > It will fail later anyway on s390_enable_sie(), but...
>
> Does it matter if it fails for a 32-bit ELF file? Just makes the code more
> complex without benefit, no?
It would be more consistent, since right now a 32-bit ELF file with
PT_S390_REQUEST_PGSTE will be exectuted, but the page tables won't have any
pgstes. That's sort of odd, isn't it? And that later on it won't be able to
create a virtual machine because our current implementation doesn't allow
that for compat tasks is sort of unrelated.
But anyway, I'll leave that up to you, it doesn't really matter.
>
> > > diff --git a/arch/s390/include/asm/mmu_context.h
> > > b/arch/s390/include/asm/mmu_context.h
> > > index c119d564d8f2..1201b18e817d 100644
> > > --- a/arch/s390/include/asm/mmu_context.h
> > > +++ b/arch/s390/include/asm/mmu_context.h
> > > @@ -25,7 +25,8 @@ static inline int init_new_context(struct task_struct
> > > *tsk,
> > > mm->context.gmap_asce = 0;
> > > mm->context.flush_mm = 0;
> > > #ifdef CONFIG_PGSTE
> > > - mm->context.alloc_pgste = page_table_allocate_pgste;
> > > + mm->context.alloc_pgste = page_table_allocate_pgste ||
> > > + test_thread_flag(TIF_REQUEST_PGSTE);
> >
> > I think the alloc_pgste flag should be inherited on fork, no?
>
> Yes, that makes it more consistent. I'll add it.
By the way, what prevents with the _current_ code a scenario like:
- set allocate_pgste sysctl to 1
- create kvm guest
- s390_enable_sie
- run vcpu
- set allocate_pgste sysctl to 0
- clone(... CLONE_FILES ...) (that is: new mm without pgstes, but shared fds)
- [child] run vcpu
Is there anything that makes sure we cannot execute the sie instruction in
the child process?
Re: [PATCH] nvmem: core: add managed version of nvmem_register
On 07/06/17 22:55, Heiner Kallweit wrote:
Am 07.06.2017 um 18:19 schrieb Srinivas Kandagatla:
On 04/06/17 12:06, Heiner Kallweit wrote:
Add a device-managed version of nvmem_register.
Signed-off-by: Heiner Kallweit
---
Documentation/nvmem/nvmem.txt | 1 +
drivers/nvmem/core.c | 35 +++
include/linux/nvmem-provider.h | 7 +++
3 files changed, 43 insertions(+)
Thanks for the patch, one comments..
diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt
index dbd40d87..b4ff7862 100644
--- a/Documentation/nvmem/nvmem.txt
+++ b/Documentation/nvmem/nvmem.txt
@@ -37,6 +37,7 @@ and write the non-volatile memory.
A NVMEM provider can register with NVMEM core by supplying relevant
nvmem configuration to nvmem_register(), on success core would return a valid
nvmem_device pointer.
+devm_nvmem_register() is a device-managed version of nvmem_register.
nvmem_unregister(nvmem) is used to unregister a previously registered
provider.
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 783eb431..55db219f 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -531,6 +531,41 @@ int nvmem_unregister(struct nvmem_device *nvmem)
}
EXPORT_SYMBOL_GPL(nvmem_unregister);
+static void devm_nvmem_release(struct device *dev, void *res)
+{
+nvmem_unregister(*(struct nvmem_device **)res);
nvmem_unregister() can fail, how are you going to deal with this error cases?
As stated in my answer to your other review comment:
Currently no caller of nvmem_unregister checks the return code.
Currently all nvmem provider drivers check return code of unregister in
remove path.
Checking the refcount I see more as a debug feature and I think making
No, I don't think its a debug feature!! without this check we would end
up dereferencing a freed pointer.
nvmem_unregister return void plus a WARN() if refcount != 0 would be better.
WARN() would not be enough to stop the system to crash, in case the
provider just unregisters with active users.
Rgds, Heiner
+}
+
+/**
+ * devm_nvmem_register() - managed version of nvmem_register
+ *
+ * @config: nvmem device configuration with which nvmem device is created.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer to nvmem_device
+ * on success.
+ */
+
+struct nvmem_device *devm_nvmem_register(const struct nvmem_config *config)
For consistency reasons, devm versions of apis should always have dev at as
first argument.
+{
+struct nvmem_device *nv, **dr;
+
+dr = devres_alloc(devm_nvmem_release, sizeof(*dr), GFP_KERNEL);
+if (!dr)
+return ERR_PTR(-ENOMEM);
+
+nv = nvmem_register(config);
+if (IS_ERR(nv)) {
+devres_free(dr);
+return nv;
+}
+
+*dr = nv;
+devres_add(config->dev, dr);
+
+return nv;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_register);
+
RE: [PATCH V2 1/3] devicetree: add UniPhier WDT devicetree bindings documentation
Hello Yamada-san
Thank you for your comment.
> > Add uniphier-wdt bindings documentation.
> >
> > Signed-off-by: Keiji Hayashibara
>
>
> Maybe "dt-bindings: watchdog: ..." for the subject.
>
> This seems what Rob prefers.
>
> For example,
> https://patchwork.kernel.org/patch/9606365/
OK. I will change the subject in v3 patch.
>
> > ---
> > .../devicetree/bindings/watchdog/uniphier-wdt.txt| 20
> >
> > 1 file changed, 20 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
> > new file mode 100644
> > index 000..a59d1ba
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
> > @@ -0,0 +1,20 @@
> > +UniPhier watchdog timer controller
> > +
> > +This UniPhier watchdog timer controller must be under sysctrl compatible
> > node.
>
> Do you mean "syscon compatible" ?
The "compatible" word is inappropriate.
I will remove it in v3 patch.
>
> > +Required properties:
> > +- compatible: should be "socionext,uniphier-wdt"
> > +
> > +Example:
> > +
> > + sysctrl@6184 {
> > + compatible = "socionext,uniphier-ld11-sysctrl",
> > +"simple-mfd", "syscon";
> > + reg = <0x6184 0x4000>;
> > +
> > + sys_wdt: watchdog {
> > + compatible = "socionext,uniphier-wdt";
> > + }
>
> Could you remove the "sys_dwt: " label?
> I'd like the example matched with actual DT files.
I will remove it.
>
> Thanks.
>
>
> > + other nodes ...
> > + };
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Keiji Hayashibara
Re: [PATCH 46/58] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks
Le Wed, 7 Jun 2017 23:08:48 +0200, Daniel Lezcano a écrit : > On Wed, Jun 07, 2017 at 05:27:50PM +0200, Alexandre Belloni wrote: > > On 07/06/2017 at 16:17:35 +0200, Daniel Lezcano wrote: > > > > You mean you don't like how it is used? Or you don't think having the > > > > timer full name is useful? > > > > > > The field is not needed, the only place where it is used is where we > > > affect it. > > > > > > > It is used in tcb_clksrc_register: > > > > tc.clksrc.name = tc.name; > > Yes, but tc.name is only in the scope of the function, so there is no need to > include this field in the structure, just a working buffer in the function is > enough. Hm, do you mean allocating the buffer dynamically and leaking the resource (not a real leak here, since we're talking about something that cannot be unregistered) or defining a 'static char name[]' variable in the function and passing this pointer to clksrc.name? Note that putting the name var on the stack won't work, because the core does not seem to duplicate the name, and uses clksrc->name after tcb_clksrc_register() has returned. Anyway, I'm not sure dynamically generating the name is really needed because we only accept a single tcb-clocksource device. We can just set tc.clksrc.name to "atmel-tcb-clocksource" and we should be good.
Re: [PATCH v5 00/23] mtd: nand: denali: Denali NAND IP patch bomb
Hi Boris, 2017-06-07 20:52 GMT+09:00 Masahiro Yamada : > This patch series intends to solve various problems. > > [1] The driver just retrieves the OOB area as-is > whereas the controller uses syndrome page layout. > [2] Many NAND chip specific parameters are hard-coded in the driver. > [3] ONFi devices are not working > [4] It can not read Bad Block Marker > > Outstanding changes are: > - Fix raw/oob callbacks for syndrome page layout > - Implement setup_data_interface() callback > - Fix/implement more commands for ONFi devices > - Allow to skip the driver internal bounce buffer > - Support PIO in case DMA is not supported > - Switch from ->cmdfunc over to ->cmd_ctrl I am planning v6, but how many can you pick-up from this series? I did not see your comments for 01-05, so are they applicable? Could you add Acked-by: Rob Herring for 05 (http://patchwork.ozlabs.org/patch/772388/) He had already acked it, but I just missed it. -- Best Regards Masahiro Yamada
[PATCH] ARM/Kconfig: make VMSPLIT_3G_OPT depends on !ARM_LPAE
When both enable CONFIG_ARM_LPAE=y and CONFIG_VMSPLIT_3G_OPT=y, which means use PAGE_OFFSET=0xB000 with ARM_LPAE, the kernel will boot fail and stop after uncompressed: Starting kernel ... Uart base = 0x20001000 watchdog reg = 0x20013000 dtb addr = 0x80840308 Uncompressing Linux... done, booting the kernel. For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in: http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16 So we should make VMSPLIT_3G_OPT depends on !ARM_LPAE to avoid trigger this bug. Signed-off-by: Yisheng Xie --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 4c1a35f..c0fcab6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1416,6 +1416,7 @@ choice config VMSPLIT_3G bool "3G/1G user/kernel split" config VMSPLIT_3G_OPT + depends on !ARM_LPAE bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G bool "2G/2G user/kernel split" -- 1.7.12.4
Re: [PATCH v5 07/23] mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()
Hi Boris,
2017-06-07 22:33 GMT+09:00 Boris Brezillon :
> On Wed, 7 Jun 2017 20:52:16 +0900
> Masahiro Yamada wrote:
>
>> Currently, the error handling of denali_write_page(_raw) is a bit
>> complicated. If the program command fails, NAND_STATUS_FAIL is set
>> to the driver internal denali->status, then read out later by
>> denali_waitfunc().
>>
>> We can avoid it by exploiting the nand_write_page() implementation.
>> If chip->ecc.write_page(_raw) returns negative code (i.e. -EIO), it
>> errors out immediately. This gives the same result as returning
>> NAND_STATUS_FAIL from chip->waitfunc. In either way, -EIO is
>> returned to the upper MTD layer.
>
> Actually, this is how it's supposed to work now (when they set
> the NAND_ECC_CUSTOM_PAGE_ACCESS flag, drivers are expected to wait for
> the program operation to finish and return -EIO if it failed), so you're
> all good ;-).
>
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2:
>> - Newly added
>>
>> drivers/mtd/nand/denali.c | 12
>> drivers/mtd/nand/denali.h | 1 -
>> 2 files changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> index 1897fe238290..22acfc34b546 100644
>> --- a/drivers/mtd/nand/denali.c
>> +++ b/drivers/mtd/nand/denali.c
>> @@ -1005,6 +1005,7 @@ static int write_page(struct mtd_info *mtd, struct
>> nand_chip *chip,
>> size_t size = mtd->writesize + mtd->oobsize;
>> uint32_t irq_status;
>> uint32_t irq_mask = INTR__DMA_CMD_COMP | INTR__PROGRAM_FAIL;
>
> As mentioned in my previous patch, I think you should wait for
> INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL here.
No.
It is intentional to use INTR__DMA_CMD_COMP
instead of INTR__PROGRAM_COMP here.
This is very strange of this IP,
INTR__PROGRAM_COMP is never set when DMA mode is being used.
(INTR__DMA_CMD_COMP is set instead.)
As far as I tested this IP,
INTR__PROGRAM_COMP is set only when data are written by PIO mode.
I introduced PIO transfer in
http://patchwork.ozlabs.org/patch/772398/
I used INTR__PROGRAM_COMP in denali_pio_write().
>> + int ret = 0;
>>
>> denali->page = page;
>>
>> @@ -1038,13 +1039,13 @@ static int write_page(struct mtd_info *mtd, struct
>> nand_chip *chip,
>> if (irq_status == 0) {
>> dev_err(denali->dev, "timeout on write_page (type = %d)\n",
>> raw_xfer);
>> - denali->status = NAND_STATUS_FAIL;
>> + ret = -EIO;
>> }
>
> if (irq_status & INTR__PROGRAM_FAIL) {
> dev_err(denali->dev, "page program failed (type = %d)\n",
> raw_xfer);
> ret = -EIO;
> }
This will be fixed anyway by
http://patchwork.ozlabs.org/patch/772414/
I do not want to include unrelated change.
--
Best Regards
Masahiro Yamada
Re: [PATCH v5 10/23] mtd: nand: denali: rework interrupt handling
Hi Boris,
2017-06-07 22:57 GMT+09:00 Boris Brezillon :
> On Wed, 7 Jun 2017 20:52:19 +0900
> Masahiro Yamada wrote:
>
>
>> -/*
>> - * This is the interrupt service routine. It handles all interrupts
>> - * sent to this device. Note that on CE4100, this is a shared interrupt.
>> - */
>> -static irqreturn_t denali_isr(int irq, void *dev_id)
>> +static uint32_t denali_wait_for_irq(struct denali_nand_info *denali,
>> + uint32_t irq_mask)
>> {
>> - struct denali_nand_info *denali = dev_id;
>> + unsigned long time_left, flags;
>> uint32_t irq_status;
>> - irqreturn_t result = IRQ_NONE;
>>
>> - spin_lock(&denali->irq_lock);
>> + spin_lock_irqsave(&denali->irq_lock, flags);
>>
>> - /* check to see if a valid NAND chip has been selected. */
>> - if (is_flash_bank_valid(denali->flash_bank)) {
>> - /*
>> - * check to see if controller generated the interrupt,
>> - * since this is a shared interrupt
>> - */
>> - irq_status = denali_irq_detected(denali);
>> - if (irq_status != 0) {
>> - /* handle interrupt */
>> - /* first acknowledge it */
>> - clear_interrupt(denali, irq_status);
>> - /*
>> - * store the status in the device context for someone
>> - * to read
>> - */
>> - denali->irq_status |= irq_status;
>> - /* notify anyone who cares that it happened */
>> - complete(&denali->complete);
>> - /* tell the OS that we've handled this */
>> - result = IRQ_HANDLED;
>> - }
>> + irq_status = denali->irq_status;
>> +
>> + if (irq_mask & irq_status) {
>> + spin_unlock_irqrestore(&denali->irq_lock, flags);
>> + return irq_status;
>> }
>> - spin_unlock(&denali->irq_lock);
>> - return result;
>> +
>> + denali->irq_mask = irq_mask;
>> + reinit_completion(&denali->complete);
>
> These 2 instructions should be done before calling
> denali_wait_for_irq() (for example in denali_reset_irq()), otherwise
> you might loose events if they happen between your irq_status read and
> the reinit_completion() call.
No.
denali->irq_lock avoids a race between denali_isr() and
denali_wait_for_irq().
The line
denali->irq_status |= irq_status;
in denali_isr() accumulates all events that have happened
since denali_reset_irq().
If the interested IRQs have already happened
before denali_wait_for_irq(), it just return immediately
without using completion.
I do not mind adding a comment like below
if you think my intention is unclear, though.
/* Return immediately if interested IRQs have already happend. */
if (irq_mask & irq_status) {
spin_unlock_irqrestore(&denali->irq_lock, flags);
return irq_status;
}
> You should also clear existing interrupts
> before launching your operation, otherwise you might wakeup on previous
> events.
I do not see a point in your suggestion.
denali_isr() reads out IRQ_STATUS(i) and immediately clears IRQ bits.
IRQ events triggered by previous events are accumulated in denali->irq_status.
denali_reset_irq() clears it.
denali->irq_status = 0;
Again, denali->irq_lock avoids a race between denali_reset_irq() and
denali_irq(),
so this works correctly.
--
Best Regards
Masahiro Yamada
Re: linux-next: bad base for the dmi quilt series
On Wed, 7 Jun 2017 09:29:08 +1000, Stephen Rothwell wrote: > Hi Jean, > > The current version of the dmi quilt series > (http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/) has a base of > 4.11.3 ... it must be base on somewhere in Linus' tree. I have used > v4.11 as a base for today (the patches applied cleanly). Oops, sorry about that. Fixed. -- Jean Delvare SUSE L3 Support
[PATCH] Fix loop device flush before configure
While installing SLES-12 (based on v4.4), I found that the installer
will stall for 60+ seconds during LVM disk scan. The root cause was
determined to be the removal of a bound device check in loop_flush()
by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
Restoring this check, examining ->lo_state as set by loop_set_fd()
eliminates the bad behavior.
Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K
for((i=0;i<4;i++))do losetup -f disk; done
mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
for f in `ls /dev/loop[0-9]*|sort`; do \
echo $f; dd if=$f of=/dev/null bs=512 count=1; \
done
Test output: stock patched
/dev/loop018.1217e-058.3842e-05
/dev/loop1 6.1114e-050.000147979
/dev/loop100.414701 0.000116564
/dev/loop110.74746.7942e-05
/dev/loop120.747986 8.9082e-05
/dev/loop130.746532 7.4799e-05
/dev/loop140.480041 9.3926e-05
/dev/loop151.26453 7.2522e-05
Note that from loop10 onward, the device is not mounted, yet the
stock kernel consumes several orders of magnitude more wall time
than it does for a mounted device.
(Thanks for Mike Galbraith , give a changelog review.)
Reviewed-by: Hannes Reinecke
Reviewed-by: Ming Lei
Signed-off-by: James Wang
Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
---
drivers/block/loop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 48f6fa6f810e..2e5b8538760c 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -625,6 +625,9 @@ static int loop_switch(struct loop_device *lo, struct file
*file)
*/
static int loop_flush(struct loop_device *lo)
{
+ /* loop not yet configured, no running thread, nothing to flush */
+ if (lo->lo_state != Lo_bound)
+ return 0;
return loop_switch(lo, NULL);
}
--
2.12.3
Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3
On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption bit that indicates
> the PGD is encrypted. The encryption bit should not be used when creating
> a virtual address for the PGD table.
>
> Create a new function, read_cr3_pa(), that will extract the physical
> address from the cr3 register. This function is then used where a virtual
> address of the PGD needs to be created/used from the cr3 register.
This is going to conflict with:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pcid&id=555c81e5d01a62b629ec426a2f50d27e2127c1df
We're both encountering the fact that CR3 munges the page table PA
with some other stuff, and some readers want to see the actual CR3
value and other readers just want the PA. The thing I prefer about my
patch is that I get rid of read_cr3() entirely, forcing the patch to
update every single reader, making review and conflict resolution much
safer.
I'd be willing to send a patch tomorrow that just does the split into
__read_cr3() and read_cr3_pa() (I like your name better) and then we
can both base on top of it. Would that make sense?
Also:
> +static inline unsigned long read_cr3_pa(void)
> +{
> + return (read_cr3() & PHYSICAL_PAGE_MASK);
> +}
Is there any guarantee that the magic encryption bit is masked out in
PHYSICAL_PAGE_MASK? The docs make it sound like it could be any bit.
(But if it's one of the low 12 bits, that would be quite confusing.)
--Andy
linux-next: build failure after merge of the uuid tree
Hi Christoph,
After merging the uuid tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from drivers/base/cpu.c:16:0:
include/linux/acpi.h:744:16: error: unknown type name 'guid_t'
const guid_t *guid,
^
Caused by commit
94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
linux/uuid.h is only include for the CONFIG_ACPI case (in commit
41c8bdb3ab10 "acpi, nfit: Switch to use new generic UUID API"). This
build does not have CONFIG_ACPI set.
I have used the uuid tree from next-20170607 for today.
--
Cheers,
Stephen Rothwell
[PATCH 1/2] drivers/net/sungem: add const to mii_phy_ops structures
The object references of mii_phy_ops structures are only stored
in the ops field of a mii_phy_def structure. This ops field is of type
const. So, mii_phy_ops structures having similar properties can be
declared as const.
Signed-off-by: Bhumika Goyal
---
drivers/net/sungem_phy.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/sungem_phy.c b/drivers/net/sungem_phy.c
index 92578d72..63a8ff8 100644
--- a/drivers/net/sungem_phy.c
+++ b/drivers/net/sungem_phy.c
@@ -886,7 +886,7 @@ static int marvell_read_link(struct mii_phy *phy)
SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full)
/* Broadcom BCM 5201 */
-static struct mii_phy_ops bcm5201_phy_ops = {
+static const struct mii_phy_ops bcm5201_phy_ops = {
.init = bcm5201_init,
.suspend= bcm5201_suspend,
.setup_aneg = genmii_setup_aneg,
@@ -905,7 +905,7 @@ static struct mii_phy_def bcm5201_phy_def = {
};
/* Broadcom BCM 5221 */
-static struct mii_phy_ops bcm5221_phy_ops = {
+static const struct mii_phy_ops bcm5221_phy_ops = {
.suspend= bcm5221_suspend,
.init = bcm5221_init,
.setup_aneg = genmii_setup_aneg,
@@ -924,7 +924,7 @@ static struct mii_phy_def bcm5221_phy_def = {
};
/* Broadcom BCM 5241 */
-static struct mii_phy_ops bcm5241_phy_ops = {
+static const struct mii_phy_ops bcm5241_phy_ops = {
.suspend= bcm5241_suspend,
.init = bcm5241_init,
.setup_aneg = genmii_setup_aneg,
@@ -942,7 +942,7 @@ static struct mii_phy_def bcm5241_phy_def = {
};
/* Broadcom BCM 5400 */
-static struct mii_phy_ops bcm5400_phy_ops = {
+static const struct mii_phy_ops bcm5400_phy_ops = {
.init = bcm5400_init,
.suspend= bcm5400_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -961,7 +961,7 @@ static struct mii_phy_def bcm5400_phy_def = {
};
/* Broadcom BCM 5401 */
-static struct mii_phy_ops bcm5401_phy_ops = {
+static const struct mii_phy_ops bcm5401_phy_ops = {
.init = bcm5401_init,
.suspend= bcm5401_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -980,7 +980,7 @@ static struct mii_phy_def bcm5401_phy_def = {
};
/* Broadcom BCM 5411 */
-static struct mii_phy_ops bcm5411_phy_ops = {
+static const struct mii_phy_ops bcm5411_phy_ops = {
.init = bcm5411_init,
.suspend= generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -999,7 +999,7 @@ static struct mii_phy_def bcm5411_phy_def = {
};
/* Broadcom BCM 5421 */
-static struct mii_phy_ops bcm5421_phy_ops = {
+static const struct mii_phy_ops bcm5421_phy_ops = {
.init = bcm5421_init,
.suspend= generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1019,7 +1019,7 @@ static struct mii_phy_def bcm5421_phy_def = {
};
/* Broadcom BCM 5421 built-in K2 */
-static struct mii_phy_ops bcm5421k2_phy_ops = {
+static const struct mii_phy_ops bcm5421k2_phy_ops = {
.init = bcm5421_init,
.suspend= generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1037,7 +1037,7 @@ static struct mii_phy_def bcm5421k2_phy_def = {
.ops= &bcm5421k2_phy_ops
};
-static struct mii_phy_ops bcm5461_phy_ops = {
+static const struct mii_phy_ops bcm5461_phy_ops = {
.init = bcm5421_init,
.suspend= generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1057,7 +1057,7 @@ static struct mii_phy_def bcm5461_phy_def = {
};
/* Broadcom BCM 5462 built-in Vesta */
-static struct mii_phy_ops bcm5462V_phy_ops = {
+static const struct mii_phy_ops bcm5462V_phy_ops = {
.init = bcm5421_init,
.suspend= generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1076,7 +1076,7 @@ static struct mii_phy_def bcm5462V_phy_def = {
};
/* Marvell 88E1101 amd 88E */
-static struct mii_phy_ops marvell88e1101_phy_ops = {
+static const struct mii_phy_ops marvell88e1101_phy_ops = {
.suspend= generic_suspend,
.setup_aneg = marvell_setup_aneg,
.setup_forced = marvell_setup_forced,
@@ -1084,7 +1084,7 @@ static struct mii_phy_ops marvell88e1101_phy_ops = {
.read_link = marvell_read_link
};
-static struct mii_phy_ops marvell88e_phy_ops = {
+static const struct mii_phy_ops marvell88e_phy_ops = {
.init = marvell88e_init,
.suspend= generic_suspend,
.setup_aneg = marvell_setup_aneg,
@@ -1122,7 +1122,7 @@ static struct mii_phy_def marvell88e_phy_def = {
};
/* Generic implementation for most 10/100 PHYs */
-static struct mii_phy_ops generic_phy_ops = {
+static const struct mii_phy_ops generic_phy_ops = {
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
.poll_link = genmii_po
[PATCH 2/2] drivers: net: emac: add const to mii_phy_ops structures
The object references of mii_phy_ops structures are only stored
in the ops field of a mii_phy_def structure. This ops field is of type
const. So, mii_phy_ops structures having similar properties can be
declared as const.
Signed-off-by: Bhumika Goyal
---
drivers/net/ethernet/ibm/emac/phy.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/phy.c
b/drivers/net/ethernet/ibm/emac/phy.c
index 5b88cc6..35865d0 100644
--- a/drivers/net/ethernet/ibm/emac/phy.c
+++ b/drivers/net/ethernet/ibm/emac/phy.c
@@ -276,7 +276,7 @@ static int genmii_read_link(struct mii_phy *phy)
}
/* Generic implementation for most 10/100/1000 PHYs */
-static struct mii_phy_ops generic_phy_ops = {
+static const struct mii_phy_ops generic_phy_ops = {
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
.poll_link = genmii_poll_link,
@@ -340,7 +340,7 @@ static int cis8201_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops cis8201_phy_ops = {
+static const struct mii_phy_ops cis8201_phy_ops = {
.init = cis8201_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -420,7 +420,7 @@ static int et1011c_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops et1011c_phy_ops = {
+static const struct mii_phy_ops et1011c_phy_ops = {
.init = et1011c_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -439,7 +439,7 @@ static struct mii_phy_def et1011c_phy_def = {
-static struct mii_phy_ops m88e_phy_ops = {
+static const struct mii_phy_ops m88e_phy_ops = {
.init = m88e_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -455,7 +455,7 @@ static struct mii_phy_def m88e_phy_def = {
.ops= &m88e_phy_ops,
};
-static struct mii_phy_ops m88e1112_phy_ops = {
+static const struct mii_phy_ops m88e1112_phy_ops = {
.init = m88e1112_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -480,7 +480,7 @@ static int ar8035_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops ar8035_phy_ops = {
+static const struct mii_phy_ops ar8035_phy_ops = {
.init = ar8035_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
--
2.7.4
[PATCH 0/2] drivers: net: add const to mii_phy_ops structures
The object references of mii_phy_ops structures are only stored in the ops field of a mii_phy_def structure. This ops field is of type const. So, mii_phy_ops structures having similar properties can be declared as const. Bhumika Goyal (2): drivers/net/sungem: add const to mii_phy_ops structures drivers: net: emac: add const to mii_phy_ops structures drivers/net/ethernet/ibm/emac/phy.c | 12 ++-- drivers/net/sungem_phy.c| 26 +- 2 files changed, 19 insertions(+), 19 deletions(-) -- 2.7.4
[PATCH] perf report: Fix broken arrow at row 0 in annotate view
When the jump instruction is displayed at the row 0 in annotate view, the arrow is broken. An example: 16.86 │ ┌──je 82 0.01 │ movsd (%rsp),%xmm0 │ movsd 0x8(%rsp),%xmm4 │ movsd 0x8(%rsp),%xmm1 │ movsd (%rsp),%xmm3 │ divsd %xmm4,%xmm0 │ divsd %xmm3,%xmm1 │ movsd (%rsp),%xmm2 │ addsd %xmm1,%xmm0 │ addsd %xmm2,%xmm0 │ movsd %xmm0,(%rsp) │82: sub$0x1,%ebx 83.03 │↑ jne38 │ add$0x10,%rsp │ xor%eax,%eax │ pop%rbx │← retq The patch increments the row number before checking with 0. Signed-off-by: Jin Yao --- tools/perf/ui/browser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c index a4d3762..83874b0 100644 --- a/tools/perf/ui/browser.c +++ b/tools/perf/ui/browser.c @@ -704,7 +704,7 @@ static void __ui_browser__line_arrow_down(struct ui_browser *browser, ui_browser__gotorc(browser, row, column + 1); SLsmg_draw_hline(2); - if (row++ == 0) + if (++row == 0) goto out; } else row = 0; -- 2.7.4
Re: [PATCH v2] refcount: Create unchecked atomic_t implementation
On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote: > Many subsystems will not use refcount_t unless there is a way to build the > kernel so that there is no regression in speed compared to atomic_t. This > adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation > which has the validation but is slightly slower. When not enabled, > refcount_t uses the basic unchecked atomic_t routines, which results in > no code changes compared to just using atomic_t directly. > > Signed-off-by: Kees Cook Acked-by: Greg Kroah-Hartman
Re: [PATCH] Fix loop device flush before configure v2
On 06/08/2017 01:06 PM, Mike Galbraith wrote:
> On Thu, 2017-06-08 at 10:17 +0800, James Wang wrote:
>> This condition check was exist at before commit b5dd2f6047ca ("block: loop:
>> improve performance via blk-mq") When add MQ support to loop device, it be
>> removed because the member of '->lo_thread' be removed. And then upstream
>> add '->worker_task', I think they forget add it to here.
>>
>> When I install SLES-12 product is base on 4.4 kernel I found installer will
>> hang +60 second at scan disks. and I found LVM tools would take this action.
>> finally I found this problem is more obvious on AMD platform. This problem
>> will impact all scenarios that scan loop devcie.
>>
>> When the loop device didn't configure backing file or Request Queue, we
>> shouldn't to cost a lot of time to flush it.
> The changelog sounds odd to me, perhaps reword/condense a bit?...
>
> While installing SLES-12 (based on v4.4), I found that the installer
> will stall for 60+ seconds during LVM disk scan. The root cause was
> determined to be the removal of a bound device check in loop_flush()
> by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
>
> Restoring this check, examining ->lo_state as set by loop_set_fd()
> eliminates the bad behavior.
Thank you sir. I will rewrite this changelog.
> Test method:
> modprobe loop max_loop=64
> dd if=/dev/zero of=disk bs=512 count=200K
> for((i=0;i<4;i++))do losetup -f disk; done
> mkfs.ext4 -F /dev/loop0
> for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
> for f in `ls /dev/loop[0-9]*|sort`; do \
> echo $f; dd if=$f of=/dev/null bs=512 count=1; \
> done
>
> Test output: stock patched
> /dev/loop018.1217e-058.3842e-05
> /dev/loop1 6.1114e-050.000147979
> /dev/loop100.414701 0.000116564
> /dev/loop110.74746.7942e-05
> /dev/loop120.747986 8.9082e-05
> /dev/loop130.746532 7.4799e-05
> /dev/loop140.480041 9.3926e-05
> /dev/loop151.26453 7.2522e-05
>
> Note that from loop10 onward, the device is not mounted, yet the
> stock kernel consumes several orders of magnitude more wall time
> than it does for a mounted device.
>
> Reviewed-by: Hannes Reinecke
> Signed-off-by: James Wang
> Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
> ---
>> drivers/block/loop.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index 48f6fa6f810e..2e5b8538760c 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -625,6 +625,9 @@ static int loop_switch(struct loop_device *lo, struct
>> file *file)
>> */
>> static int loop_flush(struct loop_device *lo)
>> {
>> +/* loop not yet configured, no running thread, nothing to flush */
>> +if (lo->lo_state != Lo_bound)
>> +return 0;
>> return loop_switch(lo, NULL);
>> }
>>
>
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Re: [PATCH v6 25/34] swiotlb: Add warnings for use of bounce buffers with SME
Hi Tom, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc4 next-20170607] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tom-Lendacky/x86-Secure-Memory-Encryption-AMD/20170608-104147 config: sparc-defconfig (attached as .config) compiler: sparc-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc All errors (new ones prefixed by >>): In file included from include/linux/dma-mapping.h:13:0, from include/linux/skbuff.h:34, from include/linux/filter.h:12, from kernel//bpf/core.c:24: >> include/linux/mem_encrypt.h:16:29: fatal error: asm/mem_encrypt.h: No such >> file or directory #include ^ compilation terminated. vim +16 include/linux/mem_encrypt.h 2d7c2ec4 Tom Lendacky 2017-06-07 10 * published by the Free Software Foundation. 2d7c2ec4 Tom Lendacky 2017-06-07 11 */ 2d7c2ec4 Tom Lendacky 2017-06-07 12 2d7c2ec4 Tom Lendacky 2017-06-07 13 #ifndef __MEM_ENCRYPT_H__ 2d7c2ec4 Tom Lendacky 2017-06-07 14 #define __MEM_ENCRYPT_H__ 2d7c2ec4 Tom Lendacky 2017-06-07 15 2d7c2ec4 Tom Lendacky 2017-06-07 @16 #include 2d7c2ec4 Tom Lendacky 2017-06-07 17 2d7c2ec4 Tom Lendacky 2017-06-07 18 #endif/* __MEM_ENCRYPT_H__ */ :: The code at line 16 was first introduced by commit :: 2d7c2ec4c60e83432b27bfb32042706f404d4158 x86/mm: Add Secure Memory Encryption (SME) support :: TO: Tom Lendacky :: CC: 0day robot --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
RE: [PATCH V2 2/3] watchdog: uniphier: add UniPhier watchdog driver
Hello Yamada-san, > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > I think you should have added on the top > to keep the includes alphabetically sorted. Sorry, I will fix in v3 patch. -- Best Regards, Keiji Hayashibara
[PATCH v5 2/6] dt-bindings: qcom: Add ipq8074 bindings
Acked-by: Rob Herring Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/arm/qcom.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.txt b/Documentation/devicetree/bindings/arm/qcom.txt index 028d16e..0ed4d39 100644 --- a/Documentation/devicetree/bindings/arm/qcom.txt +++ b/Documentation/devicetree/bindings/arm/qcom.txt @@ -25,6 +25,7 @@ The 'SoC' element must be one of the following strings: msm8994 msm8996 mdm9615 + ipq8074 The 'board' element must be one of the following strings: @@ -33,6 +34,7 @@ The 'board' element must be one of the following strings: dragonboard mtp sbc + hk01 The 'soc_version' and 'board_version' elements take the form of v. where the minor number may be omitted when it's zero, i.e. v1.0 is the same -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 5/6] arm64: dts: Add ipq8074 SoC and HK01 board support
Add initial device tree support for the Qualcomm IPQ8074 SoC and
HK01 evaluation board.
Signed-off-by: Manoharan Vijaya Raghavan
Signed-off-by: Abhishek Sahu
Signed-off-by: Varadarajan Narayanan
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 53
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 194 ++
3 files changed, 248 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
create mode 100644 arch/arm64/boot/dts/qcom/ipq8074.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index cc0f02d..ff81d7e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,5 +1,6 @@
dtb-$(CONFIG_ARCH_QCOM)+= apq8016-sbc.dtb
dtb-$(CONFIG_ARCH_QCOM)+= apq8096-db820c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= ipq8074-hk01.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
new file mode 100644
index 000..7d44be9
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -0,0 +1,53 @@
+/dts-v1/;
+/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include "ipq8074.dtsi"
+
+/ {
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ model = "Qualcomm Technologies, Inc. IPQ8074-HK01";
+ compatible = "qcom,ipq8074-hk01", "qcom,ipq8074";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ serial0 = &blsp1_uart5;
+ };
+
+ chosen {
+ bootargs = "root=/dev/ram0 rw init=/init";
+ stdout-path = "serial0";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x4000 0x0 0x2000>;
+ };
+
+ soc {
+ pinctrl@100 {
+ serial_4_pins: serial4_pinmux {
+ mux {
+ pins = "gpio23", "gpio24";
+ function = "blsp4_uart1";
+ bias-disable;
+ };
+ };
+ };
+
+ serial@78b3000 {
+ pinctrl-0 = <&serial_4_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
new file mode 100644
index 000..2bc5dec
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -0,0 +1,194 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ8074";
+ compatible = "qcom,ipq8074";
+
+ soc: soc {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ ranges = <0 0 0 0x>;
+ compatible = "simple-bus";
+
+ pinctrl@100 {
+ compatible = "qcom,ipq8074-pinctrl";
+ reg = <0x100 0x30>;
+ interrupts = ;
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+ };
+
+ intc: interrupt-controller@b00 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <0x3>;
+ reg = <0xb00 0x1000>, <0xb002000 0x1000>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+
[PATCH v5 6/6] arm64: defconfig: Enable qcom ipq8074 clock and pinctrl
From: Abhishek Sahu These configs are required for booting kernel in qcom ipq8074 boards. Signed-off-by: Abhishek Sahu Signed-off-by: Varadarajan Narayanan --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 65cdd87..c20328e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -267,6 +267,7 @@ CONFIG_SPI_S3C64XX=y CONFIG_SPI_SPIDEV=m CONFIG_SPMI=y CONFIG_PINCTRL_SINGLE=y +CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_MAX77620=y CONFIG_PINCTRL_MSM8916=y CONFIG_PINCTRL_MSM8994=y @@ -450,6 +451,7 @@ CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y CONFIG_COMMON_CLK_QCOM=y CONFIG_QCOM_CLK_SMD_RPM=y +CONFIG_IPQ_GCC_8074=y CONFIG_MSM_GCC_8916=y CONFIG_MSM_GCC_8994=y CONFIG_MSM_MMCC_8996=y -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 4/6] clk: qcom: Add ipq8074 Global Clock Controller support
From: Abhishek Sahu
This patch adds support for the global clock controller found on
the ipq8074 based devices. This includes UART, I2C, SPI etc.
Signed-off-by: Abhishek Sahu
Signed-off-by: Varadarajan Narayanan
---
drivers/clk/qcom/Kconfig |9 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-ipq8074.c | 1007
3 files changed, 1017 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-ipq8074.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 5fb8d74..9f6c278 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -82,6 +82,15 @@ config IPQ_LCC_806X
Say Y if you want to use audio devices such as i2s, pcm,
S/PDIF, etc.
+config IPQ_GCC_8074
+ tristate "IPQ8074 Global Clock Controller"
+ depends on COMMON_CLK_QCOM
+ help
+ Support for global clock controller on ipq8074 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, SD/eMMC, etc. Select this for the root clock
+ of ipq8074.
+
config MSM_GCC_8660
tristate "MSM8660 Global Clock Controller"
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 1c3e222..3f3aff2 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
+obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
obj-$(CONFIG_MDM_LCC_9615) += lcc-mdm9615.o
diff --git a/drivers/clk/qcom/gcc-ipq8074.c b/drivers/clk/qcom/gcc-ipq8074.c
new file mode 100644
index 000..0f735d3
--- /dev/null
+++ b/drivers/clk/qcom/gcc-ipq8074.c
@@ -0,0 +1,1007 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
+
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+ P_XO,
+ P_GPLL0,
+ P_GPLL0_DIV2,
+};
+
+static const char * const gcc_xo_gpll0_gpll0_out_main_div2[] = {
+ "xo",
+ "gpll0",
+ "gpll0_out_main_div2",
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll0_out_main_div2_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL0_DIV2, 4 },
+};
+
+static struct clk_alpha_pll gpll0_main = {
+ .offset = 0x21000,
+ .clkr = {
+ .enable_reg = 0x0b000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0_main",
+ .parent_names = (const char *[]){
+ "xo"
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_ops,
+ },
+ },
+};
+
+static struct clk_fixed_factor gpll0_out_main_div2 = {
+ .mult = 1,
+ .div = 2,
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0_out_main_div2",
+ .parent_names = (const char *[]){
+ "gpll0_main"
+ },
+ .num_parents = 1,
+ .ops = &clk_fixed_factor_ops,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
+static struct clk_alpha_pll_postdiv gpll0 = {
+ .offset = 0x21000,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpll0",
+ .parent_names = (const char *[]){
+ "gpll0_main"
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_postdiv_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_pcnoc_bfdcd_clk_src[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(5000, P_GPLL0, 16, 0, 0),
+ F(1, P_GPLL0, 8, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 pcnoc_bfdcd_clk_src = {
+ .cmd_rcgr = 0x27000,
+ .freq_tbl = ftbl_pcnoc_bfdcd_clk_src,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_gpll0_out_main_div2_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "pcnoc_bfdcd_clk_src",
+
[PATCH v5 3/6] clk: qcom: Add DT bindings for ipq8074 gcc clock controller
From: Abhishek Sahu Add the compatible strings and the include file for ipq8074 gcc clock controller. Acked-by: Rob Herring (bindings) Signed-off-by: Varadarajan Narayanan Signed-off-by: Abhishek Sahu --- .../devicetree/bindings/clock/qcom,gcc.txt | 1 + include/dt-bindings/clock/qcom,gcc-ipq8074.h | 152 + 2 files changed, 153 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq8074.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 5b4dfc1..551d03b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -8,6 +8,7 @@ Required properties : "qcom,gcc-apq8084" "qcom,gcc-ipq8064" "qcom,gcc-ipq4019" + "qcom,gcc-ipq8074" "qcom,gcc-msm8660" "qcom,gcc-msm8916" "qcom,gcc-msm8960" diff --git a/include/dt-bindings/clock/qcom,gcc-ipq8074.h b/include/dt-bindings/clock/qcom,gcc-ipq8074.h new file mode 100644 index 000..370c83c --- /dev/null +++ b/include/dt-bindings/clock/qcom,gcc-ipq8074.h @@ -0,0 +1,152 @@ +/* + * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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. + */ + +#ifndef _DT_BINDINGS_CLOCK_IPQ_GCC_8074_H +#define _DT_BINDINGS_CLOCK_IPQ_GCC_8074_H + +#define GPLL0 0 +#define GPLL0_MAIN 1 +#define GCC_SLEEP_CLK_SRC 2 +#define BLSP1_QUP1_I2C_APPS_CLK_SRC3 +#define BLSP1_QUP1_SPI_APPS_CLK_SRC4 +#define BLSP1_QUP2_I2C_APPS_CLK_SRC5 +#define BLSP1_QUP2_SPI_APPS_CLK_SRC6 +#define BLSP1_QUP3_I2C_APPS_CLK_SRC7 +#define BLSP1_QUP3_SPI_APPS_CLK_SRC8 +#define BLSP1_QUP4_I2C_APPS_CLK_SRC9 +#define BLSP1_QUP4_SPI_APPS_CLK_SRC10 +#define BLSP1_QUP5_I2C_APPS_CLK_SRC11 +#define BLSP1_QUP5_SPI_APPS_CLK_SRC12 +#define BLSP1_QUP6_I2C_APPS_CLK_SRC13 +#define BLSP1_QUP6_SPI_APPS_CLK_SRC14 +#define BLSP1_UART1_APPS_CLK_SRC 15 +#define BLSP1_UART2_APPS_CLK_SRC 16 +#define BLSP1_UART3_APPS_CLK_SRC 17 +#define BLSP1_UART4_APPS_CLK_SRC 18 +#define BLSP1_UART5_APPS_CLK_SRC 19 +#define BLSP1_UART6_APPS_CLK_SRC 20 +#define GCC_BLSP1_AHB_CLK 21 +#define GCC_BLSP1_QUP1_I2C_APPS_CLK22 +#define GCC_BLSP1_QUP1_SPI_APPS_CLK23 +#define GCC_BLSP1_QUP2_I2C_APPS_CLK24 +#define GCC_BLSP1_QUP2_SPI_APPS_CLK25 +#define GCC_BLSP1_QUP3_I2C_APPS_CLK26 +#define GCC_BLSP1_QUP3_SPI_APPS_CLK27 +#define GCC_BLSP1_QUP4_I2C_APPS_CLK28 +#define GCC_BLSP1_QUP4_SPI_APPS_CLK29 +#define GCC_BLSP1_QUP5_I2C_APPS_CLK30 +#define GCC_BLSP1_QUP5_SPI_APPS_CLK31 +#define GCC_BLSP1_QUP6_I2C_APPS_CLK32 +#define GCC_BLSP1_QUP6_SPI_APPS_CLK33 +#define GCC_BLSP1_UART1_APPS_CLK 34 +#define GCC_BLSP1_UART2_APPS_CLK 35 +#define GCC_BLSP1_UART3_APPS_CLK 36 +#define GCC_BLSP1_UART4_APPS_CLK 37 +#define GCC_BLSP1_UART5_APPS_CLK 38 +#define GCC_BLSP1_UART6_APPS_CLK 39 +#define GCC_PRNG_AHB_CLK 40 +#define GCC_QPIC_AHB_CLK 41 +#define GCC_QPIC_CLK 42 +#define PCNOC_BFDCD_CLK_SRC43 + +#define GCC_BLSP1_BCR 0 +#define GCC_BLSP1_QUP1_BCR 1 +#define GCC_BLSP1_UART1_BCR2 +#define GCC_BLSP1_QUP2_BCR 3 +#define GCC_BLSP1_UART2_BCR4 +#define GCC_BLSP1_QUP3_BCR 5 +#define GCC_BLSP1_UART3_BCR6 +#define GCC_BLSP1_QUP4_BCR 7 +#define GCC_BLSP1_UART4_BCR8 +#define GCC_BLSP1_QUP5_BCR 9 +#define GCC_BLSP1_UART5_BCR10 +#define GCC_BLSP1_QUP6_BCR 11 +#define GCC_BLSP1_UART6_BCR12 +#define GCC_IMEM_BCR 13 +#define GCC_SMMU_BCR 14 +#define GCC_APSS_TCU_BCR 15 +#define GCC_SMMU_XPU_BC
[PATCH v5 0/6] Add minimal boot support for IPQ8074
v5: * Removed the 'NA' binding from documentation v4: * Split the clock patch and addressed a minor comment in the clock driver as per stephen's feedback. v3: * Addressed review feedback from Bjorn for pinctrl - Unified the names for qpic pads. - Corrected the names for pwm pins. * Updated pinctrl documentation. * Updated the default bootargs in ipq8074-hk01.dts. * Updated the gcc clocks driver for removing the unused halt_bit in few places. v2: * Addressed review feedback from Stephen - Removed cpu-map entries - Added mmio-timer nodes * Fix sparse warnings in the gcc-ipq8074.c * Updated pinctrl documentation v1: https://www.spinics.net/lists/kernel/msg2498734.html This series adds minimal board boot support for ipq8074-hk01 board. Abhishek Sahu (3): clk: qcom: Add DT bindings for ipq8074 gcc clock controller clk: qcom: Add ipq8074 Global Clock Controller support arm64: defconfig: Enable qcom ipq8074 clock and pinctrl Varadarajan Narayanan (3): pinctrl: qcom: Add ipq8074 pinctrl driver dt-bindings: qcom: Add ipq8074 bindings arm64: dts: Add ipq8074 SoC and HK01 board support Documentation/devicetree/bindings/arm/qcom.txt |2 + .../devicetree/bindings/clock/qcom,gcc.txt |1 + .../bindings/pinctrl/qcom,ipq8074-pinctrl.txt | 172 arch/arm64/boot/dts/qcom/Makefile |1 + arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 53 + arch/arm64/boot/dts/qcom/ipq8074.dtsi | 194 arch/arm64/configs/defconfig |2 + drivers/clk/qcom/Kconfig |9 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/gcc-ipq8074.c | 1007 ++ drivers/pinctrl/qcom/Kconfig | 10 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-ipq8074.c | 1076 include/dt-bindings/clock/qcom,gcc-ipq8074.h | 152 +++ 14 files changed, 2681 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts create mode 100644 arch/arm64/boot/dts/qcom/ipq8074.dtsi create mode 100644 drivers/clk/qcom/gcc-ipq8074.c create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq8074.c create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq8074.h -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v5 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver
Add initial pinctrl driver to support pin configuration with pinctrl framework for ipq8074. Signed-off-by: Manoharan Vijaya Raghavan Signed-off-by: Varadarajan Narayanan --- .../bindings/pinctrl/qcom,ipq8074-pinctrl.txt | 172 drivers/pinctrl/qcom/Kconfig | 10 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-ipq8074.c | 1076 4 files changed, 1259 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq8074.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt new file mode 100644 index 000..407b944 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt @@ -0,0 +1,172 @@ +Qualcomm Technologies, Inc. IPQ8074 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +IPQ8074 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,ipq8074-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio69 + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + atest_char, atest_char0, atest_char1, atest_char2, + atest_char3, audio_rxbclk, audio_rxd, audio_rxfsync, + audio_rxmclk, audio_txbclk, audio_txd, audio_txfsync, + audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart, blsp1_i2c, + blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi, blsp2_uart, + blsp3_i2c, blsp3_spi, blsp3_spi0, blsp3_spi1, blsp3_spi2, + blsp3_spi3, blsp3_uart, blsp4_i2c0, blsp4_i2c1, blsp4_spi0, + blsp4_spi1, blsp4_uart0, blsp4_uart1, blsp5_i2c, blsp5_spi, + blsp5_uart, burn0, burn1, cri_trng, cri_trng0, cri_trng1, + cxc0, cxc1, dbg_out, gcc_plltest, gcc_tlmm, gpio, ldo_en, + ldo_update, led0, led1, led2, mac0_sa0, mac0_sa1, mac1_sa0, + mac1_sa1, mac1_sa2, mac1_sa3, mac2_sa0, mac2_sa1, mdc, + mdio, pcie0_clk, pcie0_rst, pcie0_wake, pcie1_clk, + pcie1_rst, pcie1_wake, pcm_drx, pcm_dtx, pcm_fsync, + pcm_pclk, pcm_zsi0, pcm_zsi1, prng_rosc, pta1_0, pta1_1, + pta1_2, pta2_0
Re: [PATCH 46/58] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks
Le Thu, 8 Jun 2017 01:17:15 +0200,
Alexandre Belloni a écrit :
> On 07/06/2017 at 23:08:48 +0200, Daniel Lezcano wrote:
> > > I was going to agree but this is not flexible enough because the
> > > quadrature decoder always uses the first two channels. So on some
> > > products, we may have:
> > > - TCB0:
> > >o channels 0,1: qdec
> > >o channel 2: clocksource
> > >
> > > - TCB1:
> > >o channels 0,1: qdec
> > >o channel 2: clockevent
> > >
> > > This avoids wasting TCB channels.
> >
> > Ok. In this case you can check if the interrupt is specified for the node,
> > if
> > yes, then it is a clockevent.
> >
>
> But currently it is always specified in the SoC's dtsi. I don't find
> that too practical to push that to the board's dts. Also, lying by
> omission (the IRQ is always wired) in the DT is not different from
> having a property selecting which timer is the clocksource and which is
> the clockevent.
>
I agree with Alexandre here. Really, there's not much we can do to
detect which timer should be used as a clockevent and which one should
be used as a clocksource except explicitly specifying it in the DT.
Having an interrupt defined in one case (clockevent) and undefined in
the other case (clocksource), is just as hack-ish as the detection logic
Alexandre developed to avoid explicitly specifying the function
assigned to a specific timer.
Can we please find a solution that makes everyone happy (DT,
clocksoure/clockevent and at91 maintainers)?
How about adding a linux,timer-function property to specify which
function this timer is providing?
Something like that for example:
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
#address-cells = <1>;
#size-cells = <0>;
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
clocks = <&tcb0_clk>, <&clk32k>;
clock-names = "t0_clk", "slow_clk";
timer@0 {
compatible = "atmel,tcb-timer";
reg = <0>, <1>;
linux,timer-function = "clocksource";
};
timer@2 {
compatible = "atmel,tcb-timer";
reg = <2>;
linux,timer-function = "clockevent";
};
};
Alternatively, we could have a property or a node in chosen describing which
timer should be used:
chosen {
clockevent {
timer = <&timer2>;
};
clocksource {
timer = <&timer0>;
};
/*
* or
*
* clockevent = <&timer2>;
* clocksource = <&timer0>;
*
* but I think the clocksource/clockevent node approach
* is more future proof in case we need to add extra
* information like the expected resolution/precision or
* anything that could be tweakable.
*/
};
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
#address-cells = <1>;
#size-cells = <0>;
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
clocks = <&tcb0_clk>, <&clk32k>;
clock-names = "t0_clk", "slow_clk";
timer0: timer@0 {
compatible = "atmel,tcb-timer";
reg = <0>, <1>;
};
timer2: timer@2 {
compatible = "atmel,tcb-timer";
reg = <2>;
};
};
Re: [PATCH] x86/efi: fix boot panic because of invalid bgrt image address
The subject tag should be efi instead of x86/efi since the code
is in general driver code now. Matt/Ard, if need resend please let me
know. Please help review the patch.
Maniaxx, can you verify it on your machine? It passed my test with
an emulation of your wrong address.
On 06/08/17 at 01:32pm, Dave Young wrote:
> Maniaxx reported kernel boot panic similar to
> below:
> (emulated the panic with using same invalid phys addr in a uefi vm)
> There are also a bug in bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=195633
>
> This happens after below commit:
> 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
>
> The root cause is the firmware on those machines provides invalid bgrt
> image addresses.
>
> With original efi bgrt code we initialize bgrt late
> and use ioremap to map the image address. In ioremap code we check the
> address is a valid physical address or not before really map it.
>
> With current new efi bgrt code we moved the initialization to early code
> so we switch to early_memremap which does not check the phys_addr like
> ioremap does. This lead to the early kernel panics.
>
> Fix this by checking the image physical address, if it is not within
> any EFI_BOOT_SERVICES_DATA areas then we just bail out. It is stronger
> then the original ioremap checking, according to spec the BGRT data
> should fall into EFI_BOOT_SERVICES_DATA.
>
> [0.00] BUG: unable to handle kernel paging request at ff280001
> [0.00] IP: efi_bgrt_init+0xfb/0x153
> [0.00] PGD 6e00b067
> [0.00] P4D 6e00b067
> [0.00] PUD 6e00d067
> [0.00] PMD 6e221067
> [0.00] PTE 8a08e0180163
> [0.00]
> [0.00] Oops: 0009 [#1] SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0-rc4+ #135
> [0.00] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0
> 02/06/2015
> [0.00] task: 9840f4c0 task.stack: 9840
> [0.00] RIP: 0010:efi_bgrt_init+0xfb/0x153
> [0.00] RSP: :98403d50 EFLAGS: 00010082
> [0.00] RAX: ff280001 RBX: RCX:
> 0006
> [0.00] RDX: 0a08e0181000 RSI: 8a08e0180163 RDI:
> 057e
> [0.00] RBP: 98403d68 R08: 0041 R09:
> 0002
> [0.00] R10: R11: 8c063cff8fc6 R12:
> 981d1fb2
> [0.00] R13: 986b4fa0 R14: 0010 R15:
>
> [0.00] FS: () GS:984db000()
> knlGS:
> [0.00] CS: 0010 DS: ES: CR0: 80050033
> [0.00] CR2: ff280001 CR3: 6e00a000 CR4:
> 000406b0
> [0.00] Call Trace:
> [0.00] ? bgrt_init+0xbc/0xbc
> [0.00] acpi_parse_bgrt+0xe/0x12
> [0.00] acpi_table_parse+0x89/0xb8
> [0.00] acpi_boot_init+0x445/0x4e2
> [0.00] ? acpi_parse_x2apic+0x79/0x79
> [0.00] ? dmi_ignore_irq0_timer_override+0x33/0x33
> [0.00] setup_arch+0xb63/0xc82
> [0.00] ? early_idt_handler_array+0x120/0x120
> [0.00] start_kernel+0xb7/0x443
> [0.00] ? early_idt_handler_array+0x120/0x120
> [0.00] x86_64_start_reservations+0x29/0x2b
> [0.00] x86_64_start_kernel+0x154/0x177
> [0.00] secondary_startup_64+0x9f/0x9f
> [0.00] Code: 3f ff eb 6c 48 bf 01 00 00 00 18 e0 08 0a be 06 00 00 00
> e8 ef 2b fe ff 48 85 c0 75 0e 48 c7 c7 88 09 22 98 e8 e1 31 3f ff eb 45 <66>
> 44 8b 20 be 06 00 00 00 48 89 c7 8b 58 02 e8 91 2c fe ff 66
> [0.00] RIP: efi_bgrt_init+0xfb/0x153 RSP: 98403d50
> [0.00] CR2: ff280001
> [0.00] ---[ end trace 9843d3b7cbcab26a ]---
> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> [0.00] ---[ end Kernel panic - not syncing: Attempted to kill the
> idle task!
>
> Fixes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
> Reported-by: Maniaxx
> Signed-off-by: Dave Young
> ---
> drivers/firmware/efi/efi-bgrt.c | 29 +
> 1 file changed, 29 insertions(+)
>
> --- linux.orig/drivers/firmware/efi/efi-bgrt.c
> +++ linux/drivers/firmware/efi/efi-bgrt.c
> @@ -27,6 +27,31 @@ struct bmp_header {
> u32 size;
> } __packed;
>
> +static bool efi_bgrt_addr_valid(u64 addr)
> +{
> + efi_memory_desc_t *md;
> +
> + if (!efi_enabled(EFI_MEMMAP)) {
> + pr_err("EFI_MEMMAP is not enabled.\n");
> + return true;
> + }
> +
> + for_each_efi_memory_desc(md) {
> + u64 size;
> + u64 end;
> +
> + if (md->type != EFI_BOOT_SERVICES_DATA)
> + continue;
> +
> + size = md->num_pages << EFI_PAGE_SHIFT;
> + end = md->phys_addr + size;
> + if (addr >= md->ph
Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste
On Wed, 7 Jun 2017 22:47:56 +0200
Heiko Carstens wrote:
> On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \
> > +({ \
> > + struct elf64_hdr *_ehdr = (void *) ehdr;\
> > + struct elf64_phdr *_phdr = (void *) phdr; \
> > + int _rc = 0;\
> > + if (_ehdr->e_ident[EI_CLASS] == ELFCLASS64 && \
> > + _phdr->p_type == PT_S390_REQUEST_PGSTE && \
> > + !page_table_allocate_pgste && \
> > + !test_thread_flag(TIF_REQUEST_PGSTE)) { \
> > + set_thread_flag(TIF_REQUEST_PGSTE); \
> > + set_pt_regs_flag(task_pt_regs(current), \
> > +PIF_SYSCALL_RESTART); \
> > + _rc = -EAGAIN; \
> > + } \
> > + _rc;\
> > +})
>
> I'm wondering if this should simply fail, if a PT_S390_REQUEST_PGSTE type
> segment exists, but it is not ELFCLASS64?
> It will fail later anyway on s390_enable_sie(), but...
Does it matter if it fails for a 32-bit ELF file? Just makes the code more
complex without benefit, no?
> > diff --git a/arch/s390/include/asm/mmu_context.h
> > b/arch/s390/include/asm/mmu_context.h
> > index c119d564d8f2..1201b18e817d 100644
> > --- a/arch/s390/include/asm/mmu_context.h
> > +++ b/arch/s390/include/asm/mmu_context.h
> > @@ -25,7 +25,8 @@ static inline int init_new_context(struct task_struct
> > *tsk,
> > mm->context.gmap_asce = 0;
> > mm->context.flush_mm = 0;
> > #ifdef CONFIG_PGSTE
> > - mm->context.alloc_pgste = page_table_allocate_pgste;
> > + mm->context.alloc_pgste = page_table_allocate_pgste ||
> > + test_thread_flag(TIF_REQUEST_PGSTE);
>
> I think the alloc_pgste flag should be inherited on fork, no?
Yes, that makes it more consistent. I'll add it.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH
On 08/06/17 15:35, Alexey Kardashevskiy wrote:
> Hi,
>
> How did you manage to have CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n? "make
> oldconfig" fixes this to CONFIG_VFIO_SPAPR_EEH=y.
Also, the attached config has "CONFIG_VFIO_SPAPR_EEH=m" and cannot produce
the error below, what am I missing here?
>
>
>
> On 08/06/17 02:31, kbuild test robot wrote:
>> Hi Murilo,
>>
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.12-rc4 next-20170607]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Murilo-Opsfelder-Araujo/include-linux-vfio-h-Guard-powerpc-specific-functions-with-CONFIG_VFIO_SPAPR_EEH/20170607-000643
>> config: powerpc-allmodconfig (attached as .config)
>> compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget
>> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
>> ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=powerpc
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/vfio/vfio_spapr_eeh.c:22:6: error: redefinition of
>>>> 'vfio_spapr_pci_eeh_open'
>> void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> ^~~
>>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>>include/linux/vfio.h:160:20: note: previous definition of
>> 'vfio_spapr_pci_eeh_open' was here
>> static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>^~~
>>>> drivers/vfio/vfio_spapr_eeh.c:28:6: error: redefinition of
>>>> 'vfio_spapr_pci_eeh_release'
>> void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>> ^~
>>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>>include/linux/vfio.h:164:20: note: previous definition of
>> 'vfio_spapr_pci_eeh_release' was here
>> static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>>^~
>>>> drivers/vfio/vfio_spapr_eeh.c:34:6: error: redefinition of
>>>> 'vfio_spapr_iommu_eeh_ioctl'
>> long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>> ^~
>>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>>include/linux/vfio.h:168:20: note: previous definition of
>> 'vfio_spapr_iommu_eeh_ioctl' was here
>> static inline long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>>^~
>>
>> vim +/vfio_spapr_pci_eeh_open +22 drivers/vfio/vfio_spapr_eeh.c
>>
>> 1b69be5e Gavin Shan 2014-06-10 16
>> 89a2edd6 Alexey Kardashevskiy 2014-08-08 17 #define DRIVER_VERSION "0.1"
>> 89a2edd6 Alexey Kardashevskiy 2014-08-08 18 #define DRIVER_AUTHOR "Gavin
>> Shan, IBM Corporation"
>> 89a2edd6 Alexey Kardashevskiy 2014-08-08 19 #define DRIVER_DESC"VFIO
>> IOMMU SPAPR EEH"
>> 89a2edd6 Alexey Kardashevskiy 2014-08-08 20
>> 1b69be5e Gavin Shan 2014-06-10 21 /* We might build address
>> mapping here for "fast" path later */
>> 9b936c96 Alexey Kardashevskiy 2014-08-08 @22 void
>> vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> 1b69be5e Gavin Shan 2014-06-10 23 {
>> 9b936c96 Alexey Kardashevskiy 2014-08-08 24 eeh_dev_open(pdev);
>> 1b69be5e Gavin Shan 2014-06-10 25 }
>> 92d18a68 Gavin Shan 2014-08-08 26
>> EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>> 1b69be5e Gavin Shan 2014-06-10 27
>> 1b69be5e Gavin Shan 2014-06-10 @28 void
>> vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>> 1b69be5e Gavin Shan 2014-06-10 29 {
>> 1b69be5e Gavin Shan 2014-06-10 30 eeh_dev_release(pdev);
>> 1b69be5e Gavin Shan 2014-06-10 31 }
>> 92d18a68 Gavin Shan 2014-08-08 32
>> EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
>> 1b69be5e Gavin Shan 2014-06-10 33
>> 1b69be5e Gavin Shan 2014-06-10 @34 long
>> vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>> 1b69be5e Gavin Shan 2014-06-10 35
>> unsigned int cmd, unsigned long arg)
>> 1b69be5e Gavin Shan 2014-06-10 36 {
>> 1b69be5e Gavin Shan 2014-06-10 37 struct eeh_pe *pe;
>>
>> :: The code at line 22 was first introduced by commit
>> :: 9b936c960f22954bfb89f2fefd8f96916bb42908 drivers/vfio: Enable VFIO if
>> EEH is not supported
>>
>> :: TO: Alexey Kardashevskiy
>> :: CC: Alex Williamson
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>>
>
>
--
Alexey
[PATCH] staging/lustre: echo_client.c - fix sparse warning: cast removes address space of expression
The function only cares about the value of the pointer, not the contents of the pointed-to data. Adding a `__force` annotation to the cast removes this warning. Signed-off-by: Guillermo O. Freschi --- drivers/staging/lustre/lustre/obdecho/echo_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/obdecho/echo_client.c b/drivers/staging/lustre/lustre/obdecho/echo_client.c index d4768311cf92..1757714c56a0 100644 --- a/drivers/staging/lustre/lustre/obdecho/echo_client.c +++ b/drivers/staging/lustre/lustre/obdecho/echo_client.c @@ -1428,7 +1428,7 @@ static int echo_client_brw_ioctl(const struct lu_env *env, int rw, oa->o_valid &= ~OBD_MD_FLHANDLE; /* OFD/obdfilter works only via prep/commit */ - test_mode = (long)data->ioc_pbuf1; + test_mode = (__force long)data->ioc_pbuf1; if (test_mode == 1) async = 0; -- 2.11.0
Re: [PATCH] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH
Hi,
How did you manage to have CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n? "make
oldconfig" fixes this to CONFIG_VFIO_SPAPR_EEH=y.
On 08/06/17 02:31, kbuild test robot wrote:
> Hi Murilo,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.12-rc4 next-20170607]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Murilo-Opsfelder-Araujo/include-linux-vfio-h-Guard-powerpc-specific-functions-with-CONFIG_VFIO_SPAPR_EEH/20170607-000643
> config: powerpc-allmodconfig (attached as .config)
> compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=powerpc
>
> All errors (new ones prefixed by >>):
>
>>> drivers/vfio/vfio_spapr_eeh.c:22:6: error: redefinition of
>>> 'vfio_spapr_pci_eeh_open'
> void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> ^~~
>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>include/linux/vfio.h:160:20: note: previous definition of
> 'vfio_spapr_pci_eeh_open' was here
> static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>^~~
>>> drivers/vfio/vfio_spapr_eeh.c:28:6: error: redefinition of
>>> 'vfio_spapr_pci_eeh_release'
> void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> ^~
>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>include/linux/vfio.h:164:20: note: previous definition of
> 'vfio_spapr_pci_eeh_release' was here
> static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>^~
>>> drivers/vfio/vfio_spapr_eeh.c:34:6: error: redefinition of
>>> 'vfio_spapr_iommu_eeh_ioctl'
> long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> ^~
>In file included from drivers/vfio/vfio_spapr_eeh.c:14:0:
>include/linux/vfio.h:168:20: note: previous definition of
> 'vfio_spapr_iommu_eeh_ioctl' was here
> static inline long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>^~
>
> vim +/vfio_spapr_pci_eeh_open +22 drivers/vfio/vfio_spapr_eeh.c
>
> 1b69be5e Gavin Shan 2014-06-10 16
> 89a2edd6 Alexey Kardashevskiy 2014-08-08 17 #define DRIVER_VERSION "0.1"
> 89a2edd6 Alexey Kardashevskiy 2014-08-08 18 #define DRIVER_AUTHOR "Gavin
> Shan, IBM Corporation"
> 89a2edd6 Alexey Kardashevskiy 2014-08-08 19 #define DRIVER_DESC "VFIO
> IOMMU SPAPR EEH"
> 89a2edd6 Alexey Kardashevskiy 2014-08-08 20
> 1b69be5e Gavin Shan 2014-06-10 21 /* We might build address
> mapping here for "fast" path later */
> 9b936c96 Alexey Kardashevskiy 2014-08-08 @22 void
> vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> 1b69be5e Gavin Shan 2014-06-10 23 {
> 9b936c96 Alexey Kardashevskiy 2014-08-08 24 eeh_dev_open(pdev);
> 1b69be5e Gavin Shan 2014-06-10 25 }
> 92d18a68 Gavin Shan 2014-08-08 26
> EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
> 1b69be5e Gavin Shan 2014-06-10 27
> 1b69be5e Gavin Shan 2014-06-10 @28 void
> vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> 1b69be5e Gavin Shan 2014-06-10 29 {
> 1b69be5e Gavin Shan 2014-06-10 30 eeh_dev_release(pdev);
> 1b69be5e Gavin Shan 2014-06-10 31 }
> 92d18a68 Gavin Shan 2014-08-08 32
> EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
> 1b69be5e Gavin Shan 2014-06-10 33
> 1b69be5e Gavin Shan 2014-06-10 @34 long
> vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> 1b69be5e Gavin Shan 2014-06-10 35
> unsigned int cmd, unsigned long arg)
> 1b69be5e Gavin Shan 2014-06-10 36 {
> 1b69be5e Gavin Shan 2014-06-10 37 struct eeh_pe *pe;
>
> :: The code at line 22 was first introduced by commit
> :: 9b936c960f22954bfb89f2fefd8f96916bb42908 drivers/vfio: Enable VFIO if
> EEH is not supported
>
> :: TO: Alexey Kardashevskiy
> :: CC: Alex Williamson
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
--
Alexey
Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
On Thu, 2017-06-08 at 14:24 +0900, Tomasz Figa wrote: > On Thu, Jun 8, 2017 at 2:16 PM, Joe Perches wrote: [] > > If there automated systems that rely on specific levels, then > > changing the levels of individual messages could also cause > > those automated systems to fail. > > Well, that might be true for some of them indeed. I was thinking about > our use case, which relies on particular numbers to get expected > verbosity levels not caring about particular messages. I guess the > break all or none rule is going to apply here, so we should do the > bitmap conversion indeed. :) > > On the other hand, I think it would be still preferable to do the > conversion in a separate patch. Right. No worries.
[PATCH] x86/efi: fix boot panic because of invalid bgrt image address
Maniaxx reported kernel boot panic similar to below:
(emulated the panic with using same invalid phys addr in a uefi vm)
There are also a bug in bugzilla.kernel.org:
https://bugzilla.kernel.org/show_bug.cgi?id=195633
This happens after below commit:
7b0a911 efi/x86: Move the EFI BGRT init code to early init code
The root cause is the firmware on those machines provides invalid bgrt
image addresses.
With original efi bgrt code we initialize bgrt late
and use ioremap to map the image address. In ioremap code we check the
address is a valid physical address or not before really map it.
With current new efi bgrt code we moved the initialization to early code
so we switch to early_memremap which does not check the phys_addr like
ioremap does. This lead to the early kernel panics.
Fix this by checking the image physical address, if it is not within
any EFI_BOOT_SERVICES_DATA areas then we just bail out. It is stronger
then the original ioremap checking, according to spec the BGRT data
should fall into EFI_BOOT_SERVICES_DATA.
[0.00] BUG: unable to handle kernel paging request at ff280001
[0.00] IP: efi_bgrt_init+0xfb/0x153
[0.00] PGD 6e00b067
[0.00] P4D 6e00b067
[0.00] PUD 6e00d067
[0.00] PMD 6e221067
[0.00] PTE 8a08e0180163
[0.00]
[0.00] Oops: 0009 [#1] SMP
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0-rc4+ #135
[0.00] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0
02/06/2015
[0.00] task: 9840f4c0 task.stack: 9840
[0.00] RIP: 0010:efi_bgrt_init+0xfb/0x153
[0.00] RSP: :98403d50 EFLAGS: 00010082
[0.00] RAX: ff280001 RBX: RCX: 0006
[0.00] RDX: 0a08e0181000 RSI: 8a08e0180163 RDI: 057e
[0.00] RBP: 98403d68 R08: 0041 R09: 0002
[0.00] R10: R11: 8c063cff8fc6 R12: 981d1fb2
[0.00] R13: 986b4fa0 R14: 0010 R15:
[0.00] FS: () GS:984db000()
knlGS:
[0.00] CS: 0010 DS: ES: CR0: 80050033
[0.00] CR2: ff280001 CR3: 6e00a000 CR4: 000406b0
[0.00] Call Trace:
[0.00] ? bgrt_init+0xbc/0xbc
[0.00] acpi_parse_bgrt+0xe/0x12
[0.00] acpi_table_parse+0x89/0xb8
[0.00] acpi_boot_init+0x445/0x4e2
[0.00] ? acpi_parse_x2apic+0x79/0x79
[0.00] ? dmi_ignore_irq0_timer_override+0x33/0x33
[0.00] setup_arch+0xb63/0xc82
[0.00] ? early_idt_handler_array+0x120/0x120
[0.00] start_kernel+0xb7/0x443
[0.00] ? early_idt_handler_array+0x120/0x120
[0.00] x86_64_start_reservations+0x29/0x2b
[0.00] x86_64_start_kernel+0x154/0x177
[0.00] secondary_startup_64+0x9f/0x9f
[0.00] Code: 3f ff eb 6c 48 bf 01 00 00 00 18 e0 08 0a be 06 00 00 00
e8 ef 2b fe ff 48 85 c0 75 0e 48 c7 c7 88 09 22 98 e8 e1 31 3f ff eb 45 <66> 44
8b 20 be 06 00 00 00 48 89 c7 8b 58 02 e8 91 2c fe ff 66
[0.00] RIP: efi_bgrt_init+0xfb/0x153 RSP: 98403d50
[0.00] CR2: ff280001
[0.00] ---[ end trace 9843d3b7cbcab26a ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle
task!
Fixes: 7b0a911 efi/x86: Move the EFI BGRT init code to early init code
Reported-by: Maniaxx
Signed-off-by: Dave Young
---
drivers/firmware/efi/efi-bgrt.c | 29 +
1 file changed, 29 insertions(+)
--- linux.orig/drivers/firmware/efi/efi-bgrt.c
+++ linux/drivers/firmware/efi/efi-bgrt.c
@@ -27,6 +27,31 @@ struct bmp_header {
u32 size;
} __packed;
+static bool efi_bgrt_addr_valid(u64 addr)
+{
+ efi_memory_desc_t *md;
+
+ if (!efi_enabled(EFI_MEMMAP)) {
+ pr_err("EFI_MEMMAP is not enabled.\n");
+ return true;
+ }
+
+ for_each_efi_memory_desc(md) {
+ u64 size;
+ u64 end;
+
+ if (md->type != EFI_BOOT_SERVICES_DATA)
+ continue;
+
+ size = md->num_pages << EFI_PAGE_SHIFT;
+ end = md->phys_addr + size;
+ if (addr >= md->phys_addr && addr < end)
+ return true;
+ }
+
+ return false;
+}
+
void __init efi_bgrt_init(struct acpi_table_header *table)
{
void *image;
@@ -65,6 +90,10 @@ void __init efi_bgrt_init(struct acpi_ta
goto out;
}
+ if (!efi_bgrt_addr_valid(bgrt->image_address)) {
+ pr_notice("Ignoring BGRT: invalid image address\n");
+ goto out;
+ }
image = early_memremap(bgrt->image_address, sizeof(bmp_header));
Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
On Thu, Jun 8, 2017 at 2:16 PM, Joe Perches wrote: > On Thu, 2017-06-08 at 13:39 +0900, Tomasz Figa wrote: >> On Thu, Jun 8, 2017 at 12:24 PM, Hirokazu Honda wrote: >> > Hi, >> > >> > I completely understand bitmask method now. >> > I agree to the idea, but it is necessary to change the specification of >> > a debug parameter. >> > (We probably need to change a document about that?) >> > For example, there is maybe a user who set a debug parameter 3. >> > The user assume that logs whose levels are less than 4 are shown. >> > However, after the bitmask method is adopted, someday the logs whose >> > level is 1 or 2 are only shown, not 3 level logs are not shown. >> > This will be confusing to users. >> >> I think I have to agree with Hirokazu here. Even though it's only >> about debugging, there might be some automatic testing systems that >> actually rely on certain values here. > > I think it's a non-argument. > > If there automated systems that rely on specific levels, then > changing the levels of individual messages could also cause > those automated systems to fail. Well, that might be true for some of them indeed. I was thinking about our use case, which relies on particular numbers to get expected verbosity levels not caring about particular messages. I guess the break all or none rule is going to apply here, so we should do the bitmap conversion indeed. :) On the other hand, I think it would be still preferable to do the conversion in a separate patch. Best regards, Tomasz
[PATCH linux-next v4 0/4] i.MX ECSPI controller slave mode support
Changes in v4: * rebased to head of linux-next to resolve conflict * optimized mx53_ecspi_rx_slave() Changes in v3: * renamed several variables for for better readability * created spi_imx_pio_transfer_slave() for slave pio transfer * added fifo_size, has_dmamode and has_slavemode in spi_imx_devtype_data Changes in v2: * re-workd i.MX ECSPI controller slave mode support based on Geert's work Jiada Wang (4): spi: imx: introduce fifo_size and has_dmamode in spi_imx_devtype_data spi: imx: add selection for iMX53 and iMX6 controller ARM: dts: imx: change compatibility for SPI controllers on imx53 later soc spi: imx: Add support for SPI Slave mode .../devicetree/bindings/spi/fsl-imx-cspi.txt | 1 + arch/arm/boot/dts/imx53.dtsi | 4 +- arch/arm/boot/dts/imx6q.dtsi | 2 +- arch/arm/boot/dts/imx6qdl.dtsi | 8 +- arch/arm/boot/dts/imx6sl.dtsi | 8 +- arch/arm/boot/dts/imx6sx.dtsi | 8 +- arch/arm/boot/dts/imx6ul.dtsi | 8 +- drivers/spi/spi-imx.c | 273 ++--- 8 files changed, 255 insertions(+), 57 deletions(-) -- 2.9.3
[PATCH linux-next v4 3/4] ARM: dts: imx: change compatibility for SPI controllers on imx53 later soc
for SPI controllers on imx53 and later SoCs, there is HW issue when
work in slave mode, as new device type 'IMX53_ECSPI' has been added
for these SPI controllers which is compatible with 'fsl,imx53-ecspi'.
This patch updates DTS to make imx53 later SPI controller only be
compatibile with 'fsl,imx53-ecspi'.
Signed-off-by: Jiada Wang
---
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 8
arch/arm/boot/dts/imx6sl.dtsi | 8
arch/arm/boot/dts/imx6sx.dtsi | 8
arch/arm/boot/dts/imx6ul.dtsi | 8
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 2e516f4..9eeafb9 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -243,7 +243,7 @@
ecspi1: ecspi@5001 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx53-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx53-ecspi";
reg = <0x5001 0x4000>;
interrupts = <36>;
clocks = <&clks
IMX5_CLK_ECSPI1_IPG_GATE>,
@@ -662,7 +662,7 @@
ecspi2: ecspi@63fac000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx53-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx53-ecspi";
reg = <0x63fac000 0x4000>;
interrupts = <37>;
clocks = <&clks IMX5_CLK_ECSPI2_IPG_GATE>,
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index dd33849..b214442 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -90,7 +90,7 @@
ecspi5: ecspi@02018000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi",
"fsl,imx53-ecspi";
reg = <0x02018000 0x4000>;
interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6Q_CLK_ECSPI5>,
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index f325411..ac19c58 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -266,7 +266,7 @@
ecspi1: ecspi@02008000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi",
"fsl,imx53-ecspi";
reg = <0x02008000 0x4000>;
interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI1>,
@@ -280,7 +280,7 @@
ecspi2: ecspi@0200c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi",
"fsl,imx53-ecspi";
reg = <0x0200c000 0x4000>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI2>,
@@ -294,7 +294,7 @@
ecspi3: ecspi@0201 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi",
"fsl,imx51-ecspi";
+ compatible = "fsl,imx6q-ecspi",
"fsl,imx53-ecspi";
reg = <0x0201 0x4000>;
interrupts = <0 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_ECSPI3>,
@@ -308,7 +308,7 @@
ecspi4: ecspi@02014000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx6q-ecspi",
"fsl,imx51-ecspi";
+
[PATCH linux-next v4 1/4] spi: imx: introduce fifo_size and has_dmamode in spi_imx_devtype_data
Different ECSPI controller has different fifosize and DMA capability,
instead of calling functions to identify these information by check
devtype. add fifo_size and has_dmamode to spi_imx_devtype_data.
so that these information can be directly accessed.
Signed-off-by: Jiada Wang
---
drivers/spi/spi-imx.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index e544f45..4469121 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -74,6 +74,8 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ bool has_dmamode;
+ unsigned int fifo_size;
enum spi_imx_devtype devtype;
};
@@ -125,11 +127,6 @@ static inline int is_imx51_ecspi(struct spi_imx_data *d)
return d->devtype_data->devtype == IMX51_ECSPI;
}
-static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
-{
- return is_imx51_ecspi(d) ? 64 : 8;
-}
-
#define MXC_SPI_BUF_RX(type) \
static void spi_imx_buf_rx_##type(struct spi_imx_data *spi_imx)
\
{ \
@@ -219,7 +216,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
if (bytes_per_word != 1 && bytes_per_word != 2 && bytes_per_word != 4)
return false;
- for (i = spi_imx_get_fifosize(spi_imx) / 2; i > 0; i--) {
+ for (i = spi_imx->devtype_data->fifo_size / 2; i > 0; i--) {
if (!(transfer->len % (i * bytes_per_word)))
break;
}
@@ -693,6 +690,8 @@ static struct spi_imx_devtype_data imx1_cspi_devtype_data =
{
.trigger = mx1_trigger,
.rx_available = mx1_rx_available,
.reset = mx1_reset,
+ .fifo_size = 8,
+ .has_dmamode = false,
.devtype = IMX1_CSPI,
};
@@ -702,6 +701,8 @@ static struct spi_imx_devtype_data imx21_cspi_devtype_data
= {
.trigger = mx21_trigger,
.rx_available = mx21_rx_available,
.reset = mx21_reset,
+ .fifo_size = 8,
+ .has_dmamode = false,
.devtype = IMX21_CSPI,
};
@@ -712,6 +713,8 @@ static struct spi_imx_devtype_data imx27_cspi_devtype_data
= {
.trigger = mx21_trigger,
.rx_available = mx21_rx_available,
.reset = mx21_reset,
+ .fifo_size = 8,
+ .has_dmamode = false,
.devtype = IMX27_CSPI,
};
@@ -721,6 +724,8 @@ static struct spi_imx_devtype_data imx31_cspi_devtype_data
= {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = mx31_reset,
+ .fifo_size = 8,
+ .has_dmamode = false,
.devtype = IMX31_CSPI,
};
@@ -731,6 +736,8 @@ static struct spi_imx_devtype_data imx35_cspi_devtype_data
= {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = mx31_reset,
+ .fifo_size = 8,
+ .has_dmamode = true,
.devtype = IMX35_CSPI,
};
@@ -740,6 +747,8 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data
= {
.trigger = mx51_ecspi_trigger,
.rx_available = mx51_ecspi_rx_available,
.reset = mx51_ecspi_reset,
+ .fifo_size = 64,
+ .has_dmamode = true,
.devtype = IMX51_ECSPI,
};
@@ -791,7 +800,7 @@ static void spi_imx_chipselect(struct spi_device *spi, int
is_active)
static void spi_imx_push(struct spi_imx_data *spi_imx)
{
- while (spi_imx->txfifo < spi_imx_get_fifosize(spi_imx)) {
+ while (spi_imx->txfifo < spi_imx->devtype_data->fifo_size) {
if (!spi_imx->count)
break;
spi_imx->tx(spi_imx);
@@ -938,7 +947,7 @@ static int spi_imx_sdma_init(struct device *dev, struct
spi_imx_data *spi_imx,
if (of_machine_is_compatible("fsl,imx6dl"))
return 0;
- spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
+ spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
/* Prepare for TX DMA: */
master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
@@ -1262,7 +1271,7 @@ static int spi_imx_probe(struct platform_device *pdev)
* Only validated on i.mx35 and i.mx6 now, can remove the constraint
* if validated on other chips.
*/
- if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx)) {
+ if (spi_imx->devtype_data->has_dmamode) {
ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
if (ret == -EPROBE_DEFER)
goto out_clk_put;
--
2.9.3
[PATCH linux-next v4 4/4] spi: imx: Add support for SPI Slave mode
Previously i.MX SPI controller only works in Master mode.
This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI
controller to work also in Slave mode.
Currently SPI Slave mode support patch has the following limitations:
1. The stale data in RXFIFO will be dropped when the Slave does any new
transfer.
2. One transfer can be finished only after all transfer->len data been
transferred to master device
3. Slave device only accepts transfer->len data. Any data longer than this
from master device will be dropped. Any data shorter than this from
master will cause SPI to stuck due to mentioned HW limitation 2.
4. Only PIO transfer is supported in Slave mode.
Following HW limitation applies:
1. ECSPI has a HW issue when works in Slave mode, after 64
words written to TXFIFO, even TXFIFO becomes empty,
ECSPI_TXDATA keeps shift out the last word data,
so we have to disable ECSPI when in slave mode after the
transfer completes
2. Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
Select (SS) signal in Slave mode is not functional" burst size must
be set exactly to the size of the transfer. This limit SPI transaction
with maximum 2^12 bits. This errata affects i.MX53 and i.MX6 ECSPI
controllers.
Signed-off-by: Jiada Wang
---
drivers/spi/spi-imx.c | 226 +++---
1 file changed, 196 insertions(+), 30 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 8e6f339..8211cad 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -53,9 +53,12 @@
/* generic defines to abstract from the different register layouts */
#define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
#define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
+#define MXC_INT_RDRBIT(4) /* Receive date threshold interrupt */
/* The maximum bytes that a sdma BD can transfer.*/
#define MAX_SDMA_BD_BYTES (1 << 15)
+/* The maximum bytes that IMX53_ECSPI can transfer in slave mode.*/
+#define MX53_MAX_TRANSFER_BYTES512
enum spi_imx_devtype {
IMX1_CSPI,
@@ -75,7 +78,9 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ void (*disable)(struct spi_imx_data *);
bool has_dmamode;
+ bool has_slavemode;
unsigned int fifo_size;
enum spi_imx_devtype devtype;
};
@@ -104,6 +109,11 @@ struct spi_imx_data {
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+ /* Slave mode */
+ bool slave_mode;
+ bool slave_aborted;
+ unsigned int slave_burst;
+
/* DMA */
bool usedma;
u32 wml;
@@ -217,6 +227,9 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
if (!master->dma_rx)
return false;
+ if (spi_imx->slave_mode)
+ return false;
+
bytes_per_word = spi_imx_bytes_per_word(transfer->bits_per_word);
if (bytes_per_word != 1 && bytes_per_word != 2 && bytes_per_word != 4)
@@ -256,6 +269,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_INT 0x10
#define MX51_ECSPI_INT_TEEN(1 << 0)
#define MX51_ECSPI_INT_RREN(1 << 3)
+#define MX51_ECSPI_INT_RDREN (1 << 4)
#define MX51_ECSPI_DMA 0x14
#define MX51_ECSPI_DMA_TX_WML(wml) ((wml) & 0x3f)
@@ -272,6 +286,44 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
#define MX51_ECSPI_TESTREG 0x20
#define MX51_ECSPI_TESTREG_LBC BIT(31)
+static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+
+ if (spi_imx->rx_buf) {
+ int n_bytes = spi_imx->slave_burst % sizeof(val);
+
+ if (!n_bytes)
+ n_bytes = sizeof(val);
+
+ memcpy(spi_imx->rx_buf,
+ ((u8 *)&val) + sizeof(val) - n_bytes, n_bytes);
+
+ spi_imx->rx_buf += n_bytes;
+ spi_imx->slave_burst -= n_bytes;
+ }
+}
+
+static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
+{
+ u32 val = 0;
+ int n_bytes = spi_imx->count % sizeof(val);
+
+ if (!n_bytes)
+ n_bytes = sizeof(val);
+
+ if (spi_imx->tx_buf) {
+ memcpy(((u8 *)&val) + sizeof(val) - n_bytes,
+ spi_imx->tx_buf, n_bytes);
+ val = cpu_to_be32(val);
+ spi_imx->tx_buf += n_bytes;
+ }
+
+ spi_imx->count -= n_bytes;
+
+ writel(val, spi_imx->base + MXC_CSPITXDATA);
+}
+
/* MX51 eCSPI */
static unsigned int mx51_ecspi_clkdiv(struct spi_imx_data *spi_imx,
unsigned int fspi, unsigned int *fres)
@@
Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
On Thu, 2017-06-08 at 13:39 +0900, Tomasz Figa wrote: > On Thu, Jun 8, 2017 at 12:24 PM, Hirokazu Honda wrote: > > Hi, > > > > I completely understand bitmask method now. > > I agree to the idea, but it is necessary to change the specification of > > a debug parameter. > > (We probably need to change a document about that?) > > For example, there is maybe a user who set a debug parameter 3. > > The user assume that logs whose levels are less than 4 are shown. > > However, after the bitmask method is adopted, someday the logs whose > > level is 1 or 2 are only shown, not 3 level logs are not shown. > > This will be confusing to users. > > I think I have to agree with Hirokazu here. Even though it's only > about debugging, there might be some automatic testing systems that > actually rely on certain values here. I think it's a non-argument. If there automated systems that rely on specific levels, then changing the levels of individual messages could also cause those automated systems to fail.
[PATCH linux-next v4 2/4] spi: imx: add selection for iMX53 and iMX6 controller
ECSPI contorller for iMX53 and iMX6 has few hardware issues
comparing to iMX51.
The change add possibility to detect which controller is used
to apply possible workaround and limitations.
Signed-off-by: Jiada Wang
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 1 +
drivers/spi/spi-imx.c | 26 --
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 31b5b21..5bf1396 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -9,6 +9,7 @@ Required properties:
- "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
- "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
- "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
+ - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and
later Soc
- reg : Offset and length of the register set for the device
- interrupts : Should contain CSPI/eCSPI interrupt
- cs-gpios : Specifies the gpio pins to be used for chipselects.
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4469121..8e6f339 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -63,7 +63,8 @@ enum spi_imx_devtype {
IMX27_CSPI,
IMX31_CSPI,
IMX35_CSPI, /* CSPI on all i.mx except above */
- IMX51_ECSPI,/* ECSPI on i.mx51 and later */
+ IMX51_ECSPI,/* ECSPI on i.mx51 */
+ IMX53_ECSPI,/* ECSPI on i.mx53 and later */
};
struct spi_imx_data;
@@ -127,6 +128,11 @@ static inline int is_imx51_ecspi(struct spi_imx_data *d)
return d->devtype_data->devtype == IMX51_ECSPI;
}
+static inline int is_imx53_ecspi(struct spi_imx_data *d)
+{
+ return d->devtype_data->devtype == IMX53_ECSPI;
+}
+
#define MXC_SPI_BUF_RX(type) \
static void spi_imx_buf_rx_##type(struct spi_imx_data *spi_imx)
\
{ \
@@ -752,6 +758,17 @@ static struct spi_imx_devtype_data
imx51_ecspi_devtype_data = {
.devtype = IMX51_ECSPI,
};
+static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
+ .intctrl = mx51_ecspi_intctrl,
+ .config = mx51_ecspi_config,
+ .trigger = mx51_ecspi_trigger,
+ .rx_available = mx51_ecspi_rx_available,
+ .reset = mx51_ecspi_reset,
+ .fifo_size = 64,
+ .has_dmamode = true,
+ .devtype = IMX53_ECSPI,
+};
+
static const struct platform_device_id spi_imx_devtype[] = {
{
.name = "imx1-cspi",
@@ -772,6 +789,9 @@ static const struct platform_device_id spi_imx_devtype[] = {
.name = "imx51-ecspi",
.driver_data = (kernel_ulong_t) &imx51_ecspi_devtype_data,
}, {
+ .name = "imx53-ecspi",
+ .driver_data = (kernel_ulong_t) &imx53_ecspi_devtype_data,
+ }, {
/* sentinel */
}
};
@@ -783,6 +803,7 @@ static const struct of_device_id spi_imx_dt_ids[] = {
{ .compatible = "fsl,imx31-cspi", .data = &imx31_cspi_devtype_data, },
{ .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
{ .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
+ { .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spi_imx_dt_ids);
@@ -1218,7 +1239,8 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->bitbang.master->prepare_message = spi_imx_prepare_message;
spi_imx->bitbang.master->unprepare_message = spi_imx_unprepare_message;
spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
- if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx))
+ if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx) ||
+ is_imx53_ecspi(spi_imx))
spi_imx->bitbang.master->mode_bits |= SPI_LOOP | SPI_READY;
spi_imx->spi_drctl = spi_drctl;
--
2.9.3
Re: [PATCH] Fix loop device flush before configure v2
On Thu, 2017-06-08 at 10:17 +0800, James Wang wrote:
> This condition check was exist at before commit b5dd2f6047ca ("block: loop:
> improve performance via blk-mq") When add MQ support to loop device, it be
> removed because the member of '->lo_thread' be removed. And then upstream
> add '->worker_task', I think they forget add it to here.
>
> When I install SLES-12 product is base on 4.4 kernel I found installer will
> hang +60 second at scan disks. and I found LVM tools would take this action.
> finally I found this problem is more obvious on AMD platform. This problem
> will impact all scenarios that scan loop devcie.
>
> When the loop device didn't configure backing file or Request Queue, we
> shouldn't to cost a lot of time to flush it.
The changelog sounds odd to me, perhaps reword/condense a bit?...
While installing SLES-12 (based on v4.4), I found that the installer
will stall for 60+ seconds during LVM disk scan. The root cause was
determined to be the removal of a bound device check in loop_flush()
by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
Restoring this check, examining ->lo_state as set by loop_set_fd()
eliminates the bad behavior.
Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K
for((i=0;i<4;i++))do losetup -f disk; done
mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
for f in `ls /dev/loop[0-9]*|sort`; do \
echo $f; dd if=$f of=/dev/null bs=512 count=1; \
done
Test output: stock patched
/dev/loop018.1217e-058.3842e-05
/dev/loop1 6.1114e-050.000147979
/dev/loop100.414701 0.000116564
/dev/loop110.74746.7942e-05
/dev/loop120.747986 8.9082e-05
/dev/loop130.746532 7.4799e-05
/dev/loop140.480041 9.3926e-05
/dev/loop151.26453 7.2522e-05
Note that from loop10 onward, the device is not mounted, yet the
stock kernel consumes several orders of magnitude more wall time
than it does for a mounted device.
Reviewed-by: Hannes Reinecke
Signed-off-by: James Wang
Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
---
> drivers/block/loop.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 48f6fa6f810e..2e5b8538760c 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -625,6 +625,9 @@ static int loop_switch(struct loop_device *lo, struct
> file *file)
> */
> static int loop_flush(struct loop_device *lo)
> {
> + /* loop not yet configured, no running thread, nothing to flush */
> + if (lo->lo_state != Lo_bound)
> + return 0;
> return loop_switch(lo, NULL);
> }
>
Re: [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use
Hi Ted, >> This protocol uses lots of complex cryptography that relies on securely >> generated random numbers. Thus, it's important that the RNG is actually >> seeded before use. Fortuantely, it appears we're always operating in >> process context (there are many GFP_KERNEL allocations and other >> sleeping operations), and so we can simply demand that the RNG is seeded >> before we use it. >> >> We take two strategies in this commit. The first is for the library code >> that's called from other modules like hci or mgmt: here we just change >> the call to get_random_bytes_wait, and return the result of the wait to >> the caller, along with the other error codes of those functions like >> usual. Then there's the SMP protocol handler itself, which makes many >> many many calls to get_random_bytes during different phases. For this, >> rather than have to change all the calls to get_random_bytes_wait and >> propagate the error result, it's actually enough to just put a single >> call to wait_for_random_bytes() at the beginning of the handler, to >> ensure that all the subsequent invocations are safe, without having to >> actually change them. Likewise, for the random address changing >> function, we'd rather know early on in the function whether the RNG >> initialization has been interrupted, rather than later, so we call >> wait_for_random_bytes() at the top, so that later on the call to >> get_random_bytes() is acceptable. > > Do we need to do all of this? Bluetooth folks, is it fair to assume > that hci_power_on() has to be called before any bluetooth functions > can be done? If so, adding a wait_for_random_bytes() in > hci_power_on() might be all that is necessary. yes, there are plenty of commands needed before a controller becomes usable. When plugging in new Bluetooth hardware, we have to power it up and read the initial settings and configuration out of. Also all the cryptographic features only apply to LE enabled controllers. The classic BR/EDR controllers have this all in hardware. So if you are not LE enabled, then there is not even a point in waiting for any seeding. However that said, also all LE controllers have an extra random number function we could call if we need extra seeding. We never bothered to hook this up since we thought that the kernel has enough sources. Regards Marcel
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
在 2017-06-07 22:38，Maxime Ripard 写道： On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: >I have no idea what this is supposed to be doing either. > >I might be wrong, but I really feel like there's a big mismatch >between your commit log, and what you actually implement. > >In your commit log, you should state: > >A) What is the current behaviour >B) Why that is a problem >C) How do you address it > >And you don't. > >However, after discussing it with Chen-Yu, it seems like you're trying >to have all the mixers probed before the TCONs. If that is so, there's >nothing specific to the H3 here, and we also have the same issue on >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, but >the easiest solution would be to move from a DFS algorithm to walk >down the graph to a BFS one. > >That way, we would add all mixers first, then the TCONs, then the >encoders, and the component framework will probe them in order. No. I said that they're swappable, however, I don't want to implement the swap now, but hardcode 0-0 1-1 connection. We're on the same page, it's definitely not what I was mentionning here. This would require a significant rework, and the usecase is still unclear for now. However, as you and Chen-Yu said, device tree should reflect the real hardware, there will be bonus endpoints for the swapped connection. If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to tcon 0, then yes, we're going to need it. What I want to do is to ignore the bonus connection, in order to prevent them from confusing the code. If you just change the bind sequence, I think it cannot be prevented that wrong connections will be bound. This is where I don't follow you anymore. The component framework doesn't list connections but devices. The swapped connections do not matter here, we have the same set of devices: mixer0, mixer1, tcon0 and tcon1. The thing that does change with your patch is that before, the binding sequence would have been mixer0, tcon0, tcon1, mixer1. With your patch, it's mixer0, tcon0, mixer1, tcon1. So, again, stating what issue you were seeing before making this patch would be very helpful to see what you're trying to do / fix. So maybe I can drop the forward search (searching output) code, and keep only the backward search (search input) code in TCON? Forward search code is only used when binding, but backward search is used for TCON to find connected mixer. Maxime ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v3 1/2] ip_tunnel: fix potential issue in ip_tunnel_rcv
On Thu, 2017-06-08 at 12:32 +0800, Haishuang Yan wrote:
> When ip_tunnel_rcv fails, the tun_dst won't be freed, so call
> dst_release to free it in error code path.
>
> CC: Pravin B Shelar
> Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
> Signed-off-by: Haishuang Yan
>
> ---
> Changes in v2:
> - Add the the missing Fixes information
> Changes in v3:
> - Free tun_dst from error code path
> ---
> net/ipv4/ip_tunnel.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index b878ecb..0f1d876 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -446,6 +446,8 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct
> sk_buff *skb,
> return 0;
>
> drop:
> + if (tun_dst)
> + dst_release((struct dst_entry *)tun_dst);
> kfree_skb(skb);
> return 0;
> }
Acked-by: Eric Dumazet
Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages
On 2017/6/7 16:31, zhongjiang wrote:
> The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on
> underflow") declare that reclaimed pages exceed the scanned pages due
> to the thp reclaim. it is incorrect because THP will be spilt to normal
> page and loop again. which will result in the scanned pages increment.
>
> Signed-off-by: zhongjiang
> ---
> mm/vmpressure.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> index 6063581..0e91ba3 100644
> --- a/mm/vmpressure.c
> +++ b/mm/vmpressure.c
> @@ -116,8 +116,9 @@ static enum vmpressure_levels
> vmpressure_calc_level(unsigned long scanned,
>
> /*
>* reclaimed can be greater than scanned in cases
> - * like THP, where the scanned is 1 and reclaimed
> - * could be 512
> + * like reclaimed slab pages, shrink_node just add
> + * reclaimed page without a related increment to
> + * scanned pages.
>*/
> if (reclaimed >= scanned)
> goto out;
Hi, minchan
what suggstion about the patch
Thanks
zhongjiang
[PATCH] configfs: Fix race between create_link and configfs_rmdir
From: Nicholas Bellinger
This patch closes a long standing race in configfs between
the creation of a new symlink in create_link(), while the
symlink target's config_item is being concurrently removed
via configfs_rmdir().
This can happen because the symlink target's reference
is obtained by config_item_get() in create_link() before
the CONFIGFS_USET_DROPPING bit set by configfs_detach_prep()
during configfs_rmdir() shutdown is actually checked..
This originally manifested itself on ppc64 on v4.8.y under
heavy load using ibmvscsi target ports with Novalink API:
[ 7877.289863] rpadlpar_io: slot U8247.22L.212A91A-V1-C8 added
[ 7879.893760] [ cut here ]
[ 7879.893768] WARNING: CPU: 15 PID: 17585 at ./include/linux/kref.h:46
config_item_get+0x7c/0x90 [configfs]
[ 7879.893811] CPU: 15 PID: 17585 Comm: targetcli Tainted: G O
4.8.17-customv2.22 #12
[ 7879.893812] task: c0018a0d3400 task.stack: c001f3b4
[ 7879.893813] NIP: d2c664ec LR: d2c60980 CTR: c0b70870
[ 7879.893814] REGS: c001f3b43810 TRAP: 0700 Tainted: G O
(4.8.17-customv2.22)
[ 7879.893815] MSR: 80029033 CR: 2842 XER:
[ 7879.893820] CFAR: d2c664bc SOFTE: 1
GPR00: d2c60980 c001f3b43a90 d2c70908
c000fbc06820
GPR04: c001ef1bd900 0004 0001
GPR08: 0001 d2c69560
d2c66d80
GPR12: c0b70870 ce798700 c001f3b43ca0
c001d4949d40
GPR16: c0014637e1c0
c000f2392940
GPR20: c001f3b43b98 0041 0060
GPR24: f000 d2c60be0
c001f1dac490
GPR28: 0004 c001ef1bd900
c000f2392940
[ 7879.893839] NIP [d2c664ec] config_item_get+0x7c/0x90 [configfs]
[ 7879.893841] LR [d2c60980] check_perm+0x80/0x2e0 [configfs]
[ 7879.893842] Call Trace:
[ 7879.893844] [c001f3b43ac0] [d2c60980] check_perm+0x80/0x2e0
[configfs]
[ 7879.893847] [c001f3b43b10] [c0329770] do_dentry_open+0x2c0/0x460
[ 7879.893849] [c001f3b43b70] [c0344480] path_openat+0x210/0x1490
[ 7879.893851] [c001f3b43c80] [c034708c] do_filp_open+0xfc/0x170
[ 7879.893853] [c001f3b43db0] [c032b5bc] do_sys_open+0x1cc/0x390
[ 7879.893856] [c001f3b43e30] [c0009584] system_call+0x38/0xec
[ 7879.893856] Instruction dump:
[ 7879.893858] 409d0014 38210030 e8010010 7c0803a6 4e800020 3d22 e94981e0
892a
[ 7879.893861] 2f89 409effe0 3921 992a <0fe0> 4bd0 6000
6000
[ 7879.893866] ---[ end trace 14078f0b3b5ad0aa ]---
To close this race, go ahead and obtain the symlink's target
config_item reference only after the existing CONFIGFS_USET_DROPPING
check succeeds.
This way, if configfs_rmdir() wins create_link() will return -ENONET,
and if create_link() wins configfs_rmdir() will return -EBUSY.
Reported-by: Bryant G. Ly
Tested-by: Bryant G. Ly
Cc: Bryant G. Ly
Cc: Christoph Hellwig
Cc: Joel Becker
Signed-off-by: Nicholas Bellinger
---
fs/configfs/symlink.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/configfs/symlink.c b/fs/configfs/symlink.c
index a6ab012..c8aabba 100644
--- a/fs/configfs/symlink.c
+++ b/fs/configfs/symlink.c
@@ -83,14 +83,13 @@ static int create_link(struct config_item *parent_item,
ret = -ENOMEM;
sl = kmalloc(sizeof(struct configfs_symlink), GFP_KERNEL);
if (sl) {
- sl->sl_target = config_item_get(item);
spin_lock(&configfs_dirent_lock);
if (target_sd->s_type & CONFIGFS_USET_DROPPING) {
spin_unlock(&configfs_dirent_lock);
- config_item_put(item);
kfree(sl);
return -ENOENT;
}
+ sl->sl_target = config_item_get(item);
list_add(&sl->sl_list, &target_sd->s_links);
spin_unlock(&configfs_dirent_lock);
ret = configfs_create_link(sl, parent_item->ci_dentry,
--
1.9.1
[PATCH v3 2/2] acpi/iort: numa: Add numa node mapping for smmuv3 devices
Add code to parse proximity domain in SMMUv3 IORT table to
set numa node mapping for smmuv3 devices.
Signed-off-by: Ganapatrao Kulkarni
---
drivers/acpi/arm64/iort.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index bba2b59..e804386 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -882,6 +882,23 @@ static bool __init arm_smmu_v3_is_coherent(struct
acpi_iort_node *node)
return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
}
+/*
+ * set numa proximity domain for smmuv3 device
+ */
+static void __init arm_smmu_v3_set_proximity(struct acpi_iort_node *node,
+ struct device *dev)
+{
+ struct acpi_iort_smmu_v3 *smmu;
+
+ smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
+ if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
+ set_dev_node(dev, acpi_map_pxm_to_node(smmu->pxm));
+ pr_info("SMMUV3[%llx] Mapped to Proximity domain %d\n",
+ smmu->base_address,
+ smmu->pxm);
+ }
+}
+
static int __init arm_smmu_count_resources(struct acpi_iort_node *node)
{
struct acpi_iort_smmu *smmu;
@@ -951,20 +968,24 @@ struct iort_iommu_config {
int (*iommu_count_resources)(struct acpi_iort_node *node);
void (*iommu_init_resources)(struct resource *res,
struct acpi_iort_node *node);
+ void (*iommu_set_proximity)(struct acpi_iort_node *node,
+struct device *dev);
};
static const struct iort_iommu_config iort_arm_smmu_v3_cfg __initconst = {
.name = "arm-smmu-v3",
.iommu_is_coherent = arm_smmu_v3_is_coherent,
.iommu_count_resources = arm_smmu_v3_count_resources,
- .iommu_init_resources = arm_smmu_v3_init_resources
+ .iommu_init_resources = arm_smmu_v3_init_resources,
+ .iommu_set_proximity = arm_smmu_v3_set_proximity
};
static const struct iort_iommu_config iort_arm_smmu_cfg __initconst = {
.name = "arm-smmu",
.iommu_is_coherent = arm_smmu_is_coherent,
.iommu_count_resources = arm_smmu_count_resources,
- .iommu_init_resources = arm_smmu_init_resources
+ .iommu_init_resources = arm_smmu_init_resources,
+ .iommu_set_proximity = NULL
};
static __init
@@ -1002,6 +1023,9 @@ static int __init iort_add_smmu_platform_device(struct
acpi_iort_node *node)
if (!pdev)
return -ENOMEM;
+ if (ops->iommu_set_proximity)
+ ops->iommu_set_proximity(node, &pdev->dev);
+
count = ops->iommu_count_resources(node);
r = kcalloc(count, sizeof(*r), GFP_KERNEL);
--
1.8.1.4
[PATCH v3 1/2] acpica: iort: Update SMMUv3 header for proximity domain mapping
ARM IORT specification (rev. C) has added two new fields to define
proximity domain for the SMMUv3 node in the IORT table.
Proximity Domain Valid:
Set to 1 if the value provided in the Proximity Domain field is
valid. Set to 0 otherwise.
Proximity domain:
If the Proximity Domain Valid flag is set to 1, this entry
provides the proximity domain to which this SMMU
instance belongs.
Update header file to reflect this.
Signed-off-by: Ganapatrao Kulkarni
---
include/acpi/actbl2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 4b306a6..389e91f 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -805,6 +805,9 @@ struct acpi_iort_smmu_v3 {
u32 pri_gsiv;
u32 gerr_gsiv;
u32 sync_gsiv;
+ u8 pxm;
+ u8 reserved1;
+ u16 reserved2;
};
/* Values for Model field above */
@@ -817,6 +820,7 @@ struct acpi_iort_smmu_v3 {
#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1)
#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1)
+#define ACPI_IORT_SMMU_V3_PXM_VALID (1<<3)
/***
*
--
1.8.1.4
[PATCH v3 0/2] acpi/iort, numa: Add numa node mapping for smmuv3 devices
ARM IORT specification(rev. C) has added provision to define proximity domain in SMMUv3 IORT table. Adding required code to parse Proximity domain and set numa_node of smmv3 platform devices. v3: - Addressed Lorenzo Pieralisi comment. v2: - Changed as per Lorenzo Pieralisi and Hanjun Guo suggestions. v1: - Initial patch Ganapatrao Kulkarni (2): acpica: iort: Update SMMUv3 header for proximity domain mapping acpi/iort: numa: Add numa node mapping for smmuv3 devices drivers/acpi/arm64/iort.c | 28 ++-- include/acpi/actbl2.h | 4 2 files changed, 30 insertions(+), 2 deletions(-) -- 1.8.1.4
Re: [PATCH 09/16] platform/x86: wmi: Instantiate all devices before adding them
> On Mon, Jun 5, 2017 at 8:03 PM, Darren Hart wrote: > > On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote: > >> I know I have probably started sounding like a broken record by now, but > >> I still have not seen any response (apart from the typos getting fixed) > >> to my comments on this patch which I posted in January 2016 [1]. > >> > >> None of the issues I found back then are really critical, but I did > >> point out a potential memory leak (granted, an unlikely one), so it > >> might be a good idea to at least take a second look before merging. > >> > >> [1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html > > > > Thanks for being persistent, some good points in there. I'd like to just > > squash > > these into this patch (9/16), but I'll include them here for an ack from > > you and > > Andy L. that this is what you meant, and consistent with his > > intent/understanding: > > > > Looks good to me. Same here. -- Best regards, Michał Kępień
[RESEND PATCH] input/joystick/analog: Use get_cycles() on PPC
The analog joystick driver spits a warning at us:
drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
not defined for this architecture.
PPC has get_cycles() so use that.
Signed-off-by: Michael Ellerman
---
drivers/input/joystick/analog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index 3d8ff09eba57..06962b63f3a6 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) ||
defined(CONFIG_ARM64) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) ||
defined(CONFIG_ARM64) || defined(CONFIG_TILE) || defined(CONFIG_PPC)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "get_cycles"
--
2.7.4
Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs
On Thu, Jun 8, 2017 at 12:24 PM, Hirokazu Honda wrote: > Hi, > > I completely understand bitmask method now. > I agree to the idea, but it is necessary to change the specification of > a debug parameter. > (We probably need to change a document about that?) > For example, there is maybe a user who set a debug parameter 3. > The user assume that logs whose levels are less than 4 are shown. > However, after the bitmask method is adopted, someday the logs whose > level is 1 or 2 are only shown, not 3 level logs are not shown. > This will be confusing to users. I think I have to agree with Hirokazu here. Even though it's only about debugging, there might be some automatic testing systems that actually rely on certain values here. It probably shouldn't be considered hard ABI, but that still could be a significant annoyance for everyone. However, one could add this in an incremental way, i.e. add a new debug_mask parameter that would be used by dprinkt(), while making the original debug parameter simply update the debug_mask whenever it's changed. I still think that it should be made with a separate patch, though, as adjusting the levels and changing the filtering method are orthogonal. Best regards, Tomasz
Re: [PATCH 1/2] clocksource/drivers: Add timer-of common init routine
Hi Daniel,
[auto build test WARNING on next-20170605]
[cannot apply to tip/timers/core clk/clk-next linus/master v4.9-rc8 v4.9-rc7
v4.9-rc6 v4.12-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Lezcano/clocksource-drivers-Add-timer-of-common-init-routine/20170607-024801
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:260:8: sparse: attribute 'no_sanitize_address':
unknown attribute
>> drivers/clocksource/timer-of.c:33:24: sparse: incompatible types in
>> conditional expression (different types)
vim +33 drivers/clocksource/timer-of.c
17 */
18 #include
19 #include
20 #include
21 #include
22 #include
23 #include
24
25 #include "timer-of.h"
26
27 static __init void timer_irq_exit(struct of_timer_irq *of_irq)
28 {
29 struct timer_of *to = container_of(of_irq, struct timer_of,
of_irq);
30
31 struct clock_event_device *clkevt = &to->clkevt;
32
> 33 of_irq->percpu ? free_percpu_irq(of_irq->irq, clkevt) :
34 free_irq(of_irq->irq, clkevt);
35 }
36
37 static __init int timer_irq_init(struct device_node *np,
38 struct of_timer_irq *of_irq)
39 {
40 int ret;
41 struct timer_of *to = container_of(of_irq, struct timer_of,
of_irq);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv
When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
dst_release to free it in error code path.
CC: Alexei Starovoitov
Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
Signed-off-by: Haishuang Yan
---
Changes in v2:
- Add the the missing Fixes information
Changes in v3:
- Free tun_dst from error code path
---
net/ipv6/ip6_tunnel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9b37f97..ef99d59 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -859,6 +859,8 @@ static int __ip6_tnl_rcv(struct ip6_tnl *tunnel, struct
sk_buff *skb,
return 0;
drop:
+ if (tun_dst)
+ dst_release((struct dst_entry *)tun_dst);
kfree_skb(skb);
return 0;
}
--
1.8.3.1
[PATCH v3 1/2] ip_tunnel: fix potential issue in ip_tunnel_rcv
When ip_tunnel_rcv fails, the tun_dst won't be freed, so call
dst_release to free it in error code path.
CC: Pravin B Shelar
Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
Signed-off-by: Haishuang Yan
---
Changes in v2:
- Add the the missing Fixes information
Changes in v3:
- Free tun_dst from error code path
---
net/ipv4/ip_tunnel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index b878ecb..0f1d876 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -446,6 +446,8 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct sk_buff
*skb,
return 0;
drop:
+ if (tun_dst)
+ dst_release((struct dst_entry *)tun_dst);
kfree_skb(skb);
return 0;
}
--
1.8.3.1
Re: [patch -mm] mm, hugetlb: schedule when potentially allocating many hugepages
On 06/07/2017 09:03 PM, David Rientjes wrote:
> A few hugetlb allocators loop while calling the page allocator and can
> potentially prevent rescheduling if the page allocator slowpath is not
> utilized.
>
> Conditionally schedule when large numbers of hugepages can be allocated.
>
> Signed-off-by: David Rientjes
> ---
> Based on -mm only to prevent merge conflicts with
> "mm/hugetlb.c: warn the user when issues arise on boot due to hugepages"
>
> mm/hugetlb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1754,6 +1754,7 @@ static int gather_surplus_pages(struct hstate *h, int
> delta)
> break;
> }
> list_add(&page->lru, &surplus_list);
> + cond_resched();
> }
> allocated += i;
>
> @@ -,6 +2223,7 @@ static void __init hugetlb_hstate_alloc_pages(struct
> hstate *h)
> } else if (!alloc_fresh_huge_page(h,
>&node_states[N_MEMORY]))
> break;
> + cond_resched();
> }
> if (i < h->max_huge_pages) {
> char buf[32];
> @@ -2364,6 +2366,7 @@ static unsigned long set_max_huge_pages(struct hstate
> *h, unsigned long count,
> ret = alloc_fresh_gigantic_page(h, nodes_allowed);
> else
> ret = alloc_fresh_huge_page(h, nodes_allowed);
> + cond_resched();
Are not the following lines immediately before the above huge page allocation
in set_max_huge_pages, or am I looking at an incorrect version of the file?
/* yield cpu to avoid soft lockup */
cond_resched();
--
Mike Kravetz
> spin_lock(&hugetlb_lock);
> if (!ret)
> goto out;
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
>
Re: [PATCH 3/5] mfd: tps65217: Add a dependency on OF
On Wednesday 07 June 2017 07:40 PM, Javier Martinez Canillas wrote: > Hello Keerthy, > > On Wed, Jun 7, 2017 at 3:45 PM, Keerthy wrote: > > [snip] > > I think you can remove the of_match_device checks in some drivers too i.e: http://elixir.free-electrons.com/linux/latest/source/drivers/mfd/tps65217.c#L330 >>> >>> Yes that and removal of unused i2c_device_id. I will follow it up once >>> this OF dependency is in. >> >> The of_match_device() checks should be removed with the OF patch. Lee Jones/ Enric, IIUC of_match_device call is still needed to obtain a match and in case there are multiple compatibles with different match data then this call is definitely needed. > > That's correct... That is what i wanted to know. Thanks. > >>> >>> Not sure if I follow you. My understanding is that with DT the probe >>> of this driver is only called if there is a node with the compatible = >>> "ti,tps65217" string. So if probe is called there is always a match >>> and the call to of_match_device is redundant. >> >> How will you get the matching data? >> >> For the tps65217 case you mentioned we need the match pointer to get the >> chip_id right? >> >> chip_id = (unsigned long)match->data; >> > > ...but this particular driver only has a single entry in the OF table > and so you can just do: > > tps->id = TPS65217; > > Later if there's a variant for this chip, then you can add the logic > to query the struct of_device_id .data. But for now I think that's > better to just remove as Enric proposes and also remove the .data > field from the struct of_device_id entry. okay agreed for tps65217. > > Best regards, > Javier >
Re: [PATCH v6 19/34] x86/mm: Add support to access boot related data in the clear
Hi Tom, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc4 next-20170607] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tom-Lendacky/x86-Secure-Memory-Encryption-AMD/20170608-104147 config: i386-randconfig-x077-06040719 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/dma.h:12:0, from include/linux/bootmem.h:9, from arch/x86/mm/ioremap.c:9: >> arch/x86/include/asm/io.h:386:37: error: conflicting types for >> 'arch_memremap_can_ram_remap' #define arch_memremap_can_ram_remap arch_memremap_can_ram_remap ^ >> arch/x86/mm/ioremap.c:561:6: note: in expansion of macro >> 'arch_memremap_can_ram_remap' bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size, ^~~ arch/x86/include/asm/io.h:384:13: note: previous declaration of 'arch_memremap_can_ram_remap' was here extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size, ^~~ -- In file included from arch/x86/include/asm/dma.h:12:0, from include/linux/bootmem.h:9, from arch/x86//mm/ioremap.c:9: >> arch/x86/include/asm/io.h:386:37: error: conflicting types for >> 'arch_memremap_can_ram_remap' #define arch_memremap_can_ram_remap arch_memremap_can_ram_remap ^ arch/x86//mm/ioremap.c:561:6: note: in expansion of macro 'arch_memremap_can_ram_remap' bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size, ^~~ arch/x86/include/asm/io.h:384:13: note: previous declaration of 'arch_memremap_can_ram_remap' was here extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size, ^~~ vim +/arch_memremap_can_ram_remap +386 arch/x86/include/asm/io.h 380 extern void arch_io_free_memtype_wc(resource_size_t start, resource_size_t size); 381 #define arch_io_reserve_memtype_wc arch_io_reserve_memtype_wc 382 #endif 383 384 extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size, 385 unsigned long flags); > 386 #define arch_memremap_can_ram_remap arch_memremap_can_ram_remap 387 388 #endif /* _ASM_X86_IO_H */ --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 3.10 000/250] 3.10.106-stable review
On Wed, Jun 07, 2017 at 05:38:36PM -0700, Guenter Roeck wrote: > Build results: > total: 121 pass: 121 fail: 0 > Qemu test results: > total: 83 pass: 83 fail: 0 Awesome! Thank you Guenter! Willy
[PATCH] security: selinux: use kmem_cache for ebitmap
The allocated size for each ebitmap_node is 192byte by kzalloc().
Then, ebitmap_node size is fixed, so it's possible to use only 144byte
for each object by kmem_cache_zalloc().
It can reduce some dynamic allocation size.
Signed-off-by: Junil Lee
---
security/selinux/ss/ebitmap.c | 26 --
security/selinux/ss/ebitmap.h | 3 +++
security/selinux/ss/services.c | 4
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/security/selinux/ss/ebitmap.c b/security/selinux/ss/ebitmap.c
index 9db4709a..ad38299 100644
--- a/security/selinux/ss/ebitmap.c
+++ b/security/selinux/ss/ebitmap.c
@@ -24,6 +24,8 @@
#define BITS_PER_U64 (sizeof(u64) * 8)
+static struct kmem_cache *ebitmap_node_cachep;
+
int ebitmap_cmp(struct ebitmap *e1, struct ebitmap *e2)
{
struct ebitmap_node *n1, *n2;
@@ -54,7 +56,7 @@ int ebitmap_cpy(struct ebitmap *dst, struct ebitmap *src)
n = src->node;
prev = NULL;
while (n) {
- new = kzalloc(sizeof(*new), GFP_ATOMIC);
+ new = kmem_cache_zalloc(ebitmap_node_cachep, GFP_ATOMIC);
if (!new) {
ebitmap_destroy(dst);
return -ENOMEM;
@@ -162,7 +164,7 @@ int ebitmap_netlbl_import(struct ebitmap *ebmap,
if (e_iter == NULL ||
offset >= e_iter->startbit + EBITMAP_SIZE) {
e_prev = e_iter;
- e_iter = kzalloc(sizeof(*e_iter), GFP_ATOMIC);
+ e_iter = kmem_cache_zalloc(ebitmap_node_cachep,
GFP_ATOMIC);
if (e_iter == NULL)
goto netlbl_import_failure;
e_iter->startbit = offset - (offset % EBITMAP_SIZE);
@@ -288,7 +290,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit,
int value)
prev->next = n->next;
else
e->node = n->next;
- kfree(n);
+ kmem_cache_free(ebitmap_node_cachep, n);
}
return 0;
}
@@ -299,7 +301,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit,
int value)
if (!value)
return 0;
- new = kzalloc(sizeof(*new), GFP_ATOMIC);
+ new = kmem_cache_zalloc(ebitmap_node_cachep, GFP_ATOMIC);
if (!new)
return -ENOMEM;
@@ -332,7 +334,7 @@ void ebitmap_destroy(struct ebitmap *e)
while (n) {
temp = n;
n = n->next;
- kfree(temp);
+ kmem_cache_free(ebitmap_node_cachep, temp);
}
e->highbit = 0;
@@ -400,7 +402,7 @@ int ebitmap_read(struct ebitmap *e, void *fp)
if (!n || startbit >= n->startbit + EBITMAP_SIZE) {
struct ebitmap_node *tmp;
- tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+ tmp = kmem_cache_zalloc(ebitmap_node_cachep,
GFP_KERNEL);
if (!tmp) {
printk(KERN_ERR
"SELinux: ebitmap: out of memory\n");
@@ -519,3 +521,15 @@ int ebitmap_write(struct ebitmap *e, void *fp)
}
return 0;
}
+
+void ebitmap_cache_init(void)
+{
+ ebitmap_node_cachep = kmem_cache_create("ebitmap_node",
+ sizeof(struct
ebitmap_node),
+ 0, SLAB_PANIC, NULL);
+}
+
+void ebitmap_cache_destroy(void)
+{
+ kmem_cache_destroy(ebitmap_node_cachep);
+}
diff --git a/security/selinux/ss/ebitmap.h b/security/selinux/ss/ebitmap.h
index 9637b8c..6d5a9ac 100644
--- a/security/selinux/ss/ebitmap.h
+++ b/security/selinux/ss/ebitmap.h
@@ -130,6 +130,9 @@ void ebitmap_destroy(struct ebitmap *e);
int ebitmap_read(struct ebitmap *e, void *fp);
int ebitmap_write(struct ebitmap *e, void *fp);
+void ebitmap_cache_init(void);
+void ebitmap_cache_destroy(void);
+
#ifdef CONFIG_NETLABEL
int ebitmap_netlbl_export(struct ebitmap *ebmap,
struct netlbl_lsm_catmap **catmap);
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 2021666..2f02fa6 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2054,9 +2054,11 @@ int security_load_policy(void *data, size_t len)
if (!ss_initialized) {
avtab_cache_init();
+ ebitmap_cache_init();
rc = policydb_read(&policydb, fp);
if (rc) {
avtab_cache_destroy();
+ ebitmap_cache_destroy();
goto out;
}
@@ -2067,6 +2069,7 @@ int security_load_policy(void *data, size_t len)
if (rc) {
policydb_destr
[PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length
From: Nicholas Bellinger
When iscsi WRITE underflow occurs there are two different scenarios
that can happen.
Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.
That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL. In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.
However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.
In the wild, we've never had a iscsi host environment actually
try to do this.
For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.
Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:
commit c72c5250224d475614a00c1d7e54a67f77cd3410
Author: Roland Dreier
Date: Wed Jul 22 15:08:18 2015 -0700
target: allow underflow/overflow for PR OUT etc. commands
Cc: Roland Dreier
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Martin K. Petersen
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index c025451..3fdca2c 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1279,6 +1279,18 @@ int iscsit_process_scsi_cmd(struct iscsi_conn *conn,
struct iscsi_cmd *cmd,
*/
if (dump_payload)
goto after_immediate_data;
+ /*
+* Check for underflow case where both EDTL and immediate data payload
+* exceeds what is presented by CDB's TRANSFER LENGTH, and what has
+* already been set in target_cmd_size_check() as se_cmd->data_length.
+*
+* For this special case, fail the command and dump the immediate data
+* payload.
+*/
+ if (cmd->first_burst_len > cmd->se_cmd.data_length) {
+ cmd->sense_reason = TCM_INVALID_CDB_FIELD;
+ goto after_immediate_data;
+ }
immed_ret = iscsit_handle_immediate_data(cmd, hdr,
cmd->first_burst_len);
--
1.9.1
[RFC PATCH 1/4] EDAC: mvebu: Add driver for Marvell Armada SoCs
This adds an EDAC driver for the memory controller and L2 cache used on
a number of Marvell Armada SoCs.
Signed-off-by: Chris Packham
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/edac/Kconfig | 7 +
drivers/edac/Makefile | 1 +
drivers/edac/mvebu_edac.c | 506 ++
drivers/edac/mvebu_edac.h | 66 ++
4 files changed, 580 insertions(+)
create mode 100644 drivers/edac/mvebu_edac.c
create mode 100644 drivers/edac/mvebu_edac.h
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 96afb2aeed18..5cc84b333949 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -266,6 +266,13 @@ config EDAC_MV64X60
Support for error detection and correction on the Marvell
MV64360 and MV64460 chipsets.
+config EDAC_MVEBU
+ tristate "Marvell Armada 370/385/XP"
+ depends on ARCH_MVEBU
+ help
+ Support for error detection and correction on the Marvell
+ ARM SoCs.
+
config EDAC_PASEMI
tristate "PA Semi PWRficient"
depends on PPC_PASEMI && PCI
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 0fd9ffa63299..29de6c23d15c 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -59,6 +59,7 @@ layerscape_edac_mod-y := fsl_ddr_edac.o
layerscape_edac.o
obj-$(CONFIG_EDAC_LAYERSCAPE) += layerscape_edac_mod.o
obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
+obj-$(CONFIG_EDAC_MVEBU) += mvebu_edac.o
obj-$(CONFIG_EDAC_CELL)+= cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
obj-$(CONFIG_EDAC_AMD8111) += amd8111_edac.o
diff --git a/drivers/edac/mvebu_edac.c b/drivers/edac/mvebu_edac.c
new file mode 100644
index ..624cf10f821b
--- /dev/null
+++ b/drivers/edac/mvebu_edac.c
@@ -0,0 +1,506 @@
+/*
+ * EDAC driver for Marvell ARM SoCs
+ *
+ * Copyright (C) 2017 Allied Telesis Labs
+ *
+ * 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
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "edac_module.h"
+#include "mvebu_edac.h"
+
+static const char *mvebu_ctl_name = "MVEBU";
+static int edac_mc_idx;
+static int edac_l2_idx;
+
+/*** DRAM err device **/
+
+static void mvebu_mc_check(struct mem_ctl_info *mci)
+{
+ struct mvebu_mc_pdata *pdata = mci->pvt_info;
+ u32 reg;
+ u32 err_addr;
+ u32 sdram_ecc;
+ u32 comp_ecc;
+ u32 syndrome;
+
+ reg = readl(pdata->mc_vbase + MVEBU_SDRAM_ERR_ADDR);
+ if (!reg)
+ return;
+
+ err_addr = reg & ~0x3;
+ sdram_ecc = readl(pdata->mc_vbase + MVEBU_SDRAM_ERR_ECC_RCVD);
+ comp_ecc = readl(pdata->mc_vbase + MVEBU_SDRAM_ERR_ECC_CALC);
+ syndrome = sdram_ecc ^ comp_ecc;
+
+ /* first bit clear in ECC Err Reg, 1 bit error, correctable by HW */
+ if (!(reg & 0x1))
+ edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci, 1,
+err_addr >> PAGE_SHIFT,
+err_addr & PAGE_MASK, syndrome,
+0, 0, -1,
+mci->ctl_name, "");
+ else/* 2 bit error, UE */
+ edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci, 1,
+err_addr >> PAGE_SHIFT,
+err_addr & PAGE_MASK, 0,
+0, 0, -1,
+mci->ctl_name, "");
+
+ /* clear the error */
+ writel(0, pdata->mc_vbase + MVEBU_SDRAM_ERR_ADDR);
+}
+
+static irqreturn_t mvebu_mc_isr(int irq, void *dev_id)
+{
+ struct mem_ctl_info *mci = dev_id;
+ struct mvebu_mc_pdata *pdata = mci->pvt_info;
+ u32 reg;
+
+ reg = readl(pdata->mc_vbase + MVEBU_SDRAM_ERR_ADDR);
+ if (!reg)
+ return IRQ_NONE;
+
+ /* writing 0's to the ECC err addr in check function clears irq */
+ mvebu_mc_check(mci);
+
+ return IRQ_HANDLED;
+}
+
+static void get_total_mem(struct mvebu_mc_pdata *pdata)
+{
+ struct device_node *np = NULL;
+ struct resource res;
+ int ret;
+ unsigned long total_mem = 0;
+
+ for_each_node_by_type(np, "memory") {
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret)
+ continue;
+
+ total_mem += res
[RFC PATCH 3/4] ARM: l2x0: add arm,ecc-enable property for aurora
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "arm,ecc-enable" device tree property
which can be used to enable this.
Signed-off-by: Chris Packham
---
Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++
arch/arm/mm/cache-l2x0.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt
b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index d9650c1788f4..6316e673307a 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -76,6 +76,8 @@ Optional properties:
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- arm,ecc-enable : enable ECC protection on the L2 cache
+- arm,ecc-disable : disable ECC protection on the L2 cache
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 2cc2653b046f..4f0e6d9b151d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
+ if (of_property_read_bool(np, "arm,ecc-enable")) {
+ mask |= L2C_AUX_CTRL_EVTMON_ENABLE;
+ val |= L2C_AUX_CTRL_EVTMON_ENABLE;
+ } else if (of_property_read_bool(np, "arm,ecc-disable")) {
+ mask |= L2C_AUX_CTRL_EVTMON_ENABLE;
+ }
+
if (of_property_read_bool(np, "arm,parity-enable")) {
mask |= L2C_AUX_CTRL_PARITY_ENABLE;
val |= L2C_AUX_CTRL_PARITY_ENABLE;
--
2.13.0
[RFC PATCH 4/4] ARM: dts: enable l2c parity and ecc protection on 98dx3236
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 84cc232a29e9..32d05ec88ffd 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -138,6 +138,8 @@
cache-level = <2>;
cache-unified;
wt-override;
+ arm,parity-enable;
+ arm,ecc-enable;
};
gpio0: gpio@18100 {
--
2.13.0
[RFC PATCH 2/4] ARM: l2x0: support parity-enable/disable on aurora
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.
Signed-off-by: Chris Packham
---
arch/arm/mm/cache-l2x0.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..2cc2653b046f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
+ if (of_property_read_bool(np, "arm,parity-enable")) {
+ mask |= L2C_AUX_CTRL_PARITY_ENABLE;
+ val |= L2C_AUX_CTRL_PARITY_ENABLE;
+ } else if (of_property_read_bool(np, "arm,parity-disable")) {
+ mask |= L2C_AUX_CTRL_PARITY_ENABLE;
+ }
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
--
2.13.0
[PATCH v4] mfd: lp87565: Add lp87565 PMIC support
The LP87565 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Configurable Bucks(Single and multi-phase).
- Configurable General Purpose Output Signals (GPO).
The LP87565-Q1 variant device uses two 2-phase outputs configuration,
Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
output.
Signed-off-by: Keerthy
---
The other patches are already pulled by Mark. Hence posting
the remaining patch.
Changes in v4:
* Fixed device tree comments from Rob on the pmic node name.
* removed regulators from properties list as it is a node.
Changes in v3:
* Fixed License to GPL v2.
* Fixed an indentation issue.
Changes in v2:
* Fixed a bunch of whitespace errors.
* Changed the License to short form.
* Added the generic compatible lp87565
* Removed i2c_device_id table.
* Introduced probe_new function in place of probe.
Documentation/devicetree/bindings/mfd/lp87565.txt | 43
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/lp87565.c | 92
include/linux/mfd/lp87565.h | 270 ++
5 files changed, 420 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
create mode 100644 drivers/mfd/lp87565.c
create mode 100644 include/linux/mfd/lp87565.h
diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt
b/Documentation/devicetree/bindings/mfd/lp87565.txt
new file mode 100644
index 000..a48df7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
@@ -0,0 +1,43 @@
+TI LP87565 PMIC MFD driver
+
+Required properties:
+ - compatible:"ti,lp87565", "ti,lp87565-q1"
+ - reg: I2C slave address.
+ - gpio-controller: Marks the device node as a GPIO Controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx should match
+ the supply_name populated in driver.
+Example:
+
+lp87565_pmic: pmic@60 {
+ compatible = "ti,lp87565-q1";
+ reg = <0x60>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ buck10-in-supply = <&vsys_3v3>;
+ buck23-in-supply = <&vsys_3v3>;
+
+ regulators: regulators {
+ buck10_reg: buck10 {
+ /* VDD_MPU */
+ regulator-name = "buck10";
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <125>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck23_reg: buck23 {
+ /* VDD_GPU */
+ regulator-name = "buck23";
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <125>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 95e8683..568082f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1354,6 +1354,20 @@ config MFD_TI_LP873X
This driver can also be built as a module. If so, the module
will be called lp873x.
+config MFD_TI_LP87565
+ tristate "TI LP87565 Power Management IC"
+ depends on I2C && OF
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here then you get support for the LP87565 series of
+ Power Management Integrated Circuits (PMIC).
+ These include voltage regulators, thermal protection, configurable
+ General Purpose Outputs (GPO) that are used in portable devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called lp87565.
+
config MFD_TPS65218
tristate "TI TPS65218 Power Management chips"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 6f6aed8..080793b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o
obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o
obj-$(CONFIG_MFD_TI_LP873X)+= lp873x.o
+obj-$(CONFIG_MFD_TI_LP87565) += lp87565.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
new file mode 100644
index 000..70eae40
--- /dev/null
+++ b/drivers/mfd/lp87565.c
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
Re: [1/7] powerpc/mm: rename map_page() to map_kernel_page() on PPC32
On Mon, 2017-05-29 at 15:31:56 UTC, Christophe Leroy wrote: > Signed-off-by: Christophe Leroy > Acked-by: Balbir Singh Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/4386c096c2ffa1b3232d701e9d7ff8 cheers
Re: [PATCH v2 1/2] ip_tunnel: fix potential issue in ip_tunnel_rcv
On Wed, Jun 7, 2017 at 8:15 PM, Eric Dumazet wrote:
> On Wed, 2017-06-07 at 19:13 -0700, Pravin Shelar wrote:
>> On Wed, Jun 7, 2017 at 5:57 PM, Haishuang Yan
>> wrote:
>> > When ip_tunnel_rcv fails, the tun_dst won't be freed, so move
>> > skb_dst_set to begin and tun_dst would be freed by kfree_skb.
>> >
>> > CC: Pravin B Shelar
>> > Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
>> > Signed-off-by: Haishuang Yan
>> > ---
>> > net/ipv4/ip_tunnel.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
>> > index b878ecb..27fc20f 100644
>> > --- a/net/ipv4/ip_tunnel.c
>> > +++ b/net/ipv4/ip_tunnel.c
>> > @@ -386,6 +386,9 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct
>> > sk_buff *skb,
>> > const struct iphdr *iph = ip_hdr(skb);
>> > int err;
>> >
>> > + if (tun_dst)
>> > + skb_dst_set(skb, (struct dst_entry *)tun_dst);
>> > +
>> If dst is set so early, skb_scrub_packet() would remove the tunnel dst
>> reference.
>> It is better to call skb_dst_drop() from error code path.
>
> Do we really want to keep a dst from another namespace if
> skb_scrub_packet() is called with xnet=true ?
>
tun_dst is allocated in same namespace. It is required for LWT to work.
Re: powerpc/perf: Fix Power9 test_adder field
On Fri, 2017-05-26 at 08:08:27 UTC, Madhavan Srinivasan wrote:
> Commit 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 DD1')
> was added to restrict the use of PMC5 in Power9 DD1. Intend is to diable
> the use of PMC5 using raw event code. Commit instead of updating
> "power9_isa207_pmu"
> structure, updated "power9_pmu" structure. Patch to fix the same.
>
> Fixes: 8d911904f3ce4 ('powerpc/perf: Add restrictions to PMC5 in power9 DD1')
> Reported-by: Shriya
> Signed-off-by: Madhavan Srinivasan
> Tested-by: Shriya
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/8c218578fcbbbdb10416c8614658bf
cheers
[patch -mm] mm, hugetlb: schedule when potentially allocating many hugepages
A few hugetlb allocators loop while calling the page allocator and can
potentially prevent rescheduling if the page allocator slowpath is not
utilized.
Conditionally schedule when large numbers of hugepages can be allocated.
Signed-off-by: David Rientjes
---
Based on -mm only to prevent merge conflicts with
"mm/hugetlb.c: warn the user when issues arise on boot due to hugepages"
mm/hugetlb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1754,6 +1754,7 @@ static int gather_surplus_pages(struct hstate *h, int
delta)
break;
}
list_add(&page->lru, &surplus_list);
+ cond_resched();
}
allocated += i;
@@ -,6 +2223,7 @@ static void __init hugetlb_hstate_alloc_pages(struct
hstate *h)
} else if (!alloc_fresh_huge_page(h,
&node_states[N_MEMORY]))
break;
+ cond_resched();
}
if (i < h->max_huge_pages) {
char buf[32];
@@ -2364,6 +2366,7 @@ static unsigned long set_max_huge_pages(struct hstate *h,
unsigned long count,
ret = alloc_fresh_gigantic_page(h, nodes_allowed);
else
ret = alloc_fresh_huge_page(h, nodes_allowed);
+ cond_resched();
spin_lock(&hugetlb_lock);
if (!ret)
goto out;
Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using
On Wed, 2017-06-07 at 18:26 +0100, Mark Rutland wrote: > On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote: > > > On the better bootloaders, an initramfs segment can be loaded > > > independently (and you can have as many as required), which makes > > > an > > > early_initramfs a more palatable vector to inject large amounts of > > > entropy into the next boot than, say, modifying the kernel image > > > directly at every boot/shutdown to stash entropy in there > > > somewhere. > > [...] > > > I didn't really understand the device tree approach and mentioned a > > few times before. Passing via the kernel cmdline is a lot simpler > > than > > modifying the device tree in-memory and persistent modification > > isn't > > an option unless verified boot is missing anyway. > > I might be missing something here, but the command line is inside of > the > device tree, at /chosen/bootargs, so modifying the kernel command line > *is* modifying the device tree in-memory. > > For arm64, we have a /chosen/kaslr-seed property that we hope > FW/bootloaders fill in, and similar could be done for some initial > entropy, provided appropriate HW/FW support. > > Thanks, > Mark. I was assuming it was simpler since bootloaders are already setting it, but it seems I'm wrong about that.
[PATCH] MAINTAINERS: gpio: gpio-davinci: Add entry for gpio-davinci driver
Add an entry for the gpio-davinci driver and add myself as a maintainer for the same. Signed-off-by: Keerthy --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index fbad0b6..eb908ba 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11906,6 +11906,13 @@ S: Maintained F: drivers/media/platform/davinci/ F: include/media/davinci/ +TI DAVINCI SERIES GPIO DRIVER +M: Keerthy +L: linux-g...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/gpio/gpio-davinci.txt +F: drivers/gpio/gpio-davinci.c + TI AM437X VPFE DRIVER M: "Lad, Prabhakar" L: linux-me...@vger.kernel.org -- 1.9.1
Re: [PATCH 03/17] base: fix order of OF initialization
On 06/07/17 11:39, Wesley Terpstra wrote: > It was a while ago that I debugged this. I already reported this bug > to Benjamin Herrenschmidt (now in CC), and I believe he has a patch of > his own to fix the same issue. > > As I understand it, of_core_init sets up the OF entries in > /sys/firmware/devicetree. During platform bringup, when the system > describes the cpu + cache hierarchy, it also makes an of_node symlink > into that directory. However, if it doesn't exist yet, you get the > warning. > > # ls -l /sys/devices/system/cpu/cpu3/of_node > lrwxrwxrwx1 root root 0 Jan 1 00:00 > /sys/devices/system/cpu/cpu3/of_node -> > ../../../../firmware/devicetree/base/cpus/cpu@3 > > On Wed, Jun 7, 2017 at 2:35 AM, Mark Rutland wrote: >> On Wed, Jun 07, 2017 at 09:07:20AM +0200, Geert Uytterhoeven wrote: >>> CC devicetree folks >>> >>> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt wrote: From: "Wesley W. Terpstra" This fixes: [0.01] cpu cpu0: Error -2 creating of_node link ... which you get for every CPU on all architectures with a OF cpu/ node. >> >> I take it this means a /cpus node? Or the /cpus/cpu@* nodes? >> >> I'm not seeing this on arm64 when booting v4.12-rc4 with DT, so clearly >> this doesn't affect all such architectures. >> >> What path are these errors happening in? On the surface, the patch looks reasonable. But it is not obvious to me why the error message is occurring. I would like to understand the cause before saying the patch is good. What kernel version is showing the error? For a specific architecture (the patch lists 'riscv, nios, etc'), which config and device tree source? And again, what is the calling path? - Frank >> >> Thanks, >> Mark. >> This affects riscv, nios, etc. Signed-off-by: Palmer Dabbelt --- drivers/base/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/init.c b/drivers/base/init.c index 48c0e220acc0..0dcd17e561d0 100644 --- a/drivers/base/init.c +++ b/drivers/base/init.c @@ -31,9 +31,9 @@ void __init driver_init(void) /* These are also core pieces, but must come after the * core core pieces. */ + of_core_init(); platform_bus_init(); cpu_dev_init(); memory_dev_init(); container_dev_init(); - of_core_init(); } -- 2.13.0 >>> -- >>> To unsubscribe from this list: send the line "unsubscribe devicetree" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH] cpufreq: exynos5440: Fix inconsistent indenting
On 07-06-17, 20:13, Krzysztof Kozlowski wrote: > Fix inconsistent indenting and unneeded white space in assignment. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/cpufreq/exynos5440-cpufreq.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/exynos5440-cpufreq.c > b/drivers/cpufreq/exynos5440-cpufreq.c > index 9180d34cc9fc..b6b369c22272 100644 > --- a/drivers/cpufreq/exynos5440-cpufreq.c > +++ b/drivers/cpufreq/exynos5440-cpufreq.c > @@ -173,12 +173,12 @@ static void exynos_enable_dvfs(unsigned int > cur_frequency) > /* Enable PSTATE Change Event */ > tmp = __raw_readl(dvfs_info->base + XMU_PMUEVTEN); > tmp |= (1 << PSTATE_CHANGED_EVTEN_SHIFT); > - __raw_writel(tmp, dvfs_info->base + XMU_PMUEVTEN); > + __raw_writel(tmp, dvfs_info->base + XMU_PMUEVTEN); > > /* Enable PSTATE Change IRQ */ > tmp = __raw_readl(dvfs_info->base + XMU_PMUIRQEN); > tmp |= (1 << PSTATE_CHANGED_IRQEN_SHIFT); > - __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN); > + __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN); > > /* Set initial performance index */ > cpufreq_for_each_entry(pos, freq_table) > @@ -330,7 +330,7 @@ static int exynos_cpufreq_probe(struct platform_device > *pdev) > struct resource res; > unsigned int cur_frequency; > > - np = pdev->dev.of_node; > + np = pdev->dev.of_node; > if (!np) > return -ENODEV; Acked-by: Viresh Kumar -- viresh
[PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM
Trusted Path Execution (TPE) Patch Versions: v1: * initial patch introduction v2: * included copyright notice from Brad Spengler and Corey Henderson * reversed the invert_gid logic. tpe.gid now defaults to being the trusted group rather than the untrusted group. * fixed race condition by taking reference to the parent dentry * added sysctl tpe.restrict_root that includes the root user in TPE checks * added mprotect and mmap restrictions from Corey Henderson tpe-lkm project * added documentation file This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature. It also adds features and config options that were found in Corey Henderson's tpe-lkm project. Modifications from Brad Spengler's implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook bprm_set_creds. Also, a new denial logging function was used to simplify printing messages to the kernel log. Additionally, mmap and mprotect restrictions were taken from Corey Henderson's tpe-lkm project and implemented using the LSM hooks mmap_file and file_mprotect. Trusted Path Execution is not a new idea: http://phrack.org/issues/52/6.html#article | A trusted path is one that is inside a root owned directory that | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are | (under normal circumstances) considered trusted. Any non-root | users home directory is not trusted, nor is /tmp. To be clear, Trusted Path Execution is no replacement for a MAC system like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough without requiring a userland utility to configure policies. The fact that TPE only requires the user to turn on a few sysctl options lowers the barrier to implementing a security framework substantially. Threat Models: 1. Attacker on system executing exploit on system vulnerability * If attacker uses a binary as a part of their system exploit, TPE can frustrate their efforts * This protection can be more effective when an attacker does not yet have an interactive shell on a system * Issues: * Can be bypassed by interpreted languages such as python. You can run malicious code by doing: python -c 'evil code' 2. Attacker on system replaces binary used by a privileged user with a malicious one * This situation arises when the administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model Documentation/security/tpe.txt | 59 +++ MAINTAINERS| 5 + include/linux/lsm_hooks.h | 5 + security/Kconfig | 1 + security/Makefile | 2 + security/security.c| 1 + security/tpe/Kconfig | 64 security/tpe/Makefile | 3 + security/tpe/tpe_lsm.c | 218 +
[PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM
This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature. It also adds features and config options that were found in Corey Henderson's tpe-lkm project. Modifications from Brad Spengler's implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook bprm_set_creds. Also, a new denial logging function was used to simplify printing messages to the kernel log. Additionally, mmap and mprotect restrictions were taken from Corey Henderson's tpe-lkm project and implemented using the LSM hooks mmap_file and file_mprotect. Trusted Path Execution is not a new idea: http://phrack.org/issues/52/6.html#article | A trusted path is one that is inside a root owned directory that | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are | (under normal circumstances) considered trusted. Any non-root | users home directory is not trusted, nor is /tmp. To be clear, Trusted Path Execution is no replacement for a MAC system like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough without requiring a userland utility to configure policies. The fact that TPE only requires the user to turn on a few sysctl options lowers the barrier to implementing a security framework substantially. Threat Models: 1. Attacker on system executing exploit on system vulnerability * If attacker uses a binary as a part of their system exploit, TPE can frustrate their efforts * This protection can be more effective when an attacker does not yet have an interactive shell on a system * Issues: * Can be bypassed by interpreted languages such as python. You can run malicious code by doing: python -c 'evil code' 2. Attacker on system replaces binary used by a privileged user with a malicious one * This situation arises when the administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model This Trusted Path Execution implementation introduces the following Kconfig options and sysctls. The Kconfig text and sysctl options are taken heavily from Brad Spengler's implementation. Some extra sysctl options were taken from Corey Henderson's implementation. CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled) default: n This option enables Trusted Path Execution. TPE blocks *untrusted* users from executing files that meet the following conditions: * file is not in a root-owned directory * file is writable by a user other than root NOTE: By default root is not restricted by TPE. CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid) default: 0 This option defines a group id that, by default, is the trusted group. If a user is not trusted then it has the checks described in CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the checks are not applied. You can disable the trusted gid option by setting it to 0. This makes all non-root users untrusted. CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict) default: n This option applies another set of restrictions to all non-root users even if they are trusted. This only allows execution under the following conditions: * file is in a directory owned by the user that is not group or world-writable * file is in a directory owned by root and writable only by root CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root) default: n This option applies all enabled TPE restrictions to root. CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid) default: n This option reverses the trust logic of the gid option and makes kernel.tpe.gid into the untrusted group. This means that all other groups become trusted. This sysctl is helpful when you want TPE restrictions to be limited to a small subset of users. Signed-off-by: Matt Brown --- Documentation/security/tpe.txt | 59 +++ MAINTAINERS| 5 + include/linux/lsm_hooks.h | 5 + security/Kconfig | 1 + security/Makefile | 2 + security/security.c| 1 + security/tpe/Kconfig | 64 security/tpe/Makefile | 3 + security/tpe/tpe_lsm.c | 218 + 9 files changed, 358 insertions(+) create mode 100644 Documentation/security/tpe.txt create mode 100644 security/tpe/Kconfig create mode 100644 security/tpe/Makefile create mode 100644 security/tpe/tpe_lsm.c diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt new file mode 100644 index 000..226afcc --- /dev/null +++ b/Documentation/security/tpe.txt @@ -0,0 +1,59 @@ +Trusted Path Execution is a Linux Security Module that generally requires +programs to be run from a trusted path. A trusted path is one that is owned by +root and is not group/world writable. This prevents an attacker from executing +their own malicious binaries from an unprivileged user on the system. This +feature is enabled with CONFIG_SECURITY_TPE. When enabled, a set of sysctl
Re: [PATCH v3] mfd: lp87565: Add lp87565 PMIC support
On Thursday 08 June 2017 02:41 AM, Rob Herring wrote:
> On Tue, May 30, 2017 at 06:57:40PM +0530, Keerthy wrote:
>> The LP87565 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Configurable Bucks(Single and multi-phase).
>> - Configurable General Purpose Output Signals (GPO).
>>
>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>> output.
>>
>> Signed-off-by: Keerthy
>> ---
>>
>> The other patches are already pulled by Mark. Hence posting
>> the remaining patch.
>>
>> Changes in v3:
>>
>> * Fixed License to GPL v2.
>> * Fixed an indentation issue.
>>
>> Changes in v2:
>>
>> * Fixed a bunch of whitespace errors.
>> * Changed the License to short form.
>> * Added the generic compatible lp87565
>> * Removed i2c_device_id table.
>> * Introduced probe_new function in place of probe.
>>
>> Documentation/devicetree/bindings/mfd/lp87565.txt | 45
>> drivers/mfd/Kconfig | 14 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/lp87565.c | 92
>> include/linux/mfd/lp87565.h | 270
>> ++
>> 5 files changed, 422 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>> create mode 100644 drivers/mfd/lp87565.c
>> create mode 100644 include/linux/mfd/lp87565.h
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt
>> b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> new file mode 100644
>> index 000..f63d568
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
>> @@ -0,0 +1,45 @@
>> +TI LP87565 PMIC MFD driver
>> +
>> +Required properties:
>> + - compatible: "ti,lp87565", "ti,lp87565-q1"
>> + - reg:I2C slave address.
>> + - gpio-controller:Marks the device node as a GPIO Controller.
>> + - #gpio-cells:Should be two. The first cell is the pin number and
>> +the second cell is used to specify flags.
>> +See ../gpio/gpio.txt for more information.
>> + - xxx-in-supply: Phandle to parent supply node of each regulator
>> +populated under regulators node. xxx should match
>> +the supply_name populated in driver.
>> + - regulators: List of child nodes that specify the regulator
>> +initialization data.
>
> This is a node, not a property.
Okay
>
>> +Example:
>> +
>> +lp87565_pmic: lp87565@60 {
>
> pmic@60
Okay. I will fix that.
>
>> +compatible = "ti,lp87565-q1";
>> +reg = <0x60>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +
>> +buck10-in-supply = <&vsys_3v3>;
>> +buck23-in-supply = <&vsys_3v3>;
>> +
>> +regulators: regulators {
>> +buck10_reg: buck10 {
>> +/* VDD_MPU */
>> +regulator-name = "buck10";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +};
>> +
>> +buck23_reg: buck23 {
>> +/* VDD_GPU */
>> +regulator-name = "buck23";
>> +regulator-min-microvolt = <85>;
>> +regulator-max-microvolt = <125>;
>> +regulator-boot-on;
>> +regulator-always-on;
>> +};
>> +};
>> +};
