kernel/linux.git/drivers/usb/misc/onboard_usb_dev.c, branch v6.12.80

usb: misc: onboard_usb_dev: fix build warning for CONFIG_USB_ONBOARD_DEV_USB5744=n

2025-06-19T13:32:37+00:00

commit 662a9ece32add94469138ae66999ee16cb37a531 upstream. When the USB5744 option is disabled, the onboard_usb driver warns about unused functions: drivers/usb/misc/onboard_usb_dev.c:358:12: error: 'onboard_dev_5744_i2c_write_byte' defined but not used [-Werror=unused-function] 358 | static int onboard_dev_5744_i2c_write_byte(struct i2c_client *client, u16 addr, u8 data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/misc/onboard_usb_dev.c:313:12: error: 'onboard_dev_5744_i2c_read_byte' defined but not used [-Werror=unused-function] 313 | static int onboard_dev_5744_i2c_read_byte(struct i2c_client *client, u16 addr, u8 *data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Extend the #ifdef block a little further to cover all of these functions. Ideally we'd use use if(IS_ENABLED()) instead, but that doesn't currently work because the i2c_transfer() and i2c_smbus_write_word_data() function declarations are hidden when CONFIG_I2C is disabled. Fixes: 1143d41922c0 ("usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250523120947.2170302-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence

2025-06-19T13:32:35+00:00

commit 1143d41922c0f87504f095417ba1870167970143 upstream. Introduce i2c APIs to read/write for proper configuration register programming. It ensures that read-modify-write sequence is performed and reserved bit in Runtime Flags 2 register are not touched. Also legacy smbus block write inserted an extra count value into the i2c data stream which breaks the register write on the usb5744. Switching to new read/write i2c APIs fixes both issues. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Cc: stable Signed-off-by: Jonathan Stroud Co-developed-by: Radhey Shyam Pandey Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1747398760-284021-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: fix support for Cypress HX3 hubs

2025-05-18T06:24:55+00:00

commit 9f657a92805cfc98e11cf5da9e8f4e02ecff2260 upstream. The Cypress HX3 USB3.0 hubs use different PID values depending on the product variant. The comment in compatibles table is misleading, as the currently used PIDs (0x6504 and 0x6506 for USB 3.0 and USB 2.0, respectively) are defaults for the CYUSB331x, while CYUSB330x and CYUSB332x variants use different values. Based on the datasheet [1], update the compatible usb devices table to handle different types of the hub. The change also includes vendor mode PIDs, which are used by the hub in I2C Master boot mode, if connected EEPROM contains invalid signature or is blank. This allows to correctly boot the hub even if the EEPROM will have broken content. Number of vcc supplies and timing requirements are the same for all HX variants, so the platform driver's match table does not have to be extended. [1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8 Table 9. PID Values Fixes: b43cd82a1a40 ("usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family") Cc: stable Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-1-4a76a474a010@thaumatec.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: skip suspend/resume sequence for USB5744 SMBus support

2024-12-19T17:12:58+00:00

commit ce15d6b3d5c3c6f78290066be0f0a4fd89cdeb5b upstream. USB5744 SMBus initialization is done once in probe() and doing it in resume is not supported so avoid going into suspend and reset the HUB. There is a sysfs property 'always_powered_in_suspend' to implement this feature but since default state should be set to a working configuration so override this property value. It fixes the suspend/resume testcase on Kria KR260 Robotics Starter Kit. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Cc: stable@vger.kernel.org Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1733165302-1694891-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: introduce new config symbol for usb5744 SMBus support

2024-10-04T13:36:51+00:00

Introduce new kernel config symbol for Microchip usb5744 SMBus programming support. Since usb5744 i2c initialization routine uses i2c SMBus APIs these APIs should only be invoked when kernel has I2C support. This new kernel config describes the dependency on I2C kernel support and fix the below build issues when USB_ONBOARD_DEV=y and CONFIG_I2C=m. riscv64-linux-ld: drivers/usb/misc/onboard_usb_dev.o: undefined reference to `i2c_find_device_by_fwnode' drivers/usb/misc/onboard_usb_dev.c:408:(.text+0xb24): undefined reference to `i2c_smbus_write_block_data' Parsing of the i2c-bus bus handle is not put under usb5744 kernel config check as the intention is to report an error when DT is configured for usb5744 SMBus support and kernel has USB_ONBOARD_DEV_USB5744 disabled. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Signed-off-by: Radhey Shyam Pandey Suggested-by: Matthias Kaehlcke Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202409140539.3Axwv38m-lkp@intel.com/ Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/1727529992-476088-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support

2024-09-11T13:36:25+00:00

usb5744 supports SMBus Configuration and it may be configured via the SMBus slave interface during the hub start-up configuration stage. To program it driver uses i2c-bus phandle (added in commit '02be19e914b8 dt-bindings: usb: Add support for Microchip usb5744 hub controller') to get i2c client device and then based on usb5744 compatible check calls usb5744 i2c default initialization sequence. Apart from the USB command attach, prevent the hub from suspend. when the USB Attach with SMBus (0xAA56) command is issued to the hub, the hub is getting enumerated and then it puts in a suspend mode. This causes the hub to NAK any SMBus access made by the SMBus Master during this period and not able to see the hub's slave address while running the "i2c probe" command. Prevent the MCU from putting the HUB in suspend mode through register write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2 register at address 0x411D controls this aspect of the hub. The BYPASS_UDC_SUSPEND bit in register 0x411Dh must be set to ensure that the MCU is always enabled and ready to respond to SMBus runtime commands. This register needs to be written before the USB attach command is issued. The byte sequence is as follows: Slave addr: 0x2d 00 00 05 00 01 41 1D 08 Slave addr: 0x2d 99 37 00 Slave addr: 0x2d AA 56 00 Also since usb5744 i2c initialization routine uses i2c SMBus APIs invoke these APIs only when i2c driver is enabled in the kernel configuration. Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1725732196-70975-3-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_dev: extend platform data to add power on delay field

2024-09-11T13:36:25+00:00

Introduce dedicated field 'power_on_delay_us' in onboard platform data and update its delay for USB5744 configuration. Hub itself requires some delay after reset to get to state where configuration data is going to be accepted. Without delay upcoming support for configuration via SMBUS is reporting a failure on the first SMBus write. i2c 2-002d: error -ENXIO: BYPASS_UDC_SUSPEND bit configuration failed Similar delay is likely also required for default configuration but because there is enough time (code execution) between reset and usage of the hub any issue is not visible but it doesn't mean delay shouldn't be reflected. Signed-off-by: Radhey Shyam Pandey Suggested-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/1725732196-70975-2-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: Add match function

2024-06-27T14:06:51+00:00

Add a match function for the onboard_usb_dev driver. Primary matching is still done through the VID:PID pair, as usual for USB devices. The new match function checks in addition whether the device has a device tree node, which is a needed for using the onboard_usb_dev driver. Remove the check for a device tree node from _probe(), the new match functions prevents devices without DT node from probing. Signed-off-by: Matthias Kaehlcke Tested-by: Jameson Thies Reviewed-by: Jameson Thies Link: https://lore.kernel.org/r/20240612180448.1.I805556c176c626872c15ce001f0e8198e1f95ae1@changeid Signed-off-by: Greg Kroah-Hartman

USB: fix up for "usb: misc: onboard_hub: rename to onboard_dev"

2024-04-30T16:11:13+00:00

interacting with "usb: misc: onboard_usb_hub: Disable the USB hub clock on failure" Signed-off-by: Stephen Rothwell Link: https://lore.kernel.org/r/20240424161202.7e45e19e@canb.auug.org.au Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_dev: add support for XMOS XVF3500

2024-03-27T06:57:16+00:00

The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit multicore controller for voice processing. This device requires a specific power sequence, which consists of enabling the regulators that control the 3V3 and 1V0 device supplies, and a reset de-assertion after a delay of at least 100ns. Once in normal operation, the XVF3500 registers itself as a USB device, and it does not require any device-specific operations in the driver. [1] https://www.xmos.com/xvf3500/ Acked-by: Matthias Kaehlcke Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-8-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman