| Age | Commit message (Collapse) | Author |
|---|
|
Add support for firmware filenames that include the CRC32 checksum of the
DMI product_family field. Several OEMs ship ISH firmware variants shared
across a product family while product_name or product_sku may differ. This
intermediate matching granularity reduces duplication and improves firmware
selection for vendor-customized platforms.
The newly supported filename forms are checked before existing patterns:
ish_${gen}_${vendor}_${family}_${name}_${sku}.bin
ish_${gen}_${vendor}_${family}_${sku}.bin
ish_${gen}_${vendor}_${family}_${name}.bin
ish_${gen}_${vendor}_${family}.bin
The legacy product_name/product_sku rules remain unchanged and continue
to provide fallback matching.
ISH_FW_FILENAME_LEN_MAX is changed to 72 to accommodate the product_family.
Tested with X9 series and X1 series.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Richie Roy Jayme <rjayme.jp@gmail.com>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Introduce sysfs attributes to the intel-ish-ipc driver to expose the base
and project firmware versions for ISH devices that load firmware from the
host.
The build tool embeds these versions into the ISH global manifest within
the firmware binary during the firmware build process. The driver, upon
loading the firmware, extracts this version information from the manifest
and makes it accessible via sysfs. The base version corresponds to the
firmware version provided in Intel's Firmware Development Kit (FDK), while
the project version reflects the vendor-customized firmware derived from
the FDK.
These attributes provide userspace tools and applications with the
ability to easily query the firmware versions, which is essential for
firmware validation and troubleshooting.
Example usages:
$ cat /sys/devices/pci0000\:00/0000\:00\:12.0/firmware/base_version
5.8.0.7716
$ cat /sys/devices/pci0000\:00/0000\:00\:12.0/firmware/project_version
5.8.0.12472
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Enhance the firmware loader to support the loading of vendor-specific
customized firmware for the Intel Integrated Sensor Hub (ISH). The
loader now constructs firmware file names based on the DMI_SYS_VENDOR,
DMI_PRODUCT_NAME, and DMI_PRODUCT_SKU information in Desktop Management
Interface (DMI). The loader will attempt to load the firmware files
following a specific naming convention in sequence. If successful, it
will skip the remaining files.
For more details, please refer to Documentation/hid/intel-ish-hid.rst.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
ISH allows vendors to customize ISH firmware. To differentiate different
vendors and load the correct firmware, Intel defined a firmware file
name format. As part of the filename, there is a "generation" string. To
load correct format the driver must know the generation name to create
file name.
In the absence of any vendor specific firmware, default ISH firmware is
loaded.
Currently full ISH firmware file name is stored as part of driver data.
This file name already includes the generation name. For example, for
Lunar Lake, the name is ish_lnlm.bin, where "lnlm" is the generation.
So instead of storing both generation name and ISH default firmware file
name, just store generation name and create the default ISH firmware
file name string during initialization.
No functional changes are expected.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The newly added file causes a ton of sparse warnings about the
incorrect use of __le32 and similar types:
drivers/hid/intel-ish-hid/ishtp/loader.h:41:23: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:42:27: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:43:24: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:44:24: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:45:22: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.c:172:33: warning: restricted __le32 degrades to integer
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50: warning: incorrect type in assignment (different base types)
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50: expected restricted __le32 [usertype] length
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50: got unsigned long
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50: warning: incorrect type in assignment (different base types)
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50: expected restricted __le32 [usertype] fw_off
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50: got unsigned int [usertype] offset
drivers/hid/intel-ish-hid/ishtp/loader.c:180:17: warning: cast from restricted __le32
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24: warning: invalid assignment: +=
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24: left side has type unsigned int
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24: right side has type restricted __le32
Add the necessary conversions and use temporary variables where appropriate
to avoid converting back.
Fixes: 579a267e4617 ("HID: intel-ish-hid: Implement loading firmware from host feature")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Zhang Lixu <lixu.zhang@intel.com>
Tested-by: Zhang Lixu <lixu.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
kernel test robot reported build error due to a pointer type mismatch:
.../ishtp/loader.c:172:8: error: incompatible pointer types passing
'__le64 *' (aka 'unsigned long long *') to parameter of type
'dma_addr_t *' (aka 'unsigned int *')
The issue arises because the driver, which is primarily intended for
x86-64, is also built for i386 when COMPILE_TEST is enabled.
Resolve type mismatch by using a temporary dma_addr_t variable to hold
the DMA address. Populate this temporary variable in dma_alloc_coherent()
function, and then convert and store the address in the
fragment->fragment_tbl[i].ddr_adrs field in the correct format.
Similarly, convert the ddr_adrs field back to dma_addr_t when freeing
the DMA buffer with dma_free_coherent().
Fixes: 579a267e4617 ("HID: intel-ish-hid: Implement loading firmware from host feature")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202405201313.SAStVPrT-lkp@intel.com/
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Starting from the Lunar Lake generation, the ISH firmware has been
divided into two components for better space optimization and increased
flexibility. These components include a bootloader that is integrated
into the BIOS, and a main firmware that is stored within the operating
system's file system.
Introduce support for loading ISH main firmware from host. This feature is
applicable for Lunar Lake and later generation.
Current intel-ishtp-loader, is designed for Chrome OS based systems which
uses core boot and has different firmware loading method. For non chrome
systems the ISH firmware loading uses different method.
Key differences include:
1. The new method utilizes ISHTP capability/fixed client to enumerate the
firmware loader function. It does not require a connection or flow control,
unlike the method used in Chrome OS, which is enumerated as an ISHTP
dynamic client driver, necessitating connect/disconnect operations and flow
control.
2. The new method employs a table to describe firmware fragments, which are
sent to ISH in a single operation. Conversely, the Chrome OS method sends
firmware fragments in multiple operations within a loop, sending only one
fragment at a time.
Additionally, address potential error scenarios to ensure graceful failure
handling.
- Firmware Not Found: Triggers if request_firmware() fails, leaving ISH in
a waiting state.
Recovery: Re-insmod the ISH drivers to retry.
- DMA Buffer Allocation Failure: Occurs during prepare_dma_bufs(), leading
to ISH waiting state. Allocated resources are released.
Recovery: Re-insmod the ISH drivers to retry.
- Incorrect Firmware Image: Causes ISH to refuse loading after three failed
attempts.
Recovery: A platform reset is required.
Please refer to the [Documentation](Documentation/hid/intel-ish-hid.rst)
for the details on flows.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
