You're using the word "potential" but the commit message correctly explains why a NULL dereference is impossible. Don't say potentially for things which are impossible.
On Fri, Aug 21, 2026 at 07:35:40PM +0800, hanzhijian wrote:
In gb_bootrom_get_firmware(), the queue_work label dereferences fw->size on a path where fw may have been set to NULL via the "if (!fw) goto unlock" path. This is currently masked at runtime by the !ret short-circuit (ret is non-zero on every path where fw can be NULL), but it relies on an implicit invariant that is fragile and hard to follow.
A lot of people would argue that the original code is easy to follow. In your code, to see what is passed on error you have to scroll all the way to the top of the function to see the "next_request = NEXT_REQ_GET_FIRMWARE;" assignment. In the existing code, it's clear, this is what we pass on error, this is what we pass on success.
It's not really fragile either. If we screwed up and forgot to set the error code or something then Smatch would warn about that.
drivers/staging/greybus/bootrom.c:300 gb_bootrom_get_firmware() error: we previously assumed 'fw' could be null (see line 266)
Or on the earlier paths, we would get an uninitialized variable warning.
regards, dan carpenter