Re: [PATCH v2] Input: xpad - add support for Beitong KP series controllers

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Using `IS_ENABLED(CONFIG_HID)` causes undefined reference linker errors when `CONFIG_JOYSTICK_XPAD=y` and `CONFIG_HID=m`.
--

--- Patch [1]: [PATCH v2] Input: xpad - add support for Beitong KP series controllers ---
commit aae02dfc97d563806266aab4cd52d4aaca3c3e89
Author: vegetablecat <[email protected]>
Subject: Input: xpad - add support for Beitong KP series controllers

This commit adds support for Beitong KP series controllers to the xpad driver,
triggering an XUSB10 descriptor read during probe to keep the devices in XInput
mode. It also introduces an optional HID receiver driver for the KP40D receiver
dongle to prevent interference from hid-generic.

> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index feb8f368f834e..13b61681d6ec9 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c

[ ... ]

> @@ -2312,7 +2357,79 @@ static struct usb_driver xpad_driver = {
>  	.id_table	= xpad_table,
>  };
>  
> -module_usb_driver(xpad_driver);
> +#if IS_ENABLED(CONFIG_HID)

[Severity: Low]
If the kernel is built with CONFIG_JOYSTICK_XPAD=y and CONFIG_HID=m,
IS_ENABLED(CONFIG_HID) evaluates to true.

Will this cause undefined reference linker errors in xpad_receiver_probe()
and xpad_init() since vmlinux cannot link against exported HID symbols like
hid_parse and hid_register_driver which would be built into a loadable module?

Would it be better to use IS_REACHABLE(CONFIG_HID) here, or enforce this via
a Kconfig dependency like "depends on HID || HID=n" instead?

> +static int xpad_receiver_probe(struct hid_device *hdev, const struct hid_device_id *id)
> +{
> +	int error;
> +
> +	error = hid_parse(hdev);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1