{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":497699963,"defaultBranch":"realtek-poe","name":"realtek-poe","ownerLogin":"Hurricos","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2022-05-29T20:17:05.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2000409?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714937038.0","currentOid":""},"activityList":{"items":[{"before":"2c4039fbb6b9d2f78e215190a1f4b125a33093a4","after":"631067ee260b9f57bf909499dbebfcfacba6be22","ref":"refs/heads/mrnuke-tek-poe-cleanups","pushedAt":"2024-05-05T21:39:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"realtek-poe: move blob_buf out of global scope\n\nthe `blob_buf` is only used in ubus_poe_info_cb(). Since it is also\ninitialized in the same function, it could be reasoned that it should\nbe a stack variable. However, placing it on the stack seems to cause\nsegmentation faults, as observed when calling `ubus call poe info`.\nPresumably, this is why `blob_buf` was originally made global.\n\nTo take `blob_buf` out of global scope, without casuing issues, move\nit to the poe context.\n\nSigned-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>","shortMessageHtmlLink":"realtek-poe: move blob_buf out of global scope"}},{"before":"26622af67fe6249a202089be29c3cd7e1635e57f","after":"2c4039fbb6b9d2f78e215190a1f4b125a33093a4","ref":"refs/heads/mrnuke-tek-poe-cleanups","pushedAt":"2024-05-05T20:58:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"realtek-poe: move blob_buf out of global scope\n\nthe `blob_buf` is only used in ubus_poe_info_cb(). Since it is also\ninitialized in the same function, it could be reasoned that it should\nbe a stack variable. However, placing it on the stack seems to cause\nsegmentation faults. Presumably, this is why `blob_buf` was originally\nmade a global variable.\n\nTo take `blob_buf` out of global scope, without casuing issues, move\nit to the poe context.\n\nSigned-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>","shortMessageHtmlLink":"realtek-poe: move blob_buf out of global scope"}},{"before":"8c47e33e17e57e4513c7ddecee8544b2b8b26520","after":"26622af67fe6249a202089be29c3cd7e1635e57f","ref":"refs/heads/mrnuke-tek-poe-cleanups","pushedAt":"2024-05-05T19:46:23.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"realtek-poe: clean up coding style\n\nThe old convention in realtek-poe was to leave John's old code alone,\nwith the return value and function name on separate lines, but use a\nsane style for modified or new code. This was supposed to be\ntemporary, but two years later, it is still the case.\n\nMake the style consistent, and use a single line for most function\ndefinitions. The onle place it makes sense to space things out is for\nfunctions with very large argument lists.\n\nAlso move config_apply_quirks() higher up, so that a static\ndeclaration is not. Drop the inline from ubus_to_poe_ctx().\n\nLecture time:\n\nC defines the \"execution character sets\" as 26 uppercase and lowercase\nLatin alphabet letters, 10 decimal digits, and 29 graphic characters.\nA \"char\" is intended to store these printable characters.\nNow for the fun part 6.2.5.3:\n\n    \"  If any other character is stored in a char object, the\n       resulting value is implementation-defined ... \"\n\nRant time:\n\n\"char\" is not meant to store integers, so why on earth do porgrammers\ninsist on using it when they mean 8-bit unsigned interegr? Just use\nuint8_t consistently, and end this char madness.\n\nSigned-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>","shortMessageHtmlLink":"realtek-poe: clean up coding style"}},{"before":null,"after":"8c47e33e17e57e4513c7ddecee8544b2b8b26520","ref":"refs/heads/mrnuke-tek-poe-cleanups","pushedAt":"2024-05-05T19:23:58.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"realtek-poe: clean up coding style\n\nThe old convention in realtek-poe was to leave John's old code alone,\nwith the return value and function name on separate lines, but use a\nsane style for modified or new code. This was supposed to be\ntemporary, but two years later, it is still the case.\n\nMake the style consistent, and use a single line for most function\ndefinitions. The onle place it makes sense to space things out is for\nfunctions with very large argument lists.\n\nLecture time:\n\nC defines the \"execution character sets\" as 26 uppercase and lowercase\nLatin alphabet letters, 10 decimal digits, and 29 graphic characters.\nA \"char\" is intended to store these printable characters.\nNow for the fun part 6.2.5.3:\n\n    \"  If any other character is stored in a char object, the\n       resulting value is implementation-defined ... \"\n\nRant time:\n\n\"char\" is not meant to store integers, so why on earth do porgrammers\ninsist on using it when they mean 8-bit unsigned interegr? Just use\nuint8_t consistently, and end this char madness.\n\nSigned-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>","shortMessageHtmlLink":"realtek-poe: clean up coding style"}},{"before":"c4efa8c093e757972a2a734be82fd52209533d5a","after":"d5509e449748e28035cabe5712f182889c874e59","ref":"refs/heads/mrnuke-lexicon","pushedAt":"2024-04-26T01:56:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"stash","shortMessageHtmlLink":"stash"}},{"before":"5289254af0c73ae7be5a60aea7820edea773ac3c","after":"c4efa8c093e757972a2a734be82fd52209533d5a","ref":"refs/heads/mrnuke-lexicon","pushedAt":"2024-04-25T05:57:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"stash","shortMessageHtmlLink":"stash"}},{"before":null,"after":"c916e8429c22d68765c4c688ed28b69d4001ccda","ref":"refs/heads/mrnuke-rtl8238b-devel","pushedAt":"2024-04-25T02:57:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"[WIP]: dialect_rtl: add RTL8328B (or 8238B ?) compatible dialect","shortMessageHtmlLink":"[WIP]: dialect_rtl: add RTL8328B (or 8238B ?) compatible dialect"}},{"before":"ff3298d0a02e65fbd2b711df2656f36233edf0ae","after":null,"ref":"refs/heads/mrnuke-use-autorelease","pushedAt":"2024-04-21T00:30:37.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"}},{"before":"aa16ffda94db6dd323c84ddc132c80291c3201fc","after":null,"ref":"refs/heads/mrnuke-bugging-and-debugging","pushedAt":"2024-04-21T00:29:59.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"}},{"before":"241f3a088b6b314923acd79ba8739adb13e4f3c6","after":null,"ref":"refs/heads/mrnuke-this-did-not-work","pushedAt":"2024-04-21T00:27:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"}},{"before":"42aa1968bc674dc2085486096e984a0f50a67141","after":"5289254af0c73ae7be5a60aea7820edea773ac3c","ref":"refs/heads/mrnuke-lexicon","pushedAt":"2024-04-21T00:18:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"[WIP]: dialect_rtl: add RTL8328B (or 8238B ?) compatible dialect","shortMessageHtmlLink":"[WIP]: dialect_rtl: add RTL8328B (or 8238B ?) compatible dialect"}},{"before":null,"after":"42aa1968bc674dc2085486096e984a0f50a67141","ref":"refs/heads/mrnuke-lexicon","pushedAt":"2024-04-20T21:38:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mrnuke","name":null,"path":"/mrnuke","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2610559?s=80&v=4"},"commit":{"message":"realtek-poe: clean up coding style\n\nThe old convention in realtek-poe was to leave John's old code alone,\nwith the return value and function name on separate lines, but use a\nsane style for modified or new code. This was supposed to be\ntemporary, but two years later, it is still the case.\n\nMake teh style consistent, and use a single line for most function\ndefinitions. The onle place it makes sense to space things out is for\nfunctions with very large argument lists.\n\nLecture time:\n\nC defines the \"execution character sets\" as 26 uppercase and lowercase\nLatin alphabet letters, 10 decimal digits, and 29 graphic characters.\nA \"char\" is intended to store these printable characters.\nNow for the fun part 6.2.5.3:\n\n    \"  If any other character is stored in a char object, the\n       resulting value is implementation-defined ... \"\n\nRant time:\n\n\"char\" is not meant to store integers, so why on earth do porgrammers\ninsist on using it when they mean 8-bit unsigned interegr? Just use\nuint8_t consistently, and end this char madness.\n\nSigned-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>","shortMessageHtmlLink":"realtek-poe: clean up coding style"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEQgbOUwA","startCursor":null,"endCursor":null}},"title":"Activity · Hurricos/realtek-poe"}