Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v7 21/34] i2c: tegra: Don't fall back to PIO mode if DMA
 configuration fails
To:     Thierry Reding <thierry.reding@gmail.com>
Cc:     Jonathan Hunter <jonathanh@nvidia.com>,
        Laxman Dewangan <ldewangan@nvidia.com>,
        Wolfram Sang <wsa@the-dreams.de>,
        =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20200908224006.25636-1-digetx@gmail.com>
 <20200908224006.25636-22-digetx@gmail.com> <20200917114716.GZ3515672@ulmo>
From:   Dmitry Osipenko <digetx@gmail.com>
Message-ID: <b2f68a72-9117-89d1-70f3-750ddc235482@gmail.com>
Date:   Thu, 17 Sep 2020 18:03:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200917114716.GZ3515672@ulmo>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

17.09.2020 14:47, Thierry Reding пишет:
> On Wed, Sep 09, 2020 at 01:39:53AM +0300, Dmitry Osipenko wrote:
>> The DMA code path has been tested well enough and the DMA configuration
>> performed by tegra_i2c_config_fifo_trig() shouldn't ever fail in practice.
>> Hence let's remove the obscure transfer-mode switching in order to have a
>> cleaner and simpler code. Now I2C transfer will be failed if DMA
>> configuration fails.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/i2c/busses/i2c-tegra.c | 18 ++++++++++--------
>>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> I'm not sure that's a good idea. It's always possible that the DMA setup
> is going to break because of something that's not related to the I2C
> driver itself. Having the system completely break instead of falling
> back to PIO mode seems like it would only complicate troubleshooting any
> such issues.

That code has zero test coverage because this problem never happens in
practice, hence it should be better to have it removed. We may consider
re-adding it back if there will be a real-world incident, okay?