All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v6 14/19] target-arm/powerctl: defer cpu reset work to CPU context
From: Alex Bennée @ 2016-11-09 14:57 UTC (permalink / raw)
  To: pbonzini
  Cc: qemu-devel, mttcg, fred.konrad, a.rigo, cota, bobby.prani, nikunj,
	mark.burton, jan.kiszka, serge.fdrv, rth, peter.maydell,
	claudio.fontana, Alex Bennée, open list:ARM
In-Reply-To: <20161109145748.27282-1-alex.bennee@linaro.org>

When switching a new vCPU on we want to complete a bunch of the setup
work before we start scheduling the vCPU thread. To do this cleanly we
defer vCPU setup to async work which will run the vCPUs execution
context as the thread is woken up. The scheduling of the work will kick
the vCPU awake.

This avoids potential races in MTTCG system emulation.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target-arm/arm-powerctl.c | 144 +++++++++++++++++++++++++++-------------------
 1 file changed, 86 insertions(+), 58 deletions(-)

diff --git a/target-arm/arm-powerctl.c b/target-arm/arm-powerctl.c
index fbb7a15..0ef4b29 100644
--- a/target-arm/arm-powerctl.c
+++ b/target-arm/arm-powerctl.c
@@ -48,11 +48,85 @@ CPUState *arm_get_cpu_by_id(uint64_t id)
     return NULL;
 }
 
+struct cpu_on_info {
+    uint64_t entry;
+    uint64_t context_id;
+    uint32_t target_el;
+    bool target_aa64;
+};
+
+
+static void arm_set_cpu_on_async_work(CPUState *target_cpu_state,
+                                      run_on_cpu_data data)
+{
+    ARMCPU *target_cpu = ARM_CPU(target_cpu_state);
+    struct cpu_on_info *info = (struct cpu_on_info *) data.host_ptr;
+
+    /* Initialize the cpu we are turning on */
+    cpu_reset(target_cpu_state);
+    target_cpu->powered_off = false;
+    target_cpu_state->halted = 0;
+
+    if (info->target_aa64) {
+        if ((info->target_el < 3) && arm_feature(&target_cpu->env, ARM_FEATURE_EL3)) {
+            /*
+             * As target mode is AArch64, we need to set lower
+             * exception level (the requested level 2) to AArch64
+             */
+            target_cpu->env.cp15.scr_el3 |= SCR_RW;
+        }
+
+        if ((info->target_el < 2) && arm_feature(&target_cpu->env, ARM_FEATURE_EL2)) {
+            /*
+             * As target mode is AArch64, we need to set lower
+             * exception level (the requested level 1) to AArch64
+             */
+            target_cpu->env.cp15.hcr_el2 |= HCR_RW;
+        }
+
+        target_cpu->env.pstate = aarch64_pstate_mode(info->target_el, true);
+    } else {
+        /* We are requested to boot in AArch32 mode */
+        static uint32_t mode_for_el[] = { 0,
+                                          ARM_CPU_MODE_SVC,
+                                          ARM_CPU_MODE_HYP,
+                                          ARM_CPU_MODE_SVC };
+
+        cpsr_write(&target_cpu->env, mode_for_el[info->target_el], CPSR_M,
+                   CPSRWriteRaw);
+    }
+
+    if (info->target_el == 3) {
+        /* Processor is in secure mode */
+        target_cpu->env.cp15.scr_el3 &= ~SCR_NS;
+    } else {
+        /* Processor is not in secure mode */
+        target_cpu->env.cp15.scr_el3 |= SCR_NS;
+    }
+
+    /* We check if the started CPU is now at the correct level */
+    assert(info->target_el == arm_current_el(&target_cpu->env));
+
+    if (info->target_aa64) {
+        target_cpu->env.xregs[0] = info->context_id;
+        target_cpu->env.thumb = false;
+    } else {
+        target_cpu->env.regs[0] = info->context_id;
+        target_cpu->env.thumb = info->entry & 1;
+        info->entry &= 0xfffffffe;
+    }
+
+    /* Start the new CPU at the requested address */
+    cpu_set_pc(target_cpu_state, info->entry);
+    g_free(info);
+}
+
 int arm_set_cpu_on(uint64_t cpuid, uint64_t entry, uint64_t context_id,
                    uint32_t target_el, bool target_aa64)
 {
     CPUState *target_cpu_state;
     ARMCPU *target_cpu;
+    struct cpu_on_info *info;
 
     DPRINTF("cpu %" PRId64 " (EL %d, %s) @ 0x%" PRIx64 " with R0 = 0x%" PRIx64
             "\n", cpuid, target_el, target_aa64 ? "aarch64" : "aarch32", entry,
@@ -109,64 +183,18 @@ int arm_set_cpu_on(uint64_t cpuid, uint64_t entry, uint64_t context_id,
         return QEMU_ARM_POWERCTL_INVALID_PARAM;
     }
 
-    /* Initialize the cpu we are turning on */
-    cpu_reset(target_cpu_state);
-    target_cpu->powered_off = false;
-    target_cpu_state->halted = 0;
-
-    if (target_aa64) {
-        if ((target_el < 3) && arm_feature(&target_cpu->env, ARM_FEATURE_EL3)) {
-            /*
-             * As target mode is AArch64, we need to set lower
-             * exception level (the requested level 2) to AArch64
-             */
-            target_cpu->env.cp15.scr_el3 |= SCR_RW;
-        }
-
-        if ((target_el < 2) && arm_feature(&target_cpu->env, ARM_FEATURE_EL2)) {
-            /*
-             * As target mode is AArch64, we need to set lower
-             * exception level (the requested level 1) to AArch64
-             */
-            target_cpu->env.cp15.hcr_el2 |= HCR_RW;
-        }
-
-        target_cpu->env.pstate = aarch64_pstate_mode(target_el, true);
-    } else {
-        /* We are requested to boot in AArch32 mode */
-        static uint32_t mode_for_el[] = { 0,
-                                          ARM_CPU_MODE_SVC,
-                                          ARM_CPU_MODE_HYP,
-                                          ARM_CPU_MODE_SVC };
-
-        cpsr_write(&target_cpu->env, mode_for_el[target_el], CPSR_M,
-                   CPSRWriteRaw);
-    }
-
-    if (target_el == 3) {
-        /* Processor is in secure mode */
-        target_cpu->env.cp15.scr_el3 &= ~SCR_NS;
-    } else {
-        /* Processor is not in secure mode */
-        target_cpu->env.cp15.scr_el3 |= SCR_NS;
-    }
-
-    /* We check if the started CPU is now at the correct level */
-    assert(target_el == arm_current_el(&target_cpu->env));
-
-    if (target_aa64) {
-        target_cpu->env.xregs[0] = context_id;
-        target_cpu->env.thumb = false;
-    } else {
-        target_cpu->env.regs[0] = context_id;
-        target_cpu->env.thumb = entry & 1;
-        entry &= 0xfffffffe;
-    }
-
-    /* Start the new CPU at the requested address */
-    cpu_set_pc(target_cpu_state, entry);
-
-    qemu_cpu_kick(target_cpu_state);
+    /* To avoid racing with a CPU we are just kicking off we do the
+     * final bit of preparation for the work in the target CPUs
+     * context.
+     */
+    info = g_new(struct cpu_on_info, 1);
+    info->entry = entry;
+    info->context_id = context_id;
+    info->target_el = target_el;
+    info->target_aa64 = target_aa64;
+
+    async_run_on_cpu(target_cpu_state, arm_set_cpu_on_async_work,
+                     RUN_ON_CPU_HOST_PTR(info));
 
     /* We are good to go */
     return QEMU_ARM_POWERCTL_RET_SUCCESS;
-- 
2.10.1

^ permalink raw reply related

* [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support
From: Boris Brezillon @ 2016-11-09 14:57 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161109143237.x5ih2dnsri3jrong@lukather>

On Wed, 9 Nov 2016 15:32:37 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> Hi Boris,
> 
> On Tue, Nov 08, 2016 at 05:27:48PM +0100, Boris Brezillon wrote:
> > On Tue,  8 Nov 2016 17:21:13 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >   
> > > From: Hans de Goede <hdegoede@redhat.com>
> > > 
> > > Enable the NAND and UBI support in the configuration header so that we can
> > > (finally) use it.
> > > 
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > >  include/configs/sunxi-common.h | 26 ++++++++++++++++++++++----
> > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> > > index 8363414828fa..1733767ba53b 100644
> > > --- a/include/configs/sunxi-common.h
> > > +++ b/include/configs/sunxi-common.h
> > > @@ -129,9 +129,23 @@
> > >  #define CONFIG_SERIAL_TAG
> > >  
> > >  #ifdef CONFIG_NAND_SUNXI
> > > +#define CONFIG_SYS_NAND_U_BOOT_OFFS	(8 << 20) /* 8 MiB */  
> > 
> > Can we make this configurable through Kconfig?  
> 
> Is there a need for that?

Yes, I think so, since each board has a different kind of NAND (with
possibly different eraseblock size) and I'm not sure this is always
acceptable to lose 8MiB of storage for the SPL images (especially for
small SLC NANDs).

> AFAIK, everyone in U-Boot defines it there
> (and converting everyone to Kconfig for all the CONFIG_SYS_NAND
> options is going to be painful).

It already exists: enable the SYS_NAND_U_BOOT_LOCATIONS Kconfig
option, and you should see the SYS_NAND_U_BOOT_OFFS and
SYS_NAND_U_BOOT_OFFS_REDUND ones.

> 
> Thanks!
> Maxime
> 

^ permalink raw reply

* Re: [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size
From: Mahesh Kumar @ 2016-11-09 14:58 UTC (permalink / raw)
  To: Paulo Zanoni, intel-gfx
In-Reply-To: <1477936993.2535.17.camel@intel.com>

Hi,


On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
>> This patch make changes to use linetime latency instead of allocated
>> DDB size during plane watermark calculation in switch case, This is
>> required to implement new DDB allocation algorithm.
>>
>> In New Algorithm DDB is allocated based on WM values, because of
>> which
>> number of DDB blocks will not be available during WM calculation,
>> So this "linetime latency" is suggested by SV/HW team to use during
>> switch-case for WM blocks selection.
>>
>> Changes since v1:
>>   - Rebase on top of Paulo's patch series
>> Changes since v2:
>>   - Fix if-else condition (pointed by Maarten)
>>
>> Signed-off-by: "Kumar, Mahesh" <mahesh1.kumar@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_pm.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 7f1748a..098336d 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -3616,10 +3616,14 @@ static int skl_compute_plane_wm(const struct
>> drm_i915_private *dev_priv,
>>   	    fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
>>   		selected_result = max(method2, y_tile_minimum);
>>   	} else {
>> +		uint32_t linetime_us = 0;
>> +
>> +		linetime_us = DIV_ROUND_UP(width * 1000,
>> +				skl_pipe_pixel_rate(cstate));
> Can't we just call skl_compute_linetime_wm() here? I don't like having
> two pieces of the code computing the same thing. My last round of bug
> fixes included a fix for duplicated code that got out of sync after
> spec changes.
These two have different values in skl_compute_linetime_wm we multiply 
by 8, not here.
>
>>   		if ((cpp * cstate->base.adjusted_mode.crtc_htotal /
>> 512 < 1) &&
>>   		    (plane_bytes_per_line / 512 < 1))
>>   			selected_result = method2;
>> -		else if ((ddb_allocation / plane_blocks_per_line) >=
>> 1)
>> +		else if (latency >= linetime_us)
> Still doesn't match the spec. The "ddb_allocation /
> planes_block_per_line" is still necessary.
After New algorithm patch, we will not have access to ddb_allocation, as 
allocation will happen later.
So we can't use ddb_allocation in our calculation, This check in Bspec 
is kept for the environment/OS where we don't allocate DDB dynamically.
hence those OS will have access to ddb_allocation during WM calculation 
phase.
thanks,

Regards,
-Mahesh
>
>>   			selected_result = min(method1, method2);
>>   		else
>>   			selected_result = method1;

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
From: Paul Durrant @ 2016-11-09 14:56 UTC (permalink / raw)
  To: Boris Ostrovsky, xen-devel@lists.xen.org
  Cc: Andrew Cooper, Roger Pau Monne, Wei Liu, jbeulich@suse.com,
	Ian Jackson
In-Reply-To: <1478702399-14538-8-git-send-email-boris.ostrovsky@oracle.com>

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
> Sent: 09 November 2016 14:40
> To: xen-devel@lists.xen.org
> Cc: jbeulich@suse.com; Andrew Cooper <Andrew.Cooper3@citrix.com>;
> Wei Liu <wei.liu2@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Roger
> Pau Monne <roger.pau@citrix.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; Paul Durrant <Paul.Durrant@citrix.com>
> Subject: [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO
> accesses
> 
> PVH guests will have ACPI accesses emulated by the hypervisor
> as opposed to QEMU (as is the case for HVM guests)
> 
> Support for IOREQ server emulation of CPU hotplug is indicated
> by XEN_X86_EMU_IOREQ_CPUHP flag.
> 
> Logic for the handler will be provided by a later patch.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
> CC: Paul Durrant <paul.durrant@citrix.com>
> ---
> Changes in v2:
> * Introduce XEN_X86_EMU_IOREQ_CPUHP, don't set
> HVM_PARAM_NR_IOREQ_SERVER_PAGES
>   for PVH guests

Is 'CPUHP' the right name? The same GPE block could be used for DIMM and PCI hotplug, right? That aside...

Reviewed-by: Paul Durrant <paul.durrant@citrix.com>

> * Register IO hadler for PVH from hvm_ioreq_init()
> 
>  xen/arch/x86/hvm/ioreq.c          | 18 ++++++++++++++++++
>  xen/include/asm-x86/domain.h      |  2 ++
>  xen/include/public/arch-x86/xen.h |  5 ++++-
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index d2245e2..e6ff48f 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1380,6 +1380,12 @@ static int hvm_access_cf8(
>      return X86EMUL_UNHANDLEABLE;
>  }
> 
> +static int acpi_ioaccess(
> +    int dir, unsigned int port, unsigned int bytes, uint32_t *val)
> +{
> +    return X86EMUL_OKAY;
> +}
> +
>  void hvm_ioreq_init(struct domain *d)
>  {
>      spin_lock_init(&d->arch.hvm_domain.ioreq_server.lock);
> @@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d)
> 
>      if ( !is_pvh_domain(d) )
>          register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
> +
> +    if ( !has_ioreq_cpuhp(d) )
> +    {
> +        /* Online CPU map, see DSDT's PRST region. */
> +        register_portio_handler(d, ACPI_CPU_MAP,
> +                                ACPI_CPU_MAP_LEN, acpi_ioaccess);
> +
> +        register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
> +                                ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess);
> +        register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
> +                                ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess);
> +    }
>  }
> 
>  /*
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index a279e4a..7aa736c 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -431,6 +431,8 @@ struct arch_domain
>  #define has_vvga(d)        (!!((d)->arch.emulation_flags &
> XEN_X86_EMU_VGA))
>  #define has_viommu(d)      (!!((d)->arch.emulation_flags &
> XEN_X86_EMU_IOMMU))
>  #define has_vpit(d)        (!!((d)->arch.emulation_flags &
> XEN_X86_EMU_PIT))
> +#define has_ioreq_cpuhp(d) (!!((d)->arch.emulation_flags & \
> +                               XEN_X86_EMU_IOREQ_CPUHP))
> 
>  #define has_arch_pdevs(d)    (!list_empty(&(d)->arch.pdev_list))
> 
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-
> x86/xen.h
> index cdd93c1..350bc66 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -283,12 +283,15 @@ struct xen_arch_domainconfig {
>  #define XEN_X86_EMU_IOMMU           (1U<<_XEN_X86_EMU_IOMMU)
>  #define _XEN_X86_EMU_PIT            8
>  #define XEN_X86_EMU_PIT             (1U<<_XEN_X86_EMU_PIT)
> +#define _XEN_X86_EMU_IOREQ_CPUHP    9
> +#define XEN_X86_EMU_IOREQ_CPUHP
> (1U<<_XEN_X86_EMU_IOREQ_CPUHP)
> 
>  #define XEN_X86_EMU_ALL             (XEN_X86_EMU_LAPIC |
> XEN_X86_EMU_HPET |  \
>                                       XEN_X86_EMU_PM | XEN_X86_EMU_RTC |      \
>                                       XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
>                                       XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
> -                                     XEN_X86_EMU_PIT)
> +                                     XEN_X86_EMU_PIT |                       \
> +                                     XEN_X86_EMU_IOREQ_CPUHP)
>      uint32_t emulation_flags;
>  };
>  #endif
> --
> 2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Jan Beulich @ 2016-11-09 14:55 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
	xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <fb31aaf5-b45e-9597-c295-c50c80fdc002@bitdefender.com>

>>> On 09.11.16 at 15:28, <rcojocaru@bitdefender.com> wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>>>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
>>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>>> +{
>>> +    struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>> +
>>> +    if ( vmcb->eventinj.fields.v )
>>> +        return false;
>>> +
>>> +    info->vector = vmcb->eventinj.fields.vector;
>>> +    info->type = vmcb->eventinj.fields.type;
>>> +    info->error_code = vmcb->eventinj.fields.errorcode;
>>> +    info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>> 
>> I'd prefer for this last part to be put into generic code (i.e. the
>> wrapper).
> 
> Actually, doing this:
> 
> static inline bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
> {
>     info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>     return hvm_funcs.get_pending_event(v, info);
> }
> 
> leads to "error: dereferencing pointer to incomplete type" about v->, so
> to do this an additional #include will be necessary. Is that acceptable?

Better make it an out-of-line function in hvm.c.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: omap watchdog boot status
From: Cor Peters @ 2016-11-09 14:40 UTC (permalink / raw)
  To: linux-watchdog
In-Reply-To: <8d23fff0-5e47-e623-f367-b2605b796bdf@roeck-us.net>

On Monday 07 November 2016 17:12:56 Guenter Roeck wrote:
> On 11/07/2016 06:26 AM, Cor Peters wrote:
> > Hello everybody
> >
> > I was looking into an issue with the omap-wdt.c. The  watchdog driver not is
> > reporting a different boot status when a reset is being triggered by the
> > watchdog.
> >
> >>From what I gathered, the issue is that in the omap_wdt_probe function,
> > pdev->dev->platform_data requires to be a reference to the PRM module,
> > however it has not been set, and I was wondering how this should work in
> > an environment that uses the device tree method. (Link to usage:
> > http://lxr.free-electrons.com/source/drivers/watchdog/omap_wdt.c#L268[1] ).
> >
> > My questions are as follows:
> > 1) Is my assertion correct that the current method does not work when
> >   the driver is being initialised from an device tree instead of a old style
> >   board file.
> 
> I think you are correct.
> 
> > 2) If that is the case, what would be the best method of fixing this situation.
> >
> I am not a devicetree expert, but you may have to define a property to point to
> the register and bit providing the necessary information. This could possibly
> be done with syscon, but I really don't know enough about it to really know for
> sure what the best approach would be.

Thanks, syscon seems like a good solution.
 
> Guenter
> 

Cor

^ permalink raw reply

* Re: [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
From: Boris Ostrovsky @ 2016-11-09 14:54 UTC (permalink / raw)
  To: Julien Grall, xen-devel
  Cc: wei.liu2, andrew.cooper3, ian.jackson, Paul Durrant, jbeulich,
	roger.pau
In-Reply-To: <7fd5fdc5-2742-72a2-a2e6-47627f99fe61@arm.com>

On 11/09/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> diff --git a/xen/include/public/arch-arm.h
>> b/xen/include/public/arch-arm.h
>> index bd974fb..b793774 100644
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
>>   * should instead use the FDT.
>>   */
>>
>> +/* Current supported guest VCPUs */
>> +#define GUEST_MAX_VCPUS 128
>> +
>>  /* Physical Address Space */
>>
>>  /*
>> @@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
>>  #define GUEST_ACPI_BASE 0x20000000ULL
>>  #define GUEST_ACPI_SIZE 0x02000000ULL
>>
>> +/* Location of online VCPU bitmap. */
>> +#define ACPI_CPU_MAP                 0xaf00
>> +#define ACPI_CPU_MAP_LEN             ((GUEST_MAX_VCPUS / 8) + \
>> +                                      ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
>> +
>
> I don't understand this change. PRST is not generated for ARM (see the
> return 0 in mk_dsdt a bit before).

Oh, right --- I missed it. Then this change needs to be dropped.

-boris

>
> In any case, I am expecting CPU hotplug to be handle via PSCI on ARM.
>
> Regards,
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: [PATCH v4 1/4] btrfs-progs: utils: Introduce function to escape characters
From: David Sterba @ 2016-11-09 14:54 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: dsterba, linux-btrfs
In-Reply-To: <e7291503-310e-3c93-3574-dd1f838d6ad8@cn.fujitsu.com>

On Tue, Nov 08, 2016 at 08:57:52AM +0800, Qu Wenruo wrote:
> And further more.
> 
> The new string escaping is screwing up original output.
> 
> Operation lile mkfile lacks the final '\n'.
> String over the width will lack the ending ' ' to seperate later 
> key=value pairs.

Oh right, that's the shortcut if format is null, this should print the
'\n' as welll, I'll fix it.

> It would be better to output the escaped string into a buffer and still 
> use printf() format to output them out as it used to be.

I want to avoid using the intermediate string buffers unless it's really
necessary.

^ permalink raw reply

* [PATCH v2 2/2] pinctrl: single: search for the bits property when parsing bits
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
  To: tony, haojian.zhuang, linus.walleij, khilman, nsekhar
  Cc: linux-arm-kernel, linux-omap, linux-gpio, linux-kernel,
	Axel Haslam
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>

The pcs_parse_bits_in_pinctrl_entry function should search
for the "pinctrl-single,bits" and not "pinctrl-single,pins"

Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
 drivers/pinctrl/pinctrl-single.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f36a9f1..2b196e5 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1223,7 +1223,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
 						unsigned *num_maps,
 						const char **pgnames)
 {
-	const char *name = "pinctrl-single,pins";
+	const char *name = "pinctrl-single,bits";
 	struct pcs_func_vals *vals;
 	int rows, *pins, found = 0, res = -ENOMEM, i;
 	int npins_in_row;
-- 
2.10.1


^ permalink raw reply related

* [PATCH v2 1/2] pinctrl: single: check for any error when getting rows
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
  To: tony, haojian.zhuang, linus.walleij, khilman, nsekhar
  Cc: linux-arm-kernel, linux-omap, linux-gpio, linux-kernel,
	Axel Haslam
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>

pinctrl_count_index_with_args returns -ENOENT not
-EINVAL. The return check would pass, and we would
try to kzalloc with a negative error size throwing
a warning.

Instead of checking for -EINVAL specifically, lets
check for any error and avoid negative size allocations.

Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
 drivers/pinctrl/pinctrl-single.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 539f31c..f36a9f1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1133,8 +1133,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
 	struct pcs_function *function;
 
 	rows = pinctrl_count_index_with_args(np, name);
-	if (rows == -EINVAL)
-		return rows;
+	if (rows <= 0) {
+		dev_err(pcs->dev, "Ivalid number of rows: %d\n", rows);
+		return -EINVAL;
+	}
 
 	vals = devm_kzalloc(pcs->dev, sizeof(*vals) * rows, GFP_KERNEL);
 	if (!vals)
@@ -1228,8 +1230,10 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
 	struct pcs_function *function;
 
 	rows = pinctrl_count_index_with_args(np, name);
-	if (rows == -EINVAL)
-		return rows;
+	if (rows <= 0) {
+		dev_err(pcs->dev, "Invalid number of rows: %d\n", rows);
+		return -EINVAL;
+	}
 
 	npins_in_row = pcs->width / pcs->bits_per_pin;
 
-- 
2.10.1


^ permalink raw reply related

* [PATCH v2 2/2] pinctrl: single: search for the bits property when parsing bits
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>

The pcs_parse_bits_in_pinctrl_entry function should search
for the "pinctrl-single,bits" and not "pinctrl-single,pins"

Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
 drivers/pinctrl/pinctrl-single.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f36a9f1..2b196e5 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1223,7 +1223,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
 						unsigned *num_maps,
 						const char **pgnames)
 {
-	const char *name = "pinctrl-single,pins";
+	const char *name = "pinctrl-single,bits";
 	struct pcs_func_vals *vals;
 	int rows, *pins, found = 0, res = -ENOMEM, i;
 	int npins_in_row;
-- 
2.10.1

^ permalink raw reply related

* [PATCH v2 1/2] pinctrl: single: check for any error when getting rows
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>

pinctrl_count_index_with_args returns -ENOENT not
-EINVAL. The return check would pass, and we would
try to kzalloc with a negative error size throwing
a warning.

Instead of checking for -EINVAL specifically, lets
check for any error and avoid negative size allocations.

Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
 drivers/pinctrl/pinctrl-single.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 539f31c..f36a9f1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1133,8 +1133,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
 	struct pcs_function *function;
 
 	rows = pinctrl_count_index_with_args(np, name);
-	if (rows == -EINVAL)
-		return rows;
+	if (rows <= 0) {
+		dev_err(pcs->dev, "Ivalid number of rows: %d\n", rows);
+		return -EINVAL;
+	}
 
 	vals = devm_kzalloc(pcs->dev, sizeof(*vals) * rows, GFP_KERNEL);
 	if (!vals)
@@ -1228,8 +1230,10 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
 	struct pcs_function *function;
 
 	rows = pinctrl_count_index_with_args(np, name);
-	if (rows == -EINVAL)
-		return rows;
+	if (rows <= 0) {
+		dev_err(pcs->dev, "Invalid number of rows: %d\n", rows);
+		return -EINVAL;
+	}
 
 	npins_in_row = pcs->width / pcs->bits_per_pin;
 
-- 
2.10.1

^ permalink raw reply related

* [PATCH v2 0/2] pinctrl: single: fixes for davinci
From: Axel Haslam @ 2016-11-09 14:53 UTC (permalink / raw)
  To: linux-arm-kernel

After recent pinctl patches we see a warning when booting davinci
due to a bad memory allocation:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:3511 __alloc_pages_nodemask+0x16c/0xb18
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc2-00023-g22d5127-dirty #1019
Hardware name: Generic DA850/OMAP-L138/AM18x
Backtrace: 
[<c000d670>] (dump_backtrace) from [<c000d794>] (show_stack+0x18/0x1c)
[<c000d77c>] (show_stack) from [<c021a0d0>] (dump_stack+0x20/0x28)
[<c021a0b0>] (dump_stack) from [<c001bb10>] (__warn+0xe8/0x100)
[<c001ba28>] (__warn) from [<c001bb50>] (warn_slowpath_null+0x28/0x30)
[<c001bb28>] (warn_slowpath_null) from [<c0097e7c>] (__alloc_pages_nodemask+0x16c/0xb18)
[<c0097d10>] (__alloc_pages_nodemask) from [<c00afef4>] (kmalloc_order+0x20/0x58)
[<c00afed4>] (kmalloc_order) from [<c00ce7ac>] (__kmalloc_track_caller+0x188/0x190)
[<c00ce624>] (__kmalloc_track_caller) from [<c02a762c>] (devm_kmalloc+0x24/0x70)
[<c02a7608>] (devm_kmalloc) from [<c0247d10>] (pcs_dt_node_to_map+0x1d0/0xa40)
[<c0245ec8>] (pinctrl_dt_to_map) from [<c0242fd0>] (pinctrl_get+0xe8/0x484)
[snip]

This series fixes this error.

Changes form v1 -> v2
* Add an error message, and correct also other places where the
issue is seen

* Add patch to parse for bits instead of pins

Axel Haslam (2):
  pinctrl: single: check for any error when getting rows
  pinctrl: single: search for the bits property when parsing bits

 drivers/pinctrl/pinctrl-single.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
2.10.1

^ permalink raw reply

* [PATCH v2 0/2] pinctrl: single: fixes for davinci
From: Axel Haslam @ 2016-11-09 14:53 UTC (permalink / raw)
  To: tony, haojian.zhuang, linus.walleij, khilman, nsekhar
  Cc: linux-arm-kernel, linux-omap, linux-gpio, linux-kernel,
	Axel Haslam

After recent pinctl patches we see a warning when booting davinci
due to a bad memory allocation:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:3511 __alloc_pages_nodemask+0x16c/0xb18
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc2-00023-g22d5127-dirty #1019
Hardware name: Generic DA850/OMAP-L138/AM18x
Backtrace: 
[<c000d670>] (dump_backtrace) from [<c000d794>] (show_stack+0x18/0x1c)
[<c000d77c>] (show_stack) from [<c021a0d0>] (dump_stack+0x20/0x28)
[<c021a0b0>] (dump_stack) from [<c001bb10>] (__warn+0xe8/0x100)
[<c001ba28>] (__warn) from [<c001bb50>] (warn_slowpath_null+0x28/0x30)
[<c001bb28>] (warn_slowpath_null) from [<c0097e7c>] (__alloc_pages_nodemask+0x16c/0xb18)
[<c0097d10>] (__alloc_pages_nodemask) from [<c00afef4>] (kmalloc_order+0x20/0x58)
[<c00afed4>] (kmalloc_order) from [<c00ce7ac>] (__kmalloc_track_caller+0x188/0x190)
[<c00ce624>] (__kmalloc_track_caller) from [<c02a762c>] (devm_kmalloc+0x24/0x70)
[<c02a7608>] (devm_kmalloc) from [<c0247d10>] (pcs_dt_node_to_map+0x1d0/0xa40)
[<c0245ec8>] (pinctrl_dt_to_map) from [<c0242fd0>] (pinctrl_get+0xe8/0x484)
[snip]

This series fixes this error.

Changes form v1 -> v2
* Add an error message, and correct also other places where the
issue is seen

* Add patch to parse for bits instead of pins

Axel Haslam (2):
  pinctrl: single: check for any error when getting rows
  pinctrl: single: search for the bits property when parsing bits

 drivers/pinctrl/pinctrl-single.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

-- 
2.10.1

^ permalink raw reply

* Re: [PATCH] drm/i915: Spin until breadcrumb threads are complete
From: Tvrtko Ursulin @ 2016-11-09 14:53 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx
In-Reply-To: <20161108143719.32215-1-chris@chris-wilson.co.uk>


On 08/11/2016 14:37, Chris Wilson wrote:
> When we need to reset the global seqno on wraparound, we have to wait
> until the current rbtrees are drained (or otherwise the next waiter will
> be out of sequence). The current mechanism to kick and spin until
> complete, may exit too early as it would break if the target thread was
> currently running. Instead, we must wake up the threads, but keep
> spinning until the trees have been deleted.
>
> In order to appease Tvrtko, busy spin rather than yield().
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c  |  5 ++---
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 31 ++++++++++++-------------------
>  drivers/gpu/drm/i915/intel_ringbuffer.h  |  3 +--
>  3 files changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> index d866069c1767..6c71637d4be1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -319,9 +319,8 @@ static int i915_gem_init_global_seqno(struct drm_i915_private *i915, u32 seqno)
>
>  	/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
>  	if (!i915_seqno_passed(seqno, atomic_read(&timeline->next_seqno))) {
> -		while (intel_kick_waiters(i915) || intel_kick_signalers(i915))
> -			yield();
> -		yield();
> +		while (intel_breadcrumbs_busy(i915))
> +			cond_resched(); /* spin until threads are complete */
>  	}
>  	atomic_set(&timeline->next_seqno, seqno);
>
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index c410d3d6465f..c9c46a538edb 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -629,35 +629,28 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
>  	cancel_fake_irq(engine);
>  }
>
> -unsigned int intel_kick_waiters(struct drm_i915_private *i915)
> +unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915)
>  {
>  	struct intel_engine_cs *engine;
>  	enum intel_engine_id id;
>  	unsigned int mask = 0;
>
> -	/* To avoid the task_struct disappearing beneath us as we wake up
> -	 * the process, we must first inspect the task_struct->state under the
> -	 * RCU lock, i.e. as we call wake_up_process() we must be holding the
> -	 * rcu_read_lock().
> -	 */
> -	for_each_engine(engine, i915, id)
> -		if (unlikely(intel_engine_wakeup(engine)))
> -			mask |= intel_engine_flag(engine);
> +	for_each_engine(engine, i915, id) {
> +		struct intel_breadcrumbs *b = &engine->breadcrumbs;
>
> -	return mask;
> -}
> +		spin_lock_irq(&b->lock);
>
> -unsigned int intel_kick_signalers(struct drm_i915_private *i915)
> -{
> -	struct intel_engine_cs *engine;
> -	enum intel_engine_id id;
> -	unsigned int mask = 0;
> +		if (b->first_wait) {
> +			wake_up_process(b->first_wait->tsk);
> +			mask |= intel_engine_flag(engine);
> +		}
>
> -	for_each_engine(engine, i915, id) {
> -		if (unlikely(READ_ONCE(engine->breadcrumbs.first_signal))) {
> -			wake_up_process(engine->breadcrumbs.signaler);
> +		if (b->first_signal) {
> +			wake_up_process(b->signaler);
>  			mask |= intel_engine_flag(engine);
>  		}
> +
> +		spin_unlock_irq(&b->lock);
>  	}
>
>  	return mask;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index cbc148863a03..3466b4e77e7c 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -587,7 +587,6 @@ static inline bool intel_engine_wakeup(const struct intel_engine_cs *engine)
>
>  void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
>  void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
> -unsigned int intel_kick_waiters(struct drm_i915_private *i915);
> -unsigned int intel_kick_signalers(struct drm_i915_private *i915);
> +unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915);
>
>  #endif /* _INTEL_RINGBUFFER_H_ */
>

Looks OK. Side note to myself - catch up on the rcu waiter business.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_p
From: Lee Jones @ 2016-11-09 14:52 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Thierry Reding, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
	linux-pwm, linux-kernel, Fabio Estevam, Fabio Estevam,
	linux-fbdev, Liu Ying
In-Reply-To: <20161108232525.639ea49f@jawa>

On Tue, 08 Nov 2016, Lukasz Majewski wrote:

> Dear All,
> 
> > The commit a55944ca82d2 ("backlight: update bd state & fb_blank
> > properties when necessary") has posed some extra restrictions on
> > blanking and unblanking frame buffer device.
> > 
> > Unfortunately, pwm_bl driver's probe did not initialize members of
> > struct backlight_device necessary for further blank/unblank operation.
> > 
> > This code in case of initial unblank of backlight device (default 
> > behaviour) sets use_count to 1 and marks this particular backlight
> > device as used by all available fb devices (since it is not known
> > during probe how much and which fb devices will be assigned).
> > 
> > Without this code, the backlight works properly until one tries to
> > blank it manually from sysfs with "echo 1
> > > /sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
> > > were both set to 0, the logic at
> > fb_notifier_callback (@backlight.c) thought that we didn't turn on
> > (unblanked) the backlight device and refuses to disable (blank) it.
> > As a result we see garbage from fb displayed.
> 
> COmments/acks are more than welcome :-)

I thought Jingoo already replied to you?

> > Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
> > ---
> > The patch has been tested on i.MX6q with 4.9-rc3
> > SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
> > ---
> > Changes for v2:
> > - Update commit message with proper other commit reference
> > 
> > ---
> >  drivers/video/backlight/pwm_bl.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev) struct pwm_bl_data *pb;
> >  	int initial_blank = FB_BLANK_UNBLANK;
> >  	struct pwm_args pargs;
> > -	int ret;
> > +	int ret, i;
> >  
> >  	if (!data) {
> >  		ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
> > @@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
> > platform_device *pdev) 
> >  	bl->props.brightness = data->dft_brightness;
> >  	bl->props.power = initial_blank;
> > +
> > +	if (initial_blank = FB_BLANK_UNBLANK) {
> > +		for (i = 0; i < FB_MAX; i++)
> > +			bl->fb_bl_on[i] = true;
> > +
> > +		bl->use_count = 1;
> > +	}
> > +
> >  	backlight_update_status(bl);
> >  
> >  	platform_set_drvdata(pdev, bl);
> 



-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [SECILC] does not seem to filter redundant attributes and rules
From: James Carter @ 2016-11-09 14:52 UTC (permalink / raw)
  To: Dominick Grift, selinux
In-Reply-To: <a1c00b1d-c5fd-981e-489a-591f3bff3407@gmail.com>

On 11/09/2016 07:40 AM, Dominick Grift wrote:
> I am in the process of a DSSP rewrite, taking a different approach this
> time.
>
> However I encountered something that seems suboptimal:
>
> SECILC seems to not filter redundant attributes and rules
>
> Example i have a type attribute and it has rules associated with it.
> However, the type attribute is not associated with any types.
>
> I was hoping that SECILC would be smart enough to determine that it
> might as well filter both the type attribute as well as the rules
> associated with it.
>
> To reproduce:
>
> git clone https://github.com/DefenSec/dssp1-base.git
> cd dssp1-base
> secilc `ls *.cil`
> sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30
> seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30
>
>
> Am i expecting the impossible by expecting SECILC to be smart enough to
> determine that something is redundant, and that it can be filtered out
> until it becomes applicable?
>
>

I don't think that it would be too hard to remove attributes that have no types 
associated with them along with rules containing those attributes. I have this 
nagging feeling, though, that there is a reason that we didn't do that. I'll 
have to think about it a bit.

Jim


>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

^ permalink raw reply

* Re: [PATCH 1/2] iio: bmi160: Support hardware fifo
From: Marcin Niestroj @ 2016-11-09 14:52 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
	Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b7dd5694-b757-c0d1-3400-46e92b8deb58-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Hi,
Thanks for review. I agree with all of the comments and will fix these 
in next patch version. Below is just a comment on hwfifo_* sysfs access.

On 06.11.2016 13:35, Jonathan Cameron wrote:
> On 03/11/16 11:25, Marcin Niestroj wrote:
>> This patch was developed primarily based on bmc150_accel hardware fifo
>> implementation.
>>
>> IRQ handler was added, which for now is responsible only for handling
>> watermark interrupts. The BMI160 chip has two interrupt outputs. By
>> default INT is considered to be connected. If INT2 is used instead, the
>> interrupt-names device-tree property can be used to specify that.
>>
>> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
> I agree with Peter that there should have been a few precursor patches
> to this one doing various cleanups and reworking bits that you have
> in here.  Would have made it easier to review (always a good thing :)
>
> In general the resulting code looks good to me.  A few little
> additional comments inline from me.  Mostly about small code ordering things
> and function rename suggestions that would make the code more 'obviously'
> correct.
>
> Thanks,
>
> Jonathan
>> ---
>>  drivers/iio/imu/bmi160/bmi160.h      |   3 +-
>>  drivers/iio/imu/bmi160/bmi160_core.c | 633 +++++++++++++++++++++++++++++++++--
>>  drivers/iio/imu/bmi160/bmi160_i2c.c  |   7 +-
>>  drivers/iio/imu/bmi160/bmi160_spi.c  |   3 +-
>>  4 files changed, 618 insertions(+), 28 deletions(-)

<snip>

>> +
>> +static IIO_CONST_ATTR(hwfifo_watermark_min, "1");
>> +static IIO_CONST_ATTR(hwfifo_watermark_max,
>> +		      __stringify(BMI160_FIFO_LENGTH));
>> +static IIO_DEVICE_ATTR(hwfifo_enabled, S_IRUGO,
>> +		       bmi160_get_fifo_state, NULL, 0);
>> +static IIO_DEVICE_ATTR(hwfifo_watermark, S_IRUGO,
>> +		       bmi160_get_fifo_watermark, NULL, 0);
>> +
>> +static const struct attribute *bmi160_fifo_attributes[] = {
>> +	&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
>> +	&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
>> +	&iio_dev_attr_hwfifo_watermark.dev_attr.attr,
>> +	&iio_dev_attr_hwfifo_enabled.dev_attr.attr,
> There are enough of these drivers now that sometimes soon we should
> revisit the question of pulling these into the core.  Can certainly
> concieve of downstream consumer devices (in particular the iio_input
> bridge when that finally resurfaces - my fault) wanting to be able to
> manipulate or at least have visibilty of these.

One more thing to consider is setting hwfifo_watermark to other value 
than "userspace" watermark. It would be nice to set hwfifo_watermark to 
a *safe* value to be able to get all data from hardware to kfifo. By 
safe I mean that the chance of hardware fifo overflow will be small. On 
the other hand there might be no reason to have such small watermark for 
userspace application, so we can save scheduler cycles.


<snip>

-- 
Marcin Niestroj

^ permalink raw reply

* Re: [PATCH 1/2] iio: bmi160: Support hardware fifo
From: Marcin Niestroj @ 2016-11-09 14:52 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	Daniel Baluta, Gregor Boirie, Sanchayan Maity, Rob Herring,
	Mark Rutland, linux-iio, devicetree
In-Reply-To: <b7dd5694-b757-c0d1-3400-46e92b8deb58@kernel.org>

Hi,
Thanks for review. I agree with all of the comments and will fix these 
in next patch version. Below is just a comment on hwfifo_* sysfs access.

On 06.11.2016 13:35, Jonathan Cameron wrote:
> On 03/11/16 11:25, Marcin Niestroj wrote:
>> This patch was developed primarily based on bmc150_accel hardware fifo
>> implementation.
>>
>> IRQ handler was added, which for now is responsible only for handling
>> watermark interrupts. The BMI160 chip has two interrupt outputs. By
>> default INT is considered to be connected. If INT2 is used instead, the
>> interrupt-names device-tree property can be used to specify that.
>>
>> Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
> I agree with Peter that there should have been a few precursor patches
> to this one doing various cleanups and reworking bits that you have
> in here.  Would have made it easier to review (always a good thing :)
>
> In general the resulting code looks good to me.  A few little
> additional comments inline from me.  Mostly about small code ordering things
> and function rename suggestions that would make the code more 'obviously'
> correct.
>
> Thanks,
>
> Jonathan
>> ---
>>  drivers/iio/imu/bmi160/bmi160.h      |   3 +-
>>  drivers/iio/imu/bmi160/bmi160_core.c | 633 +++++++++++++++++++++++++++++++++--
>>  drivers/iio/imu/bmi160/bmi160_i2c.c  |   7 +-
>>  drivers/iio/imu/bmi160/bmi160_spi.c  |   3 +-
>>  4 files changed, 618 insertions(+), 28 deletions(-)

<snip>

>> +
>> +static IIO_CONST_ATTR(hwfifo_watermark_min, "1");
>> +static IIO_CONST_ATTR(hwfifo_watermark_max,
>> +		      __stringify(BMI160_FIFO_LENGTH));
>> +static IIO_DEVICE_ATTR(hwfifo_enabled, S_IRUGO,
>> +		       bmi160_get_fifo_state, NULL, 0);
>> +static IIO_DEVICE_ATTR(hwfifo_watermark, S_IRUGO,
>> +		       bmi160_get_fifo_watermark, NULL, 0);
>> +
>> +static const struct attribute *bmi160_fifo_attributes[] = {
>> +	&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
>> +	&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
>> +	&iio_dev_attr_hwfifo_watermark.dev_attr.attr,
>> +	&iio_dev_attr_hwfifo_enabled.dev_attr.attr,
> There are enough of these drivers now that sometimes soon we should
> revisit the question of pulling these into the core.  Can certainly
> concieve of downstream consumer devices (in particular the iio_input
> bridge when that finally resurfaces - my fault) wanting to be able to
> manipulate or at least have visibilty of these.

One more thing to consider is setting hwfifo_watermark to other value 
than "userspace" watermark. It would be nice to set hwfifo_watermark to 
a *safe* value to be able to get all data from hardware to kfifo. By 
safe I mean that the chance of hardware fifo overflow will be small. On 
the other hand there might be no reason to have such small watermark for 
userspace application, so we can save scheduler cycles.


<snip>

-- 
Marcin Niestroj

^ permalink raw reply

* Re: [PATCH v2] ASoC: add rt5665 codec driver
From: Mark Brown @ 2016-11-09 14:51 UTC (permalink / raw)
  To: Bard Liao
  Cc: oder_chiou, jack.yu, alsa-devel, lars, lgirdwood, shumingf, flove
In-Reply-To: <1478587987-23999-1-git-send-email-bardliao@realtek.com>


[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

On Tue, Nov 08, 2016 at 02:53:07PM +0800, Bard Liao wrote:

> +- realtek,regulator_1v8
> +- realtek,regulator_3v3
> +- realtek,regulator_5v
> +  The name of regulators

No, this is not how regulator bindings work.  The driver should just
request the supplies with the names they have in the datasheet.  Please
look at other users of regulators for examples.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: [PATCH] virtio: tx with can_push when VERSION_1 is set
From: Maxime Coquelin @ 2016-11-09 14:51 UTC (permalink / raw)
  To: Pierre Pfister (ppfister), Yuanhan Liu; +Cc: dev@dpdk.org
In-Reply-To: <1FAE01C3-B03F-443A-A77C-579254A07E0E@cisco.com>

Hi Pierre,

On 11/09/2016 01:42 PM, Pierre Pfister (ppfister) wrote:
> Hello Maxime,
>
> Sorry for the late reply.
>
>
>> Le 8 nov. 2016 à 10:44, Maxime Coquelin <maxime.coquelin@redhat.com> a écrit :
>>
>> Hi Pierre,
>>
>> On 11/08/2016 10:31 AM, Pierre Pfister (ppfister) wrote:
>>> Current virtio driver advertises VERSION_1 support,
>>> but does not handle device's VERSION_1 support when
>>> sending packets (it looks for ANY_LAYOUT feature,
>>> which is absent).
>>>
>>> This patch enables 'can_push' in tx path when VERSION_1
>>> is advertised by the device.
>>>
>>> This significantly improves small packets forwarding rate
>>> towards devices advertising VERSION_1 feature.
>> I think it depends whether offloading is enabled or not.
>> If no offloading enabled, I measured significant drop.
>> Indeed, when no offloading is enabled, the Tx path in Virtio
>> does not access the virtio header before your patch, as the header is memset to zero at device init time.
>> With your patch, it gets memset to zero at every transmit in the hot
>> path.
>
> Right. On the virtio side that is true, but on the device side, we have to access the header anyway.
No more now, if no offload features have been negotiated.
I have done a patch that landed in v16.11 to skip header parsing in
this case.
That said, we still have to access its descriptor.

> And accessing two descriptors (with the address resolution and memory fetch which comes with it)
> is a costy operation compared to a single one.
> In the case indirect descriptors are used, this is 1 desc access instead or 3.
I agree this is far from being optimal.

> And in the case chained descriptors are used, this doubles the number of packets that you can put in your queue.
>
> Those are the results in my PHY -> VM (testpmd) -> PHY setup
> Traffic is flowing bidirectionally. Numbers are for lossless-rates.
>
> When chained buffers are used for dpdk's TX: 2x2.13Mpps
> When indirect descriptors are used for dpdk's TX: 2x2.38Mpps
> When shallow buffers are used for dpdk's TX (with this patch): 2x2.42Mpps
When I tried it, I also did PVP 0% benchmark, and I got opposite 
results. Chained and indirect cases were significantly better.

My PVP setup was using a single NIC and single Virtio PMD, and NIC2VM
forwarding was IO mode done with testpmd on host, and Rx->Tx forwarding
was macswap mode on guest side.

I also saw some perf regression when running simple tespmd test on both
ends.

Yuanhan, did you run some benchmark with your series enabling
ANY_LAYOUT?

>
> I must also note that qemu 2.5 does not seem to deal with VERSION_1 and ANY_LAYOUT correctly.
> The patch I am proposing here works for qemu 2.7, but with qemu 2.5, testpmd still behaves as if ANY_LAYOUT (or VERSION_1) was not available. This is not catastrophic. But just note that you will not see performance in some cases with qemu 2.5.

Thanks for the info.

Regards,
Maxime

^ permalink raw reply

* [Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
From: bugzilla-daemon @ 2016-11-09 14:51 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <bug-98638-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 387 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98638

--- Comment #5 from Alex Deucher <alexdeucher@gmail.com> ---
Shutdown and remove use same code in the driver.  Can you reproduce the issue
by unloading the amdgpu module?  E.g., as root:

echo 0 > /sys/class/vtconsole/vtcon1/bind
modprobe -r amdgpu

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Aw: hppa qemu and string functions
From: Helge Deller @ 2016-11-09 14:51 UTC (permalink / raw)
  To: Richard Henderson; +Cc: linux-parisc, GNU C Library
In-Reply-To: <21645bc2-f005-5e60-d26a-41af60e3c035@twiddle.net>

Hi Richard,

> Off and on, I've been working on a user-only target of hppa to qemu.  It's now 
> about 95% working.  If anyone would like to try it out, it's available at
>    git://github.com/rth7680/qemu.git tgt-hppa

COOL!
I'm happy to test, but can you shortly describe the required steps how I can build & test it?

With "user-only target of hppa" I assume this means that I can run hppa binaries
on e.g. x86-64, similiar to what is described here: https://wiki.debian.org/QemuUserEmulation ?

> While implementing the unit-type instructions, I wondered why no one (outside 
> hp?) had written a version of the string routines utilizing the UXOR insn, with 
> the SomeByteZero and NoByteZero conditions.

Interesting.
I assume nobody did, because there are a few hppa/linux/glibc users anyway ? :-)
 
> Attached are versions of strlen, strchr and strrchr.  They pass simple tests 
> within my emulator; I'd be interested to know if they pass full glibc testing 
> on real hardware.

If you like I can give you access to a hppa-linux box...

Helge

^ permalink raw reply

* Re: [PATCH] hwmon: (scpi) Fix module autoload
From: Guenter Roeck @ 2016-11-09 14:51 UTC (permalink / raw)
  To: Javier Martinez Canillas, linux-kernel; +Cc: linux-hwmon, Jean Delvare
In-Reply-To: <1478550704-20825-1-git-send-email-javier@osg.samsung.com>

On 11/07/2016 12:31 PM, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias
> alias:          of:N*T*Carm,scpi-sensorsC*
> alias:          of:N*T*Carm,scpi-sensors
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Applied.

Thanks,
Guenter

> ---
>
>  drivers/hwmon/scpi-hwmon.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
> index 559a3dcd64d8..094f948f99ff 100644
> --- a/drivers/hwmon/scpi-hwmon.c
> +++ b/drivers/hwmon/scpi-hwmon.c
> @@ -251,6 +251,7 @@ static const struct of_device_id scpi_of_match[] = {
>  	{.compatible = "arm,scpi-sensors"},
>  	{},
>  };
> +MODULE_DEVICE_TABLE(of, scpi_of_match);
>
>  static struct platform_driver scpi_hwmon_platdrv = {
>  	.driver = {
>


^ permalink raw reply

* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-09 14:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161109135453.2e5402bd@lxorguk.ukuu.org.uk>

> -----Original Message-----
> From: One Thousand Gnomes [mailto:gnomes at lxorguk.ukuu.org.uk]
> Sent: 09 November 2016 13:55
> To: Arnd Bergmann
> Cc: Mark Rutland; Yuanzhichang; catalin.marinas at arm.com;
> will.deacon at arm.com; robh+dt at kernel.org; bhelgaas at google.com;
> olof at lixom.net; linux-arm-kernel at lists.infradead.org;
> lorenzo.pieralisi at arm.com; linux-kernel at vger.kernel.org; Linuxarm;
> devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-
> serial at vger.kernel.org; minyard at acm.org; benh at kernel.crashing.org;
> liviu.dudau at arm.com; zourongrong at gmail.com; John Garry; Gabriele
> Paoloni; zhichang.yuan02 at gmail.com; kantyzc at 163.com; xuwei (O);
> marc.zyngier at arm.com
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
> 
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
> 
> It's not a safe assumption for x86 at least. There are a few systems
> with
> multiple ISA busses particularly older laptops with a docking station.

Mmmm right...now the point is that this kind of special devices appearing
as a special ISA bus will probably never appear on x86 platforms (I guess).

So maybe it is a safe assumption because of this...?

Thanks

Gab

> 
> > when talking to an ISA device, so having multiple instances is
> > already problematic.
> 
> PCMCIA devices handle it themselves so are ok. I'm not clear how the
> dual
> PIIX4 configuration used in the older IBM laptop docks actually worked
> so
> I assume the transaction went out of both bridges and providing one of
> them responded the other kept silent as you simply stuffed the card
> into
> the dock and it worked.
> 
> Alan

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.