2021年9月30日(木) 18:23 Lee Jones <lee.jones@xxxxxxxxxx>: > > I've taken the liberty of cherry-picking some of the points you have > reiteratted a few times. Hopefully I can help to address them > adequently. > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote: > > Reminder: these are essential drivers and all Exynos platforms must have > > them as built-in (at least till someone really tests this on multiple > > setups). > > > Therefore I don't agree with calling it a "problem" that we select > > *necessary* drivers for supported platforms. It's by design - supported > > platforms should receive them without ability to remove. > > > The selected drivers are essential for supported platforms. > > SoC specific drivers are only essential/necessary/required in > images designed to execute solely on a platform that requires them. > For a kernel image which is designed to be generic i.e. one that has > the ability to boot on vast array of platforms, the drivers simply > have to be *available*. > > Forcing all H/W drivers that are only *potentially* utilised on *some* > platforms as core binary built-ins doesn't make any technical sense. > The two most important issues this causes are image size and a lack of > configurability/flexibility relating to real-world application i.e. > the one issue we already agreed upon; H/W or features that are too > new (pre-release). > > Bloating a generic kernel with potentially hundreds of unnecessary > drivers that will never be executed in the vast majority of instances > doesn't achieve anything. If we have a kernel image that has the > ability to boot on 10's of architectures which have 10's of platforms > each, that's a whole host of unused/wasted executable space. > > In order for vendors to work more closely with upstream, they need the > ability to over-ride a *few* drivers to supplement them with some > functionality which they believe provides them with a competitive edge > (I think you called this "value-add" before) prior to the release of a > device. This is a requirement that cannot be worked around. [Chiming in as a clock driver sub-maintainer and someone who spent a non-insignificant part of his life on SoC driver bring-up - not as a Google employee.] I'd argue that the proper way for them to achieve it would be to extend the upstream frameworks and/or existing drivers with appropriate APIs to allow their downstream modules to plug into what's already available upstream. Best regards, Tomasz
