Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[[email protected]: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing