Optoe driver compilation fails with Linux kernel 6.1.55

[SLLU77]

Optoe driver compilation fails with Linux kernel 6.1.55. Would you provide a patch to correct the issue?

[layman6666]

---这是来自QQ邮箱的自动回复邮件。 ---This is from the QQ mailbox automated reply. 您好！您的来信我已经收到，我会尽快给您回复。Hello

[layman6666]

---这是来自QQ邮箱的自动回复邮件。 ---This is from the QQ mailbox automated reply. 您好！您的来信我已经收到，我会尽快给您回复。Hello

[rasatpetabit]

Seeing the same thing... Looks like they killed off the old i2c_new_dummy() API, which seems to have been worked on in optoe at some point:

#ifdef LATEST_KERNEL
optoe->optoe_dummy.client =
devm_i2c_new_dummy_device(dev, client->adapter, 0x51);
#else
optoe->optoe_dummy.client =
i2c_new_dummy(client->adapter, 0x51);
#end

But turning on LATEST_KERNEL causes a bunch of other issues, seems like this is rather bitrotted in new kernels.

[rasatpetabit]

Looks like Linux got rid of devm_nvmem_unregister()... Turning on LATEST_KERNEL and removing all of those references in optoe as well seems to get the job done, but I have no idea if that's the proper way to do it. :)

[donboll]

Yes, this project is not being maintained, at least not in this repository. I’m the author. This work was done in collaboration with Finisar, starting in 2015. Their funding ended in 2020. I have been maintaining it on my own time (dime) since then. In 2021 I tried to get optoe into the upstream Linux kernel. The latest version in the optoe repository worked correctly in the latest kernel at the time, but was rejected because it was not integrated with the Linux kernel networking architecture. My users don’t use that architecture, and I was unwilling to create a dependency on that subsystem. So I made the code available as a guide for the day when someone would want to run optoe on a newer kernel. In the years since, my hardware infrastructure has become obsolete, and without a corporate sponsor I have not refreshed it. My skills have degraded as well. Consider this my formal retirement from this project. Updating optoe to the latest kernel will take more relearning and effort than I’m willing to spend. I intend to continue answering the occasional question about how to use optoe and OOM, and I’m willing to review modest code changes to provide any feedback I can. Optoe lives on at Microsoft, where their Sonic team is using it and maintaining it for their own use. See sonic-linux-kernel/patch at master · sonic-net/sonic-linux-kernel (github.com)<https://github.com/sonic-net/sonic-linux-kernel/tree/master/patch>, find a series of patches that establish and then modify optoe.c. Perhaps someone from that team can offer a path forward for optoe as an open source project. The oom/optoe repository could be transferred to their control, or they could manage it in a repository of their choosing. Don Bollinger OOM/optoe author From: Richard A Steenbergen ***@***.***> Sent: Saturday, October 12, 2024 1:25 AM To: opencomputeproject/oom ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [opencomputeproject/oom] Optoe driver compilation fails with Linux kernel 6.1.55 (Issue #24) Looks like Linux got rid of devm_nvmem_unregister()... Turning on LATEST_KERNEL and removing all of those references in optoe as well seems to get the job done, but I have no idea if that's the proper way to do it. :) — Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD6VCJZYZXJP62FH72ELIFTZ3DMHFAVCNFSM6AAAAABLTUAYECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGQ2TKOBZHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[donboll]

Richard, Let’s take this conversation off the github/OOM distribution. Send me an email at ***@***.******@***.***> Don From: Richard A Steenbergen ***@***.***> Sent: Sunday, October 13, 2024 2:13 PM To: opencomputeproject/oom ***@***.***> Cc: don thebollingers.org ***@***.***>; Comment ***@***.***> Subject: Re: [opencomputeproject/oom] Optoe driver compilation fails with Linux kernel 6.1.55 (Issue #24) Hi Don, Good to talk to you, I've been meaning to reach out to you about this project a few different times, but just never got around to actually doing it. But I'd like to say think you for the time and effort you put into this project, I've used the hell out of it for a number of projects, and it's been incredibly helpful. I eventually ended up rewriting the EEPROM code into my own implementation (mostly because I'm a control freak who hates Python :P), but used OOM directly for many years before that happened, and then referenced your work literally thousands of times while learning how to do it myself. I'm confused about some of the details of the Linux architectural objections though. The optoe_doc file mentioned that they didn't want to allow userland access to xcvr EEPROMs, which didn't make sense because I've never seen any NIC driver allowing direct exposure of the xcvr i2c in the first place. In what other way could they have possibly wanted it integrated, my understanding was that this type of thing was firmly constrained to the netlink/ethtool interfaces? I would argue that this has no relationship to Linux's normal networking layer at all. This is a specific driver for talking hardware for a specific and popular industrial process, which as far as Linux's architecture is concerned never extends past the EEPROM layer. Unless there's something else that I'm missing, you could probably take another run at it, and I'll get them beat into submission if they still don't get it. :) I still need to do some proper testing, but as far as I can tell you already did 99% of the work, it only took me about 30 minutes of poking and minor tweaking of only a few lines of code to get it working on current kernels. I spent WAY more time fighting with it trying to get it imported and built manually as per your docs, before finally realizing the MUCH smarter approach was to build it as an external kernel module. One very small Makefile later, it literally "just works" using nothing but a standard linux-headers package. But IMHO you deserve all of the credit here, and should stay on as the primary author, but if you wanted to split optoe out into a separate project I'd be more than happy to help maintain it. But in all honesty, I'm not not a fan of ceding this kind of stuff over to SONiC, they're not doing a great job at avoiding rampant bit-rot themselves. And while I appreciate all the effort they've put into it, and will even agree that it's the "least bad" free option out there, from the perspective of my "day job" building "real networks" for 25+ years it's a literal dumpster fire that physically hurts every time I'm forced to touch it. :) FYI, our commercial application for this code is doing things like turning whitebox switches into large-scale optic coding and testing platforms, doing things like processing 800G optics for AI/ML applications by the thousands at a time. I assure you, I have no shortage of hardware available to support anything you would ever need. I'll admit I've been bad about pushing stuff back into open source here (a lot of this really is a highly valuable differentiator for us), but I'd like to at least get some basic libraries and tools (e.g. just finished a CMIS VDM decoder the other day) pushed out soon. — Richard A Steenbergen ***@***.***<mailto:***@***.***>> Chief Executive Officer, Petabit Scale, Inc. https://www.petabitscale.com/

On Sat, Oct 12, 2024 at 3:11 PM donboll ***@***.***<mailto:***@***.***>> wrote: Yes, this project is not being maintained, at least not in this repository. I’m the author. This work was done in collaboration with Finisar, starting in 2015. Their funding ended in 2020. I have been maintaining it on my own time (dime) since then. In 2021 I tried to get optoe into the upstream Linux kernel. The latest version in the optoe repository worked correctly in the latest kernel at the time, but was rejected because it was not integrated with the Linux kernel networking architecture. My users don’t use that architecture, and I was unwilling to create a dependency on that subsystem. So I made the code available as a guide for the day when someone would want to run optoe on a newer kernel. In the years since, my hardware infrastructure has become obsolete, and without a corporate sponsor I have not refreshed it. My skills have degraded as well. Consider this my formal retirement from this project. Updating optoe to the latest kernel will take more relearning and effort than I’m willing to spend. I intend to continue answering the occasional question about how to use optoe and OOM, and I’m willing to review modest code changes to provide any feedback I can. Optoe lives on at Microsoft, where their Sonic team is using it and maintaining it for their own use. See sonic-linux-kernel/patch at master · sonic-net/sonic-linux-kernel (github.com)< https://github.com/sonic-net/sonic-linux-kernel/tree/master/patch>, find a series of patches that establish and then modify optoe.c. Perhaps someone from that team can offer a path forward for optoe as an open source project. The oom/optoe repository could be transferred to their control, or they could manage it in a repository of their choosing. Don Bollinger OOM/optoe author From: Richard A Steenbergen ***@***.***<mailto:***@***.***>> Sent: Saturday, October 12, 2024 1:25 AM To: opencomputeproject/oom ***@***.***<mailto:***@***.***>> Cc: Subscribed ***@***.***<mailto:***@***.***>> Subject: Re: [opencomputeproject/oom] Optoe driver compilation fails with Linux kernel 6.1.55 (Issue #24) Looks like Linux got rid of devm_nvmem_unregister()... Turning on LATEST_KERNEL and removing all of those references in optoe as well seems to get the job done, but I have no idea if that's the proper way to do it. :) — Reply to this email directly, view it on GitHub< #24 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AD6VCJZYZXJP62FH72ELIFTZ3DMHFAVCNFSM6AAAAABLTUAYECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGQ2TKOBZHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***<mailto:***@***.******@***.***>>> — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJE2LK5BN4SYDL7JMY2MK3LZ3GM73AVCNFSM6AAAAABLTUAYECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYG4YTGNRYGA> . You are receiving this because you commented.Message ID: ***@***.***<mailto:***@***.***>>

— Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD6VCJ4CWQFZTHQBXWGE64DZ3LO4XAVCNFSM6AAAAABLTUAYECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBZGEZTGMBRGQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[insekt]

Hi Don @donboll ,
I'm sorry for the off-topic.

Consider this my formal retirement from this project.

I just want to express my deep gratitude to you for this project. It helped me a lot with my hobby projects.

[donboll]

Thank you Mikhail. That means a lot, much appreciated. Don From: Mikhail Sokolov ***@***.***> Sent: Monday, October 21, 2024 7:04 AM To: opencomputeproject/oom ***@***.***> Cc: don thebollingers.org ***@***.***>; Mention ***@***.***> Subject: Re: [opencomputeproject/oom] Optoe driver compilation fails with Linux kernel 6.1.55 (Issue #24) Hi Don @donboll<https://github.com/donboll> , I'm sorry for the off-topic. Consider this my formal retirement from this project. I just want to express my deep gratitude to you for this project. It helped me a lot with my hobby projects. — Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD6VCJZZ3UQOLFNDHDOLYETZ4UCVXAVCNFSM6AAAAABLTUAYECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRWG44DCOBRHE>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>