This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/simtrace2/+/23620 ) Change subject: cardem: Use USART timeout for waiting time ...................................................................... Patch Set 2: (5 comments) https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG Commit Message: https://gerrit.osmocom.org/c/simtrace2/+/23620/2//COMMIT_MSG@1 PS2, Line 1: Parent: d6005fcd (make sim switch board specific) actaully, the clock signal is connected (TCLK1). It's the I/O signal which is not connected to any TIO{A,B}1 so we cannot determine when exactly a bit starts or ends on the I/O line. https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c File firmware/apps/cardem/main.c: https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/apps/cardem/main.c@a168 PS2, Line 168: #if 0 unrelated change. https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h File firmware/libcommon/include/simtrace_prot.h: https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/include/simtrace_prot.h@236 PS2, Line 236: uint3 waiting_time to wt rename should be one purely cosmetic patch (if at all) https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c File firmware/libcommon/source/card_emu.c: https://gerrit.osmocom.org/c/simtrace2/+/23620/2/firmware/libcommon/source/card_emu.c@424 PS2, Line 424: if (ISO_S_WAIT_POWER == new_state) { the UART I/O related changes are independent of the USART timer changes. To be honest, I don't see how those do anything at all. The UART I/O lines are all routed to the peripheral function via the PIO_PER (peripheral enable register). Unless you disable the peripheral via PIO_PDR, the changes to the GPIO output data via PIO_SODR / PIO_CODR done here are no-ops as the alternate function always overrides any configured output levels. How was this tested/validated? Maybe there are some hardware bugs I'm unaware of? https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c File firmware/libcommon/source/mode_cardemu.c: https://gerrit.osmocom.org/c/simtrace2/+/23620/1/firmware/libcommon/source/mode_cardemu.c@217 PS1, Line 217: ("% > not sure we want to make this a non-fatal error. Clearly this should never happen... Done -- To view, visit https://gerrit.osmocom.org/c/simtrace2/+/23620 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: simtrace2 Gerrit-Branch: master Gerrit-Change-Id: Ibcb2c8cace9137695adf5fb3de43566f7cfb93b5 Gerrit-Change-Number: 23620 Gerrit-PatchSet: 2 Gerrit-Owner: laforge <laforge at osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: tsaitgaist <kredon at sysmocom.de> Gerrit-Comment-Date: Mon, 05 Apr 2021 12:25:41 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: laforge <laforge at osmocom.org> Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210405/b0623f5e/attachment.htm>