Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <redacted>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/can/grcan.c | 8 ++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 ++++-----
2 files changed, 8 insertions(+), 9 deletions(-)
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <redacted>
This won't compile if I apply it.
You really have to be clear when you submit patches like this.
Since you only CC:'d the networking developers for this one
patch, there is _ZERO_ context for us to work with to understand
what's going on.
You have to also CC: us on the other relevant changes and your
"[PATCH 00/33]" posting that explains what is happening.
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding <redacted>
This won't compile if I apply it.
You really have to be clear when you submit patches like this.
Since you only CC:'d the networking developers for this one
patch, there is _ZERO_ context for us to work with to understand
what's going on.
You have to also CC: us on the other relevant changes and your
"[PATCH 00/33]" posting that explains what is happening.
I planned to do so initially, but that yielded a Cc list of 156 people
and mailing lists, which I thought wasn't going to go down so well
either. In general I like Cc'ing everyone concerned on all patches of
the series, specifically for reasons of context. Some people have been
annoyed when I did so. Still, for small series where only a few dozen
people are concerned that seems to me to be the best way. But 156 email
addresses is a different story.
Either you add to many people or you don't add enough. Where do we draw
the line?
Thierry
I planned to do so initially, but that yielded a Cc list of 156 people
and mailing lists, which I thought wasn't going to go down so well
either. In general I like Cc'ing everyone concerned on all patches of
the series, specifically for reasons of context. Some people have been
annoyed when I did so. Still, for small series where only a few dozen
people are concerned that seems to me to be the best way. But 156 email
addresses is a different story.
Either you add to many people or you don't add enough. Where do we draw
the line?
I've had the same problem a couple of times. The best compromise seems
to be to Cc only the top-level subsystem maintainers and mailing lists
on the first email.
Arnd
On Tue, Jan 22, 2013 at 01:03:06PM +0000, Arnd Bergmann wrote:
On Tuesday 22 January 2013, Thierry Reding wrote:
quoted
I planned to do so initially, but that yielded a Cc list of 156 people
and mailing lists, which I thought wasn't going to go down so well
either. In general I like Cc'ing everyone concerned on all patches of
the series, specifically for reasons of context. Some people have been
annoyed when I did so. Still, for small series where only a few dozen
people are concerned that seems to me to be the best way. But 156 email
addresses is a different story.
Either you add to many people or you don't add enough. Where do we draw
the line?
I've had the same problem a couple of times. The best compromise seems
to be to Cc only the top-level subsystem maintainers and mailing lists
on the first email.
Even that would have been about 50 addresses IIRC. But perhaps that's
still the best compromise to avoid any confusion.
Thierry
I've had the same problem a couple of times. The best compromise seems
to be to Cc only the top-level subsystem maintainers and mailing lists
on the first email.
Even that would have been about 50 addresses IIRC. But perhaps that's
still the best compromise to avoid any confusion.
Be careful though that the Cc list must not exceed 1024 characters or
it will get rejected by some of the mailing list servers.
Arnd
I planned to do so initially, but that yielded a Cc list of 156 people
and mailing lists, which I thought wasn't going to go down so well
either. In general I like Cc'ing everyone concerned on all patches of
the series, specifically for reasons of context. Some people have been
annoyed when I did so. Still, for small series where only a few dozen
people are concerned that seems to me to be the best way. But 156 email
addresses is a different story.
Either you add to many people or you don't add enough. Where do we draw
the line?
I've had the same problem a couple of times. The best compromise seems
to be to Cc only the top-level subsystem maintainers and mailing lists
on the first email.
CC:'ing individuals is pointless, CC: only the subsystem lists in
question, the maintainers had better be reading those lists.