* [U-Boot] [PATCH 00/10] sunxi: Add basic PSCI support to enable SMP on the A80's first cluster
From: Hans de Goede @ 2016-11-09 10:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161109102136.13479-1-wens@csie.org>
Hi,
On 09-11-16 11:21, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This series adds basic PSCI support for the A80 to enable SMP on the
> first cluster. This at least allows people to use more than one core.
> The term "basic" is used because the series does not add support for
> multi-cluster cache and power management.
>
> The PSCI code is based on existing code for all the single cluster
> SoCs, and the kernel patches for MCPM SMP I did some time ago.
>
> Unfortunately only SMP works at this time. The last patch does not
> actually work. While the system is indeed booted non-secure, tested
> by trying to write to secure SRAM and the results not sticking, reads
> from the GIC CPU interface shows that it's still returning the secure
> copy of registers, and since we use a secure monitor FIQ to do core
> power down, the FIQ gets passed to the kernel. The patch is included
> so people with in-depth ARM knowledge could probably help work out
> what is wrong.
Cools stuff, when I find some time I will review and merge
patches 1-9 to sunxi-next.
First a question though, do you see any chance that merging this might
get in the way of enabling support for both clusters in the future?
Since the interface between u-boot and the kernel here is well defined
(and outside our control) I guess in the worst case, we would need to
revert some bits of this series from u-boot if they turn out to be non
suitable, right?
Regards,
Hans
>
>
> Regards
> ChenYu
>
> Chen-Yu Tsai (10):
> ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
> sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
> sunxi: Add base address of secure SRAM B for sun9i/A80
> sunxi: Use secure SRAM B for secure RAM for sun9i/A80
> sunxi: Add PRCM register definition for sun9i/A80
> sunxi: Add CPUCFG register definitions for sun9i/A80
> sunxi: Add support for TZPC on sun9i/A80
> sunxi: Add basic PSCI implementation for A80
> sunxi: Enable PSCI on sun9i/A80
> sunxi: Add PSCI core power off support for A80's first cluster
>
> arch/arm/cpu/armv7/Kconfig | 1 +
> arch/arm/cpu/armv7/sunxi/Makefile | 5 +
> arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 322 +++++++++++++++++++++++++
> arch/arm/cpu/armv7/sunxi/tzpc.c | 6 +
> arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 5 +
> arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 51 ++++
> arch/arm/include/asm/arch-sunxi/prcm_sun9i.h | 55 +++++
> arch/arm/include/asm/arch-sunxi/tzpc.h | 4 +
> arch/arm/mach-sunxi/board.c | 3 +-
> board/sunxi/Kconfig | 4 +
> include/configs/sun9i.h | 4 +
> 11 files changed, 459 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
> create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
> create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
>
^ permalink raw reply
* Re: [PATCH v3 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Vivek Gautam @ 2016-11-09 10:37 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, Bjorn Helgaas, linux-pci, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm
In-Reply-To: <1478264387-17914-3-git-send-email-srinivas.kandagatla@linaro.org>
Hi,
On Fri, Nov 4, 2016 at 6:29 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
> pipe clocks are only setup after the phy is powered on.
> It also adds ltssm_enable callback as it is very much different to other
> supported SOCs in the driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
Few minor nits.
> .../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
> drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
> 2 files changed, 239 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> index 4059a6f..4a0538d 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -7,6 +7,7 @@
> - "qcom,pcie-ipq8064" for ipq8064
> - "qcom,pcie-apq8064" for apq8064
> - "qcom,pcie-apq8084" for apq8084
> + - "qcom,pcie-msm8996" for msm8996 or apq8096
Since this works for both apq8096 and msm8996, compatible -
"qcom,pcie-apq8096" for uniformity ?
[snip]
> @@ -231,3 +242,58 @@
> pinctrl-0 = <&pcie0_pins_default>;
> pinctrl-names = "default";
> };
> +
> +* Example for apq8096:
> +
> + pcie@00608000{
> + compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
this will change accordingly.
> + power-domains = <&gcc PCIE1_GDSC>;
> + bus-range = <0x00 0xff>;
> + num-lanes = <1>;
> +
[snip]
> +
> +static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> + struct device *dev = pcie->pp.dev;
> + u32 val;
> + int ret = 0;
you don't need to initialize ret here.
> +
> + ret = clk_prepare_enable(res->aux_clk);
> + if (ret) {
> + dev_err(dev, "cannot prepare/enable aux clock\n");
> + return ret;
> + }
[snip]
> @@ -429,6 +571,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
> return !!(val & PCI_EXP_LNKSTA_DLLLA);
> }
>
> +static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
> +
> + clk_disable_unprepare(res->slave_clk);
> + clk_disable_unprepare(res->master_clk);
> + clk_disable_unprepare(res->cfg_clk);
> + clk_disable_unprepare(res->aux_clk);
> + clk_disable_unprepare(res->pipe_clk);
i am sure, this is not affecting the functionality, but the pipe clock
is enabled after all the clocks.
so it makes sense to disable it in the first place. you can just move
this above slave_clk.
[snip]
> @@ -572,6 +738,7 @@ static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-ipq8064", .data = &ops_v0 },
> { .compatible = "qcom,pcie-apq8064", .data = &ops_v0 },
> { .compatible = "qcom,pcie-apq8084", .data = &ops_v1 },
> + { .compatible = "qcom,pcie-msm8996", .data = &ops_v2 },
this will change according to earlier comment in bindings.
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/5] drm/i915: Assorted dev_priv cleanups
From: David Weinehall @ 2016-11-09 10:37 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Intel-gfx
In-Reply-To: <1478270568-7902-2-git-send-email-tvrtko.ursulin@linux.intel.com>
On Fri, Nov 04, 2016 at 02:42:44PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> A small selection of macros which can only accept dev_priv from
> now on and a resulting trickle of fixups.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 31 ++++++++++++++++--------------
> drivers/gpu/drm/i915/i915_gem.c | 13 +++++++------
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 3 ++-
> drivers/gpu/drm/i915/i915_gem_userptr.c | 3 ++-
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> 7 files changed, 34 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4735b4177100..45a30f730216 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2851,28 +2851,31 @@ struct drm_i915_cmd_table {
> #define ALL_ENGINES (~0)
>
> #define HAS_ENGINE(dev_priv, id) \
> - (!!(INTEL_INFO(dev_priv)->ring_mask & ENGINE_MASK(id)))
> + (!!((dev_priv)->info.ring_mask & ENGINE_MASK(id)))
>
> #define HAS_BSD(dev_priv) HAS_ENGINE(dev_priv, VCS)
> #define HAS_BSD2(dev_priv) HAS_ENGINE(dev_priv, VCS2)
> #define HAS_BLT(dev_priv) HAS_ENGINE(dev_priv, BCS)
> #define HAS_VEBOX(dev_priv) HAS_ENGINE(dev_priv, VECS)
>
> -#define HAS_LLC(dev) (INTEL_INFO(dev)->has_llc)
> -#define HAS_SNOOP(dev) (INTEL_INFO(dev)->has_snoop)
> -#define HAS_EDRAM(dev) (!!(__I915__(dev)->edram_cap & EDRAM_ENABLED))
> +#define HAS_LLC(dev_priv) ((dev_priv)->info.has_llc)
> +#define HAS_SNOOP(dev_priv) ((dev_priv)->info.has_snoop)
> +#define HAS_EDRAM(dev_priv) (!!((dev_priv)->edram_cap & EDRAM_ENABLED))
> #define HAS_WT(dev_priv) ((IS_HASWELL(dev_priv) || \
> IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
> -#define HWS_NEEDS_PHYSICAL(dev) (INTEL_INFO(dev)->hws_needs_physical)
>
> -#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->has_hw_contexts)
> -#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->has_logical_ring_contexts)
> -#define USES_PPGTT(dev) (i915.enable_ppgtt)
> -#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
> -#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
> +#define HWS_NEEDS_PHYSICAL(dev_priv) ((dev_priv)->info.hws_needs_physical)
>
> -#define HAS_OVERLAY(dev) (INTEL_INFO(dev)->has_overlay)
> -#define OVERLAY_NEEDS_PHYSICAL(dev) (INTEL_INFO(dev)->overlay_needs_physical)
> +#define HAS_HW_CONTEXTS(dev_priv) ((dev_priv)->info.has_hw_contexts)
> +#define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
> + ((dev_priv)->info.has_logical_ring_contexts)
> +#define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
> +#define USES_FULL_PPGTT(dev_priv) (i915.enable_ppgtt >= 2)
> +#define USES_FULL_48BIT_PPGTT(dev_priv) (i915.enable_ppgtt == 3)
> +
> +#define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay)
> +#define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
> + ((dev_priv)->info.overlay_needs_physical)
>
> /* Early gen2 have a totally busted CS tlb and require pinned batches. */
> #define HAS_BROKEN_CS_TLB(dev_priv) (IS_I830(dev_priv) || IS_845G(dev_priv))
> @@ -2889,8 +2892,8 @@ struct drm_i915_cmd_table {
> * legacy irq no. is shared with another device. The kernel then disables that
> * interrupt source and so prevents the other device from working properly.
> */
> -#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->has_gmbus_irq)
> +#define HAS_AUX_IRQ(dev_priv) ((dev_priv)->info.gen >= 5)
> +#define HAS_GMBUS_IRQ(dev_priv) ((dev_priv)->info.has_gmbus_irq)
>
> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> * rows, which changed the alignment requirements and fence programming.
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1f995ced524e..e9808c8ef55b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -48,7 +48,7 @@ static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *o
> static bool cpu_cache_is_coherent(struct drm_device *dev,
> enum i915_cache_level level)
> {
> - return HAS_LLC(dev) || level != I915_CACHE_NONE;
> + return HAS_LLC(to_i915(dev)) || level != I915_CACHE_NONE;
> }
>
> static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
> @@ -1757,7 +1757,7 @@ int i915_gem_fault(struct vm_area_struct *area, struct vm_fault *vmf)
> goto err_rpm;
>
> /* Access to snoopable pages through the GTT is incoherent. */
> - if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev)) {
> + if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev_priv)) {
> ret = -EFAULT;
> goto err_unlock;
> }
> @@ -3414,7 +3414,8 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> - if (!HAS_LLC(obj->base.dev) && cache_level != I915_CACHE_NONE) {
> + if (!HAS_LLC(to_i915(obj->base.dev)) &&
> + cache_level != I915_CACHE_NONE) {
> /* Access to snoopable pages through the GTT is
> * incoherent and on some machines causes a hard
> * lockup. Relinquish the CPU mmaping to force
> @@ -4199,7 +4200,7 @@ i915_gem_object_create(struct drm_device *dev, u64 size)
> obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> obj->base.read_domains = I915_GEM_DOMAIN_CPU;
>
> - if (HAS_LLC(dev)) {
> + if (HAS_LLC(dev_priv)) {
> /* On some devices, we can have the GPU use the LLC (the CPU
> * cache) for about a 10% performance improvement
> * compared to uncached. Graphics requests other than
> @@ -4444,7 +4445,7 @@ int i915_gem_suspend(struct drm_device *dev)
> * machines is a good idea, we don't - just in case it leaves the
> * machine in an unusable condition.
> */
> - if (HAS_HW_CONTEXTS(dev)) {
> + if (HAS_HW_CONTEXTS(dev_priv)) {
> int reset = intel_gpu_reset(dev_priv, ALL_ENGINES);
> WARN_ON(reset && reset != -ENODEV);
> }
> @@ -4535,7 +4536,7 @@ i915_gem_init_hw(struct drm_device *dev)
> /* Double layer security blanket, see i915_gem_init() */
> intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>
> - if (HAS_EDRAM(dev) && INTEL_GEN(dev_priv) < 9)
> + if (HAS_EDRAM(dev_priv) && INTEL_GEN(dev_priv) < 9)
> I915_WRITE(HSW_IDICR, I915_READ(HSW_IDICR) | IDIHASHMSK(0xf));
>
> if (IS_HASWELL(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 322c580a739f..9c7d9c88d879 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -287,7 +287,7 @@ static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
> if (DBG_USE_CPU_RELOC)
> return DBG_USE_CPU_RELOC > 0;
>
> - return (HAS_LLC(obj->base.dev) ||
> + return (HAS_LLC(to_i915(obj->base.dev)) ||
> obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> obj->cache_level != I915_CACHE_NONE);
> }
> @@ -833,7 +833,7 @@ need_reloc_mappable(struct i915_vma *vma)
> return false;
>
> /* See also use_cpu_reloc() */
> - if (HAS_LLC(vma->obj->base.dev))
> + if (HAS_LLC(to_i915(vma->obj->base.dev)))
> return false;
>
> if (vma->obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index b1d367dba347..54085df1f227 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -596,7 +596,8 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
>
> obj->stolen = stolen;
> obj->base.read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
> - obj->cache_level = HAS_LLC(dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
> + obj->cache_level = HAS_LLC(to_i915(dev)) ?
> + I915_CACHE_LLC : I915_CACHE_NONE;
>
> if (i915_gem_object_pin_pages(obj))
> goto cleanup;
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 64261639f547..107ddf51065e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -753,12 +753,13 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
> int
> i915_gem_userptr_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
> {
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_i915_gem_userptr *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
> u32 handle;
>
> - if (!HAS_LLC(dev) && !HAS_SNOOP(dev)) {
> + if (!HAS_LLC(dev_priv) && !HAS_SNOOP(dev_priv)) {
> /* We cannot support coherent userptr objects on hw without
> * LLC and broken snooping.
> */
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 204093f3eaa5..d430b9441e6b 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1489,7 +1489,7 @@ static void i915_capture_reg_state(struct drm_i915_private *dev_priv,
> }
>
> /* 4: Everything else */
> - if (HAS_HW_CONTEXTS(dev))
> + if (HAS_HW_CONTEXTS(dev_priv))
> error->ccid = I915_READ(CCID);
>
> if (INTEL_INFO(dev)->gen >= 8) {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9df331b3305b..d4e9cf3ad26e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -942,14 +942,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> uint8_t *recv, int recv_size)
> {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = intel_dig_port->base.base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
> uint32_t aux_clock_divider;
> int i, ret, recv_bytes;
> uint32_t status;
> int try, clock = 0;
> - bool has_aux_irq = HAS_AUX_IRQ(dev);
> + bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
> bool vdd;
>
> pps_lock(intel_dp);
> --
> 2.7.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* next-20161109 build: 0 failures 2 warnings (next-20161109)
From: Build bot for Mark Brown @ 2016-11-09 10:36 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20161109
Git describe: next-20161109
Commit: 6b9ac964c2 Add linux-next specific files for 20161109
Build Time: 159 min 43 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : x86_64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
1 ../mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
1 ../drivers/tty/serial/pxa.c:944:1: warning: 'serial_pxa_init' is deprecated [-Wdeprecated-declarations]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/tty/serial/pxa.c:944:1: warning: 'serial_pxa_init' is deprecated [-Wdeprecated-declarations]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
* [Buildroot] [PATCH] package/e2fsprogs: backport build fix for rhel5 due to missing magic
From: Thomas Petazzoni @ 2016-11-09 10:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109082435.33pxg5mzjq5nebv3@tarshish>
Hello,
On Wed, 9 Nov 2016 10:24:35 +0200, Baruch Siach wrote:
> On Wed, Nov 09, 2016 at 12:18:07AM -0800, Max Filippov wrote:
> > On Wed, Nov 9, 2016 at 12:03 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Tue, Nov 08, 2016 at 11:39:02PM -0800, Max Filippov wrote:
> > >> RHEL 5.x does have magic.h, but it does not define all expected symbols. In
> > >> particular, the NO_CHECK symbols were only added in file 4.20 and RHEL 5.x
> > >> is using 4.17.
> > >
> > > Instead of relying on host libmagic that may or may not be installed, why not
> > > add host-file to HOST_E2FSPROGS_DEPENDENCIES?
> >
> > My first reaction was to look if the issue is addressed in the package mainline,
> > and that's how e2fsprogs mainline decided to deal with that. So the next
> > version bump of e2fsprogs will make host-libmagic not necessary, there's
> > probably no reason to introduce that dependency?
> >
> > "libmagic installed" vs. "not installed" is handled well by e2fsprogs, it's
> > "installed, but too old" case that fails.
>
> We would generally like to avoid dependency on host libraries as much as
> possible since it reduces the build reproducibility. But as this is just a
> host tool I'm not sure we care.
We do care.
So in this case, it would be better (if possible) to completely disable
the use of libmagic by host-e2fsprogs. This way, the behavior is
consistent on both machines that have libmagic installed and those who
don't.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Working From Home
From: Nitori Furniture @ 2016-11-09 5:07 UTC (permalink / raw)
To: Recipients
Hi Dear,
Did you receive our previous email regarding our company offer? Are you interested in working with us at the comfort of your home or office to earn $2,900+/month at your convenience? Do email us back if you are interested in this opportunity for more Information.
Note: The job will only take few minutes of your time daily.Your area of specialization is of no reference
" Nitori Furniture co. ltd "
^ permalink raw reply
* [U-Boot] [linux-sunxi] [PATCH 2/3] net: phy: realtek: make define more concistent
From: Olliver Schinagl @ 2016-11-09 10:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <2a8a5822-8cd4-15df-2981-4c25c8ef003a@elopez.com.ar>
Crap! I thought I spotted it but wasn't sure :)
If there needs to be a v2 i'll fix it; if the v1 is accepted, Joe could
hopefully fix that in the message *wink* :)
Olliver
On 09-11-16 00:17, Emilio L?pez wrote:
> Small nitpick:
>
> El 08/11/16 a las 13:38, Olliver Schinagl escribi?:
>> All internal defines in the realtek phy are with a small X,
>> except MIIM_RTL8211X_CTRL1000T_MASTER. Make this more concistent
> s/concistent/consistent/ both here and on the subject :)
>
> Cheers!
> Emilio
^ permalink raw reply
* Re: [PATCH v2 2/3] 99base: apply kernel module memory debug support
From: Xunlei Pang @ 2016-11-09 10:34 UTC (permalink / raw)
To: Dave Young, Xunlei Pang
Cc: Harald Hoyer, initramfs-u79uwXL29TY76Z2rM5mHXA, Pratush Panand
In-Reply-To: <20161109083351.GA5663-0VdLhd/A9Pl+NNSt+8eSiB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
On 2016/11/09 at 16:33, Dave Young wrote:
> Hi, Xunlei
> On 11/07/16 at 01:34pm, Xunlei Pang wrote:
>> Extend "rd.memdebug" to "4", and "make_trace_mem" to "4+:komem".
>> Add new "cleanup_trace_mem" to cleanup the trace if active.
>>
>> Signed-off-by: Xunlei Pang <xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> modules.d/98dracut-systemd/dracut-cmdline.sh | 2 +-
>> modules.d/98dracut-systemd/dracut-pre-mount.sh | 2 +-
>> modules.d/98dracut-systemd/dracut-pre-pivot.sh | 3 ++-
>> modules.d/98dracut-systemd/dracut-pre-trigger.sh | 2 +-
>> modules.d/99base/dracut-lib.sh | 13 ++++++++++++-
>> modules.d/99base/init.sh | 9 +++++----
>> modules.d/99base/module-setup.sh | 1 +
>> 7 files changed, 23 insertions(+), 9 deletions(-)
>>
>> diff --git a/modules.d/98dracut-systemd/dracut-cmdline.sh b/modules.d/98dracut-systemd/dracut-cmdline.sh
>> index 6c6ee02..bff9435 100755
>> --- a/modules.d/98dracut-systemd/dracut-cmdline.sh
>> +++ b/modules.d/98dracut-systemd/dracut-cmdline.sh
>> @@ -42,7 +42,7 @@ export root
>> export rflags
>> export fstype
>>
>> -make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab'
>> +make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab' '4+:komem'
>> # run scriptlets to parse the command line
>> getarg 'rd.break=cmdline' -d 'rdbreak=cmdline' && emergency_shell -n cmdline "Break before cmdline"
>> source_hook cmdline
>> diff --git a/modules.d/98dracut-systemd/dracut-pre-mount.sh b/modules.d/98dracut-systemd/dracut-pre-mount.sh
>> index ae51128..a3b9d29 100755
>> --- a/modules.d/98dracut-systemd/dracut-pre-mount.sh
>> +++ b/modules.d/98dracut-systemd/dracut-pre-mount.sh
>> @@ -8,7 +8,7 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>>
>> source_conf /etc/conf.d
>>
>> -make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab'
>> +make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>> # pre pivot scripts are sourced just before we doing cleanup and switch over
>> # to the new root.
>> getarg 'rd.break=pre-mount' 'rdbreak=pre-mount' && emergency_shell -n pre-mount "Break pre-mount"
>> diff --git a/modules.d/98dracut-systemd/dracut-pre-pivot.sh b/modules.d/98dracut-systemd/dracut-pre-pivot.sh
>> index cc70e3c..dc9a250 100755
>> --- a/modules.d/98dracut-systemd/dracut-pre-pivot.sh
>> +++ b/modules.d/98dracut-systemd/dracut-pre-pivot.sh
>> @@ -8,12 +8,13 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>>
>> source_conf /etc/conf.d
>>
>> -make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab'
>> +make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>> # pre pivot scripts are sourced just before we doing cleanup and switch over
>> # to the new root.
>> getarg 'rd.break=pre-pivot' 'rdbreak=pre-pivot' && emergency_shell -n pre-pivot "Break pre-pivot"
>> source_hook pre-pivot
>>
>> +cleanup_trace_mem
>> # pre pivot cleanup scripts are sourced just before we switch over to the new root.
>> getarg 'rd.break=cleanup' 'rdbreak=cleanup' && emergency_shell -n cleanup "Break cleanup"
>> source_hook cleanup
>> diff --git a/modules.d/98dracut-systemd/dracut-pre-trigger.sh b/modules.d/98dracut-systemd/dracut-pre-trigger.sh
>> index ac1ec36..7cd821e 100755
>> --- a/modules.d/98dracut-systemd/dracut-pre-trigger.sh
>> +++ b/modules.d/98dracut-systemd/dracut-pre-trigger.sh
>> @@ -8,7 +8,7 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>>
>> source_conf /etc/conf.d
>>
>> -make_trace_mem "hook pre-trigger" "1:shortmem" "2+:mem" "3+:slab"
>> +make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>>
>> source_hook pre-trigger
>>
>> diff --git a/modules.d/99base/dracut-lib.sh b/modules.d/99base/dracut-lib.sh
>> index 060b3fe..2a29bbc 100755
>> --- a/modules.d/99base/dracut-lib.sh
>> +++ b/modules.d/99base/dracut-lib.sh
>> @@ -1206,12 +1206,20 @@ are_lists_eq() {
>>
>> setmemdebug() {
>> if [ -z "$DEBUG_MEM_LEVEL" ]; then
>> - export DEBUG_MEM_LEVEL=$(getargnum 0 0 3 rd.memdebug)
>> + export DEBUG_MEM_LEVEL=$(getargnum 0 0 4 rd.memdebug)
>> fi
>> }
>>
>> setmemdebug
>>
>> +cleanup_trace_mem()
>> +{
>> + # tracekomem based on kernel trace needs cleanup after use.
>> + if [[ $DEBUG_MEM_LEVEL -eq 4 ]]; then
> It does not work if out of tree modules add it to DEBUG_MEM_LEVEL <
> 4, sounds bad to hard code it. It seems good to do the cleanup without
> the check.
Hi Dave,
I can't understand why out of tree modules would do this, however we can't
guarantee that even after removing the hard code condition. Let's say, out of
tree modules use it at the very beginning and disable it quite after pre-pivot
with no "rd.memdebug", then the trace will be disabled at pre-pivot which will
cause confusion(or unnoticed data loss) for the out of tree modules.
>
> There is another concern, if someone manually enables tracing in kernel
> cmdline then we should not cleanup, maybe we can print a warning msg
> and do not do our tracing at all.
>
> For cleanup and prepare ideally we can do something like make_trace_mem,
> like prepare_trace_mem and cleanup_trace_mem, for each facility if there
> is a prepare/cleanup function then call it. But for the time being it
> may not worth to add the complexity. What do you think?
Because the script does cleanup iff is_trace_ready() returns true when
both tracing is on and the events match, I think it is safe enough that
we don't need to worry about the wrong cleanup if we really want to do this:
is_trace_ready() {
local trace_base want_events current_events
trace_base=$(get_trace_base)
! [[ -f "$trace_base/tracing/trace" ]] && return 1
[[ $(cat $trace_base/tracing/tracing_on) = 0 ]] && return 1
# Also check if trace events were properly setup.
want_events=$(get_want_events)
current_events=$(echo $(cat $trace_base/tracing/set_event))
[[ "$current_events" != "$want_events" ]] && return 1
return 0
}
Regards,
Xunlei
>
>> + tracekomem --cleanup
>> + fi
>> +}
>> +
>> # parameters: msg [trace_level:trace]...
>> make_trace_mem()
>> {
>> @@ -1296,6 +1304,9 @@ show_memstats()
>> iomem)
>> cat /proc/iomem
>> ;;
>> + komem)
>> + tracekomem
>> + ;;
>> esac
>> }
>>
>> diff --git a/modules.d/99base/init.sh b/modules.d/99base/init.sh
>> index a563393..e4f7cff 100755
>> --- a/modules.d/99base/init.sh
>> +++ b/modules.d/99base/init.sh
>> @@ -131,7 +131,7 @@ if ! getargbool 1 'rd.hostonly'; then
>> fi
>>
>> # run scriptlets to parse the command line
>> -make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab'
>> +make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab' '4+:komem'
>> getarg 'rd.break=cmdline' -d 'rdbreak=cmdline' && emergency_shell -n cmdline "Break before cmdline"
>> source_hook cmdline
>>
>> @@ -160,7 +160,7 @@ fi
>>
>> udevproperty "hookdir=$hookdir"
>>
>> -make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab'
>> +make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>> getarg 'rd.break=pre-trigger' -d 'rdbreak=pre-trigger' && emergency_shell -n pre-trigger "Break before pre-trigger"
>> source_hook pre-trigger
>>
>> @@ -230,7 +230,7 @@ unset RDRETRY
>>
>> # pre-mount happens before we try to mount the root filesystem,
>> # and happens once.
>> -make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab'
>> +make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>> getarg 'rd.break=pre-mount' -d 'rdbreak=pre-mount' && emergency_shell -n pre-mount "Break pre-mount"
>> source_hook pre-mount
>>
>> @@ -266,11 +266,12 @@ done
>>
>> # pre pivot scripts are sourced just before we doing cleanup and switch over
>> # to the new root.
>> -make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab'
>> +make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>> getarg 'rd.break=pre-pivot' -d 'rdbreak=pre-pivot' && emergency_shell -n pre-pivot "Break pre-pivot"
>> source_hook pre-pivot
>>
>> make_trace_mem "hook cleanup" '1:shortmem' '2+:mem' '3+:slab'
>> +cleanup_trace_mem
>> # pre pivot cleanup scripts are sourced just before we switch over to the new root.
>> getarg 'rd.break=cleanup' -d 'rdbreak=cleanup' && emergency_shell -n cleanup "Break cleanup"
>> source_hook cleanup
>> diff --git a/modules.d/99base/module-setup.sh b/modules.d/99base/module-setup.sh
>> index b03772e..a1569b1 100755
>> --- a/modules.d/99base/module-setup.sh
>> +++ b/modules.d/99base/module-setup.sh
>> @@ -35,6 +35,7 @@ install() {
>> inst_script "$moddir/initqueue.sh" "/sbin/initqueue"
>> inst_script "$moddir/loginit.sh" "/sbin/loginit"
>> inst_script "$moddir/rdsosreport.sh" "/sbin/rdsosreport"
>> + inst_script "$moddir/memtrace-ko.sh" "/sbin/tracekomem"
>>
>> [ -e "${initdir}/lib" ] || mkdir -m 0755 -p ${initdir}/lib
>> mkdir -m 0755 -p ${initdir}/lib/dracut
>> --
>> 1.8.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe initramfs" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Thanks
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/12] mm: page migration enhancement for thp
From: Anshuman Khandual @ 2016-11-09 10:33 UTC (permalink / raw)
To: Naoya Horiguchi, linux-mm
Cc: Kirill A. Shutemov, Hugh Dickins, Andrew Morton, Dave Hansen,
Andrea Arcangeli, Mel Gorman, Michal Hocko, Vlastimil Babka,
Pavel Emelyanov, Zi Yan, Balbir Singh, linux-kernel,
Naoya Horiguchi
In-Reply-To: <1478561517-4317-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
> Hi everyone,
>
> I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> with feedbacks for ver.1.
>
> General description (no change since ver.1)
> ===========================================
>
> This patchset enhances page migration functionality to handle thp migration
> for various page migration's callers:
> - mbind(2)
> - move_pages(2)
> - migrate_pages(2)
> - cgroup/cpuset migration
> - memory hotremove
> - soft offline
>
> The main benefit is that we can avoid unnecessary thp splits, which helps us
> avoid performance decrease when your applications handles NUMA optimization on
> their own.
>
> The implementation is similar to that of normal page migration, the key point
> is that we modify a pmd to a pmd migration entry in swap-entry like format.
Will it be better to have new THP_MIGRATE_SUCCESS and THP_MIGRATE_FAIL
VM events to capture how many times the migration worked without first
splitting the huge page and how many time it did not work ? Also do you
have a test case which demonstrates this THP migration and kind of shows
its better than the present split and move method ?
^ permalink raw reply
* Re: [PATCH v2 00/12] mm: page migration enhancement for thp
From: Anshuman Khandual @ 2016-11-09 10:33 UTC (permalink / raw)
To: Naoya Horiguchi, linux-mm
Cc: Kirill A. Shutemov, Hugh Dickins, Andrew Morton, Dave Hansen,
Andrea Arcangeli, Mel Gorman, Michal Hocko, Vlastimil Babka,
Pavel Emelyanov, Zi Yan, Balbir Singh, linux-kernel,
Naoya Horiguchi
In-Reply-To: <1478561517-4317-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
> Hi everyone,
>
> I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> with feedbacks for ver.1.
>
> General description (no change since ver.1)
> ===========================================
>
> This patchset enhances page migration functionality to handle thp migration
> for various page migration's callers:
> - mbind(2)
> - move_pages(2)
> - migrate_pages(2)
> - cgroup/cpuset migration
> - memory hotremove
> - soft offline
>
> The main benefit is that we can avoid unnecessary thp splits, which helps us
> avoid performance decrease when your applications handles NUMA optimization on
> their own.
>
> The implementation is similar to that of normal page migration, the key point
> is that we modify a pmd to a pmd migration entry in swap-entry like format.
Will it be better to have new THP_MIGRATE_SUCCESS and THP_MIGRATE_FAIL
VM events to capture how many times the migration worked without first
splitting the huge page and how many time it did not work ? Also do you
have a test case which demonstrates this THP migration and kind of shows
its better than the present split and move method ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] HID:i2c-hid: add a simple quirk to fix device defects
From: Benjamin Tissoires @ 2016-11-09 10:33 UTC (permalink / raw)
To: hn.chen; +Cc: jkosina, dmitry.torokhov, linux-input
In-Reply-To: <1478686848-22968-1-git-send-email-hn.chen@weidahitech.com>
On Nov 09 2016 or thereabouts, hn.chen@weidahitech.com wrote:
> From: HungNien Chen <hn.chen@weidahitech.com>
>
> Add a static quirk table and lookup for the quirks in i2c_hid_probe().
> Also add comments and do return value check in i2c_hid_set_power().
>
> Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
> ---
> drivers/hid/hid-ids.h | 5 ++++
> drivers/hid/i2c-hid/i2c-hid.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 6cfb5ca..787afdf 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -1033,6 +1033,11 @@
> #define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
> #define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
>
> +#define USB_VENDOR_ID_WEIDA 0x2575
> +#define USB_DEVICE_ID_WEIDA_8756 0x8756
> +#define USB_DEVICE_ID_WEIDA_8752 0xC300
> +#define USB_DEVICE_ID_WEIDA_8755 0xC301
> +
> #define USB_VENDOR_ID_WISEGROUP 0x0925
> #define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
> #define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index b3ec4f2..b32a063 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -41,6 +41,11 @@
>
> #include <linux/i2c/i2c-hid.h>
>
> +#include "../hid-ids.h"
> +
> +/* quirks to control the device */
> +#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
You can use BIT(0) instead of (1 << 0)
> +
> /* flags */
> #define I2C_HID_STARTED 0
> #define I2C_HID_RESET_PENDING 1
> @@ -143,6 +148,7 @@ struct i2c_hid {
> char *argsbuf; /* Command arguments buffer */
>
> unsigned long flags; /* device flags */
> + unsigned long quirks; /* Various quirks */
>
> wait_queue_head_t wait; /* For waiting the interrupt */
> struct gpio_desc *desc;
> @@ -154,6 +160,39 @@ struct i2c_hid {
> struct mutex reset_lock;
> };
>
> +static const struct i2c_hid_blacklist {
> + __u16 idVendor;
> + __u16 idProduct;
> + __u32 quirks;
> +} i2c_hid_blacklist[] = {
I'd prefer not using "blacklist". i2c_hid_quirks?
> + { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8752,
> + I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> + { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8755,
> + I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> + { 0, 0 }
> +};
> +
> +/*
> + * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID device
> + * @idVendor: the 16-bit vendor ID
> + * @idProduct: the 16-bit product ID
> + *
> + * Returns: a u32 quirks value.
> + */
> +static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct)
> +{
> + u32 quirks = 0;
> + int n = 0;
int n;
> +
> + for (; i2c_hid_blacklist[n].idVendor; n++)
for (n = 0; ...)
please :)
> + if (i2c_hid_blacklist[n].idVendor == idVendor &&
> + (i2c_hid_blacklist[n].idProduct == (__u16)HID_ANY_ID ||
> + i2c_hid_blacklist[n].idProduct == idProduct))
> + quirks = i2c_hid_blacklist[n].quirks;
> +
> + return quirks;
> +}
> +
> static int __i2c_hid_command(struct i2c_client *client,
> const struct i2c_hid_cmd *command, u8 reportID,
> u8 reportType, u8 *args, int args_len,
> @@ -346,11 +385,27 @@ static int i2c_hid_set_power(struct i2c_client *client, int power_state)
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> + /*
> + * Some devices require to send a command to wakeup before power on.
> + * The call will get a return value (EREMOTEIO) but device will be
> + * triggered and activated. After that, it goes like a normal device.
> + */
> + if (power_state == I2C_HID_PWR_ON &&
> + ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV) {
> + ret = i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
> +
> + /* Device was already activated */
> + if (!ret)
> + goto set_pwr_exit;
> + }
> +
> ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
> 0, NULL, 0, NULL, 0);
> +
> if (ret)
> dev_err(&client->dev, "failed to change power setting.\n");
>
> +set_pwr_exit:
> return ret;
> }
>
> @@ -1050,6 +1105,8 @@ static int i2c_hid_probe(struct i2c_client *client,
> client->name, hid->vendor, hid->product);
> strlcpy(hid->phys, dev_name(&client->dev), sizeof(hid->phys));
>
> + ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
> +
> ret = hid_add_device(hid);
> if (ret) {
> if (ret != -ENODEV)
> --
> 1.9.1
>
OK, thanks for the resubmission. I am happy with the changes so far, so
with the few nitpicks I expressed, it should be mergeable soon.
Cheers,
Benjamin
^ permalink raw reply
* Re: [RFC 2/4] Alsa: control: increment index field for duplicated control.
From: Arnaud Pouliquen @ 2016-11-09 10:32 UTC (permalink / raw)
To: Takashi Sakamoto, alsa-devel@alsa-project.org, Charles Keepax,
Vinod Koul
Cc: Takashi Iwai, broonie@kernel.org, lgirdwood@gmail.com
In-Reply-To: <01cac646-0abb-caa7-fe59-dee1f5d4a755@sakamocchi.jp>
Hello Takashi,
On 11/09/2016 05:04 AM, Takashi Sakamoto wrote:
> Hi,
>
> On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
>> Instead of returning an error when a control is already present, the
>> index field is incremented and a warning message is printed.
>> This allows drivers to instanciate same control without
>> device and sub device number management ( MIXER type controls).
>>
>> Change-Id: Ifcc60dca9d1cf4c3a424bb9653296678aa7953cb
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>> ---
>> sound/core/control.c | 28 ++++++++++++++++++----------
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/sound/core/control.c b/sound/core/control.c
>> index fb096cb..014e3f4 100644
>> --- a/sound/core/control.c
>> +++ b/sound/core/control.c
>> @@ -365,6 +365,7 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol *kcontrol)
>> struct snd_ctl_elem_id id;
>> unsigned int idx;
>> unsigned int count;
>> + struct snd_kcontrol *elem_set;
>> int err = -EINVAL;
>>
>> if (! kcontrol)
>> @@ -376,17 +377,24 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol *kcontrol)
>> goto error;
>>
>> down_write(&card->controls_rwsem);
>> - if (snd_ctl_find_id(card, &id)) {
>> - up_write(&card->controls_rwsem);
>> - dev_err(card->dev, "control %i:%i:%i:%s:%i is already present\n",
>> - id.iface,
>> - id.device,
>> - id.subdevice,
>> - id.name,
>> - id.index);
>> - err = -EBUSY;
>> - goto error;
>> + while (elem_set = snd_ctl_find_id(card, &id)) {
>> + id.index++;
>> + if (id.index > UINT_MAX - kcontrol->count) {
>> + up_write(&card->controls_rwsem);
>> + dev_err(card->dev, "no more free index for control %i:%i:%i:%s\n",
>> + id.iface, id.device, id.subdevice, id.name);
>> + err = -ENOSPC;
>> + goto error;
>> + }
>> + }
>> + if (kcontrol->id.index != id.index) {
>> + dev_warn(card->dev, "control %i:%i:%i:%s:%i is already present\n",
>> + id.iface, id.device, id.subdevice, id.name, id.index);
>> + dev_warn(card->dev, "control index updated from %i to %i\n",
>> + kcontrol->id.index, id.index);
>> + kcontrol->id.index = id.index;
>> }
>> +
>> if (snd_ctl_find_hole(card, kcontrol->count) < 0) {
>> up_write(&card->controls_rwsem);
>> err = -ENOMEM;
>
> As Iwai-san explained below, this integration is a bit
> over-specification in control core, because your issue is specific in
> ALSA SoC part.
>
>
> On Nov 8 2016 23:30, Takashi Iwai wrote:
> > Right, this behavior must be optional. For the normal drivers, the
> > duplicated controls *are* errors, and we catch it instead. For
> > drivers that are aware of confliction and want the automatic
> > workaround (e.g. HD-audio driver does it already), this kind of code
> > would be useful to be in the common place.
> (http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.html)
>
> For drivers outside of ALSA SoC part, developers can and should program
> control element sets with unique identification information, because
> design of sound card is fixed at development time. Therefore, these
> codes should be in ALSA SoC core, as I introduced once.
>
> When we have the same requirement for drivers outside of ALSA SoC part,
> then we're going to move these codes from ALSA SoC core to ALSA control
> core, I think.
I have generalized this in control.c, precisely because, as you pointed,
HDA-audio as same requirement. In other words, this could also seem as
an helper for the control indexation.
Now no problem to limit it to ASoC as you propose (need to implement it
in snd_soc_cnew to take into account prefix).
Now regarding the discussion and the set of patches in my RFC:
In my environment, this patch is mandatory to be able to address 'IEC958
Playback Default' control using iecset application.
if patch in iecset is accepted, it is no more mandatory.
(http://www.spinics.net/lists/alsa-devel/msg56480.html)
So the right way to do it, is to propose the iecset patch in a first step.
Then if it is rejected or if you estimate that patch makes sense anyway
for other "generic" controls i will rework it and propose it.
Thanks and Regards
Arnaud
^ permalink raw reply
* Re: [PATCH v10 3/7] x86/arch_prctl: Add do_arch_prctl_common
From: Borislav Petkov @ 2016-11-09 10:31 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-4-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:52AM -0800, Kyle Huey wrote:
> Add do_arch_prctl_common to handle arch_prctls that are not specific to 64
do_arch_prctl_common()
> bits. Call it from the syscall entry point, but not any of the other
"... to 64-bit mode." Or something like that...
> callsites in the kernel, which all want one of the existing 64 bit only
64-bit
> arch_prctls.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v10 3/7] x86/arch_prctl: Add do_arch_prctl_common
From: Borislav Petkov @ 2016-11-09 10:31 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-4-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:52AM -0800, Kyle Huey wrote:
> Add do_arch_prctl_common to handle arch_prctls that are not specific to 64
do_arch_prctl_common()
> bits. Call it from the syscall entry point, but not any of the other
"... to 64-bit mode." Or something like that...
> callsites in the kernel, which all want one of the existing 64 bit only
64-bit
> arch_prctls.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v2 0/3] ASoC: intel: atom: Add FW version information
From: Vinod Koul @ 2016-11-09 10:40 UTC (permalink / raw)
To: Sebastien Guiriec; +Cc: liam.r.girdwood, alsa-devel, pierre-louis.bossart
In-Reply-To: <20161109084736.28265-1-sebastien.guiriec@intel.com>
On Wed, Nov 09, 2016 at 09:47:33AM +0100, Sebastien Guiriec wrote:
> This patch series is adding FW version information of SST. Version is both
> log as dev_info and sysfs entry.
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
^ permalink raw reply
* Re: [Qemu-devel] [PATCHv2] cipher: fix leak on initialization error
From: Daniel P. Berrange @ 2016-11-09 10:30 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: qemu-devel
In-Reply-To: <20161109102818.9566-1-marcandre.lureau@redhat.com>
On Wed, Nov 09, 2016 at 02:28:18PM +0400, Marc-André Lureau wrote:
> On error path, ctx may be leaked. Assign ctx earlier, and call
> qcrypto_cipher_free() on error.
>
> Spotted thanks to ASAN.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> crypto/cipher-nettle.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Thanks, queued on my crypto-next branch
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* [Qemu-devel] [PATCHv2] cipher: fix leak on initialization error
From: Marc-André Lureau @ 2016-11-09 10:28 UTC (permalink / raw)
To: qemu-devel; +Cc: berrange, Marc-André Lureau
On error path, ctx may be leaked. Assign ctx earlier, and call
qcrypto_cipher_free() on error.
Spotted thanks to ASAN.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
crypto/cipher-nettle.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cd094cd..5798910 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -254,6 +254,7 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
cipher->mode = mode;
ctx = g_new0(QCryptoCipherNettle, 1);
+ cipher->opaque = ctx;
switch (alg) {
case QCRYPTO_CIPHER_ALG_DES_RFB:
@@ -384,13 +385,11 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
}
ctx->iv = g_new0(uint8_t, ctx->blocksize);
- cipher->opaque = ctx;
return cipher;
error:
- g_free(cipher);
- g_free(ctx);
+ qcrypto_cipher_free(cipher);
return NULL;
}
--
2.10.0
^ permalink raw reply related
* [Qemu-devel] [PATCH] Fix cursesw detection
From: Samuel Thibault @ 2016-11-09 10:27 UTC (permalink / raw)
To: qemu-devel; +Cc: Samuel Thibault, peter.maydell, kraxel, pbonzini, mjt
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
configure | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
- curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+ curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+ IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+ if test "$curses_found" = yes ; then
+ break
+ fi
done
unset IFS
if test "$curses_found" = "yes" ; then
--
2.10.2
^ permalink raw reply related
* Patch "video: fbdev: pxafb: potential NULL dereference on error" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: dan.carpenter, gregkh, robert.jarzmik, tomi.valkeinen
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
video: fbdev: pxafb: potential NULL dereference on error
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
video-fbdev-pxafb-potential-null-dereference-on-error.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From e0299908d606a99e7ffb467bc3c11dfe54133af3 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 15 Jul 2016 14:07:32 +0300
Subject: video: fbdev: pxafb: potential NULL dereference on error
From: Dan Carpenter <dan.carpenter@oracle.com>
commit e0299908d606a99e7ffb467bc3c11dfe54133af3 upstream.
If we "goto out;" then it calls display_timings_release(timings);
Since "timings" is NULL, that's going to oops. Just return directly.
Fixes: 420a488278e8 ('video: fbdev: pxafb: initial devicetree conversion')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/pxafb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2125,7 +2125,7 @@ static int of_get_pxafb_display(struct d
timings = of_get_display_timings(disp);
if (!timings)
- goto out;
+ return -EINVAL;
ret = -ENOMEM;
info->modes = kmalloc_array(timings->num_timings,
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.8/ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
queue-4.8/video-fbdev-pxafb-potential-null-dereference-on-error.patch
^ permalink raw reply
* Patch "[media] v4l: vsp1: Prevent pipelines from running when not streaming" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: laurent.pinchart+renesas, gregkh, kieran, mchehab; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] v4l: vsp1: Prevent pipelines from running when not streaming
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
v4l-vsp1-prevent-pipelines-from-running-when-not-streaming.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From e4e70a147a48618a36ae1b81c641516cb9d45993 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Fri, 8 Jul 2016 06:20:51 -0300
Subject: [media] v4l: vsp1: Prevent pipelines from running when not streaming
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
commit e4e70a147a48618a36ae1b81c641516cb9d45993 upstream.
Pipelines can only be run if all their video nodes are streaming. Commit
b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first
STREAMOFF") fixed the pipeline stop sequence, but introduced a race
condition that makes it possible to run a pipeline after stopping the
stream on a video node by queuing a buffer on the other side of the
pipeline.
Fix this by clearing the buffers ready flag when stopping the stream,
which will prevent the QBUF handler from running the pipeline.
Fixes: b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF")
Reported-by: Kieran Bingham <kieran@bingham.xyz>
Tested-by: Kieran Bingham <kieran@bingham.xyz>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/vsp1/vsp1_video.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -675,6 +675,13 @@ static void vsp1_video_stop_streaming(st
unsigned long flags;
int ret;
+ /* Clear the buffers ready flag to make sure the device won't be started
+ * by a QBUF on the video node on the other side of the pipeline.
+ */
+ spin_lock_irqsave(&video->irqlock, flags);
+ pipe->buffers_ready &= ~(1 << video->pipe_index);
+ spin_unlock_irqrestore(&video->irqlock, flags);
+
mutex_lock(&pipe->lock);
if (--pipe->stream_count == pipe->num_inputs) {
/* Stop the pipeline. */
Patches currently in stable-queue which might be from laurent.pinchart+renesas@ideasonboard.com are
queue-4.8/v4l-vsp1-prevent-pipelines-from-running-when-not-streaming.patch
^ permalink raw reply
* Patch "usb: musb: Fix hardirq-safe hardirq-unsafe lock order error" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: tony, b-liu, gregkh, laurent.pinchart; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-musb-fix-hardirq-safe-hardirq-unsafe-lock-order-error.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d8e5f0eca1e88215e45aca27115ea747e6164da1 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 19 Oct 2016 12:03:39 -0500
Subject: usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
From: Tony Lindgren <tony@atomide.com>
commit d8e5f0eca1e88215e45aca27115ea747e6164da1 upstream.
If we configure musb with 2430 glue as a peripheral, and then rmmod
omap2430 module, we'll get the following error:
[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
(&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8
[ 204.678710]
and this task is already holding:
(&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>]
musb_gadget_stop+0x24/0xec [musb_hdrc]
which would create a new lock dependency:
(&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...
This is because some glue layers expect musb_platform_enable/disable
to be called with spinlock held, and 2430 glue layer has USB PHY on
the I2C bus using a mutex.
We could fix the glue layers to take the spinlock, but we still have
a problem of musb_plaform_enable/disable being called in an unbalanced
manner. So that would still lead into USB PHY enable/disable related
problems for omap2430 glue layer.
While it makes sense to only enable USB PHY when needed from PM point
of view, in this case we just can't do it yet without breaking things.
So let's just revert phy_enable/disable related changes instead and
reconsider this after we have fixed musb_platform_enable/disable to
be balanced.
Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/omap2430.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -337,6 +337,7 @@ static int omap2430_musb_init(struct mus
}
musb->isr = omap2430_musb_interrupt;
phy_init(musb->phy);
+ phy_power_on(musb->phy);
l = musb_readl(musb->mregs, OTG_INTERFSEL);
@@ -373,8 +374,6 @@ static void omap2430_musb_enable(struct
struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev);
struct omap_musb_board_data *data = pdata->board_data;
- if (!WARN_ON(!musb->phy))
- phy_power_on(musb->phy);
omap2430_set_power(musb, true, glue->cable_connected);
@@ -413,9 +412,6 @@ static void omap2430_musb_disable(struct
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
- if (!WARN_ON(!musb->phy))
- phy_power_off(musb->phy);
-
if (glue->status != MUSB_UNKNOWN)
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_DISCONNECT);
@@ -429,6 +425,7 @@ static int omap2430_musb_exit(struct mus
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
omap2430_low_level_exit(musb);
+ phy_power_off(musb->phy);
phy_exit(musb->phy);
musb->phy = NULL;
cancel_work_sync(&glue->omap_musb_mailbox_work);
Patches currently in stable-queue which might be from tony@atomide.com are
queue-4.8/usb-musb-fix-hardirq-safe-hardirq-unsafe-lock-order-error.patch
^ permalink raw reply
* Re: per-domain logging
From: Cedric Bosdonnat @ 2016-11-09 10:27 UTC (permalink / raw)
To: Wei Liu; +Cc: Ian Jackson, xen-devel
In-Reply-To: <20161013094146.GE3687@citrix.com>
Hi Wei, Ian,
I now have a big lot of changes to use the LOG*D family through the libxl code.
What should be the best way to submit that for review? I guess a giant commit
won't be too easy to handle for review and maintenance, maybe I should have one
commit per changed file... any opinion on that?
--
Cedric
On Thu, 2016-10-13 at 10:41 +0100, Wei Liu wrote:
> On Thu, Oct 13, 2016 at 11:28:21AM +0200, Cedric Bosdonnat wrote:
> > Hi Wei, Ian,
> >
> > In quite a number of places, the domid we have in the function calling LOG*
> > may be the one of a stubdom. In the log we want to output the domid of the
> > domain the user knows about. Would there be a way to get it?
> >
> > An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting
> > that domid may not be the real domain id. An I wonder if there are other
> > places where domid may be the one of a stubdom and I don't know it.
> >
>
> The third argument of libxl_is_stubdom can be used to retrieve the
> target domid.
>
> If you find other places where you need to get the domid, please let me
> know. I believe there are some fields embedded in various structs that
> we can interrogate.
>
> Wei.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [U-Boot] net: use random ethernet address if invalid and not zero
From: Michal Simek @ 2016-11-09 10:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161107173142.12ABEFEB38@linux-xvxi.amer.corp.natinst.com>
On 7.11.2016 18:31, Joe Hershberger wrote:
> Hi Michal,
>
> https://patchwork.ozlabs.org/patch/690374/ was applied to u-boot-net.git.
Thanks,
Michal
^ permalink raw reply
* Patch "usb: chipidea: host: fix NULL ptr dereference during shutdown" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: stefan.wahren, gregkh, peter.chen, stern; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: chipidea: host: fix NULL ptr dereference during shutdown
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-chipidea-host-fix-null-ptr-dereference-during-shutdown.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 991d5add50a5bb6ab8f12f2129f5c7487f6baaf6 Mon Sep 17 00:00:00 2001
From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Sat, 10 Sep 2016 12:53:21 +0000
Subject: usb: chipidea: host: fix NULL ptr dereference during shutdown
From: Stefan Wahren <stefan.wahren@i2se.com>
commit 991d5add50a5bb6ab8f12f2129f5c7487f6baaf6 upstream.
After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown
callback") and commit 43a404577a93 ("usb: chipidea: host: set host to
be null after hcd is freed") a NULL pointer dereference is caused
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: b09b5224fe86 ("usb: chipidea: implement platform shutdown callback")
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/host.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci
if (hcd) {
usb_remove_hcd(hcd);
+ ci->role = CI_ROLE_END;
+ synchronize_irq(ci->irq);
usb_put_hcd(hcd);
if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))
Patches currently in stable-queue which might be from stefan.wahren@i2se.com are
queue-4.8/usb-chipidea-host-fix-null-ptr-dereference-during-shutdown.patch
^ permalink raw reply
* Patch "usb: dwc3: Fix size used in dma_free_coherent()" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: christophe.jaillet, felipe.balbi, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix size used in dma_free_coherent()
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-dwc3-fix-size-used-in-dma_free_coherent.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 Mon Sep 17 00:00:00 2001
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri, 7 Oct 2016 22:12:39 +0200
Subject: usb: dwc3: Fix size used in dma_free_coherent()
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream.
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.
This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////
Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3055,7 +3055,7 @@ err3:
kfree(dwc->setup_buf);
err2:
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
err1:
@@ -3080,7 +3080,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
kfree(dwc->zlp_buf);
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
Patches currently in stable-queue which might be from christophe.jaillet@wanadoo.fr are
queue-4.8/usb-dwc3-fix-size-used-in-dma_free_coherent.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.