[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220119163012.4274665d@endymion>
Date: Wed, 19 Jan 2022 16:30:12 +0100
From: Jean Delvare <jdelvare@...e.de>
To: Terry Bowman <terry.bowman@....com>
Cc: <linux@...ck-us.net>, <linux-watchdog@...r.kernel.org>,
<jdelvare@...e.com>, <linux-i2c@...r.kernel.org>, <wsa@...nel.org>,
<andy.shevchenko@...il.com>, <rafael.j.wysocki@...el.com>,
<linux-kernel@...r.kernel.org>, <wim@...ux-watchdog.org>,
<rrichter@....com>, <thomas.lendacky@....com>,
<Nehal-bakulchandra.Shah@....com>, <Basavaraj.Natikar@....com>,
<Shyam-sundar.S-k@....com>, <Mario.Limonciello@....com>
Subject: Re: [PATCH v3 0/4] Watchdog: sp5100_tco: Replace cd6h/cd7h port I/O
accesses with MMIO accesses
Hi Terry,
On Tue, 18 Jan 2022 14:22:30 -0600, Terry Bowman wrote:
> This series uses request_mem_region() to synchronize accesses to the MMIO
> registers mentioned above. request_mem_region() is missing the retry
> logic in the case the resource is busy. As a result, request_mem_region()
> will fail immediately if the resource is busy. The 'muxed' variant is
> needed here but request_muxed_mem_region() is not defined to use. I will
> follow up with another patch series to define the
> request_muxed_mem_region() and use in both drivers.
Shouldn't this be done the other way around, first introducing
request_muxed_mem_region() and then using it directly in both drivers,
rather than having a temporary situation where a failure can happen?
As far as I'm concerned, the patch series you just posted are
acceptable only if request_muxed_mem_region() gets accepted too.
Otherwise we end up with the situation where a driver could randomly
fail.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists