[PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs

[Vladimir Zapolskiy]

Hi Uwe,

On 12/23/2016 12:01 PM, Uwe Kleine-König wrote:
> On Fri, Dec 23, 2016 at 11:27:24AM +0200, Vladimir Zapolskiy wrote:
>> On 12/23/2016 10:32 AM, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Fri, Dec 23, 2016 at 10:20:20AM +0200, Vladimir Zapolskiy wrote:
>>>> On 12/23/2016 03:55 AM, Guenter Roeck wrote:
>>>>> What is the ultimate conclusion of this exchange ?
>>>>>
>>>>> Are we going to get another version of the patch, or did everyone agree that
>>>>> the patch is good as it is and does not require further changes ?
>>>>>
>>>>
>>>> I can not imagine a different fix.
>>>
>>> my preferred fix would be:
>>>
>>>  - add an imx35 compatible to all newer dtsi
>>>  - update the driver to only write the wmcr on imx35 compatible devices
>>>    adding only imx35.
>>>
>>
>> It breaks old DTS vs. new kernel compatibility, I've already mentioned this.
> 
> Correct, and I didn't deny that. In my mail I pointed out the problem
> this imposes and I think it's small enough to not justify the complexity
> introduced in your proposed change.
> 

I can not statistically estimate well the severity of the problem which was
fixed by commit 5fe65ce7cc (all boards with a similar change not found in
a bootloader will be affected, I believe) multiplied by the rate of users,
who don't update DTB. But statistically the probability is non-zero, and
thus it is better to consider that the new problem which I still resist to
introduce will hit somebody.

> If we cannot agree then at least this needs to be better documented in
> the driver because otherwise someone makes a cleanup later dropping all
> the compatibles that are needed to keep backwards compatibility.
> 

My position is to avoid fixing a bug by introducing another known in
advance bug, IMHO it overrules your statement about data redundancy.

Here I'd like to separate responsibilities. If somebody cleans the list
of compatibles up and it accidentally causes problems, the author of that
commit will be blamed and that commit will be reverted, and the revert
commit won't touch my fix -- make i.MX31 boards boot again.

> But my suggestion is to first do the minimal fix, and if in the next
> merge window people lament about breakages on their machine, we can
> still extend the simple fix to a fully backwards compatible change.

Let's fix one problem stated in the commit subject cleanly and without
any known side effects like I suggest, a questionable and optional purge
of compatibles can be done by somebody else later on.

--
With best wishes,
Vladimir