From: Aditya Chari S adi25charis@gmail.com
Previously, when a firmware size request, get firmware request, or ready-to-boot request from a module timed out, the driver would log an error and free any firmware buffer, but left the module powered on in a potentially inconsistent state.
Fix this by ejecting the module's interface via the SVC when a timeout occurs, forcing it to be power-cycled and re-detected rather than left in limbo.
Signed-off-by: Aditya Chari S adi25charis@gmail.com --- drivers/staging/greybus/bootrom.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c index 83921d90c..b564d2255 100644 --- a/drivers/staging/greybus/bootrom.c +++ b/drivers/staging/greybus/bootrom.c @@ -54,8 +54,12 @@ static void gb_bootrom_timedout(struct work_struct *work) struct delayed_work *dwork = to_delayed_work(work); struct gb_bootrom *bootrom = container_of(dwork, struct gb_bootrom, dwork); - struct device *dev = &bootrom->connection->bundle->dev; + struct gb_connection *connection = bootrom->connection; + struct device *dev = &connection->bundle->dev; + struct gb_interface *intf = connection->bundle->intf; + struct gb_svc *svc = connection->hd->svc; const char *reason; + int ret;
switch (bootrom->next_request) { case NEXT_REQ_FIRMWARE_SIZE: @@ -82,7 +86,11 @@ static void gb_bootrom_timedout(struct work_struct *work) free_firmware(bootrom); mutex_unlock(&bootrom->mutex);
- /* TODO: Power-off Module ? */ + /* Power-off Module */ + ret = gb_svc_intf_eject(svc, intf->interface_id); + if (ret) + dev_err(dev, "failed to eject interface %u (%d)\n", + intf->interface_id, ret); }
static void gb_bootrom_set_timeout(struct gb_bootrom *bootrom,
On Sat, Jul 04, 2026 at 12:49:26PM +0530, adi25charis@gmail.com wrote:
From: Aditya Chari S adi25charis@gmail.com
Previously, when a firmware size request, get firmware request, or ready-to-boot request from a module timed out, the driver would log an error and free any firmware buffer, but left the module powered on in a potentially inconsistent state.
Fix this by ejecting the module's interface via the SVC when a timeout occurs, forcing it to be power-cycled and re-detected rather than left in limbo.
Signed-off-by: Aditya Chari S adi25charis@gmail.com
drivers/staging/greybus/bootrom.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
Cool, but how was this tested? What hardware needs this?
thanks,
greg k-h
On Sat, Jul 04, 2026 at 09:34:47AM +0200, Greg KH wrote:
Cool, but how was this tested? What hardware needs this?
Fair question. Honestly - I don't have Project Ara hardware, and as far as I can tell it's not really possible to get any at this point (the project's been dead for years and I haven't found boards floating around anywhere).
So this was build-tested only - compiles clean, checkpatch clean - but I haven't been able to actually trigger the timeout path on real hardware. I based the fix on the existing gb_svc_intf_eject() usage elsewhere in the SVC code, so the API usage should be correct, but I can't vouch for the runtime behavior beyond that.
That said, if this driver is effectively unmaintained at this point and changes without hardware validation aren't worth taking, I'd appreciate knowing that as well - happy to defer to your judgment on whether this is worth pursuing further.
Thanks, Aditya
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/adi25charis-gmail-com/staging... base: staging/staging-testing patch link: https://lore.kernel.org/r/20260704071926.6606-1-adi25charis%40gmail.com patch subject: [PATCH] staging: greybus: bootrom: power off module on timeout config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260704/202607042245.XyM6HiC2-lkp@i...) compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 0a2fb2a2269da0e2a3e230beb6cad39ca314db33) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260704/202607042245.XyM6HiC2-lkp@i...)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot lkp@intel.com | Closes: https://lore.kernel.org/oe-kbuild-all/202607042245.XyM6HiC2-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
ERROR: modpost: "gb_svc_intf_eject" [drivers/staging/greybus/gb-bootrom.ko] undefined!
-- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
-
adi25charis＠gmail.com -
Greg KH -
kernel test robot