From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
Necip Fazil Yildiran <fazilyildiran@gmail.com>,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v1] soc/tegra: fuse: Drop Kconfig dependency on TEGRA20_APB_DMA
Date: Mon, 16 Nov 2020 16:48:39 +0300 [thread overview]
Message-ID: <4699e7eb-ac82-4666-9bca-7692d5441b3f@gmail.com> (raw)
In-Reply-To: <20201116132005.GD2224373@ulmo>
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.
next prev parent reply other threads:[~2020-11-16 13:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 0:34 [PATCH v1] soc/tegra: fuse: Drop Kconfig dependency on TEGRA20_APB_DMA Dmitry Osipenko
2020-11-16 10:04 ` Dmitry Osipenko
2020-11-16 13:20 ` Thierry Reding
2020-11-16 13:48 ` Dmitry Osipenko [this message]
2020-11-16 16:49 ` Thierry Reding
2020-11-16 19:16 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4699e7eb-ac82-4666-9bca-7692d5441b3f@gmail.com \
--to=digetx@gmail.com \
--cc=fazilyildiran@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox