From: Hayes Wang
Date: Mon, 25 Aug 2014 06:43:02 +
> Except the step 3, 4, 6 and 7, the other steps depend on the
> context of the firmware. That is, for different firmware, some
> actions would be removed or added, and some settings would be
> different. Especially the step 8, it often diffe
From: David Miller [mailto:da...@davemloft.net]
[...]
> That still doesn't convince me.
>
> The functions I see you removing are just programming a set of
> registers in some way.
That is to clear the break point of the firmware. If a firmware exists,
you should clear it before updating a new o
From: Hayes Wang
Date: Mon, 25 Aug 2014 03:43:04 +
> From: David Miller [mailto:da...@davemloft.net]
> [...]
>> You haven't told us why you need to do this.
>>
>> These are just programming registers in the chip, and I see no reason
>> to not keep these in the driver with real code.
>>
>>
From: David Miller [mailto:da...@davemloft.net]
[...]
> You haven't told us why you need to do this.
>
> These are just programming registers in the chip, and I see no reason
> to not keep these in the driver with real code.
>
> I'm not applying this series, you haven't explained what is happen
From: Hayes Wang
Date: Wed, 20 Aug 2014 16:58:35 +0800
> Parsing, checking, and writing the firmware.
You haven't told us why you need to do this.
These are just programming registers in the chip, and I see no reason
to not keep these in the driver with real code.
I'm not applying this series,
