You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering when you are going to make this driver have upstream kernel support. Your current roadmap is missing this critical milestone, and I think it prevents wider testing and adoption of your downstream hardware while you add other seemingly less-critical features.
Today, it's a very involved process to build the driver for the typical user, and the Linux kernel made changes post 5.15 that made using this driver a lot more unfriendly to install and use. I understand that the new driver for versions greater than that are using a static DTS file at driver compile time. That is unfortunate, because it breaks the plug and play functionality that would be useful from the perspective of a user that wants to have a plug and play device over a USB-SPI bridge chip or similar interface, without writing a custom USB driver that has a custom vendor ID on it to allow plug and play device usage.
If the driver that you have is upstreamed with the Linux kernel, once accepted the driver functionality would be updated by the kernel developers in refactory changes, and it would eliminate the issue that your drivers are unusable between major kernel releases, as we have seen in the past. It also means that developers and makers that want to use your device with newer hardware that only supports in-tree drivers on newer kernels can use your driver without a lot of frustration. An example of this, I would really like to be able to use your device in the Ten64 as part of a mesh networking project, but I can't because the Ten64 really needs a newer 6.x kernel to have the proper device support that it needs to even boot, and making your driver work in that hardware is difficult as a result. I'm sure that this is not the only example of this issue.
The text was updated successfully, but these errors were encountered:
I was wondering when you are going to make this driver have upstream kernel support. Your current roadmap is missing this critical milestone, and I think it prevents wider testing and adoption of your downstream hardware while you add other seemingly less-critical features.
Today, it's a very involved process to build the driver for the typical user, and the Linux kernel made changes post 5.15 that made using this driver a lot more unfriendly to install and use. I understand that the new driver for versions greater than that are using a static DTS file at driver compile time. That is unfortunate, because it breaks the plug and play functionality that would be useful from the perspective of a user that wants to have a plug and play device over a USB-SPI bridge chip or similar interface, without writing a custom USB driver that has a custom vendor ID on it to allow plug and play device usage.
If the driver that you have is upstreamed with the Linux kernel, once accepted the driver functionality would be updated by the kernel developers in refactory changes, and it would eliminate the issue that your drivers are unusable between major kernel releases, as we have seen in the past. It also means that developers and makers that want to use your device with newer hardware that only supports in-tree drivers on newer kernels can use your driver without a lot of frustration. An example of this, I would really like to be able to use your device in the Ten64 as part of a mesh networking project, but I can't because the Ten64 really needs a newer 6.x kernel to have the proper device support that it needs to even boot, and making your driver work in that hardware is difficult as a result. I'm sure that this is not the only example of this issue.
The text was updated successfully, but these errors were encountered: