From f4cdf7ca9a1fdcca413157df19753f388a5a224e Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Wed, 19 Aug 2026 10:09:22 -0700 Subject: Merge tag 'media/v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - v4l2-core: added ISP statistics support and per-block validation - v4l2-core: Allow unknown HDR10 white point and luminance - New camera sensors: Sony IMX678 and IMX471m, Himax HM1092 IR sensor - New codec: Milos: VPU v2.0 codec support - isp driver: gained support for Dreamchip RPPX1 ISP framework - vsp1 driver: gained support for RZ/T2H and RZ/N2H - Novalake driver: gained CVS support for new NVL hardware - dvb-core: fix feed leak on failed DMX_ADD_PID - several driver fixes, cleanups and minor improvements * tag 'media/v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (308 commits) media: ipu-bridge: check all DMI entries when overriding sensor rotation media: v4l2-async: avoid deleting unlinked ASC entry on link error media: rzg2l-cru: Align bytesperline to hardware DMA stride requirement media: intel/ipu6: fix async notifier cleanup leak on parse error media: staging/ipu7: fix async notifier UAF on probe error path media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path media: amd: isp4: release partial allocations in isp4if_alloc_fw_gpumem() media: rcar-isp: Fix VSPX reference leaks media: rcar-isp: Release ISPCORE resources media: i2c: imx415: Release runtime PM reference on VBLANK error media: i2c: imx415: Return test pattern write errors media: renesas: vsp1: Declare index variables in for loop statement media: renesas: vsp1: Make reset control optional to support platforms without a reset line media: dt-bindings: media: renesas,vsp1: Document RZ/T2H and RZ/N2H SoCs media: dt-bindings: media: renesas,fcp: Document RZ/T2H and RZ/N2H SoCs media: nxp: imx8-isi: Add additional 32-bit RGB format support media: nxp: imx8-isi: Add 16-bit raw Bayer format support media: nxp: imx8-isi: Implement per-stream reference counting for multiplexed streams media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks media: nxp: imx8-isi: Correct color map between V4L2 and ISI ... --- Documentation/ABI/testing/debugfs-wilco-ec | 45 ++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-wilco-ec (limited to 'Documentation/ABI/testing/debugfs-wilco-ec') diff --git a/Documentation/ABI/testing/debugfs-wilco-ec b/Documentation/ABI/testing/debugfs-wilco-ec new file mode 100644 index 000000000..682e3c09e --- /dev/null +++ b/Documentation/ABI/testing/debugfs-wilco-ec @@ -0,0 +1,45 @@ +What: /sys/kernel/debug/wilco_ec/h1_gpio +Date: April 2019 +KernelVersion: 5.2 +Description: + As part of Chrome OS's FAFT (Fully Automated Firmware Testing) + tests, we need to ensure that the H1 chip is properly setting + some GPIO lines. The h1_gpio attribute exposes the state + of the lines: + - ENTRY_TO_FACT_MODE in BIT(0) + - SPI_CHROME_SEL in BIT(1) + + Output will formatted with "0x%02x\n". + +What: /sys/kernel/debug/wilco_ec/raw +Date: January 2019 +KernelVersion: 5.1 +Description: + Write and read raw mailbox commands to the EC. + + You can write a hexadecimal sentence to raw, and that series of + bytes will be sent to the EC. Then, you can read the bytes of + response by reading from raw. + + For writing, bytes 0-1 indicate the message type, one of enum + wilco_ec_msg_type. Byte 2+ consist of the data passed in the + request, starting at MBOX[0]. At least three bytes are required + for writing, two for the type and at least a single byte of + data. + + Example:: + + // Request EC info type 3 (EC firmware build date) + // Corresponds with sending type 0x00f0 with + // MBOX = [38, 00, 03, 00] + $ echo 00 f0 38 00 03 00 > /sys/kernel/debug/wilco_ec/raw + // View the result. The decoded ASCII result "12/21/18" is + // included after the raw hex. + // Corresponds with MBOX = [00, 00, 31, 32, 2f, 32, 31, 38, ...] + $ cat /sys/kernel/debug/wilco_ec/raw + 00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 ..12/21/18.8... + + Note that the first 16 bytes of the received MBOX[] will be + printed, even if some of the data is junk, and skipping bytes + 17 to 32. It is up to you to know how many of the first bytes of + data are the actual response. -- cgit v1.3.1