All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver
From: Zhi Li @ 2016-11-08 19:21 UTC (permalink / raw)
  To: Paul Gortmaker
  Cc: Frank Li, Shawn Guo, linux-arm-kernel@lists.infradead.org, LKML,
	Peter Zijlstra, Ingo Molnar, acme, alexander.shishkin,
	Mark Rutland, jerry shen, Zhengyu Shen
In-Reply-To: <CAP=VYLo_p3ZmOFcyM9om_31-=5O3ZiRLCBkJDDtj84JxAA7h8Q@mail.gmail.com>

On Tue, Nov 8, 2016 at 1:00 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On Mon, Sep 19, 2016 at 1:47 PM, Frank Li <Frank.Li@nxp.com> wrote:
>> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>>
>> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
>> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
>> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
>> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
>> MMDC provides registers for performance counters which read via this
>> driver to help debug memory throughput and similar issues.
>>
>> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
>> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>>
>>          898021787      mmdc/busy-cycles/
>>           14819600      mmdc/read-accesses/
>>             471.30 MB   mmdc/read-bytes/
>>         2815419216      mmdc/total-cycles/
>>           13367354      mmdc/write-accesses/
>>             427.76 MB   mmdc/write-bytes/
>>
>>        5.334757334 seconds time elapsed
>>
>> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
>> Signed-off-by: Frank Li <frank.li@nxp.com>
>> ---
>> Changes from v6 to v7
>>     use mmdc_pmu prefix
>>     remove unnecessary check
>>     improve group event check according to mark's feedback.
>>     check pmu_mmdc->mmdc_events[cfg] at event_add
>>     only check == 0 at event_del
>>
>> Changes from v5 to v6
>>     Improve group event error handle
>>
>> Changes from v4 to v5
>>     Remove mmdc_pmu:irq
>>     remove static variable cpuhp_mmdc_pmu
>>     remove spin_lock
>>     check is_sampling_event(event)
>>     remove unnecessary cast
>>     use hw_perf_event::prev_count
>>
>> Changes from v3 to v4:
>>     Tested and fixed crash relating to removing events with perf fuzzer
>>     Adjusted formatting
>>     Moved all perf event code under CONFIG_PERF_EVENTS
>>         Switched cpuhp_setup_state to cpuhp_setup_state_nocalls
>>
>> Changes from v2 to v3:
>>     Use WARN_ONCE instead of returning generic error values
>>     Replace CPU Notifiers with newer state machine hotplug
>>     Added additional checks on event_init for grouping and sampling
>>     Remove useless mmdc_enable_profiling function
>>     Added comments
>>     Moved start index of events from 0x01 to 0x00
>>     Added a counter to pmu_mmdc to only stop hrtimer after all events are finished
>>     Replace readl_relaxed and writel_relaxed with readl and writel
>>     Removed duplicate update function
>>     Used devm_kasprintf when naming mmdcs probed
>>
>> Changes from v1 to v2:
>>     Added cpumask and migration handling support to driver
>>     Validated event during event_init
>>     Added code to properly stop counters
>>     Used perf_invalid_context instead of perf_sw_context
>>     Added hrtimer to poll for overflow
>>     Added better description
>>     Added support for multiple mmdcs
>>
>>  arch/arm/mach-imx/mmdc.c | 459 ++++++++++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 457 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
>> index db9621c..1f70376 100644
>> --- a/arch/arm/mach-imx/mmdc.c
>> +++ b/arch/arm/mach-imx/mmdc.c
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright 2011 Freescale Semiconductor, Inc.
>> + * Copyright 2011,2016 Freescale Semiconductor, Inc.
>>   * Copyright 2011 Linaro Ltd.
>>   *
>>   * The code contained herein is licensed under the GNU General Public
>> @@ -10,12 +10,16 @@
>>   * http://www.gnu.org/copyleft/gpl.html
>>   */
>>
>> +#include <linux/hrtimer.h>
>>  #include <linux/init.h>
>> +#include <linux/interrupt.h>
>>  #include <linux/io.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/of_address.h>
>>  #include <linux/of_device.h>
>> +#include <linux/perf_event.h>
>> +#include <linux/slab.h>
>>
>>  #include "common.h"
>>
>> @@ -27,8 +31,458 @@
>>  #define BM_MMDC_MDMISC_DDR_TYPE        0x18
>>  #define BP_MMDC_MDMISC_DDR_TYPE        0x3
>>
>> +#define TOTAL_CYCLES           0x0
>> +#define BUSY_CYCLES            0x1
>> +#define READ_ACCESSES          0x2
>> +#define WRITE_ACCESSES         0x3
>> +#define READ_BYTES             0x4
>> +#define WRITE_BYTES            0x5
>> +
>> +/* Enables, resets, freezes, overflow profiling*/
>> +#define DBG_DIS                        0x0
>> +#define DBG_EN                 0x1
>> +#define DBG_RST                        0x2
>> +#define PRF_FRZ                        0x4
>> +#define CYC_OVF                        0x8
>> +
>> +#define MMDC_MADPCR0   0x410
>> +#define MMDC_MADPSR0   0x418
>> +#define MMDC_MADPSR1   0x41C
>> +#define MMDC_MADPSR2   0x420
>> +#define MMDC_MADPSR3   0x424
>> +#define MMDC_MADPSR4   0x428
>> +#define MMDC_MADPSR5   0x42C
>> +
>> +#define MMDC_NUM_COUNTERS      6
>> +
>> +#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>> +
>>  static int ddr_type;
>>
>> +#ifdef CONFIG_PERF_EVENTS
>> +
>> +static DEFINE_IDA(mmdc_ida);
>> +
>> +PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles, "event=0x00")
>> +PMU_EVENT_ATTR_STRING(busy-cycles, mmdc_pmu_busy_cycles, "event=0x01")
>> +PMU_EVENT_ATTR_STRING(read-accesses, mmdc_pmu_read_accesses, "event=0x02")
>> +PMU_EVENT_ATTR_STRING(write-accesses, mmdc_pmu_write_accesses, "config=0x03")
>> +PMU_EVENT_ATTR_STRING(read-bytes, mmdc_pmu_read_bytes, "event=0x04")
>> +PMU_EVENT_ATTR_STRING(read-bytes.unit, mmdc_pmu_read_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(read-bytes.scale, mmdc_pmu_read_bytes_scale, "0.000001");
>> +PMU_EVENT_ATTR_STRING(write-bytes, mmdc_pmu_write_bytes, "event=0x05")
>> +PMU_EVENT_ATTR_STRING(write-bytes.unit, mmdc_pmu_write_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(write-bytes.scale, mmdc_pmu_write_bytes_scale, "0.000001");
>> +
>> +struct mmdc_pmu {
>> +       struct pmu pmu;
>> +       void __iomem *mmdc_base;
>> +       cpumask_t cpu;
>> +       struct hrtimer hrtimer;
>> +       unsigned int active_events;
>> +       struct device *dev;
>> +       struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
>> +       struct hlist_node node;
>> +};
>> +
>> +/*
>> + * Polling period is set to one second, overflow of total-cycles (the fastest
>> + * increasing counter) takes ten seconds so one second is safe
>> + */
>> +static unsigned int mmdc_pmu_poll_period_us = 1000000;
>> +
>> +module_param_named(pmu_pmu_poll_period_us, mmdc_pmu_poll_period_us, uint,
>> +               S_IRUGO | S_IWUSR);
>
> I just noticed this commit now that linux-next is back after the week off.
>
> This should probably use core_param or setup_param since the Kconfig
> for this is bool and not tristate.  Similarly, that means that the .remove
> function you've added is dead code -- unless you envision a case where
> the user needs to forcibly unbind the driver...
>
> Do you want to redo the existing commit or do you want me to submit
> a follow-up fixup patch?

I will do follow-up fixup patch.

I think pmu_pmu_poll_period_us should be removed because no benefit to
change it.
I can delete .remove

best regards
Frank Li

>
> Thanks
> Paul.
> --
>
>> +
>> +static ktime_t mmdc_pmu_timer_period(void)
>> +{
>> +       return ns_to_ktime((u64)mmdc_pmu_poll_period_us * 1000);
>> +}
>> +

^ permalink raw reply

* [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver
From: Zhi Li @ 2016-11-08 19:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAP=VYLo_p3ZmOFcyM9om_31-=5O3ZiRLCBkJDDtj84JxAA7h8Q@mail.gmail.com>

On Tue, Nov 8, 2016 at 1:00 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On Mon, Sep 19, 2016 at 1:47 PM, Frank Li <Frank.Li@nxp.com> wrote:
>> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>>
>> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
>> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
>> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
>> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
>> MMDC provides registers for performance counters which read via this
>> driver to help debug memory throughput and similar issues.
>>
>> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
>> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>>
>>          898021787      mmdc/busy-cycles/
>>           14819600      mmdc/read-accesses/
>>             471.30 MB   mmdc/read-bytes/
>>         2815419216      mmdc/total-cycles/
>>           13367354      mmdc/write-accesses/
>>             427.76 MB   mmdc/write-bytes/
>>
>>        5.334757334 seconds time elapsed
>>
>> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
>> Signed-off-by: Frank Li <frank.li@nxp.com>
>> ---
>> Changes from v6 to v7
>>     use mmdc_pmu prefix
>>     remove unnecessary check
>>     improve group event check according to mark's feedback.
>>     check pmu_mmdc->mmdc_events[cfg] at event_add
>>     only check == 0 at event_del
>>
>> Changes from v5 to v6
>>     Improve group event error handle
>>
>> Changes from v4 to v5
>>     Remove mmdc_pmu:irq
>>     remove static variable cpuhp_mmdc_pmu
>>     remove spin_lock
>>     check is_sampling_event(event)
>>     remove unnecessary cast
>>     use hw_perf_event::prev_count
>>
>> Changes from v3 to v4:
>>     Tested and fixed crash relating to removing events with perf fuzzer
>>     Adjusted formatting
>>     Moved all perf event code under CONFIG_PERF_EVENTS
>>         Switched cpuhp_setup_state to cpuhp_setup_state_nocalls
>>
>> Changes from v2 to v3:
>>     Use WARN_ONCE instead of returning generic error values
>>     Replace CPU Notifiers with newer state machine hotplug
>>     Added additional checks on event_init for grouping and sampling
>>     Remove useless mmdc_enable_profiling function
>>     Added comments
>>     Moved start index of events from 0x01 to 0x00
>>     Added a counter to pmu_mmdc to only stop hrtimer after all events are finished
>>     Replace readl_relaxed and writel_relaxed with readl and writel
>>     Removed duplicate update function
>>     Used devm_kasprintf when naming mmdcs probed
>>
>> Changes from v1 to v2:
>>     Added cpumask and migration handling support to driver
>>     Validated event during event_init
>>     Added code to properly stop counters
>>     Used perf_invalid_context instead of perf_sw_context
>>     Added hrtimer to poll for overflow
>>     Added better description
>>     Added support for multiple mmdcs
>>
>>  arch/arm/mach-imx/mmdc.c | 459 ++++++++++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 457 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
>> index db9621c..1f70376 100644
>> --- a/arch/arm/mach-imx/mmdc.c
>> +++ b/arch/arm/mach-imx/mmdc.c
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright 2011 Freescale Semiconductor, Inc.
>> + * Copyright 2011,2016 Freescale Semiconductor, Inc.
>>   * Copyright 2011 Linaro Ltd.
>>   *
>>   * The code contained herein is licensed under the GNU General Public
>> @@ -10,12 +10,16 @@
>>   * http://www.gnu.org/copyleft/gpl.html
>>   */
>>
>> +#include <linux/hrtimer.h>
>>  #include <linux/init.h>
>> +#include <linux/interrupt.h>
>>  #include <linux/io.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/of_address.h>
>>  #include <linux/of_device.h>
>> +#include <linux/perf_event.h>
>> +#include <linux/slab.h>
>>
>>  #include "common.h"
>>
>> @@ -27,8 +31,458 @@
>>  #define BM_MMDC_MDMISC_DDR_TYPE        0x18
>>  #define BP_MMDC_MDMISC_DDR_TYPE        0x3
>>
>> +#define TOTAL_CYCLES           0x0
>> +#define BUSY_CYCLES            0x1
>> +#define READ_ACCESSES          0x2
>> +#define WRITE_ACCESSES         0x3
>> +#define READ_BYTES             0x4
>> +#define WRITE_BYTES            0x5
>> +
>> +/* Enables, resets, freezes, overflow profiling*/
>> +#define DBG_DIS                        0x0
>> +#define DBG_EN                 0x1
>> +#define DBG_RST                        0x2
>> +#define PRF_FRZ                        0x4
>> +#define CYC_OVF                        0x8
>> +
>> +#define MMDC_MADPCR0   0x410
>> +#define MMDC_MADPSR0   0x418
>> +#define MMDC_MADPSR1   0x41C
>> +#define MMDC_MADPSR2   0x420
>> +#define MMDC_MADPSR3   0x424
>> +#define MMDC_MADPSR4   0x428
>> +#define MMDC_MADPSR5   0x42C
>> +
>> +#define MMDC_NUM_COUNTERS      6
>> +
>> +#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>> +
>>  static int ddr_type;
>>
>> +#ifdef CONFIG_PERF_EVENTS
>> +
>> +static DEFINE_IDA(mmdc_ida);
>> +
>> +PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles, "event=0x00")
>> +PMU_EVENT_ATTR_STRING(busy-cycles, mmdc_pmu_busy_cycles, "event=0x01")
>> +PMU_EVENT_ATTR_STRING(read-accesses, mmdc_pmu_read_accesses, "event=0x02")
>> +PMU_EVENT_ATTR_STRING(write-accesses, mmdc_pmu_write_accesses, "config=0x03")
>> +PMU_EVENT_ATTR_STRING(read-bytes, mmdc_pmu_read_bytes, "event=0x04")
>> +PMU_EVENT_ATTR_STRING(read-bytes.unit, mmdc_pmu_read_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(read-bytes.scale, mmdc_pmu_read_bytes_scale, "0.000001");
>> +PMU_EVENT_ATTR_STRING(write-bytes, mmdc_pmu_write_bytes, "event=0x05")
>> +PMU_EVENT_ATTR_STRING(write-bytes.unit, mmdc_pmu_write_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(write-bytes.scale, mmdc_pmu_write_bytes_scale, "0.000001");
>> +
>> +struct mmdc_pmu {
>> +       struct pmu pmu;
>> +       void __iomem *mmdc_base;
>> +       cpumask_t cpu;
>> +       struct hrtimer hrtimer;
>> +       unsigned int active_events;
>> +       struct device *dev;
>> +       struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
>> +       struct hlist_node node;
>> +};
>> +
>> +/*
>> + * Polling period is set to one second, overflow of total-cycles (the fastest
>> + * increasing counter) takes ten seconds so one second is safe
>> + */
>> +static unsigned int mmdc_pmu_poll_period_us = 1000000;
>> +
>> +module_param_named(pmu_pmu_poll_period_us, mmdc_pmu_poll_period_us, uint,
>> +               S_IRUGO | S_IWUSR);
>
> I just noticed this commit now that linux-next is back after the week off.
>
> This should probably use core_param or setup_param since the Kconfig
> for this is bool and not tristate.  Similarly, that means that the .remove
> function you've added is dead code -- unless you envision a case where
> the user needs to forcibly unbind the driver...
>
> Do you want to redo the existing commit or do you want me to submit
> a follow-up fixup patch?

I will do follow-up fixup patch.

I think pmu_pmu_poll_period_us should be removed because no benefit to
change it.
I can delete .remove

best regards
Frank Li

>
> Thanks
> Paul.
> --
>
>> +
>> +static ktime_t mmdc_pmu_timer_period(void)
>> +{
>> +       return ns_to_ktime((u64)mmdc_pmu_poll_period_us * 1000);
>> +}
>> +

^ permalink raw reply

* FAILED: patch "[PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready" failed to apply to 4.4-stable tree
From: gregkh @ 2016-11-08 19:13 UTC (permalink / raw)
  To: stefan, leoyang.li, u.kleine-koenig, wsa; +Cc: stable


The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 533169d164c6b4c8571d0d48779f6ff6be593d72 Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan@agner.ch>
Date: Mon, 26 Sep 2016 17:18:58 -0700
Subject: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some SoC might load the GPIO driver after the I2C driver and
using the I2C bus recovery mechanism via GPIOs. In this case
it is crucial to defer probing if the GPIO request functions
do so, otherwise the I2C driver gets loaded without recovery
mechanisms enabled.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 592a8f26a708..47fc1f1acff7 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 	rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", 0);
 	rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", 0);
 
-	if (!gpio_is_valid(rinfo->sda_gpio) ||
-	    !gpio_is_valid(rinfo->scl_gpio) ||
-	    IS_ERR(i2c_imx->pinctrl_pins_default) ||
-	    IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
+	if (rinfo->sda_gpio == -EPROBE_DEFER ||
+	    rinfo->scl_gpio == -EPROBE_DEFER) {
+		return -EPROBE_DEFER;
+	} else if (!gpio_is_valid(rinfo->sda_gpio) ||
+		   !gpio_is_valid(rinfo->scl_gpio) ||
+		   IS_ERR(i2c_imx->pinctrl_pins_default) ||
+		   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
 		dev_dbg(&pdev->dev, "recovery information incomplete\n");
 		return 0;
 	}


^ permalink raw reply related

* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Luis R. Rodriguez @ 2016-11-08 19:21 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis R. Rodriguez, Lukas Wunner, Rafael J. Wysocki, Linux PM list,
	Alan Stern, Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
	Marek Szyprowski, Kevin Hilman, Ulf Hansson, Laurent Pinchart,
	Lars-Peter Clausen, Grant Likely, Mauro Carvalho Chehab,
	Andrzej Hajda
In-Reply-To: <20161108064541.GA13024@kroah.com>

On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote:
> > We have no explicit semantics to check if a driver / subsystem
> > supports deferred probe.
> 
> Why would we need such a thing?

It depends on the impact of a driver/subsystem not properly supporting
deffered probe, if this is no-op then such a need is not critical but
would be good to proactively inform developers / users so they avoid 
its use, if this will cause issues its perhaps best to make this a
no-op through a check. AFAICT reviewing implications of not supporting
deferred probe on drivers/subsytsems for this framework is not clearly
spelled out, if we start considering re-using this framework for probe
ordering I'd hate to see issues come up without this corner case being
concretely considered.

Furthermore -- how does this framework compare to Andrzej's resource tracking
solution? I confess I have not had a chance yet to review yet but in light of
this question it would be good to know if Andrzej's framework also requires
deferred probe as similar concerns would exist there as well.

  Luis

^ permalink raw reply

* Re: [RFC v4 08/21] media: Enable allocating the media device dynamically
From: Shuah Khan @ 2016-11-08 19:20 UTC (permalink / raw)
  To: Sakari Ailus
  Cc: linux-media, hverkuil, mchehab, shuahkh, laurent.pinchart,
	Sakari Ailus
In-Reply-To: <1478613330-24691-8-git-send-email-sakari.ailus@linux.intel.com>

On Tue, Nov 8, 2016 at 6:55 AM, Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
> From: Sakari Ailus <sakari.ailus@iki.fi>
>
> Allow allocating the media device dynamically. As the struct media_device
> embeds struct media_devnode, the lifetime of that object is that same than
> that of the media_device.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  drivers/media/media-device.c | 15 +++++++++++++++
>  include/media/media-device.h | 13 +++++++++++++
>  2 files changed, 28 insertions(+)
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index a31329d..496195e 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -684,6 +684,21 @@ void media_device_init(struct media_device *mdev)
>  }
>  EXPORT_SYMBOL_GPL(media_device_init);
>
> +struct media_device *media_device_alloc(struct device *dev)
> +{
> +       struct media_device *mdev;
> +
> +       mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> +       if (!mdev)
> +               return NULL;
> +
> +       mdev->dev = dev;
> +       media_device_init(mdev);
> +
> +       return mdev;
> +}
> +EXPORT_SYMBOL_GPL(media_device_alloc);
> +

One problem with this allocation is, this media device can't be shared across
drivers. For au0828 and snd-usb-audio should be able to share the
media_device. That is what the Media Allocator API patch series does.
This a quick review and I will review the patch series and get back to
you.

thanks,
-- Shuah

>  void media_device_cleanup(struct media_device *mdev)
>  {
>         ida_destroy(&mdev->entity_internal_idx);
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 96de915..c9b5798 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -207,6 +207,15 @@ static inline __must_check int media_entity_enum_init(
>  void media_device_init(struct media_device *mdev);
>
>  /**
> + * media_device_alloc() - Allocate and initialise a media device
> + *
> + * @dev:       The associated struct device pointer
> + *
> + * Allocate and initialise a media device. Returns a media device.
> + */
> +struct media_device *media_device_alloc(struct device *dev);
> +
> +/**
>   * media_device_cleanup() - Cleanups a media device element
>   *
>   * @mdev:      pointer to struct &media_device
> @@ -451,6 +460,10 @@ void __media_device_usb_init(struct media_device *mdev,
>                              const char *driver_name);
>
>  #else
> +static inline struct media_device *media_device_alloc(struct device *dev)
> +{
> +       return NULL;
> +}
>  static inline int media_device_register(struct media_device *mdev)
>  {
>         return 0;
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: BUG: Hung task timeouts in for-4.10/dio
From: Jens Axboe @ 2016-11-08 19:19 UTC (permalink / raw)
  To: Logan Gunthorpe, Christoph Hellwig; +Cc: linux-block, Stephen Bates
In-Reply-To: <c2d69ddc-28c9-bf26-5b06-74d00e88a700@deltatee.com>

On 11/08/2016 12:03 PM, Logan Gunthorpe wrote:
> Hey,
>
> I haven't check 82a78cd, but when I tried reverting the commit in
> yesterdays version there were conflicts, as a subsequent patch removed
> the defines that the specific patch operated on.

Can you try and boot for-4.10/block instead?

-- 
Jens Axboe


^ permalink raw reply

* Re: ceph rpm packaging failure -- installed but unpackaged files found
From: Jeff Layton @ 2016-11-08 19:17 UTC (permalink / raw)
  To: Ken Dreyer; +Cc: Ceph Development
In-Reply-To: <CALqRxCy4OFSWfxhwqkO=yHGtTEeFdDhpHWHrrCbis5kYX52J_A@mail.gmail.com>

Ahh ok, I didn't realize that this was new stuff. Are the gitbuilders
also failing?

Until then, is there some way to turn off support for these so
packaging can proceed? Why aren't the gitbuilders failing?

...oh, nevermind...they are:

http://gitbuilder.sepia.ceph.com/gitbuilder-ceph-rpm-centos7-amd64-basic/log.cgi?log=a38d53e1d29eefc35dd5cfb14dc0996253cdc468


On Tue, 2016-11-08 at 12:06 -0700, Ken Dreyer wrote:
> Hi Jeff,
> 
> It sounds like we need a new "python-rgw" package for RPMs/DEBs so
> these files are properly packaged.
> 
> - Ken
> 
> On Tue, Nov 8, 2016 at 12:02 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > I needed to build some rpms from a make-srpm.sh generated srpm, and hit
> > this failure during the packaging phase. Something with the rgw python
> > bindings it appears?
> > 
> > The tree here is based on a38d53e1d29eefc35dd5cfb14dc0996253cdc468,
> > with a few cephfs patches on top.
> > 
> > Here's the tail end of the rpm build log:
> > 
> > Provides: ceph-debuginfo = 1:11.0.2-1287.gbd4abb0f7496.fc24 ceph-debuginfo(x86-64) = 1:11.0.2-1287.gbd4abb0f7496.fc24
> > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> > Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/jlayton/rpmbuild/BUILDROOT/ceph-11.0.2-1287.gbd4abb0f7496.fc24.x86_64
> > error: Installed (but unpackaged) file(s) found:
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/PKG-INFO
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/SOURCES.txt
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/dependency_links.txt
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/top_level.txt
> >    /usr/lib64/python2.7/site-packages/rgw.so
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/PKG-INFO
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/SOURCES.txt
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/dependency_links.txt
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/top_level.txt
> >    /usr/lib64/python3.5/site-packages/rgw.cpython-35m-x86_64-linux-gnu.so
> > 
> > 
> > RPM build errors:
> >     Installed (but unpackaged) file(s) found:
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/PKG-INFO
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/SOURCES.txt
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/dependency_links.txt
> >    /usr/lib64/python2.7/site-packages/rgw-2.0.0-py2.7.egg-info/top_level.txt
> >    /usr/lib64/python2.7/site-packages/rgw.so
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/PKG-INFO
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/SOURCES.txt
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/dependency_links.txt
> >    /usr/lib64/python3.5/site-packages/rgw-2.0.0-py3.5.egg-info/top_level.txt
> >    /usr/lib64/python3.5/site-packages/rgw.cpython-35m-x86_64-linux-gnu.so
> > --
> > Jeff Layton <jlayton@redhat.com>
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply

* Re: Fixup set PCM/headphones volume from Master
From: David Jordan @ 2016-11-08 19:17 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: alsa-devel, Clemens Ladisch
In-Reply-To: <s5hinry9gnm.wl-tiwai@suse.de>

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

I've attached both the patch I've been working with, and the
alsa-info.txt for the hardware running an unmodified kernel.  

-- 
  David Jordan
  david2@system76.com

On Tue, Nov 8, 2016, at 06:42 AM, Takashi Iwai wrote:
> On Mon, 07 Nov 2016 22:36:21 +0100,
> David Jordan wrote:
> > 
> > It's HDA, Realtek ALC898.  The headphones jack (analog 3.5mm output)
> > (0x1b) is connected to a separate ESS DAC, which takes sound input from
> > the PCM SPDIF output.  
> 
> Note that the "Master" volume is a vmaster control, and usually it
> covers all DAC volume controls.
> 
> It'd be better if you provide a patch you're fighting with, together
> with alsa-info.sh output.  Then other people can track the issue
> either with the real h/w or hda-emu.
> 
> 
> Takashi
> 
> 
> > 
> > -- 
> >   David Jordan
> >   david2@system76.com
> > 
> > On Mon, Nov 7, 2016, at 01:19 PM, Clemens Ladisch wrote:
> > > David Jordan wrote:
> > > > I'm working on a kernel-level fixup for a set of hardware
> > > 
> > > What hardware?  If HDA, which codec, and how is it connected?
> > > 
> > > 
> > > Regards,
> > > Clemens
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: alsa-hda-alc898-pcm-hp-dac-vol-test.patch --]
[-- Type: text/x-patch; name="alsa-hda-alc898-pcm-hp-dac-vol-test.patch", Size: 11432 bytes --]

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4b6d861..4419a7e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -32,6 +32,7 @@
 #include <linux/input.h>
 #include <sound/core.h>
 #include <sound/jack.h>
+#include <sound/tlv.h>
 #include "hda_codec.h"
 #include "hda_local.h"
 #include "hda_auto_parser.h"
@@ -128,6 +129,14 @@ struct alc_spec {
 	unsigned int coef0;
 	struct input_dev *kb_dev;
 	u8 alc_mute_keycode_map[1];
+	
+	/* for clevo headphones fix */
+	unsigned int hp_volume;
+	unsigned int num_inits;
+	struct snd_kcontrol *master_kctl;
+	struct snd_kcontrol *pcm_kctl;
+	struct snd_kcontrol embedded_pcm_kctl;
+/*	struct snd_kcontrol *master_kctl;*/
 };
 
 /*
@@ -1797,6 +1806,7 @@ enum {
 	ALC882_FIXUP_NO_PRIMARY_HP,
 	ALC887_FIXUP_ASUS_BASS,
 	ALC887_FIXUP_BASS_CHMAP,
+	ALC898_FIXUP_CLEVO_SPDIF,
 };
 
 static void alc889_fixup_coef(struct hda_codec *codec,
@@ -1956,6 +1966,205 @@ static void alc882_fixup_no_primary_hp(struct hda_codec *codec,
 	}
 }
 
+
+
+
+
+/* Set PCM volume from Master.  HP volume is based on PCM volume exclusively.
+ * TODO: Trigger this function on Master Volume Change.
+ * TODO: Ensure appropriate scaling of PCM levels relative to Master.
+ */
+ 
+#define CLEVO_PCM_MAX_VOLUME 31
+
+static int snd_clevo_pcm_volume_info(struct snd_kcontrol *kcontrol,
+					 struct snd_ctl_elem_info *uinfo)
+{
+    
+	printk("SYS76: snd_clevo_pcm_volume_info\n");
+	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+	uinfo->count = 2;
+	uinfo->value.integer.min = 0;
+	uinfo->value.integer.max = CLEVO_PCM_MAX_VOLUME;
+    return 0;
+}
+
+static int snd_clevo_pcm_volume_get(struct snd_kcontrol *kcontrol,
+					 struct snd_ctl_elem_value *ucontrol)
+{
+    
+	printk("SYS76: snd_clevo_pcm_volume_get\n");
+	struct hda_codec *chip = snd_kcontrol_chip(kcontrol);
+	unsigned int idx = kcontrol->id.subdevice;
+	
+	
+	struct alc_spec *spec = chip->spec;
+	
+	printk("SYS76: pcm_volume get...addrs\n");
+	printk("addr spec %lu \n", spec);
+	printk("addr codec %lu \n", chip);
+	printk("spec->hp_volume %u\n", spec->hp_volume);
+    
+    if (spec != 0) {
+        printk("meep!\n");
+	    ucontrol->value.integer.value[0] = CLEVO_PCM_MAX_VOLUME - spec->hp_volume;//chip->playback_volume[idx][0];
+	    ucontrol->value.integer.value[1] = CLEVO_PCM_MAX_VOLUME - spec->hp_volume;//chip->playback_volume[idx][1];
+	}
+	else {
+	    printk("leep!\n");
+	    ucontrol->value.integer.value[0] = CLEVO_PCM_MAX_VOLUME - 1;//chip->playback_volume[idx][0];
+	    ucontrol->value.integer.value[1] = CLEVO_PCM_MAX_VOLUME - 1;//chip->playback_volume[idx][1];
+	}
+    return 0;
+}
+
+//Okay, so this is creating the pcm_volume_ctl, but how is hard?
+static int snd_clevo_pcm_volume_put(struct snd_kcontrol *kcontrol,
+					 struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *chip = snd_kcontrol_chip(kcontrol);
+	unsigned int idx;
+	unsigned char val;
+	int i, change = 0;
+	
+	printk("SYS76: snd_clevo_pcm_volume_put\n");
+	
+	struct alc_spec *spec = chip->spec;
+	struct snd_card *card = chip->card;
+	
+	printk(kcontrol->id.name);
+	
+	
+	/*	*/
+/*	struct snd_ctl_elem_id pcm_id;*/
+/*	struct snd_kcontrol *pcm_control;*/
+/*	memset(&pcm_id, 0, sizeof(pcm_id));*/
+/*	pcm_id.iface = SNDRV_CTL_ELEM_IFACE_MIXER;*/
+/*	pcm_id.device = 0;*/
+/*	pcm_id.index = 0;*/
+/*	strcpy(pcm_id.name, "PCM Playback Volume");*/
+/*    Crashes Here:*/
+/*	pcm_control = snd_ctl_find_id(chip->card, &pcm_id);*/
+/*	*/
+	
+	printk("SYS76: PUT snd before find mixer ctl\n");
+	
+/*	Get the PCM Control to set it.  For some reason this fails.*/
+	struct snd_kcontrol * pcm_kctl = snd_hda_find_mixer_ctl(chip, "PCM Playback Volume");
+	struct snd_ctl_elem_value *pcm_uctl;
+	
+	printk("SYS76: PUT snd_hda_find_mixer_ctl\n");
+	
+	if (!pcm_kctl)
+	    printk("SYS76: PUT no kctl\n");
+		return;
+	pcm_uctl = kzalloc(sizeof(*pcm_uctl), GFP_KERNEL);
+	if (!pcm_uctl)
+		return;
+		
+/*	Set the PCM ucontrol from Master ucontrol*/
+	val = ucontrol->value.integer.value[0];
+	val &= HDA_AMP_VOLMASK;
+	
+	pcm_uctl->value.integer.value[0] = val;
+	pcm_uctl->value.integer.value[1] = val;
+	pcm_kctl->put(pcm_kctl, pcm_uctl);
+	
+	kfree(pcm_uctl);
+	
+	return change;
+}
+
+
+static void alc898_clevo_automute_hook(struct hda_codec *codec,
+				    struct hda_jack_callback *jack)
+{
+	int val;
+	snd_hda_codec_write(codec, codec->core.afg, 0,
+			    AC_VERB_SET_GPIO_MASK, 2);
+	snd_hda_codec_write(codec, codec->core.afg, 0,
+			    AC_VERB_SET_GPIO_DIRECTION, 0);
+    
+	struct alc_spec *spec = codec->spec;
+	
+	if (snd_hda_jack_detect(codec, 0x1b) && (snd_hda_codec_read(codec, codec->core.afg, 0,
+				       AC_VERB_GET_GPIO_DATA, 0) >= 0)) {
+		val = snd_hda_codec_get_pin_target(codec, 0x1b);
+		val |= AC_PINCTL_VREF_80;
+		snd_hda_set_pin_ctl(codec, 0x1b, val);
+		snd_hda_gen_hp_automute(codec, jack);
+	} else {
+	    printk("S76: automute case B\n");
+		val = snd_hda_codec_get_pin_target(codec, 0x1b);
+		val = val & 0xfff8;
+		snd_hda_set_pin_ctl(codec, 0x1b, val);
+		snd_hda_gen_hp_automute(codec, jack);
+		
+		/* Don't mute the digital output, needed for ESS DAC operation */
+		/* TODO: This might belong in alc898_fixup_clevo instead. */
+		/* struct snd_kcontrol *kctl;
+		kctl = snd_hda_find_mixer_ctl(codec, "IEC958 Playback Switch");
+		if (!kctl)
+			return;
+		kctl->put = NULL; */
+
+	}
+}				    
+static void alc898_fixup_clevo(struct hda_codec *codec,
+				       const struct hda_fixup *fix, int action)
+{
+	struct alc_spec *spec = codec->spec;
+	
+	printk("SYS76: version 0020\n");
+	printk("SYS76: num_mixers = %u\n", spec->num_mixers);
+	if (action == HDA_FIXUP_ACT_PRE_PROBE) {
+		spec->gen.detect_hp = 1;
+		spec->gen.automute_speaker = 1;
+		spec->gen.autocfg.hp_pins[0] = 0x1b; /* copy it for automute */	
+		snd_hda_jack_detect_enable_callback(codec, 0x1b,
+						    alc898_clevo_automute_hook);
+		spec->gen.hp_automute_hook = alc898_clevo_automute_hook;
+	}
+	
+	
+	struct snd_ctl_elem_id mid;
+	memset(&mid, 0, sizeof(mid));
+	strcpy(mid.name, "PCM Playback Volume");
+	mid.iface = SNDRV_CTL_ELEM_IFACE_MIXER;
+	struct snd_kcontrol * pcm_kcontrol;
+	pcm_kcontrol = snd_ctl_find_id(codec->card, &mid);
+	if (!pcm_kcontrol) {
+	    printk("SYS76: No PCM_kcontrol\n");
+	    printk("SYS76: oh well\n");
+	    return; //returning so we don't do the master stuff until pcm exists...maybe fix kernel panic this way
+	}
+	else {
+	    spec->pcm_kctl = pcm_kcontrol;
+	    spec->embedded_pcm_kctl = *pcm_kcontrol;
+	    printk("MY PCM NUMID IS: %x", pcm_kcontrol->id.numid);
+	}
+	
+	struct snd_ctl_elem_id sid;
+	memset(&sid, 0, sizeof(sid));
+	strcpy(sid.name, "Master Playback Volume");
+	sid.iface = SNDRV_CTL_ELEM_IFACE_MIXER;
+	struct snd_kcontrol * newsid;
+	//huh, find_id and find_numid are different...look into this
+	newsid = snd_ctl_find_id(codec->card, &sid);
+	if (!newsid) {
+	    printk("SYS76: No PCM Playback Volume ctl\n");
+	    //Now try *replacing* the headphone control instead of adding another
+	    //the snd_ctl_activate function is interesting maybe?
+	    //snd_ctl_replace(codec->card, snd_ctl_new1(&snd_clevo_pcm_volume_control, codec), 0);
+	}
+	else {
+	    printk("SYS76: PCM Playback Volume ctl id is %d\n", newsid->id.numid);
+	    newsid->put = snd_clevo_pcm_volume_put;
+	    printk("SYS76: My ID hahaha!\n");
+	}
+}
+
+
 static void alc_fixup_bass_chmap(struct hda_codec *codec,
 				 const struct hda_fixup *fix, int action);
 
@@ -2195,6 +2404,10 @@ static const struct hda_fixup alc882_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc_fixup_bass_chmap,
 	},
+	[ALC898_FIXUP_CLEVO_SPDIF] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc898_fixup_clevo,
+	},
 };
 
 static const struct snd_pci_quirk alc882_fixup_tbl[] = {
@@ -2264,6 +2477,41 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
 	SND_PCI_QUIRK_VENDOR(0x1462, "MSI", ALC882_FIXUP_GPIO3),
 	SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte EP45-DS3/Z87X-UD3H", ALC889_FIXUP_FRONT_HP_NO_PRESENCE),
 	SND_PCI_QUIRK(0x147b, 0x107a, "Abit AW9D-MAX", ALC882_FIXUP_ABIT_AW9D_MAX),
+	SND_PCI_QUIRK(0x1558, 0x0872, "Clevo P870DM2/P870DM3", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x0873, "Clevo P870DM2-G/P870DM3-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x0874, "Clevo P870DM2-G/P870DM3-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x0875, "Clevo P870KM/P870KM1", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x0876, "Clevo P870KM-G/P870KM1_G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x65a1, "Clevo P65xHS_HP-D0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x65a2, "Clevo P65xHS_HP-D", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x65a3, "Clevo P65xHS_HP-G0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x65a4, "Clevo P65xHS_HP-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x67a1, "Clevo P67xHS_HP-D0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x67a2, "Clevo P67xHS_HP-D", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x67a3, "Clevo P67xHS_HP-G0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x67a4, "Clevo P67xHS_HP-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a01, "Clevo P65xRS_RP-D0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a02, "Clevo P65xRS_RP-D", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a03, "Clevo P65xRS_RP-G0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a04, "Clevo P65xRS_RP-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a05, "Clevo P65xRS_RP-V", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6a06, "Clevo P65xRS_RP-Direct", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b01, "Clevo P67xRS_RP-D0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b02, "Clevo P67xRS_RP-D", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b03, "Clevo P67xRS_RP-G0", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b04, "Clevo P67xRS_RP-G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b05, "Clevo P67xRS_RP-V", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b06, "Clevo P67xRS_RP-Direct", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7504, "Clevo P750DM2", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7505, "Clevo P750DM2G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7506, "Clevo P750KM", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7507, "Clevo P750KMG", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7705, "Clevo P775DM2", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7706, "Clevo P775DM2G", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7707, "Clevo P775KM", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7708, "Clevo P775KMG", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x7705, "System76 serw10", ALC898_FIXUP_CLEVO_SPDIF),
+	SND_PCI_QUIRK(0x1558, 0x6b01, "System76 oryp2-ess", ALC898_FIXUP_CLEVO_SPDIF),
 	SND_PCI_QUIRK_VENDOR(0x1558, "Clevo laptop", ALC882_FIXUP_EAPD),
 	SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_FIXUP_EAPD),
 	SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Y530", ALC882_FIXUP_LENOVO_Y530),
@@ -2277,6 +2525,7 @@ static const struct hda_model_fixup alc882_fixup_models[] = {
 	{.id = ALC883_FIXUP_ACER_EAPD, .name = "acer-aspire"},
 	{.id = ALC882_FIXUP_INV_DMIC, .name = "inv-dmic"},
 	{.id = ALC882_FIXUP_NO_PRIMARY_HP, .name = "no-primary-hp"},
+	{.id = ALC898_FIXUP_CLEVO_SPDIF, .name = "system76"},
 	{}
 };

[-- Attachment #3: alsa-info.txt --]
[-- Type: text/plain, Size: 48228 bytes --]

upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.64
!!################################

!!Script ran on: Tue Nov  8 18:28:09 UTC 2016


!!Linux Distribution
!!------------------

Ubuntu 16.04.1 LTS \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS" NAME="Ubuntu" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.1 LTS" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" UBUNTU_CODENAME=xenial


!!DMI Information
!!---------------

Manufacturer:       System76, Inc.
Product Name:       Oryx Pro
Product Version:    oryp2-ess
Firmware Version:  1.05.04RSA2


!!Kernel Information
!!------------------

Kernel release:    4.4.0-38-generic
Operating System:  GNU/Linux
Architecture:      x86_64
Processor:         x86_64
SMP Enabled:       Yes


!!ALSA Version
!!------------

Driver version:     k4.4.0-38-generic
Library version:    1.1.0
Utilities version:  1.1.0


!!Loaded ALSA modules
!!-------------------

snd_hda_intel
snd_hda_intel


!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes


!!Soundcards recognised by ALSA
!!-----------------------------

 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x2ffff20000 irq 127
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xdc080000 irq 17


!!PCI Soundcards installed in the system
!!--------------------------------------

00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
01:00.1 Audio device: NVIDIA Corporation Device 10f0 (rev a1)


!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

00:1f.3 0403: 8086:a170 (rev 31)
	Subsystem: 1558:6b02
--
01:00.1 0403: 10de:10f0 (rev a1)
	Subsystem: 1558:6b01


!!Modprobe options (Sound related)
!!--------------------------------

snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2
snd_usb_audio: index=-2
snd_usb_caiaq: index=-2
snd_usb_ua101: index=-2
snd_usb_us122l: index=-2
snd_usb_usx2y: index=-2
snd_cmipci: mpu_port=0x330 fm_port=0x388
snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_hda_intel: system76-audio-patch
snd_hda_intel: patch=system76-audio-patch


!!Loaded sound module options
!!---------------------------

!!Module: snd_hda_intel
	align_buffer_size : -1
	bdl_pos_adj : 1,32,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	beep_mode : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N
	enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable_msi : -1
	id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	patch : system76-audio-patch,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	power_save : 0
	power_save_controller : Y
	probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	single_cmd : N
	snoop : -1

!!Module: snd_hda_intel
	align_buffer_size : -1
	bdl_pos_adj : 1,32,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	beep_mode : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N
	enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
	enable_msi : -1
	id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	patch : system76-audio-patch,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
	position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	power_save : 0
	power_save_controller : Y
	probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
	probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
	single_cmd : N
	snoop : -1


!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Realtek ALC898
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0899
Subsystem Id: 0x15586b02
Revision Id: 0x100003
No Modem Function Group found
Default PCM:
    rates [0x5f0]: 32000 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power states:  D0 D1 D2 D3 CLKSTOP EPSS
  Power: setting=D0, actual=D0
GPIO: io=2, o=0, i=0, unsolicited=1, wake=0
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x02 [Audio Output] wcaps 0x411: Stereo
  Device: name="ALC898 Analog", type="Audio", device=0
  Converter: stream=1, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x03 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=1, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x04 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=1, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x05 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=0, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x06 [Audio Output] wcaps 0x611: Stereo Digital
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
  Device: name="ALC898 Digital", type="SPDIF", device=1
  Converter: stream=1, channel=0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x5f0]: 32000 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x07 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Control: name="Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Capture Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Device: name="ALC898 Analog", type="Audio", device=0
  Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1
  Amp-In vals:  [0xb2 0xb2]
  Converter: stream=1, channel=0
  SDI-Select: 0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x24
Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1
  Amp-In vals:  [0x97 0x97]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x23
Node 0x09 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1
  Amp-In vals:  [0x97 0x97]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x22
Node 0x0a [Audio Input] wcaps 0x100791: Stereo Digital
  Converter: stream=0, channel=0
  SDI-Select: 0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x570]: 32000 44100 48000 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x1f
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Control: name="Mic Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Mic Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Beep Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=5, ofs=0
  Control: name="Beep Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=5, ofs=0
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 10
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17
Node 0x0c [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Control: name="Line Out Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 2
     0x02 0x0b
Node 0x0d [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Control: name="Headphone Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 2
     0x03 0x0b
Node 0x0e [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Control: name="Speaker Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 2
     0x04 0x0b
Node 0x0f [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x80 0x80]
  Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
  Amp-Out vals:  [0x57 0x57]
  Connection: 2
     0x05 0x0b
Node 0x10 [Audio Output] wcaps 0x611: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x5f0]: 32000 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x11 [Pin Complex] wcaps 0x400701: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x4000d000: [N/A] Line Out at Ext N/A
    Conn = Unknown, Color = UNKNOWN
    DefAssociation = 0x0, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x10
Node 0x12 [Pin Complex] wcaps 0x400401: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x90a60150: [Fixed] Mic at Int N/A
    Conn = Digital, Color = Unknown
    DefAssociation = 0x5, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Speaker Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0001003c: IN OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c 0x0d 0x0e* 0x0f 0x26
Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000003c: IN OUT HP Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c 0x0d* 0x0e 0x0f 0x26
Node 0x16 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000003c: IN OUT HP Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c 0x0d 0x0e* 0x0f 0x26
Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Line Out Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0000003c: IN OUT HP Detect
  Pin Default 0x01011020: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x18 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000373c: IN OUT HP Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x01a11040: [Jack] Mic at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x21: IN VREF_50
  Unsolicited: tag=03, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000373c: IN OUT HP Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000373c: IN OUT HP Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0001373c: IN OUT HP EAPD Detect
    Vref caps: HIZ 50 GRD 80 100
  EAPD 0x2: EAPD
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0xc0: OUT HP VREF_HIZ
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 5
     0x0c 0x0d* 0x0e 0x0f 0x26
Node 0x1c [Pin Complex] wcaps 0x400481: Stereo
  Pincap 0x00000024: IN Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x1d [Pin Complex] wcaps 0x400400: Mono
  Pincap 0x00000020: IN
  Pin Default 0x40330829: [N/A] CD at Ext N/A
    Conn = ATAPI, Color = Unknown
    DefAssociation = 0x2, Sequence = 0x9
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x1e [Pin Complex] wcaps 0x400701: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x01441130: [Jack] SPDIF Out at Ext Rear
    Conn = RCA, Color = Black
    DefAssociation = 0x3, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x06
Node 0x1f [Pin Complex] wcaps 0x400681: Stereo Digital
  Pincap 0x00000020: IN
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
  Processing caps: benign=0, ncoeff=28
Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 11
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 11
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
Node 0x24 [Audio Selector] wcaps 0x300101: Stereo
  Connection: 12
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b 0x12*
Node 0x25 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=0, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x26 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x80 0x80]
  Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
  Amp-Out vals:  [0x57 0x57]
  Connection: 2
     0x25 0x0b
Codec: Nvidia Generic HDMI
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10de0083
Subsystem Id: 0x15586b01
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
    rates [0x0]:
    bits [0x0]:
    formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power states:  D0 D1 D2 D3 CLKSTOP EPSS
  Power: setting=D0, actual=D0
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x04 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="ELD", index=0, device=3
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=01, enabled=1
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x05 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x06 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Control: name="IEC958 Playback Con Mask", index=1, device=0
  Control: name="IEC958 Playback Pro Mask", index=1, device=0
  Control: name="IEC958 Playback Default", index=1, device=0
  Control: name="IEC958 Playback Switch", index=1, device=0
  Control: name="ELD", index=0, device=7
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=02, enabled=1
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x07 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Control: name="IEC958 Playback Con Mask", index=2, device=0
  Control: name="IEC958 Playback Pro Mask", index=2, device=0
  Control: name="IEC958 Playback Default", index=2, device=0
  Control: name="IEC958 Playback Switch", index=2, device=0
  Control: name="ELD", index=0, device=8
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x185600f0: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=03, enabled=1
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x08 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x09 [Pin Complex] wcaps 0x407381: 8-Channels Digital CP
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x585600f0: [N/A] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0xf, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Connection: 4
     0x0a* 0x0b 0x0c 0x0d
Node 0x0a [Audio Output] wcaps 0x62b1: 8-Channels Digital Stripe
  Converter: stream=5, channel=0
  Digital: Enabled
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Unsolicited: tag=00, enabled=0
Node 0x0b [Audio Output] wcaps 0x62b1: 8-Channels Digital Stripe
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Unsolicited: tag=00, enabled=0
Node 0x0c [Audio Output] wcaps 0x62b1: 8-Channels Digital Stripe
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Unsolicited: tag=00, enabled=0
Node 0x0d [Audio Output] wcaps 0x62b1: 8-Channels Digital Stripe
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  IEC Coding Type: 0x0
  PCM:
    rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000
    bits [0xe]: 16 20 24
    formats [0x5]: PCM AC3
  Unsolicited: tag=00, enabled=0
--endcollapse--


!!ALSA Device nodes
!!-----------------

crw-rw----+ 1 root audio 116,  2 Nov  8 11:26 /dev/snd/controlC0
crw-rw----+ 1 root audio 116,  7 Nov  8 11:26 /dev/snd/controlC1
crw-rw----+ 1 root audio 116,  6 Nov  8 11:26 /dev/snd/hwC0D0
crw-rw----+ 1 root audio 116, 11 Nov  8 11:26 /dev/snd/hwC1D0
crw-rw----+ 1 root audio 116,  4 Nov  8 11:26 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116,  3 Nov  8 11:26 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116,  5 Nov  8 11:26 /dev/snd/pcmC0D1p
crw-rw----+ 1 root audio 116,  8 Nov  8 11:27 /dev/snd/pcmC1D3p
crw-rw----+ 1 root audio 116,  9 Nov  8 11:26 /dev/snd/pcmC1D7p
crw-rw----+ 1 root audio 116, 10 Nov  8 11:26 /dev/snd/pcmC1D8p
crw-rw----+ 1 root audio 116,  1 Nov  8 11:26 /dev/snd/seq
crw-rw----+ 1 root audio 116, 33 Nov  8 11:26 /dev/snd/timer

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root  80 Nov  8 11:26 .
drwxr-xr-x 3 root root 300 Nov  8 11:26 ..
lrwxrwxrwx 1 root root  12 Nov  8 11:26 pci-0000:00:1f.3 -> ../controlC0
lrwxrwxrwx 1 root root  12 Nov  8 11:26 pci-0000:01:00.1 -> ../controlC1


!!Aplay/Arecord output
!!--------------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC898 Analog [ALC898 Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC898 Digital [ALC898 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC898 Analog [ALC898 Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [PCH]

Card hw:0 'PCH'/'HDA Intel PCH at 0x2ffff20000 irq 127'
  Mixer name	: 'Realtek ALC898'
  Components	: 'HDA:10ec0899,15586b02,00100003'
  Controls      : 32
  Simple ctrls  : 13
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 87
  Mono: Playback 78 [90%] [-6.75dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 87
  Mono:
  Front Left: Playback 0 [0%] [-65.25dB] [off]
  Front Right: Playback 0 [0%] [-65.25dB] [off]
Simple mixer control 'Speaker',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 87
  Mono:
  Front Left: Playback 87 [100%] [0.00dB] [on]
  Front Right: Playback 87 [100%] [0.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Line Out',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 87
  Mono:
  Front Left: Playback 87 [100%] [0.00dB] [on]
  Front Right: Playback 87 [100%] [0.00dB] [on]
Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 0 [0%] [0.00dB]
  Front Right: 0 [0%] [0.00dB]
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'IEC958 Default PCM',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Beep',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 63
  Front Left: Capture 50 [79%] [20.25dB] [off]
  Front Right: Capture 50 [79%] [20.25dB] [off]
Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Speaker Only' 'Line Out+Speaker'
  Item0: 'Line Out+Speaker'
Simple mixer control 'Loopback Mixing',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Enabled'

!!-------Mixer controls for card 1 [NVidia]

Card hw:1 'NVidia'/'HDA NVidia at 0xdc080000 irq 17'
  Mixer name	: 'Nvidia Generic HDMI'
  Components	: 'HDA:10de0083,15586b01,00100100'
  Controls      : 21
  Simple ctrls  : 3
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',1
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',2
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]


!!Alsactl output
!!--------------

--startcollapse--
state.PCH {
	control.1 {
		iface MIXER
		name 'Line Out Playback Volume'
		value.0 87
		value.1 87
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 87'
			dbmin -6525
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.2 {
		iface MIXER
		name 'Line Out Playback Switch'
		value.0 true
		value.1 true
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.3 {
		iface MIXER
		name 'Headphone Playback Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 87'
			dbmin -6525
			dbmax 0
			dbvalue.0 -6525
			dbvalue.1 -6525
		}
	}
	control.4 {
		iface MIXER
		name 'Headphone Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.5 {
		iface MIXER
		name 'Speaker Playback Volume'
		value.0 87
		value.1 87
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 87'
			dbmin -6525
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.6 {
		iface MIXER
		name 'Speaker Playback Switch'
		value.0 true
		value.1 true
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.7 {
		iface MIXER
		name 'Loopback Mixing'
		value Enabled
		comment {
			access 'read write'
			type ENUMERATED
			count 1
			item.0 Disabled
			item.1 Enabled
		}
	}
	control.8 {
		iface MIXER
		name 'Mic Playback Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 31'
			dbmin -3450
			dbmax 1200
			dbvalue.0 -3450
			dbvalue.1 -3450
		}
	}
	control.9 {
		iface MIXER
		name 'Mic Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.10 {
		iface MIXER
		name 'Auto-Mute Mode'
		value 'Line Out+Speaker'
		comment {
			access 'read write'
			type ENUMERATED
			count 1
			item.0 Disabled
			item.1 'Speaker Only'
			item.2 'Line Out+Speaker'
		}
	}
	control.11 {
		iface MIXER
		name 'Capture Volume'
		value.0 50
		value.1 50
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 63'
			dbmin -1725
			dbmax 3000
			dbvalue.0 2025
			dbvalue.1 2025
		}
	}
	control.12 {
		iface MIXER
		name 'Capture Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.13 {
		iface MIXER
		name 'Mic Boost Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 3'
			dbmin 0
			dbmax 3000
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.14 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.15 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.16 {
		iface MIXER
		name 'IEC958 Playback Default'
		value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.17 {
		iface MIXER
		name 'IEC958 Playback Switch'
		value false
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.18 {
		iface MIXER
		name 'IEC958 Default PCM Playback Switch'
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.19 {
		iface MIXER
		name 'Master Playback Volume'
		value 78
		comment {
			access 'read write'
			type INTEGER
			count 1
			range '0 - 87'
			dbmin -6525
			dbmax 0
			dbvalue.0 -675
		}
	}
	control.20 {
		iface MIXER
		name 'Master Playback Switch'
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.21 {
		iface CARD
		name 'Mic Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.22 {
		iface CARD
		name 'Internal Mic Phantom Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.23 {
		iface CARD
		name 'Line Out Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.24 {
		iface CARD
		name 'Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.25 {
		iface CARD
		name 'Speaker Phantom Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.26 {
		iface CARD
		name 'SPDIF Phantom Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.27 {
		iface MIXER
		name 'Beep Playback Volume'
		value.0 0
		value.1 0
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 31'
			dbmin -3450
			dbmax 1200
			dbvalue.0 -3450
			dbvalue.1 -3450
		}
	}
	control.28 {
		iface MIXER
		name 'Beep Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.29 {
		iface PCM
		name 'Playback Channel Map'
		value.0 3
		value.1 4
		comment {
			access read
			type INTEGER
			count 2
			range '0 - 36'
		}
	}
	control.30 {
		iface PCM
		name 'Capture Channel Map'
		value.0 3
		value.1 4
		comment {
			access read
			type INTEGER
			count 2
			range '0 - 36'
		}
	}
	control.31 {
		iface PCM
		device 1
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		comment {
			access read
			type INTEGER
			count 2
			range '0 - 36'
		}
	}
	control.32 {
		iface MIXER
		name 'PCM Playback Volume'
		value.0 255
		value.1 255
		comment {
			access 'read write user'
			type INTEGER
			count 2
			range '0 - 255'
			tlv '0000000100000008ffffec1400000014'
			dbmin -5100
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
}
state.NVidia {
	control.1 {
		iface CARD
		name 'HDMI/DP,pcm=3 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.2 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.3 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.4 {
		iface MIXER
		name 'IEC958 Playback Default'
		value '0482000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write locked'
			type IEC958
			count 1
		}
	}
	control.5 {
		iface MIXER
		name 'IEC958 Playback Switch'
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.6 {
		iface PCM
		device 3
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.7 {
		iface CARD
		name 'HDMI/DP,pcm=7 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.8 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 1
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.9 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 1
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.10 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 1
		value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.11 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 1
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.12 {
		iface PCM
		device 7
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.13 {
		iface CARD
		name 'HDMI/DP,pcm=8 Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.14 {
		iface MIXER
		name 'IEC958 Playback Con Mask'
		index 2
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.15 {
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		index 2
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access read
			type IEC958
			count 1
		}
	}
	control.16 {
		iface MIXER
		name 'IEC958 Playback Default'
		index 2
		value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
		comment {
			access 'read write'
			type IEC958
			count 1
		}
	}
	control.17 {
		iface MIXER
		name 'IEC958 Playback Switch'
		index 2
		value true
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.18 {
		iface PCM
		device 8
		name ELD
		value ''
		comment {
			access 'read volatile'
			type BYTES
			count 0
		}
	}
	control.19 {
		iface PCM
		device 3
		name 'Playback Channel Map'
		value.0 3
		value.1 4
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.20 {
		iface PCM
		device 7
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
	control.21 {
		iface PCM
		device 8
		name 'Playback Channel Map'
		value.0 0
		value.1 0
		value.2 0
		value.3 0
		value.4 0
		value.5 0
		value.6 0
		value.7 0
		comment {
			access 'read write'
			type INTEGER
			count 8
			range '0 - 36'
		}
	}
}
--endcollapse--


!!All Loaded Modules
!!------------------

Module
drbg
ansi_cprng
ctr
ccm
rfcomm
bnep
nls_iso8859_1
snd_hda_codec_hdmi
arc4
intel_rapl
x86_pkg_temp_thermal
snd_hda_codec_realtek
intel_powerclamp
snd_hda_codec_generic
coretemp
kvm_intel
kvm
i915_bpo
mxm_wmi
irqbypass
iwlmvm
crct10dif_pclmul
intel_ips
crc32_pclmul
i2c_algo_bit
mac80211
aesni_intel
aes_x86_64
lrw
gf128mul
glue_helper
ablk_helper
cryptd
uvcvideo
snd_seq_midi
snd_seq_midi_event
snd_hda_intel
videobuf2_vmalloc
videobuf2_memops
joydev
btusb
videobuf2_v4l2
snd_hda_codec
btrtl
videobuf2_core
btbcm
iwlwifi
v4l2_common
btintel
videodev
snd_hda_core
snd_rawmidi
mei_me
media
bluetooth
input_leds
snd_hwdep
cfg80211
snd_seq
rtsx_pci_ms
mei
snd_pcm
memstick
snd_seq_device
serio_raw
snd_timer
snd
soundcore
shpchp
wmi
mac_hid
acpi_pad
parport_pc
ppdev
lp
parport
autofs4
btrfs
xor
uas
usb_storage
raid6_pq
hid_generic
usbhid
hid
dm_mirror
dm_region_hash
dm_log
rtsx_pci_sdmmc
nvidia_drm
nvidia_modeset
drm_kms_helper
syscopyarea
sysfillrect
sysimgblt
fb_sys_fops
drm
psmouse
r8169
nvidia
rtsx_pci
ahci
mii
libahci
video
fjes


!!Sysfs Files
!!-----------

/sys/class/sound/hwC0D0/init_pin_configs:
0x11 0x4000d000
0x12 0x90a60150
0x14 0x90170110
0x15 0x411111f0
0x16 0x411111f0
0x17 0x01011020
0x18 0x01a11040
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x40330829
0x1e 0x01441130
0x1f 0x411111f0

/sys/class/sound/hwC0D0/driver_pin_configs:

/sys/class/sound/hwC0D0/user_pin_configs:
0x1b 0x01211030

/sys/class/sound/hwC0D0/init_verbs:

/sys/class/sound/hwC0D0/hints:

/sys/class/sound/hwC1D0/init_pin_configs:
0x04 0x185600f0
0x05 0x585600f0
0x06 0x185600f0
0x07 0x185600f0
0x08 0x585600f0
0x09 0x585600f0

/sys/class/sound/hwC1D0/driver_pin_configs:

/sys/class/sound/hwC1D0/user_pin_configs:

/sys/class/sound/hwC1D0/init_verbs:

/sys/class/sound/hwC1D0/hints:


!!ALSA/HDA dmesg
!!--------------

[    2.926733] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[    2.928935] snd_hda_intel: unknown parameter 'system76-audio-patch' ignored
[    2.930985] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    2.931071] snd_hda_intel 0000:00:1f.3: Applying patch firmware 'system76-audio-patch'
[    2.931114] snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002)
[    2.931152] snd_hda_intel 0000:01:00.1: Disabling MSI
[    2.931156] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client
[    2.931791] Bluetooth: hci0: Device revision is 5
--
[    3.008519] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[    3.010481] snd_hda_intel 0000:00:1f.3: failed to add i915_bpo component master (-19)
[    3.026340] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC898: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:line
[    3.026342] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
[    3.026344] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[    3.026345] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[    3.026345] snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x1e/0x0
[    3.026346] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[    3.026347] snd_hda_codec_realtek hdaudioC0D0:      Mic=0x18
[    3.026348] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x12
[    3.034197] intel_rapl: Found RAPL domain package
--
[    3.034203] intel_rapl: Found RAPL domain dram
[    3.035326] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input17
[    3.035374] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18
[    3.035411] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input19
[    3.120867] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
--
[    3.446425] audit: type=1400 audit(1478629606.038:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/lightdm/lightdm-guest-session//chromium" pid=747 comm="apparmor_parser"
[    3.477387] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20
[    3.477487] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input21
[    3.478591] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input22
[    3.663594] IPv6: ADDRCONF(NETDEV_UP): wlp110s0: link is not ready



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



^ permalink raw reply related

* Re: compile error for handwritten "perl-RPM2", 'RPM_GNUC_NULL_TERMINATED' error
From: Robert P. J. Day @ 2016-11-08 19:16 UTC (permalink / raw)
  To: Tim Orling; +Cc: OE Core mailing list
In-Reply-To: <CANx9H-Bfd6hKhcKhNbx8DVYBUTRPQbpxM7naw+aEW5dNc+vhKw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9049 bytes --]

On Tue, 8 Nov 2016, Tim Orling wrote:

> NOTE: by convention, OE perl recipes follow debian naming so this
> should be librpm2-perl_1.3.bb. Obviously, in your own layer you are
> free to do what you want, but it will require the name change if you
> want it to go into meta-perl.

  i had noticed the naming convention after i started writing those
recipes, it won't be hard to go back and rename. i hadn't planned
submitting anything upstream, but maybe after all that work, i might
as well, so no one else has to go through the same effort.

> For dependencies, since you are looking at CentOS rpms, you can look
> at, e.g. [0] to see the DEPENDS (BuildRequires:) and RDEPENDS
> (Requires:). This would have shown you the need for rpm-devel.

  true enough ... it didn't take long to realize i needed the rpm
devel package installed for this.

> I also use metacpan, e.g. [1], to look for dependencies in perl
> modules. It also has a very slick ElasticSearch JSON API that you
> can use to automatically query data [2].

  i'd noticed that as well ... still playing with it.

> To pass in the extra variables, for 'inherit cpan' you probably need
> to set EXTRA_CPANFLAGS [3] or for 'inherit cpan_build'
> EXTRA_CPAN_BUILD_FLAGS [4], e.g. [5].

  except i'm not sure what those variables are for ... it *appears*
they're for Perl-related settings, not simple toolchain-related
settings. i will have to read further to understand precisely what the
purpose of those variables is.

> You might want to file a documentation bug for the next release? 

  not sure what this means, i'm still trying to debug this issue
before i try to submit anything official. :-)

> [0] http://pkgs.fedoraproject.org/cgit/rpms/perl-RPM2.git/tree/perl-RPM2.spec?h=epel7
> [1] https://metacpan.org/pod/RPM2
> [2] https://github.com/metacpan/metacpan-api/blob/master/docs/API-docs.md
> [3] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cpan.bbclass#n20
> [4] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cpan_build.bbclass#n21
> [5] http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb#n37
>
> On Tue, Nov 8, 2016 at 3:17 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>         replying to my earlier post with additional info ... man, i want to
>       debug this ...
>
>       On Tue, 8 Nov 2016, Robert P. J. Day wrote:
>
>       >   following on my earlier post, here's the specific issue i'm
>       > tackling. having found no existing OE recipe equivalent to a centos
>       > "perl-RPM2" RPM, i wrote my own. here's the info about that RH RPM on
>       > my fedora system, so i know what the final result should look like:
>       >
>       >   $ rpm -ql perl-RPM2
>       >   /usr/lib64/perl5/vendor_perl/RPM2.pm
>       >   /usr/lib64/perl5/vendor_perl/auto/RPM2
>       >   /usr/lib64/perl5/vendor_perl/auto/RPM2/RPM2.so
>       >   /usr/share/doc/perl-RPM2
>       >   /usr/share/doc/perl-RPM2/Changes
>       >   /usr/share/doc/perl-RPM2/README
>       >   /usr/share/man/man3/RPM2.3pm.gz
>       >   $
>       >
>       > so, as before, track down the source at cpan:
>       >
>       >   https://metacpan.org/pod/RPM2
>       >
>       > and write a boilerplate recipe, "perl-rpm2", containing the following
>       > line since it's an older style recipe:
>       >
>       >   inherit cpan_build
>       >
>       > fetching works fine:
>       >
>       >   $ bitbake -c fetchall perl-rpm2
>       >
>       > but here's the problem:
>       >
>       >   $ bitbake perl-rpm2
>       >
>       > ... snip ...
>       >
>       > | DEBUG: Executing shell function do_compile
>       > | Copying lib/RPM2.pm -> blib/lib/RPM2.pm
>       > | lib/RPM2.xs -> lib/RPM2.c
>       > | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=7400 -mno-spe
>       > --sysroot=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc
>       > -I/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/lib/perl/5.22.1/CORE
>       > -DVERSION="1.3" -DXS_VERSION="1.3" -fPIC -DRPM2_API=5004
>       > -I/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/include/rpm
>       > -c -O2 -pipe -g -feliminate-unused-debug-types
>       >
>       -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/work/ppc7400-poky-linux/perl/5.22.1-r0=/usr/src/debug/perl/5.22.1-r0
>       > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/x86_64-linux=
>       > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc=
>       > -DDEBIAN -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
>       > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2
>       > -pipe -g -feliminate-unused-debug-types
>       >
>       -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/work/ppc7400-poky-linux/perl-rpm2/1.3-r0=/usr/src/debug/perl-rpm2/1.3-r0
>       > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/x86_64-linux=
>       > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc=
>       > -O2 -o lib/RPM2.o lib/RPM2.c
>       > | In file included from
>       > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/include/rpm/rpmcli.h:9:0,
>       > |                  from lib/RPM2.xs:3:
>       > |
>       > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/include/rpm/rpmmacro.h:
>       > In function 'rpmExpand':
>       > |
>       > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/include/rpm/rpmmacro.h:249:2:
>       > error: expected declaration specifiers before
>       > 'RPM_GNUC_NULL_TERMINATED'
>       > |   RPM_GNUC_NULL_TERMINATED
>       > |   ^~~~~~~~~~~~~~~~~~~~~~~~
>       > |
>       > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/usr/include/rpm/rpmmacro.h:260:2:
>       > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>       > 'RPM_GNUC_NULL_TERMINATED'
>       > |   RPM_GNUC_NULL_TERMINATED
>       > |   ^~~~~~~~~~~~~~~~~~~~~~~~
>       >
>       > ... big snip, lots more errors ...
>
>   ok, here's my wildly-uneducated record of what is going on:
>
>   first, unpacking and configuring perl-RPM2 source (and running XS
> processor) gives me the source file "lib/RPM2.c" (which is what is
> generating the first build error above), which includes the header
> file:
>
>   #include <rpm/rpmcli.h>
>
>   next, wander over to the qemuppc sysroot, to usr/include/rpm/, to
> check out that header file, which contains (among other things):
>
>   #include <popt.h>
>   #include <rpmmacro.h>      <----- there
>   #include <rpmtypes.h>
>   #include <rpmtag.h>
>   #include <rpmps.h>
>   #include <rpmrc.h>
>   #include <rpmfi.h>      /* XXX rpmfileAttrs */
>   #include <rpmts.h>      /* XXX rpmdepFlags *
>
>   next, in the same directory, examine rpmmacro.h, which contains:
>
>   #if defined(_MACRO_INTERNAL)
>   #include <rpmiotypes.h>
>   ... snip ...
>
>   at this point, inclusion is now conditional on _MACRO_INTERNAL, so
> move on to rpmiotypes.h, which contains:
>
>   #include <rpmutil.h>
>
> and finally visit that header file in the qemuppc sysroot to find:
>
>   #if     __GNUC__ >= 4
>   #define RPM_GNUC_NULL_TERMINATED __attribute__((__sentinel__))
>   #else
>   #define RPM_GNUC_NULL_TERMINATED
>   #endif
>
> where we find the definition of that macro.
>
>   now, is it my imagination, or could a lot of this compile-time error
> be resolved by simply defining the macro "_MACRO_INTERNAL" for the
> build? and if so, what is the proper way to add that setting to the
> compile step for this recipe?
>
>   would i use the standard EXTRA_* variables? or are there
> perl-specific variables one would use when build CPAN recipes? or am i
> totally off-track here?
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

^ permalink raw reply

* Re: [PATCH v1] ufs: introcude UFSHCD_QUIRK_GET_VS_RESULT quirk
From: Subhash Jadavani @ 2016-11-08 19:16 UTC (permalink / raw)
  To: Kiwoong Kim
  Cc: James E.J. Bottomley, linux-scsi, Martin K. Petersen,
	vinholikatti, 추헌광, linux-scsi-owner
In-Reply-To: <002001d23994$8cce5080$a66af180$@samsung.com>

On 2016-11-07 23:48, Kiwoong Kim wrote:
> Some UFS host controllers may not report a result of
> UIC command completion properly.
> In such cases, they should get the result from UIC directly
> if their architectures support that.
> 
> Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> ---
>  drivers/scsi/ufs/ufshcd.c | 27 +++++++++++++++++++++++----
>  drivers/scsi/ufs/ufshcd.h | 20 ++++++++++++++++++++
>  2 files changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index d4a5a9c..8e19631 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1011,7 +1011,10 @@ static inline bool
> ufshcd_ready_for_uic_cmd(struct ufs_hba *hba)
>   */
>  static inline u8 ufshcd_get_upmcrs(struct ufs_hba *hba)
>  {
> -	return (ufshcd_readl(hba, REG_CONTROLLER_STATUS) >> 8) & 0x7;
> +	if (hba->quirks & UFSHCD_QUIRK_GET_VS_RESULT)
> +		return (u8)ufshcd_vops_get_vs_info(hba, VS_OP_03);
> +	else
> +		return (ufshcd_readl(hba, REG_CONTROLLER_STATUS) >> 8) & 0x7;
>  }
> 
>  /**
> @@ -1038,6 +1041,17 @@ ufshcd_dispatch_uic_cmd(struct ufs_hba *hba,
> struct uic_command *uic_cmd)
>  		      REG_UIC_COMMAND);
>  }
> 
> +static inline enum vs_opcode ufshcd_get_vs_opcode(struct uic_command 
> *uic_cmd)
> +{
> +	if (uic_cmd->command == UIC_CMD_DME_LINK_STARTUP)
> +		return VS_OP_00;
> +	else if ((uic_cmd->command == UIC_CMD_DME_HIBER_ENTER))
> +		return VS_OP_01;
> +	else if ((uic_cmd->command == UIC_CMD_DME_HIBER_EXIT))
> +		return VS_OP_02;
> +	else
> +		return VS_OP_INVALID;
> +}
>  /**
>   * ufshcd_wait_for_uic_cmd - Wait complectioin of UIC command
>   * @hba: per adapter instance
> @@ -1051,11 +1065,16 @@ ufshcd_wait_for_uic_cmd(struct ufs_hba *hba,
> struct uic_command *uic_cmd)
>  {
>  	int ret;
>  	unsigned long flags;
> +	enum vs_opcode vs_op = ufshcd_get_vs_opcode(uic_cmd);

Please move this after we check the quirk below.

> 
>  	if (wait_for_completion_timeout(&uic_cmd->done,
> -					msecs_to_jiffies(UIC_CMD_TIMEOUT)))
> -		ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> -	else
> +					msecs_to_jiffies(UIC_CMD_TIMEOUT))) {
> +		if (hba->quirks & UFSHCD_QUIRK_GET_VS_RESULT &&
> +					vs_op != VS_OP_INVALID)
> +			ret = ufshcd_vops_get_vs_info(hba, vs_op);
> +		else
> +			ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> +	} else
>  		ret = -ETIMEDOUT;
> 
>  	spin_lock_irqsave(hba->host->host_lock, flags);
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 13504b4..8cf3991 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -245,6 +245,14 @@ struct ufs_pwr_mode_info {
>  	struct ufs_pa_layer_attr info;
>  };
> 
> +enum vs_opcode {
> +	VS_OP_00 = 0x00,
> +	VS_OP_01,
> +	VS_OP_02,
> +	VS_OP_03,
> +	VS_OP_INVALID = 0xFF,
> +};
> +

How do we interpret these codes? and how is this useful for non-exynos 
UFS host controller? Please make it generic which can be used by other 
controllers in future (if required).

>  /**
>   * struct ufs_hba_variant_ops - variant specific callbacks
>   * @name: variant name
> @@ -297,6 +305,7 @@ struct ufs_hba_variant_ops {
>  	int     (*resume)(struct ufs_hba *, enum ufs_pm_op);
>  	void	(*dbg_register_dump)(struct ufs_hba *hba);
>  	int	(*phy_initialization)(struct ufs_hba *);
> +	int	(*get_vs_info)(struct ufs_hba *hba, enum vs_opcode);
>  };
> 
>  /* clock gating state  */
> @@ -484,6 +493,8 @@ struct ufs_hba {
>  	 */
>  	#define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION		UFS_BIT(5)
> 
> +	#define UFSHCD_QUIRK_GET_VS_RESULT			UFS_BIT(6)

Name is weird, can we name it to reflect the actual purpose of this 
quirk? something like UFSHCD_QUIRK_BROKEN_UIC_COMPL ?

> +
>  	unsigned int quirks;	/* Deviations from standard UFSHCI spec. */
> 
>  	/* Device deviations from standard UFS device spec. */
> @@ -853,4 +864,13 @@ static inline void
> ufshcd_vops_dbg_register_dump(struct ufs_hba *hba)
>  		hba->vops->dbg_register_dump(hba);
>  }
> 
> +static inline int ufshcd_vops_get_vs_info(struct ufs_hba *hba,


You may name it as *get_uic_coml_info() ?

> +					enum vs_opcode op)
> +{
> +	if (hba->vops && hba->vops->get_vs_info)
> +		return hba->vops->get_vs_info(hba, op);
> +
> +	return -ENOTSUPP;
> +}
> +
>  #endif /* End of Header */

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock
From: Eric W. Biederman @ 2016-11-08 19:13 UTC (permalink / raw)
  To: James Bottomley
  Cc: Bart Van Assche, Martin K. Petersen, Greg Kroah-Hartman,
	Hannes Reinecke, Johannes Thumshirn, Sagi Grimberg,
	linux-scsi@vger.kernel.org
In-Reply-To: <1478628101.2824.27.camel@linux.vnet.ibm.com>

James Bottomley <jejb@linux.vnet.ibm.com> writes:

> On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
>> On 11/08/2016 07:28 AM, James Bottomley wrote:
>> > On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
>> > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
>> > > index cf4c636..44ec536 100644
>> > > --- a/fs/kernfs/dir.c
>> > > +++ b/fs/kernfs/dir.c
>> > > @@ -1410,7 +1410,7 @@ int kernfs_remove_by_name_ns(struct
>> > > kernfs_node
>> > > *parent, const char *name,
>> > >  	mutex_lock(&kernfs_mutex);
>> > > 
>> > >  	kn = kernfs_find_ns(parent, name, ns);
>> > > -	if (kn)
>> > > +	if (kn && !(kn->flags & KERNFS_SUICIDED))
>> > 
>> > Actually, wrong flag, you need KERNFS_SUICIDAL.  The reason is that
>> > kernfs_mutex is actually dropped half way through __kernfs_remove, 
>> > so KERNFS_SUICIDED is not set atomically with this mutex.
>> 
>> Hello James,
>> 
>> Sorry but what you wrote is not correct.
>
> I think you agree it is dropped.  I don't need to add the bit about the
> reacquisition because the race is mediated by the first acquisition not
> the second one, if you mediate on KERNFS_SUICIDAL, you only need to
> worry about this because the mediation is in the first acquisition.  If
> you mediate on KERNFS_SUICIDED, you need to explain that the final
> thing that means the race can't happen is the unbreak in the sysfs
> delete path re-acquiring s_active ... the explanation of what's going
> on and why gets about 2x more complex.

Is it really the dropping of the lock that is causing this?
I don't see that when I read those traces.

I am going to put my vote in for doing all of the self removal
sem-asynchronously by using task_work_add, and killing
device_remove_self, sysfs_remove_self, kernfs_remove_self.  Using
task_work_add remains synchronous with userspace so userspace should not
care, and we get the benefit of not having two different variants of the
same code racing with each other.

It might take a little more work but will leave code that is much more
maintainable in the long run.

Eric

^ permalink raw reply

* Re: [Qemu-devel] [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops
From: Alex Williamson @ 2016-11-08 19:14 UTC (permalink / raw)
  To: Kirti Wankhede
  Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
	bjsdjshi, linux-kernel
In-Reply-To: <67cd108d-0792-d2d4-29d9-7560e472e7ce@nvidia.com>

On Wed, 9 Nov 2016 00:17:53 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> On 11/8/2016 10:09 PM, Alex Williamson wrote:
> > On Tue, 8 Nov 2016 19:25:35 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >   
> ...
> 
> >>>> -
> >>>> +	int		(*pin_pages)(void *iommu_data, unsigned long *user_pfn,
> >>>> +				     int npage, int prot,
> >>>> +				     unsigned long *phys_pfn);
> >>>> +	int		(*unpin_pages)(void *iommu_data,    
> >>>
> >>> Are we changing from long to int here simply because of the absurdity
> >>> in passing in more than a 2^31 entry array, that would already consume
> >>> more than 16GB itself?
> >>>     
> >>
> >> These are on demand pin/unpin request, will that request go beyond 16GB
> >> limit? For Nvidia vGPU solution, pin request will not go beyond this limit.  
> > 
> > 16G is simply the size of the user_pfn or phys_pfn arrays at a maximal
> > int32_t npage value, the interface actually allows mapping up to 8TB
> > per call, but at that point we have 16GB of input, 16GB of output, and
> > 80GB of vfio_pfns created.  So I don't really have a problem changing
> > form long to int given lack of scalability in the API in general, but
> > it does make me second guess the API itself.  Thanks,
> >   
> 
> Changing to 'long', in future we might enhance this API without changing
> it signature.

I think the pfn arrays are more of a problem long term than whether we
can only map 2^31 pfns in one call.  I particularly dislike that the
caller provides both the iova and pfn arrays for unpinning.  Being an
in-kernel driver, we should trust it, but it makes the interface
difficult to use and seems like it indicates that our tracking data
structures aren't architected the way they should be.  Upstream, this
API will need to be flexible and change over time, it's only the
downstream distros that may lock in a kABI.  Not breaking them should
be a consideration, but also needs to be weighted against long term
upstream goals.  Thanks,

Alex

^ permalink raw reply

* Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops
From: Alex Williamson @ 2016-11-08 19:14 UTC (permalink / raw)
  To: Kirti Wankhede
  Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
	bjsdjshi, linux-kernel
In-Reply-To: <67cd108d-0792-d2d4-29d9-7560e472e7ce@nvidia.com>

On Wed, 9 Nov 2016 00:17:53 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> On 11/8/2016 10:09 PM, Alex Williamson wrote:
> > On Tue, 8 Nov 2016 19:25:35 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >   
> ...
> 
> >>>> -
> >>>> +	int		(*pin_pages)(void *iommu_data, unsigned long *user_pfn,
> >>>> +				     int npage, int prot,
> >>>> +				     unsigned long *phys_pfn);
> >>>> +	int		(*unpin_pages)(void *iommu_data,    
> >>>
> >>> Are we changing from long to int here simply because of the absurdity
> >>> in passing in more than a 2^31 entry array, that would already consume
> >>> more than 16GB itself?
> >>>     
> >>
> >> These are on demand pin/unpin request, will that request go beyond 16GB
> >> limit? For Nvidia vGPU solution, pin request will not go beyond this limit.  
> > 
> > 16G is simply the size of the user_pfn or phys_pfn arrays at a maximal
> > int32_t npage value, the interface actually allows mapping up to 8TB
> > per call, but at that point we have 16GB of input, 16GB of output, and
> > 80GB of vfio_pfns created.  So I don't really have a problem changing
> > form long to int given lack of scalability in the API in general, but
> > it does make me second guess the API itself.  Thanks,
> >   
> 
> Changing to 'long', in future we might enhance this API without changing
> it signature.

I think the pfn arrays are more of a problem long term than whether we
can only map 2^31 pfns in one call.  I particularly dislike that the
caller provides both the iova and pfn arrays for unpinning.  Being an
in-kernel driver, we should trust it, but it makes the interface
difficult to use and seems like it indicates that our tracking data
structures aren't architected the way they should be.  Upstream, this
API will need to be flexible and change over time, it's only the
downstream distros that may lock in a kABI.  Not breaking them should
be a consideration, but also needs to be weighted against long term
upstream goals.  Thanks,

Alex

^ permalink raw reply

* Re: [B.A.T.M.A.N.] i have a question ? How many relay nodes can be supported at NetworkCoding ( mtu 1546 ) .
From: Simon Wunderlich @ 2016-11-08 19:14 UTC (permalink / raw)
  To: b.a.t.m.a.n, johnzeng; +Cc: Martin Hundebøll
In-Reply-To: <mailman.63.1478602511.678.b.a.t.m.a.n@lists.open-mesh.org>

[-- Attachment #1: Type: text/plain, Size: 6733 bytes --]

On Tuesday, November 8, 2016 11:55:14 AM CET johnzeng via B.A.T.M.A.N wrote:
> Hello Dear Sven and Martin:
> 
>                                               Thanks for your advisement
> 
>                                               I hope to aviod Excavation 
> of underground pipeline in the smart community or Park .
> 
>                                               if Batman-adv can support 
> smart relay ( networking code ) at mesh network really , and it will be 
> very valuable for us .

Hi Johnzeng,

why are you insisting on using network coding? Batman-adv can do relay without 
network coding enabled, this is part of the basic mesh technology. Network 
Coding (or CATWOMAN) was research project/proof of concept implementation 
which isn't actively maintained right now. But from what I understood, your 
setups can be supported with "standard" batman-adv mesh.

Thanks,
    Simon 

> 
>                                               i think one of  core 
> valuable point is  relay mode   and   Client roaming
> 
>                                               i prepare to build more ap 
> evironment and test for the part  later
> 
> 
> 
> 
> As market competition intensifies,
> 
>                                               the gap between similar 
> productsis getting smaller and smaller,
> 
>                                               likewise the evolution of 
> growing homogenization trends within the industry.
> 
> 
> 
>                                               i hope we can find 
> valuable point for Blue Ocean each other .
> 
>                                               if you have some different 
> point , and I would be happy to be the first and build win-win mode each 
> other .
> 
> 
>                                               Best Regards
> 
>                                                Tiger
> 
> > Hi,
> > 
> >> When i compile the part , whether i need make
> >> CONFIG_BATMAN_ADV_BATMAN_V=y at batman-adv-2016.2
> > 
> > 2016.2 is "old". And BATMAN_V has nothing to do with network coding.
> > 
> >> i read some detail about NetworkCoding , my understanding :
> >> 
> >> every relay node will detects neighbors packet at promisc mode and
> >> combine these packet into a single transmission ,
> > 
> > I think Martin can help here. He also provided some documentation:
> > 
> > * https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding
> > *
> > https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding-technica
> > l *
> > https://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.p
> > df *
> > https://vbn.aau.dk/da/publications/catwoman(214ee21a-e786-495d-85c9-3efac
> > 4718ead).html *
> > https://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi
> > 
> > And it will not try to forward each packet is overheard. Instead it
> > will try to find coding opportunities which it then uses to forward
> > its own packets in less transmissions (by using packets which the
> > other nodes should already know).
> > 
> >> batctl nc 1
> >> echo 1 > /sys/class/net/bat0/mesh/network_coding
> >> ip link set dev wlan0 promisc on
> >> ip link set dev wlan0 mtu 1546
> > 
> > Your cards/drivers will most likely not even support promiscuous mode.
> > Some of them require to have an monitor mode interface at the same time
> > and
> > some of them will simply not work.
> > 
> > You can test it by simply checking what tcpdump is showing you on the
> > underlying interface (wlan0). If it doesn't show you the packets between
> > two other nodes then promiscuous mode is not working for you.
> > 
> > The feature itself is not used very often (Martin, please correct me
> > here).
> > It is not enabled by default because it is not making things "better" all
> > the time [1]. So it is also not tested as much as other components in
> > batman-adv and you should think first if it is really useful for your
> > scenario/HW. I knew at least from some Freifunk communities played around
> > when it was enabled by default but had to revert when they experienced
> > "non
> > functional mesh links" (nothing more about it is known to me - sorry
> > Martin).> 
> >> if i send a packet from host A to hostC via hostB, whether hostB will
> >> open relay mode at layer2 .
> > 
> > I completely failed to parse this.
> > 
> > batman-adv will send your data from hostA to hostC via hostB when the TQ
> > value for the link "from hostA to hostC via hostB" is higher than the TQ
> > value for the link "hostA to hostC directly". This has nothing to do with
> > network coding and is a standard feature of batman-adv (this is actually
> > what it is about).
> > 
> > network coding can only (when lucky) try to combine some packets - but
> > this will only work when promiscuous mode is actually working and the
> > nodes can overhear packets. Otherwise it will (in theory - Martin please
> > correct me if I overlooked a safety mechanism) just create a lot of coded
> > packets which cannot be decoded anymore. This seems to be especially
> > problematic when some nodes are for example 2x2 MIMO devices and others
> > are 3x3. At least this would be a good way to let the 2x2 miss important
> > packets when the 3x3 devices talk between each other.
> > 
> > I would even guess that things like dynamic transmission power would make
> > overhearing packets also more problematic.
> > 
> >> but i have a question ? How many relay nodes can be supported at
> >> NetworkCoding ( mtu 1546 ) .
> > 
> > I am not sure what you are asking here. The implementation in batman-adv
> > can combine two packets into one. And this combining of these two packets
> > is done by exact one relay node. The decoding is done by the two receiving
> > nodes. What you can build with it is been shown in the documentation from
> > Martin. The network coding used here is therefore done by a relay node and
> > its neighbors. But there can be multiple relay nodes in the mesh doing
> > network coding at the same time.
> > 
> > 
> > I personally haven't used network coding with batman-adv. But since you've
> > created multiple new threads on the mailing list [1,2,3,4] (beside the
> > private mail *grml*) - here is at least a pseudo-answer.
> > 
> > Kind regards,
> > Sven
> > 
> > [1]
> > https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding#Drawback
> > s [2]
> > https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016586.ht
> > ml [3]
> > https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016587.ht
> > ml [4]
> > https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016588.ht
> > ml [5]
> > https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016592.ht
> > ml
> End of encapsulated message


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* sip helper doesn't match on calls to myself
From: Juergen Schmidt @ 2016-11-08 19:01 UTC (permalink / raw)
  To: netfilter-devel

Hello!

I've got the following problem: If I'm calling myself, the incoming call
isn't matched by the sip helper rules, but the rules w/o sip helper. I
would have expected, that both calls are matched by the sip helper rules.


In detail:

Given is an asterisk server, one extension (C610 IP with 3 phones, which
can handle 2 lines at the same time) and a trunk to the provider.

The extension calls the own number, which provides the following scenario:

outgoing call: extension -> asterisk -> provider

   and

incoming call: provider -> asterisk -> extension


*Important*: the provider uses independent media servers. This means:
the signaling server and the media servers have different IP addresses.


The calls from asterisk to the extensions are not described here,
because there is no problem.


This means:
At the outgoing interface (ppp0) to the provider can be seen 4 legs, 2
of the outgoing call and 2 of the incoming call. The 2 legs of the
incoming call are not matched by the sip helper rules!

kernel is 	4.4.26
iptables is 	v1.4.21



iptables is configured like this:


modprobe nf_conntrack_sip sip_direct_media=0
echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper


# register sip helper
iptables -I OUTPUT -t raw -p udp -m udp -o ppp0  -d 217.0.22.0/23 -s
$IPLOCAL --dport 5060 -j CT --helper sip

iptables -I PREROUTING -t raw -p udp -m udp -i ppp0 s 217.0.22.0/23 -d
$IPLOCAL --sport 5060 -j CT --helper sip


# match packages in OUTPUT:
---------------------------
iptables -I OUTPUT -p udp -s $IPLOCAL -d 217.0.22.0/23 --sport 5060
--dport 5060 -j ACCEPT

# rtp (matched by the outgoing call)
iptables -A OUTPUT -p udp -s $IPLOCAL -d 217.0.0.0/13 --sport
30000:40000 -m conntrack --ctstate RELATED,ESTABLISHED -m helper
--helper sip -j ACCEPT

# why is this rule necessary for the incoming call when calling to self?
# matched by the incoming call
iptables -A internet-out -p udp -o ppp0 -s $IPLOCAL -d 217.0.0.0/13
--sport 30000:40000 -m conntrack --ctstate ESTABLISHED -j ACCEPT


match packages in INPUT:
------------------------
iptables -I INPUT -i ppp0 -p udp -s 217.0.22.0/23 -d $IPLOCAL --sport
5060 --dport 5060 -m conntrack --ctstate RELATED,ESTABLISHED  -j ACCEPT

# rtp (matched by the outgoing call)
iptables -A internet-in -i ppp0 -p udp -s 217.0.0.0/13 -d $IPLOCAL
--dport 30000:40000 -m conntrack --ctstate RELATED,ESTABLISHED -m helper
--helper sip -j ACCEPT

# why is this rule necessary for the incoming call?
# matched by the incoming call
iptables -A internet-in -i ppp0 -p udp -s 217.0.0.0/13 -d $IPLOCAL
--dport 30000:40000 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT




conntrack -L gives:

# Outgoing call (is matched as expected):
# rtp
udp      17 179 src=$IPLOCAL dst=217.0.4.103 sport=17188 dport=2016
src=217.0.4.103 dst=$IPLOCAL sport=2016 dport=17188 [ASSURED] mark=0 use=1
# rtcp
udp      17 175 src=$IPLOCAL dst=217.0.4.103 sport=17189 dport=2017
src=217.0.4.103 dst=$IPLOCAL sport=2017 dport=17189 [ASSURED] mark=0 use=1


# Incoming call - which is *not* matched by sip helper rules, but by the
conntrack rule without sip helper:
# rtp
udp      17 179 src=217.0.4.135 dst=$IPLOCAL sport=53254 dport=18900
src=$IPLOCAL dst=217.0.4.135 sport=18900 dport=53254 [ASSURED] mark=0 use=2
# rtcp
udp      17 175 src=217.0.4.135 dst=$IPLOCAL sport=53255 dport=18901
src=$IPLOCAL dst=217.0.4.135 sport=18901 dport=53255 [ASSURED] mark=0 use=1



I would be glad to get some hint why it behaves like this.



Thanks,
Juergen

^ permalink raw reply

* Re: [PATCH 2/4] qla2xxx: Fix mailbox command timeout due to starvation
From: Madhani, Himanshu @ 2016-11-08 17:40 UTC (permalink / raw)
  To: emilne@redhat.com
  Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	himanshu.madhani@qlogic.com
In-Reply-To: <1478534026.32271.28.camel@localhost.localdomain>

Hi Ewan,



On 11/7/16, 7:53 AM, "Ewan D. Milne" <emilne@redhat.com> wrote:

>On Fri, 2016-11-04 at 09:33 -0700, himanshu.madhani@cavium.com wrote:
>...
>> @@ -2349,6 +2349,17 @@ uint32_t qla2x00_isp_reg_stat(struct qla_hw_data *ha)
>>  	return atomic_read(&vha->loop_state) == LOOP_READY;
>>  }
>>  
>> +static void qla2x00_destroy_mbx_wq(struct qla_hw_data *ha)
>> +{
>> +	struct workqueue_struct *wq = ha->mbx_wq;
>> +
>> +	if (wq) {
>> +		ha->mbx_wq = NULL;
>> +		flush_workqueue(wq);
>> +		destroy_workqueue(wq);
>> +	}
>> +}
>> +
>>  /*
>>   * PCI driver interface
>>   */
>
>There is already a function qla2x00_destroy_deferred_work() that
>destroys 3 other workqueues.
>
>...
>
>> @@ -3059,6 +3079,8 @@ uint32_t qla2x00_isp_reg_stat(struct qla_hw_data *ha)
>>  
>>  	qla2x00_free_fw_dump(ha);
>>  
>> +	qla2x00_destroy_mbx_wq(ha);
>> +
>>  	pci_disable_pcie_error_reporting(pdev);
>>  	pci_disable_device(pdev);
>>  }
>
>This code path (pci_driver->shutdown) does not appear to destroy the
>other workqueues created by the driver. ???
>
>> @@ -5011,6 +5033,8 @@ void qla2x00_relogin(struct scsi_qla_host *vha)
>>  	 */
>>  	qla2x00_free_sysfs_attr(base_vha, false);
>>  
>> +	qla2x00_destroy_mbx_wq(ha);
>> +
>>  	fc_remove_host(base_vha->host);
>>  
>>  	scsi_remove_host(base_vha->host);
>
>See above.

Ack. will fix up patch to address these comments. 
 

>
>-Ewan

Thanks,
Himanshu

^ permalink raw reply

* Re: [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Bjorn Andersson @ 2016-11-08 19:13 UTC (permalink / raw)
  To: Srinivas Kandagatla
  Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
	linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1478622577-20699-2-git-send-email-srinivas.kandagatla@linaro.org>

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:

> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 1dbe697..fde006c 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -627,6 +627,34 @@
>  			clock-names = "core";
>  		};
>  
> +		qcom,ssbi@c00000 {

No "qcom," in the node name.

> +			compatible = "qcom,ssbi";
> +			reg = <0x00c00000 0x1000>;
> +			qcom,controller-type = "pmic-arbiter";
> +
> +			pmicintc2: pmic@1 {

I think we should follow Linus' lead and label this "pm8821".

> +				compatible = "qcom,pm8821";
> +				interrupt-parent = <&tlmm_pinmux>;
> +				interrupts = <76 8>;

Please spell out IRQ_TYPE_LEVEL_LOW.

And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
the two lines nicely.

> +				#interrupt-cells = <2>;
> +				interrupt-controller;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				pm8821_mpps: mpps@50 {
> +

Extra newline.

> +					compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
> +					reg = <0x50>;
> +
> +					interrupts = <24 1>, <25 1>, <26 1>,
> +						     <27 1>;

I think these should be IRQ_TYPE_NONE per the discussion on how to share
interrupts between the gpio/mpp driver and other clients.

On the other hand, per the pm8821 driver we only support LEVEL_LOW
(high?).

> +
> +					gpio-controller;
> +					#gpio-cells = <2>;
> +		                };
> +			};
> +		};
> +

Regards,
Bjorn

^ permalink raw reply

* [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Bjorn Andersson @ 2016-11-08 19:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478622577-20699-2-git-send-email-srinivas.kandagatla@linaro.org>

On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:

> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 1dbe697..fde006c 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -627,6 +627,34 @@
>  			clock-names = "core";
>  		};
>  
> +		qcom,ssbi at c00000 {

No "qcom," in the node name.

> +			compatible = "qcom,ssbi";
> +			reg = <0x00c00000 0x1000>;
> +			qcom,controller-type = "pmic-arbiter";
> +
> +			pmicintc2: pmic at 1 {

I think we should follow Linus' lead and label this "pm8821".

> +				compatible = "qcom,pm8821";
> +				interrupt-parent = <&tlmm_pinmux>;
> +				interrupts = <76 8>;

Please spell out IRQ_TYPE_LEVEL_LOW.

And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
the two lines nicely.

> +				#interrupt-cells = <2>;
> +				interrupt-controller;
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				pm8821_mpps: mpps at 50 {
> +

Extra newline.

> +					compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
> +					reg = <0x50>;
> +
> +					interrupts = <24 1>, <25 1>, <26 1>,
> +						     <27 1>;

I think these should be IRQ_TYPE_NONE per the discussion on how to share
interrupts between the gpio/mpp driver and other clients.

On the other hand, per the pm8821 driver we only support LEVEL_LOW
(high?).

> +
> +					gpio-controller;
> +					#gpio-cells = <2>;
> +		                };
> +			};
> +		};
> +

Regards,
Bjorn

^ permalink raw reply

* Re: [PATCH 3/4] qla2xxx: Add Block Multi Queue functionality.
From: Madhani, Himanshu @ 2016-11-08 17:37 UTC (permalink / raw)
  To: emilne@redhat.com
  Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	himanshu.madhani@qlogic.com
In-Reply-To: <1478537008.32271.43.camel@localhost.localdomain>

Hi Ewan,



On 11/7/16, 8:43 AM, "Ewan D. Milne" <emilne@redhat.com> wrote:

>On Fri, 2016-11-04 at 09:33 -0700, himanshu.madhani@cavium.com wrote:
>> From: Michael Hernandez <michael.hernandez@cavium.com>
>> 
>> Tell the SCSI layer how many hardware queues we have based on the
>> number of max queue pairs created. The number of max queue pairs
>> created will depend on number of MSI X vector count or number of CPU's
>> in a system.
>> 
>> This feature can be turned on via CONFIG_SCSI_MQ_DEFAULT or passing
>> scsi_mod.use_blk_mq=Y as a parameter to the kernel
>> Queue pair creation depend on module parameter "ql2xmqsupport", which
>> need to be enabled to create queue pair.
>> 
>
>I don't understand this change at all.  Setting ->nr_hw_queues causes
>the block layer to allocate a number of queues for that Scsi_Host
>object, but it does not appear as if this code uses that functionality.
>There is nothing in the patch that examines the tag to see which queue
>the request came in on, in order to map it to a hardware queue.
>
>Instead, this patch seems to be reworking the mechanism involved in
>NPIV vport creation, which creates an entirely separate Scsi_Host
>object.  The driver was already creating separate request queues to
>the card for vports, so what does this have to do with Block-MQ?

Thanks for the review comments. We are reworking patch series to address 
your review comments. 

>
>-Ewan
> 
>

Thanks,
Himanshu

^ permalink raw reply

* Re: [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support
From: Thomas Gleixner @ 2016-11-08 19:06 UTC (permalink / raw)
  To: Kyle Huey
  Cc: Robert O'Callahan, Andy Lutomirski, Ingo Molnar,
	H. Peter Anvin, x86, Paolo Bonzini, Radim Krčmář,
	Jeff Dike, Richard Weinberger, Alexander Viro, Shuah Khan,
	Dave Hansen, Borislav Petkov, Peter Zijlstra, Boris Ostrovsky,
	Len Brown, Rafael J. Wysocki, Dmitry Safonov, David Matlack,
	linux-kernel
In-Reply-To: <20161108183956.4521-6-khuey@kylehuey.com>

On Tue, 8 Nov 2016, Kyle Huey wrote:

> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. This will allow a ptracer to emulate the CPUID
> instruction.
> 
> Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
> documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf

Can you please stick that document into the kernel bugzilla, as it's going
to be on a different place before this gets merged into Linus tree?

See: http://lkml.kernel.org/r/1478631281-5061-1-git-send-email-kan.liang@intel.com

> +	static const struct msr_bit msr_bits[] = {
> +		{ X86_FEATURE_CPUID_FAULT,	MSR_PLATFORM_INFO, 31 },

Can you please make that PLATINFO_CPUID_FAULT_BIT instead of 31?

Thanks,

	tglx

^ permalink raw reply

* FAILED: patch "[PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready" failed to apply to 4.8-stable tree
From: gregkh @ 2016-11-08 19:10 UTC (permalink / raw)
  To: stefan, leoyang.li, u.kleine-koenig, wsa; +Cc: stable


The patch below does not apply to the 4.8-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 533169d164c6b4c8571d0d48779f6ff6be593d72 Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan@agner.ch>
Date: Mon, 26 Sep 2016 17:18:58 -0700
Subject: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some SoC might load the GPIO driver after the I2C driver and
using the I2C bus recovery mechanism via GPIOs. In this case
it is crucial to defer probing if the GPIO request functions
do so, otherwise the I2C driver gets loaded without recovery
mechanisms enabled.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 592a8f26a708..47fc1f1acff7 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 	rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", 0);
 	rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", 0);
 
-	if (!gpio_is_valid(rinfo->sda_gpio) ||
-	    !gpio_is_valid(rinfo->scl_gpio) ||
-	    IS_ERR(i2c_imx->pinctrl_pins_default) ||
-	    IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
+	if (rinfo->sda_gpio == -EPROBE_DEFER ||
+	    rinfo->scl_gpio == -EPROBE_DEFER) {
+		return -EPROBE_DEFER;
+	} else if (!gpio_is_valid(rinfo->sda_gpio) ||
+		   !gpio_is_valid(rinfo->scl_gpio) ||
+		   IS_ERR(i2c_imx->pinctrl_pins_default) ||
+		   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
 		dev_dbg(&pdev->dev, "recovery information incomplete\n");
 		return 0;
 	}


^ permalink raw reply related

* Summary of LPC guest MSI discussion in Santa Fe
From: Will Deacon @ 2016-11-08 19:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5822214F.2070500@redhat.com>

On Tue, Nov 08, 2016 at 02:02:39PM -0500, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
> >A first step would be making all this opt-in, and only supporting GICv3
> >ITS for now.
> You're trying to support a config that is < GICv3 and no ITS ? ...
> That would be the equiv. of x86 pre-intr-remap, and that's why allow_unsafe_interrupts
> hook was created ... to enable devel/kick-the-tires.

Yup, that's exactly what I was envisaging. For systems that can't do
passthrough safely, we'll always have to throw a devel switch.

Will

^ permalink raw reply

* Re: Summary of LPC guest MSI discussion in Santa Fe
From: Will Deacon @ 2016-11-08 19:10 UTC (permalink / raw)
  To: Don Dutile
  Cc: Auger Eric, Alex Williamson, drjones, jason, kvm, marc.zyngier,
	benh, joro, punit.agrawal, linux-kernel, arnd, diana.craciun,
	iommu, pranav.sawargaonkar, linux-arm-kernel, jcm, tglx,
	robin.murphy, dwmw, christoffer.dall, eric.auger.pro
In-Reply-To: <5822214F.2070500@redhat.com>

On Tue, Nov 08, 2016 at 02:02:39PM -0500, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
> >A first step would be making all this opt-in, and only supporting GICv3
> >ITS for now.
> You're trying to support a config that is < GICv3 and no ITS ? ...
> That would be the equiv. of x86 pre-intr-remap, and that's why allow_unsafe_interrupts
> hook was created ... to enable devel/kick-the-tires.

Yup, that's exactly what I was envisaging. For systems that can't do
passthrough safely, we'll always have to throw a devel switch.

Will

^ permalink raw reply

* Re: [RFC v3 1/6] Track the active utilisation
From: Luca Abeni @ 2016-11-08 19:09 UTC (permalink / raw)
  To: Juri Lelli
  Cc: linux-kernel, Peter Zijlstra, Ingo Molnar, Claudio Scordino,
	Steven Rostedt
In-Reply-To: <20161108185309.GG16920@e106622-lin>

Hi again,

On Tue, 8 Nov 2016 18:53:09 +0000
Juri Lelli <juri.lelli@arm.com> wrote:
[...]
> > > Also, AFAIU, do_exit() works on current and the TASK_DEAD case is
> > > handled in finish_task_switch(), so I don't think we are taking
> > > care of the "task is dying" condition.
> > Ok, so I am missing something... The state is set to TASK_DEAD, and
> > then schedule() is called... So, __schedule() sees the dying task as
> > "prev" and invokes deactivate_task() with the DEQUEUE_SLEEP flag...
> > After that, finish_task_switch() calls task_dead_dl(). Is this
> > wrong? If not, why aren't we taking care of the "task is dying"
> > condition?
> > 
> 
> No, I think you are right. But, semantically this cleanup goes in
> task_dead_dl(), IMHO.
Just to be sure I understand correctly: you suggest to add a check for
"state == TASK_DEAD" (skipping the cleanup if the condition is true) in
dequeue_task_dl(), and to add a sub_running_bw() in task_dead_dl()...
Is this understanding correct?

> It's most probably moot if it complicates
> things, but it might be helpful to differentiate the case between a
> task that is actually going to sleep (and for which we want to
> activate the timer) and a task that is dying (and for which we want
> to release bw immediately).
I suspect the two cases should be handled in the same way :)

> So, it actually matters for next patch,
> not here. But, maybe we want to do things clean from start?
You mean, because patch 2/6 adds
+       if (hrtimer_active(&p->dl.inactive_timer)) {
+               raw_spin_lock_irq(&task_rq(p)->lock);
+               sub_running_bw(&p->dl, dl_rq_of_se(&p->dl));
+               raw_spin_unlock_irq(&task_rq(p)->lock);
+       }
in task_dead_dl()? I suspect this hunk is actually unneeded (worse, it
is wrong :). I am trying to remember why it is there, but I cannot find
any reason... In the next days, I'll run some tests to check if that
hunk is actually needed. If yes, then I'll modify patch 1/6 as you
suggest; if it is not needed, I'll remove it from patch 2/6 and I'll
not do this change to patch 1/6... Is this ok?



			Thanks,
				Luca


> 
> > 
> > > Peter, does what I'm saying make any sense? :)
> > > 
> > > I still have to set up things here to test these patches (sorry,
> > > I was travelling), but could you try to create some tasks and
> > > that kill them from another shell to see if the accounting
> > > deviates or not? Or did you already do this test?
> > I think this is one of the tests I tried... 
> > I have to check if I changed this code after the test (but I do not
> > think I did). Anyway, tomorrow I'll write a script for automating
> > this test, and I'll leave it running for some hours.
> > 
> 
> OK, thanks. As said I think that you actually handle the case already,
> but I'll try to setup testing as well soon.
> 
> Thanks,
> 
> - Juri

^ permalink raw reply

* [Intel-wired-lan] [PATCH v2] ixgbevf: handle race between close and suspend on shutdown
From: Singh, Krishneil K @ 2016-11-08 19:09 UTC (permalink / raw)
  To: intel-wired-lan
In-Reply-To: <EF50CC0C76A53A44BAD798C58E0A157E42E43983@ORSMSX103.amr.corp.intel.com>


-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Singh, Krishneil K
Sent: Wednesday, November 2, 2016 4:38 PM
To: Tantilov, Emil S <emil.s.tantilov@intel.com>; intel-wired-lan at lists.osuosl.org
Subject: Re: [Intel-wired-lan] [PATCH v2] ixgbevf: handle race between close and suspend on shutdown


-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On Behalf Of Emil Tantilov
Sent: Tuesday, November 1, 2016 1:11 PM
To: intel-wired-lan@lists.osuosl.org
Subject: [Intel-wired-lan] [PATCH v2] ixgbevf: handle race between close and suspend on shutdown

When an interface is part of a namespace it is possible that
ixgbevf_close() may be called while ixgbevf_suspend() is running which ends up in a double free WARN and/or a BUG in free_msi_irqs()

To handle this situation we extend the rtnl_lock() to protect the call to netif_device_detach() and check for !netif_device_present() to avoid entering close while in suspend.

Also added rtnl locks to ixgbevf_queue_reset_subtask().

-v2 handle the race with netif_device_detach/present() and rtnl locks as suggested by Alex Duyck

CC: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
---

^ 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.