No, that's not right at all, for a couple of reasons.
First, &ep->desc is the address of a member of a structure. Even if ep
itself were null, &ep->desc would not be NULL unless desc happened to
be the first member of the ep structure (it is now, but there's no
guarantee that it always will be). Probably you really meant to test
ep instead of &ep->desc.
Maybe I read the kernel OOPS wrong. Was &ep->desc NULL or not?
Also there's a check for a NULL ep 9 lines above this code, so I guess
ep was not NULL.
Second, ep will never be NULL if the system is working correctly. If
it is NULL then the caller is buggy. We don't want to paper over bugs
in drivers; we want to find them and fix them.
Maybe BUG_ON or something?
The driver is i2c-tiny-usb (as seen in the stack trace). It ships with
the vanilla kernel since 2007 I think.
drivers/i2c/busses/i2c-tiny-usb.c
I've triggered this issue while hacking on the firmware for an attiny25
micro-controller that the driver communicates with. I know my firmware
was broken for sure, but that's another story.
I've not debug-ed the driver itself yet. I just thought that extra
check in urb.c should be added first.
No, just fix the driver. Then the check won't be needed.
It's not my driver, and I don't imagine it's something I can do easily.
But let's see.
--
дамјан
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
