16.11.2020 16:20, Thierry Reding пишет: > On Wed, Sep 23, 2020 at 03:34:21AM +0300, Dmitry Osipenko wrote: >> The DMA subsystem could be entirely disabled in Kconfig and then the >> TEGRA20_APB_DMA option isn't available too. Hence kernel configuration >> fails if DMADEVICES Kconfig option is disabled due to the unsatisfiable >> dependency. >> >> The FUSE driver isn't a critical driver and currently it only provides >> NVMEM interface to userspace which isn't known to be widely used, and >> thus, it's fine if FUSE driver fails to load. > > This isn't entirely accurate. The FUSE driver also provides SKU specific > information via tegra_sku_info and exposes some of the FUSE registers to > other drivers, such as the calibration data for XUSB. The SKU data is read out only once during early boot and the DMA is not used for this. The FUSE platform driver exists separately from the early FUSE code. > The APB DMA is really only needed to work around an issue on Tegra20, so > perhaps this really is okay. On the other hand, could we not just change > the dependency to something like > > select DMADEVICES if ARCH_TEGRA_2x_SOC > select TEGRA20_APB_DMA if ARCH_TEGRA_2x_SOC > > to fix the Kconfig issue but keep the explicit documentation of this > dependency? On Tegra20, the APB DMA is used only for by NVMEM which is exposed via sysfs. If DMA is disabled, then NVMEM isn't registered because tegra20_fuse_probe() returns -EPROBE_DEFER. Hence there is no real need to enforce the extra dependencies. It's always better to allow minimizing the build dependencies whenever possible, IMO, and it's possible to do it in this case.
