Hi Chris, > Yep I plan on being around. I've got access to a couple of designs with > P2040 and T2081 so hopefully that's sufficient to deal with any > regressions. One issue is a lack of different i2c devices (the systems > we have tend to use the same devices) but hopefully any reports of > regression will be from people with access to such devices. Sounds very good to me. > > That kind of leads to the question if you want to > > step up as the maintainer for this driver? > Sure can do. It'd be nice if it was someone from NXP but I think they've > lost interest in the PowerPC based SoCs. Should I send a patch for > MAINTAINERS? If so does that go through the i2c tree? Yes, please send a patch and I will merge it via I2C. I don't have hope for someone from NXP because it was difficult enough to get maintainers for the actively sold SoCs. > > Only thing I noticed was a "BUG" and "BUG_ON" and wonder if we really > > need to halt the kernel in that case. Maybe WARN is enough? > > Yeah I think they can both be WARN variants. The one in mpc_xfer() can > happily continue. It's a little less clear what I should do in > mpc_i2c_do_action() if the WARN is ever hit but in theory it should be > an unreachable case anyway so the only thing that could get there is > some kind of memory corruption which would likely cause a crash elsewhere. Yeah, please change to WARN. > Do you want me to send a V3 of just that patch? Yes, plus the MAINTAINERS patch, please. Happy hacking, Wolfram
Attachment:
signature.asc
Description: PGP signature
