- 05 Nov, 2017 6 commits
-
-
Kuppuswamy Sathyanarayanan authored
For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not mandatory. So when PMC IPC driver creates a PUNIT device, if these resources are not available then it creates dummy resource entries for these missing resources. But during PUNIT device probe, doing ioremap on these dummy resources generates following warning messages. intel_punit_ipc: can't request region for resource [mem 0x00000000] intel_punit_ipc: can't request region for resource [mem 0x00000000] intel_punit_ipc: can't request region for resource [mem 0x00000000] intel_punit_ipc: can't request region for resource [mem 0x00000000] This patch fixes this issue by adding extra check for resource size before performing ioremap operation. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Colin Ian King authored
Variable byte_data is being initialized and re-assigned with values that are never read. Remove these as these redundant assignments. Cleans up clang warning: drivers/platform/x86/dell-smo8800.c:106:2: warning: Value stored to 'byte_data' is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Stefan Brüns authored
Commit f9cf3b28 ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers") consolidated the methods for docking and laptop mode detection, but omitted to apply the correct mask for the laptop mode (it always uses the constant for docking). Fixes: f9cf3b28 ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers") Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Kees Cook authored
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Moves timer structure off stack and into struct ips_driver. Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org> Cc: platform-driver-x86@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Markus Elfring authored
The local variable "err" will eventually be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Markus Elfring authored
Source code review for a specific software refactoring showed the need for another correction because the error code "-1" was returned so far if a call of the function "sony_call_snc_handle" failed here. Thus assign the return value from these two function calls also to the variable "err" and provide it in case of a failure. Fixes: d6f15ed8 ("sony-laptop: use soft rfkill status stored in hw") Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lkml.org/lkml/2017/10/31/463 Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg@mail.gmail.com> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 03 Nov, 2017 22 commits
-
-
Mario Limonciello authored
This application uses the character device /dev/wmi/dell-smbios to perform SMBIOS communications from userspace. It offers demonstrations of a few simple tasks: - Running a class/select command - Querying a token value - Activating a token Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI calling interface buffer between userspace and kernel space. This character device is intended to deprecate the dcdbas kernel module and the interface that it provides to userspace. To perform an SMBIOS IOCTL call using the character device userspace will perform a read() on the the character device. The WMI bus will provide a u64 variable containing the necessary size of the IOCTL buffer. The API for interacting with this interface is defined in documentation as well as the WMI uapi header provides the format of the structures. Not all userspace requests will be accepted. The dell-smbios filtering functionality will be used to prevent access to certain tokens and calls. All whitelisted commands and tokens are now shared out to userspace so applications don't need to define them in their own headers. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
For WMI operations that are only Set or Query readable and writable sysfs attributes created by WMI vendor drivers or the bus driver makes sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method call. Sysfs attributes don't work well in this scenario because two userspace processes may be competing at reading/writing an attribute and step on each other's data. When a WMI vendor driver declares a callback method in the wmi_driver the WMI bus driver will create a character device that maps to that function. This callback method will be responsible for filtering invalid requests and performing the actual call. That character device will correspond to this path: /dev/wmi/$driver Performing read() on this character device will provide the size of the buffer that the character device needs to perform calls. This buffer size can be set by vendor drivers through a new symbol or when MOF parsing is available by the MOF. Performing ioctl() on this character device will be interpretd by the WMI bus driver. It will perform sanity tests for size of data, test them for a valid instance, copy the data from userspace and pass iton to the vendor driver to further process and run. This creates an implicit policy that each driver will only be allowed a single character device. If a module matches multiple GUID's, the wmi_devices will need to be all handled by the same wmi_driver. The WMI vendor drivers will be responsible for managing inappropriate access to this character device and proper locking on data used by it. When a WMI vendor driver is unloaded the WMI bus driver will clean up the character device and any memory allocated for the call. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
When a userspace interface is introduced to dell-smbios filtering support will be used to make sure that userspace doesn't make calls deemed unsafe or that can cause the kernel drivers to get out of sync. A blacklist is provided for the following: - Items that are in use by other kernel drivers - Items that are deemed unsafe (diagnostics, write-once, etc) - Any items in the blacklist will be rejected. Following that a whitelist is provided as follows: - Each item has an associated capability. If a userspace interface accesses this item, that capability will be tested to filter the request. - If the process provides CAP_SYS_RAWIO the whitelist will be overridden. When an item is not in the blacklist, or whitelist and the process is run with insufficient capabilities the call will be rejected. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to operate over WMI-ACPI will use an ACPI OperationRegion for a buffer of data storage when SMM calls are performed. This is a safer approach to use in kernel drivers as the SMM will only have access to that OperationRegion. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a single global buffer being allocated for all drivers, each driver will allocate and be responsible for it's own buffer. The pointer will be passed to the calling function and each dispatcher driver will then internally copy it to the proper location to perform it's call. Add defines for calls used by these methods in the dell-smbios.h header for tracking purposes. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is intentionally marked to only be readable as a process with CAP_SYS_ADMIN as it can contain sensitive information about the platform's configuration. While adding this interface I found that some tokens are duplicated. These need to be ignored from sysfs to avoid duplicate files. MAINTAINERS was missing for this driver. Add myself and Pali to maintainers list for it. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
This is intended to be variable and provided by the platform. Some platforms this year will be adopting a 32k WMI buffer, so don't complain when encountering those platforms or any other future changes. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the data should not be relied upon. For the remaining data set vectors, continue to notate a warning in undefined results, but as those are fields that the descriptor intended to refer to other applications, don't fail if they're new values. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Mario Limonciello authored
Later on these structures will be brought up to userspace. the word "class" is a reserved word in c++ and this will prevent uapi headers from being included directly in c++ programs. To make life easier on these applications, prepare the change now. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
Hans de Goede authored
The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id rather then just "fusb302" and needs us to set a number of device- properties, adjust the intel_cht_int33fe driver accordingly. One of the properties set is max-snk-mv which makes the fusb302 driver negotiate up to 12V charging voltage, which is a bad idea on boards which are not setup to handle this, so this commit also adds 2 extra sanity checks to make sure that the expected Whiskey Cove PMIC + TI bq24292i charger combo, which can handle 12V, is present. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
Merge branch 'i2c/cht-wc-fusb302-immutable' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c/cht-wc-fusb302-immutable immutable branch from Wolfram Sang: as discussed before, here is the immutable branch for the i2c-cht-wc driver, so you can safely apply Hans' patch [1] "platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties" on top of this. [1] http://patchwork.ozlabs.org/patch/824314/
-
Sergey Tshovrebov authored
Add touchscreen platform data for the Digma e200 tablet. Signed-off-by: Sergey Tshovrebov <sinxwal@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Hans de Goede authored
The GP-electronic T701 has its LCD panel mounted upside-down, initially my plan was to fix this by transparently rotating the image in the i915 driver (my "drm/i915: Deal with upside-down mounted LCD" patch), but that approach has been rejected instead the kernel will now export a "panel orientation" property on the drm-connector for the panel and let userspace deal with it. But userspace expects the touchscreen coordinates to match the panel coordinates *before* applying any rotation, so now that we no longer hide the upside-down-ness of the LCD panel from userspace the coordinates being generated are wrong and we need to apply a rotation of 180 degrees to the coordinates to fix this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Hans de Goede authored
peaq_wmi_exit will only ever get called if peaq_wmi_init succeeds, so there is no need to repeat the checks from peaq_wmi_init. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Hans de Goede authored
Add missing terminating entry to peaq_dmi_table. Fixes: 3b952061 ("platform/x86: peaq-wmi: Add DMI check before ...") Cc: stable@vger.kernel.org Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 31 Oct, 2017 1 commit
-
-
Philipp Hug authored
The Lenovo Yoga 920-13IKB does not have a hw rfkill switch, and trying to read the hw rfkill switch through the ideapad module causes it to always report as blocked. This commit adds the Lenovo Yoga 920-13IKB to the no_hw_rfkill dmi list, fixing the WiFI breakage. Signed-off-by: Philipp Hug <philipp@hug.cx> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
-
- 30 Oct, 2017 1 commit
-
-
Michał Kępień authored
Radio LED detection method implemented in commit 4f62568c ("fujitsu-laptop: Support radio LED") turned out to be incorrect as it causes a radio LED to be erroneously detected on a Fujitsu Lifebook E751 which has a slide switch (and thus no radio LED). Use bit 17 of flags_supported (the value returned by method S000 of ACPI device FUJ02E3) to determine whether a radio LED is present as it seems to be a more reliable indicator, based on comparing DSDT tables of four Fujitsu Lifebook models (E744, E751, S7110, S8420). Fixes: 4f62568c ("fujitsu-laptop: Support radio LED") Reported-by: Heinrich Siebmanns <harv@gmx.de> Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Heinrich Siebmanns <harv@gmx.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 27 Oct, 2017 6 commits
-
-
Osama Khan authored
Added support for HP ProBook 440 G4 laptops by including the accelerometer orientation quirk for that device. Testing was performed based on the axis orientation guidelines here: https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d which states "If the left side is elevated, X increases (becomes positive)". When tested, on lifting the left edge, x values became increasingly negative thus indicating an inverted x-axis on the installed lis3lv02d chip. This was compensated by adding an entry for this device in hp_accel.c specifying the quirk as x_inverted. The patch was tested on a ProBook 440 G4 device and x-axis as well as y and z-axis values are now generated as per spec. Signed-off-by: Osama Khan <osama.khan@ericsson.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Srinivas Pandruvada authored
Ev Kontsevoy reported that he can't see the presence of "/proc/sys/kernel/sched_itmt_enabled" on i9-7900x with Asrock x299 Taichi system even if he enabled "Turbo 3.0" in the BIOS. The problem is that even if one core max is 200MHz more than others, the current implementation couldn't enumerate that with the way the system is configured. The system by default configured for legacy mode (no HWP or speed shift technology), in this mode only way we can enumerate via the mail box interface as implemented in this driver. We were planing to only use this driver for Broadwell, but we need to extend this because some Skylake system has same issue as Braodwell systems. On this system BIOS allows to change to HWP mode, where we expect that we can enumerate favored core with ACPI-CPPC. But on this system the core priority is 0xff for all cores in CPPC object. So this is not an option. Hence this change allows Skylake systems to be enumerate favored core similar to Broadwell in legacy mode. Reported-and-tested-by: Ev Kontsevoy <ev@kontsevoy.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
'default n' is a default behaviour of Kconfig options. So, remove explicit line from Kconfig. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Andy Shevchenko authored
linux/io.h defines readq() and ioremap_nocache() / iounmap() functions. If not included, the build fails: intel_telemetry_pltdrv.c:1165:31: warning: assignment makes pointer from integer without a cast [-Wint-conversion] intel_telemetry_pltdrv.c:1165:33: error: implicit declaration of function 'ioremap_nocache' [-Werror=implicit-function-declaration] intel_telemetry_pltdrv.c:1202:3: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] intel_telemetry_pltdrv.c:900:20: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] Fix this by including linux/io.h. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Hans de Goede authored
Add device-properties to make the bq24292i charger connected to the bus get its input-current-limit from the fusb302 Type-C port controller which is used on boards with the cht-wc PMIC, as well as regulator_init_data for the 5V boost converter on the bq24292i. Since this means we now hook-up the bq24292i to the fusb302 Type-C port controller add a check for the ACPI device which instantiates the fusb302. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Hans de Goede authored
For devices not instantiated through ACPI the i2c-client's device-name gets set to <busnr>-<addr> by default, e.g. "0-0022" this means that the device-name is dependent on the order in which the i2c-busses are enumerated. In some cases having a predictable constant device-name is desirable, for example on non device-tree platforms the link between a regulator and its consumers is specified by the platform code by setting regulator_init_data.consumers. This array identifies the regulator's consumers by dev_name and supply(-name). Which requires a constant dev_name. This commit adds a dev_name field to i2c_board_info allowing platform code to set a contstant dev_name so that the device can be identified by its dev_name in other platform code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> (live at ELCE17) Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (live at ELCE17) Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
- 23 Oct, 2017 4 commits
-
-
Kuppuswamy Sathyanarayanan authored
Currently, update_no_reboot_bit() function implemented in this driver uses mutex_lock() to protect its register updates. But this function is called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop() functions in iTCO_wdt.c driver, which in turn causes "sleeping into atomic context" issue. This patch fixes this issue by replacing the mutex_lock() with spin_lock() to protect the GCR read/write/update APIs. Fixes: 9d855d46 ("platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure") Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kupuswamy@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Rajneesh Bhardwaj authored
Removes unnecessary header files included in the driver and sorts the remaining ones in the alphabetical order. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Rajneesh Bhardwaj authored
Telemetry word is misspelled several times in this file as Telemtry. This fixes the spelling mistake and folds in another minor typo. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Rajneesh Bhardwaj authored
Intel Telemetry driver depends on IPC1 interface. If IPC1 interface is disabled on a given platform by the system firmware, the driver does not load but prints misleading information in the dmesg logs. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-