On Mon, Sep 12, 2016 at 11:35 AM, Leo Li <pku.leo@xxxxxxxxx> wrote: > On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@xxxxxxxxx> wrote: >> Hello, bus recovery is needed generally speaking because of potential >> protocol errors that might cause a failure condition hanging the bus. >> >> It happens frequently during bring-up of new I2C devices because firmware in >> I2C controllers fail to handle properly protocol errors. >> >> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch-- >> unless there is no HW bus recovery mechanism? >> >> The concern is while fixing I.MX, NXP will fail to fix the driver bus >> recovery for the LS1021A and LS1043A and the bus will hang. >> >> If bus recovery is supported on the LS1021A and the LS1043A, a patch should >> be provided or added in this patch instead of simply disabling bus recovery. >> Request NXP to consider the patch if there is HW support for bus recovery. > > FYI. http://patchwork.ozlabs.org/patch/573879/ Hi Gao Pan, Do you think the operations in the proposed patch is also usable on the I.MX SoC for bus recovery? If so, would it be better to align the bus recovery implementation for both I.MX and QorIQ to use the same logic inside the IP? Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html