On 2012年07月30日 23:16, Alan Stern wrote:
On Mon, 30 Jul 2012, Oliver Neukum wrote:
On Monday 30 July 2012 10:39:50 Alan Stern wrote:
this leads to behavior that is not easy to predict or understand.
It would be cleaner to leave the flag alone and check for the quirk
in addition for the flag when the check is done.
I disagree. Leaving the flag set but then not implementing the
persist behavior would be confusing also. Maybe even worse.
But we cannot guarantee persistance anyway. We can only try.
But trying makes no sense if we are sure to fail.
In addition, we even undermine the file permission to a small
extent if we allow one attribute to alter another attribute.
Putting all these thoughts together leads to a single conclusion:
We should not change persist_enabled when avoid_reset_quirk
gets set.
As you say, coupling the two attributes is confusing and circumvents
the permissions. If the device needs a reset-resume, we'll go ahead
and try to do it. If the reset fails because the firmware gets erased,
at least there will be an error message in the system log to explain
what went wrong. (But it's still a good idea to add a sentence about
this issue to the Documentation file.)
Whereas if we silently change attribute values or silently skip a
reset-resume when RESET_MORPHS is set, there will be no indication in
the log or anywhere else to tell the user what happened.
How about checking RESET_MORPHS before doing reset_resume, set reset_resume
to 0 and do resume when RESET_MORPHS is set. At the same time, print "Convert
reset_resume to resume due to RESET_MORPHS". Then these two attributes are
separated but for reset-resume, there are two conditions. persist is true
RESET_MORPHS is unset.
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
