On Mon, Oct 14, 2024 at 11:53:47AM +0800, Chen-Yu Tsai wrote: > On Thu, Oct 10, 2024 at 11:16 PM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > On Tue, Oct 08, 2024 at 03:34:23PM +0800, Chen-Yu Tsai wrote: ... > > Fresh reading of the commit message make me think why the firmware or > > bootloader on such a device can't form a dynamic OF (overlay?) to fulfill > > the need? > > The firmware / bootloader on existing devices are practically not upgradable. > On the other hand, the kernel is very easy to upgrade or swap out. > > For said shipped devices, there is also nothing to key the detection > off of besides actually powering things up and doing I2C transfers, > which takes time that the firmware has little to spare. We (ChromeOS) > require that the bootloader jump into the kernel within 1 second of > power on. That includes DRAM calibration, whatever essential hardware > initialization, and loading and uncompressing the kernel. Anything > non-essential that can be done in the kernel is going to get deferred > to the kernel. > > Also, due to project timelines oftentimes the devices are shipped with a > downstream kernel with downstream device trees. We don't want to tie the > firmware too tightly to the device tree in case the downstream stuff gets > reworked when upstreamed. Okay, I was always under impression that DT has at least one nice feature in comparison with ACPI that it can be replaced / updated in much quicker / independent manner. What you are telling seems like the same issue that ACPI-based platforms have. However, there they usually put all possible devices into DSDT and firmware enables them via run-time (ACPI) variables. Are you trying to implement something similar here? ... > > Another question is that we have the autoprobing mechanism for I2C for ages, > > why that one can't be (re-)used / extended to cover these cases? > > I haven't looked into it very much, but a quick read of > Documentation/i2c/instantiating-devices.rst suggests that it's solving > a different problem? > > In our case, we know that it is just one of a handful of possible > devices that we already described in the device tree. We don't need > to probe the full address range nor the full range of drivers. We > already have a hacky workaround in place, but that mangles the > device tree in a way that doesn't really match the hardware. > > The components that we are handling don't seem to have any hardware > ID register, nor do their drivers implement the .detect() callback. > There's also power sequencing (regulator and GPIO lines) and interrupt > lines from the device tree that need to be handled, something that is > missing in the autoprobe path. > > Based on the above I don't think the existing autoprobe is a good fit. > Trying to shoehorn it in is likely going to be a mess. > > Doug's original cover letter describes the problem in more detail, > including why we think this should be done in the kernel, not the > firmware: > https://lore.kernel.org/all/20230921102420.RFC.1.I9dddd99ccdca175e3ceb1b9fa1827df0928c5101@changeid/ Perhaps it needs to be summarised to cover at least this question along with the above? -- With Best Regards, Andy Shevchenko
