Re: [PATCH] staging: greybus: arche: drop dangling Kconfig symbol

[Randy Dunlap <rdunlap@infradead.org>]

On 1/16/26 2:48 AM, Johan Hovold wrote:
> On Wed, Jan 14, 2026 at 04:28:33PM -0800, Randy Dunlap wrote:
>> On 1/14/26 1:21 AM, Johan Hovold wrote:
>>> On Mon, Dec 29, 2025 at 10:27:04PM -0800, Randy Dunlap wrote:
>>>> The Kconfig symbol USB_HSIC_USB3613 is not defined in the kernel source
>>>> tree. Drop it since it unused.
>>>>
>>>> Fixes: 2eccd4aa19fc ("staging: greybus: enable compile testing of arche driver")
>>>
>>> As the commit message of that commit says this was done on purpose to
>>> allow the driver to be compile tested without the out-of-tree driver
>>> that never went upstream.
>>>
>>> These days we have a USB hub driver that should probably be used
>>> instead, but yeah, someone would need to do the rework.
>>
>> We?
>> Do you mean drivers/usb/core/hub.c?
> 
> I meant the on-board hub driver (now renamed to "on-board dev") which
> did not exist when this greybus driver was written and merged to
> staging:
> 
> 	drivers/usb/misc/onboard_usb_dev_pdevs.c
> 
>>>> -#if IS_ENABLED(CONFIG_USB_HSIC_USB3613)
>>>> -#include <linux/usb/usb3613.h>
>>>> -#else
>>>>  static inline int usb3613_hub_mode_ctrl(bool unused)
>>>>  {
>>>>  	return 0;
>>>>  }
>>>> -#endif
>>>>  
>>>>  #define WD_COLDBOOT_PULSE_WIDTH_MS	30
>>>>  
>>>> --- linux-next-20251219.orig/drivers/staging/greybus/Kconfig
>>>> +++ linux-next-20251219/drivers/staging/greybus/Kconfig
>>>> @@ -206,7 +206,6 @@ endif	# GREYBUS_BRIDGED_PHY
>>>>  
>>>>  config GREYBUS_ARCHE
>>>>  	tristate "Greybus Arche Platform driver"
>>>> -	depends on USB_HSIC_USB3613 || COMPILE_TEST
>>>>  	help
>>>>  	  Select this option if you have an Arche device.
>>>
>>> The above just seems to hide the fact that the driver currently cannot
>>> be used.
>>>
>>> Can you please at least add some kind of TODO comment to indicate that
>>> the driver should be reworked to drop the dependency on the OOT driver?
>>
>> Sure, I can add that, but I think it needs more info. Reworked how?
>> What should the usb3613_hub_mode_ctrl() function do?
> 
> IIRC, this driver exists since we needed to power on the on-board USB
> hub so that the controller could be enumerated. Since there was no
> support for doing such things at the time in mainline, we have this
> custom interface for calling into the out-of-tree hub driver.
> 
> I'd need to spend more time looking at this to say exactly how this
> should be reworked.
> 
>>> And it's probably best to keep the depends on COMPILE_TEST until that
>>
>> ack
>>
>>> has been resolved. Perhaps also wrap usb3613_hub_mode_ctrl() in
>>>
>>> 	#ifdef CONFIG_COMPILE_TEST
>>> 	...
>>> 	#endif
>>
>> Don't think so. The driver calls usb3613_hub_mod_ctrl() in 4 places,
>> so it needs to be there.
> 
> Not if the driver can only be enabled for compile testing.
> 
> Perhaps replacing USB_HSIC_USB3613 with
> 
> 	depends on BROKEN || COMPILE_TEST
> 
> and adding a comment above the ifdeffed usb3613_hub_mode_ctrl() helper
> would make the state of things more clear.
> 
> Or just keep the dependency on the non-existing hub driver symbol. 

Yeah, it's such a mess that I'll just leave it as is.

Perhaps you or someone who cares about it can do something about it.

-- 
~Randy