Jean, As Mike noted, "transceiver" is a contraction of "transmitter-receiver". But I wouldn't blame English speakers in general for that, just English speaking engineers. ;) English speaking engineers (likely) also orignated use of the "x" as shorthand for "trans-" and "crys-". "Transceiver_lock" was intended to mean a lock protecting access to both portions of a chip: tx and rx. I'm still mulling it all over though. Some change will be made to IR_i2c_init_data. I found I need some more time to design exactly what I need. Regards, Andy Mike Isely <isely@xxxxxxxxx> wrote: >On Wed, 19 Jan 2011, Jean Delvare wrote: > >> Hi Andy, >> >> On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote: >> > 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if >> > adding some new fields for struct IR_i2c_init_data is acceptable. >> > Specifically, I'd like to add a transceiver_lock mutex, a transceiver >> > reset callback, and a data pointer for that reset callback. >> > (Only lirc_zilog would use the reset callback and data pointer.) >> >> Adding fields to these structures is perfectly fine, if you need to do >> that, just go on. >> >> But I'm a little confused about the names you chose, >> "ir_transceiver_lock" and "transceiver_lock". These seem too >> TX-oriented for a mutex that is supposed to synchronize TX and RX >> access. It's particularly surprising for the ir-kbd-i2c driver, which >> as far as I know only supports RX. The name "xcvr_lock" you used for >> lirc_zilog seems more appropriate. > >Actually the term "transceiver" is normally understood to mean both >directions. Otherwise it would be "receiver" or "transmitter". >Another screwy as aspect of english, and I say this as a native english >speaker. The term "xcvr" is usually just considered to be shorthand for >"transceiver". > > -Mike > > >-- > >Mike Isely >isely @ isely (dot) net >PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þg‰¯â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
