>> The proposed update candidates are contained in the source >> file "drivers/hid/i2c-hid/i2c-hid.c" from Linux next-20150708. >> >> * i2c_hid_remove() function: >> Can it be tolerated here that the pointer "ihid->desc" might be eventually null? >> >> * i2c_hid_probe() function: >> Is this implementation structured in such a way that a pointer for valid data >> will be usually passed for "ihid->desc" if the statements after the jump >> label "err" will be reached? >> > > Again, in both case it is completely normal to have "ihid->desc == > NULL" given that this field is only retrieved in case of an ACPI > device which does not declares an IRQ but a GPIO. Most ACPI devices I > saw are using a simple IRQ, and the OF instantiations of the driver > will definitively have ihid->desc null. So I do not want to have a > warning for most of i2c-hid devices out there (because I will have to > explain that this is completely normal again and again). Would it make sense to annotate checks before such function calls as "unlikely" then? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
