OMAP: GPIO: Use PM runtime framework
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest posting 5/50 of 7 patches 0 repliesNew
- v2 posting 4/50 of 7 patches 0 repliesSuperseded
- v2 posting 3/50 of 7 patches 0 repliesSuperseded
Earlier versions · 2
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 posting 2/5 | 0 of 7 patches | 0 replies | Superseded | |
| v2 posting 1/5 | 0 of 7 patches | 0 replies | Superseded |
Patches in v2 posting 5/5 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [v2 0/7] OMAP: GPIO: Use PM runtime framework
Quoted 5 lines · Linus Walleij
2011/5/3 Kevin Hilman <[email protected]>:
Quoted 2 lines
Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into
drivers/gpiofirst, followed by the cleanup/restructure patches?
Quoted 7 lines
In my case I actually did some cleanup after moving the driver for U300, but I think this is a question to the GPIO maintainer who I want to ACK this stuff in the end.
Grant?
You can always squash it later ...
Personally I would prefer absolutely minimal clean-up of current code before moving to drivers/gpio to cut down the "crazy churn" in arch/arm/. Also then further changes are easier for the GPIO maintainers to review.
Of course I understand that this might cause extra load for the GPIO maintainers, so it's up to the GPIO maintainers to set the required standards before accepting the code into drivers/gpio.
Regards,
Tony