4 ms·

I'm curious as to what things DT cannot access. Is this a general issue (and if so have you spoken to the DT maintainers?), or is this because the systems you a

by Khol 9y ago

I'm curious as to what things DT cannot access. Is this a general issue (and if so have you spoken to the DT maintainers?), or is this because the systems you are working on are doing something unexpected?

simias 9y ago
I've had situations where we had to add a small functionality to a driver. For instance a secondary functionality that wasn't supported in the upstream version. It's very rare for drivers of complex components to support 100% of the functionality. An example that comes to mind was a video chip that also had a GPIO pin that we needed to control. The chip had a driver in the kernel but it didn't have support for the GPIO (it is after all a very secondary function). That required a small patch. It would of course have been possible to upstream it but then that meant implementing a "clean" patch (using the kernel GPIO API etc... instead of a one liner to toggle the PIN high on dereset) then submitting it upstream, maybe doing a couple of back and forth... Some will bother to do it, many won't.
- castratikron 9y ago
  Drivers can be built as modules most of the time. Google could still ship a single kernel binary and any vendor that had a weird quirk could load their own module. In fact I wouldn't be surprised if Google requires every driver to be built as a module and they ship a minimal core kernel.
  - fmntf 9y ago
    Unfortunately there is no binary compatibility between modules and different kernels. Moreover Google recommends CONFIG_MODVERSIONS=y, which prevents to load even practically compatible modules.
    - rbanffy 9y ago
      The vendor would need to recompile their modules for every kernel Google releases, but that's not a huge issue - how many times does Google update the kernel?
fmntf 9y ago
All the ARM boards i know share our same kernel issues. The problem is that DT is basically a configuration, which is accessed by drivers. If a driver do not read it, you must edit the driver. For instance a 2 lines patch [1] is about the fec (ethernet) driver. DT can specify a sleep time before the PHY reset GPIO is toggled. However we need to sleep also after the toggle, hence the patch. [1] https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba41c7f7af86b99476055c2b46e86605 https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...

by Khol 9y ago

simias 9y ago

I've had situations where we had to add a small functionality to a driver. For instance a secondary functionality that wasn't supported in the upstream version. It's very rare for drivers of complex components to support 100% of the functionality. An example that comes to mind was a video chip that also had a GPIO pin that we needed to control. The chip had a driver in the kernel but it didn't have support for the GPIO (it is after all a very secondary function). That required a small patch. It would of course have been possible to upstream it but then that meant implementing a "clean" patch (using the kernel GPIO API etc... instead of a one liner to toggle the PIN high on dereset) then submitting it upstream, maybe doing a couple of back and forth... Some will bother to do it, many won't.

castratikron 9y ago
Drivers can be built as modules most of the time. Google could still ship a single kernel binary and any vendor that had a weird quirk could load their own module. In fact I wouldn't be surprised if Google requires every driver to be built as a module and they ship a minimal core kernel.
- fmntf 9y ago
  Unfortunately there is no binary compatibility between modules and different kernels. Moreover Google recommends CONFIG_MODVERSIONS=y, which prevents to load even practically compatible modules.
  - rbanffy 9y ago
    The vendor would need to recompile their modules for every kernel Google releases, but that's not a huge issue - how many times does Google update the kernel?

fmntf 9y ago

All the ARM boards i know share our same kernel issues. The problem is that DT is basically a configuration, which is accessed by drivers. If a driver do not read it, you must edit the driver. For instance a 2 lines patch [1] is about the fec (ethernet) driver. DT can specify a sleep time before the PHY reset GPIO is toggled. However we need to sleep also after the toggle, hence the patch. [1] https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba41c7f7af86b99476055c2b46e86605 https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...