| Message ID | 20180520051736.4842-6-manivannan.sadhasivam@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Add gpio support for Action Semi S900 SoC | expand |
On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote: > Add S900 pinctrl entries under ARCH_ACTIONS > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Patch applied tentatively so we have some maintenance entry for this. Andreas expressed concerns about the driver earlier, so he might want it split from the platform parts and have a separate entry for the pinctrl+GPIO so Manivannan can maintain that part, also it makes sense to list Manivannan as comaintainer of ARCH_ACTIONS with this in. Andreas: how would you like to proceed? I understand that I was a bit pushy or even rude in my last message about the maintenance of this platform and the code structure of the pin control driver. I am sorry if it caused any bad feelings on your side :( social conflicts give me the creeps, I just try my best. Maybe my best isn't always what it should be. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.05.2018 um 10:40 schrieb Linus Walleij: > On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam > <manivannan.sadhasivam@linaro.org> wrote: > >> Add S900 pinctrl entries under ARCH_ACTIONS >> >> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > Patch applied tentatively so we have some maintenance entry for this. > > Andreas expressed concerns about the driver earlier, so he might want it > split from the platform parts and have a separate entry for the pinctrl+GPIO > so Manivannan can maintain that part, also it makes sense to list > Manivannan as comaintainer of ARCH_ACTIONS with this in. > > Andreas: how would you like to proceed? > > I understand that I was a bit pushy or even rude in my last message > about the maintenance of this platform and the code structure of > the pin control driver. I am sorry if it caused any bad feelings on your > side :( social conflicts give me the creeps, I just try my best. Maybe > my best isn't always what it should be. I fail to understand how splitting the MAINTAINERS section is going to help with the pinctrl conflict at hand? The problem is that instead of refactoring my S500 pinctrl driver to his liking, Mani has submitted a competing S900 pinctrl driver that you went on to merge. The human aspect is that merging his driver took the credit away from me having written the earlier pinctrl driver (based on my rtd1295 pinctrl driver). The practical aspect is that I can't drop my pinctrl driver from my work branch until there is equivalent functionality in the merged driver. I am lacking the time to rewrite S500 pin definitions on top of Mani's myself at this time, and I haven't seen S500 patches from him yet. Also I had been investing efforts in explaining the upstreaming process to Actions, last in November. I see Thomas Liau and Jeff Chen missing in CC and I have not seen any Reviewed-by or Acked-by from anyone at Actions on this and the preceding series. There are more chips than the one on Linaro's 96board, so I would prefer to assure that the design works for all. Thus I am very critical of you applying the patches without waiting for review by Actions. Other aspects are: The reason I wrote the pinctrl driver is that I experienced a UART TX issue on the Sparky board and was hoping a pinctrl driver might resolve that, but it didn't. So I still have a mix of boards where some are working and some are pretty unusable, without any clues on why. That said, I don't object to having a separate MAINTAINERS section for the pinctrl driver(s) as long as I still get CC'ed on changes. We have wanted to add Mani as R for Actions overall, so that would probably mean adding me as R to an Actions pinctrl section, to avoid syncing the paths between two sections. I had previously felt that it does not make sense to list Mani as co-maintainer (M) for Actions overall since he can't tag and submit from my repo. And for the record I have offered him to take over which he didn't want to. I still hope to find some more time to review and queue his SPS patches, a driver that I have designed and thus understand and am much happier about the incremental additions there. A further side note is that I had reached out about setting up an infradead mailing list linux-actions, but there was no response from David or anyone. Having an L on the section(s) would avoid messing with R and hand-maintained CC lists. Any help with that appreciated. Regards, Andreas
Hi Andreas, On Fri, May 25, 2018 at 06:12:00AM +0200, Andreas Färber wrote: > Am 23.05.2018 um 10:40 schrieb Linus Walleij: > > On Sun, May 20, 2018 at 7:17 AM, Manivannan Sadhasivam > > <manivannan.sadhasivam@linaro.org> wrote: > > > >> Add S900 pinctrl entries under ARCH_ACTIONS > >> > >> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > > > Patch applied tentatively so we have some maintenance entry for this. > > > > Andreas expressed concerns about the driver earlier, so he might want it > > split from the platform parts and have a separate entry for the pinctrl+GPIO > > so Manivannan can maintain that part, also it makes sense to list > > Manivannan as comaintainer of ARCH_ACTIONS with this in. > > > > Andreas: how would you like to proceed? > > > > I understand that I was a bit pushy or even rude in my last message > > about the maintenance of this platform and the code structure of > > the pin control driver. I am sorry if it caused any bad feelings on your > > side :( social conflicts give me the creeps, I just try my best. Maybe > > my best isn't always what it should be. > > I fail to understand how splitting the MAINTAINERS section is going to > help with the pinctrl conflict at hand? The problem is that instead of > refactoring my S500 pinctrl driver to his liking, Mani has submitted a > competing S900 pinctrl driver that you went on to merge. The human > aspect is that merging his driver took the credit away from me having > written the earlier pinctrl driver (based on my rtd1295 pinctrl driver). > The practical aspect is that I can't drop my pinctrl driver from my work > branch until there is equivalent functionality in the merged driver. I > am lacking the time to rewrite S500 pin definitions on top of Mani's > myself at this time, and I haven't seen S500 patches from him yet. > I think we discussed this few more times before and I clearly mentioned this pinctrl driver confilct in my old pinctrl series cover letter. If you had submitted your pinctrl driver then Linus would had the option of picking up the most robust one. But sadly you didn't had any time to complete and submit yours and since there was only one pinctrl driver floating for Actions, Linus went and merged mine. Regarding the S500/S700 support, again I told you that my goal is to set up the base driver for Actions OWL series SoC first and then adding support for every other SoC's of the same family later. Now, I have succeeded in setting up the clock, pinctrl and gpio drivers, so I can now work on extending support for other SoC's as well. FYI, I have ordered S700 based Cubieboard and will work on adding support for that first. I still don't have access to S500 board yet since it is not available on my region. Will find a way to get this asap. > Also I had been investing efforts in explaining the upstreaming process > to Actions, last in November. I see Thomas Liau and Jeff Chen missing in > CC and I have not seen any Reviewed-by or Acked-by from anyone at > Actions on this and the preceding series. There are more chips than the > one on Linaro's 96board, so I would prefer to assure that the design > works for all. Thus I am very critical of you applying the patches > without waiting for review by Actions. > I don't think Actions would be interested in any upstreaming efforts. It is our (comunity) responsibility to add support for that in order to have our boards running mainline kernel and that's what we both have been doing. Moreover I only saw once David Liau responded to your patchset and there isn't much further. So how can you expect the subsystem maintainer's to hold the patch series waiting for a so far silent SoC manufacturer's response? We should get move on and since my drivers are completely tested, we can work on adding more SoC support later. And if something breaks on other SoC platform, we can always modify the base driver accordingly. > Other aspects are: The reason I wrote the pinctrl driver is that I > experienced a UART TX issue on the Sparky board and was hoping a pinctrl > driver might resolve that, but it didn't. So I still have a mix of > boards where some are working and some are pretty unusable, without any > clues on why. > > That said, I don't object to having a separate MAINTAINERS section for > the pinctrl driver(s) as long as I still get CC'ed on changes. We have > wanted to add Mani as R for Actions overall, so that would probably mean > adding me as R to an Actions pinctrl section, to avoid syncing the paths > between two sections. I had previously felt that it does not make sense > to list Mani as co-maintainer (M) for Actions overall since he can't tag > and submit from my repo. And for the record I have offered him to take > over which he didn't want to. I still hope to find some more time to > review and queue his SPS patches, a driver that I have designed and thus > understand and am much happier about the incremental additions there. > Yes I agree that you offered me to take the Maintainership once through IRC conversation, but I kind of refused it because I don't want to completely take over the maintainership role from you since you did a great job in getting the base SoC support mainlined initially. On the other hand, I did ask you to add me as Co-Maintainer but you didn't responded to that. I know that I can't send any pull requests to Arnd, but we should sort it out IMO. Also, if you are completely swamped, then I take take up the maintainership role now inorder to keep the things moving. TBH I don't want my patches to be floating for months without any reason. > A further side note is that I had reached out about setting up an > infradead mailing list linux-actions, but there was no response from > David or anyone. Having an L on the section(s) would avoid messing with > R and hand-maintained CC lists. Any help with that appreciated. > This is something we have to look out for and I will also see the possibility of setting up the mailing list from my side. Thanks for all of your great efforts! Regards, Mani > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 25, 2018 at 6:12 AM, Andreas Färber <afaerber@suse.de> wrote: > I fail to understand how splitting the MAINTAINERS section is going to > help with the pinctrl conflict at hand? OK let's keep it like it is then, one entry. >The problem is that instead of > refactoring my S500 pinctrl driver to his liking, Mani has submitted a > competing S900 pinctrl driver that you went on to merge. The human > aspect is that merging his driver took the credit away from me having > written the earlier pinctrl driver (based on my rtd1295 pinctrl driver). > The practical aspect is that I can't drop my pinctrl driver from my work > branch until there is equivalent functionality in the merged driver. I > am lacking the time to rewrite S500 pin definitions on top of Mani's > myself at this time, and I haven't seen S500 patches from him yet. I am sorry if you feel you are being treated unfairly. I can't help to think about the old IT project motto "always calculate to throw one version away". We are always going to have a bit of collateral damage around out sometimes chaotic and unstructured development process. I haven't seen this S500 patch posted anywhere on the pin control official mailing list. As subsystem maintainer I have a vast flow of information already, actively polling around other subcommunities is simply not possible for me. I need to deal with what ends up on the list, I think it would have been better if you simply posted your S500 driver at the time, no matter the state. "Release early, release often" and discuss design on the GPIO mailing list where I can see it, so I have some idea what is going on here. > Also I had been investing efforts in explaining the upstreaming process > to Actions, last in November. I see Thomas Liau and Jeff Chen missing in > CC and I have not seen any Reviewed-by or Acked-by from anyone at > Actions on this and the preceding series. There are more chips than the > one on Linaro's 96board, so I would prefer to assure that the design > works for all. Thus I am very critical of you applying the patches > without waiting for review by Actions. It is not too late to take it out if there is some problem from their side. When I merge a driver it doesn't mean "definately approved, will send to Torvalds", type of "seal of approval" it rather usually it means "I want to test it in linux-next in due time for the merge window". I don't mind taking it out if there are problems, and I do not mind even reverting it in the -rc phase if there are problems. I don't mind having to revert patches like this or even rebasing the tree if required. However if they do not come back at all within some week or two that is passivity and then it goes in. > Other aspects are: The reason I wrote the pinctrl driver is that I > experienced a UART TX issue on the Sparky board and was hoping a pinctrl > driver might resolve that, but it didn't. So I still have a mix of > boards where some are working and some are pretty unusable, without any > clues on why. Hm how typical :/ Getting to serial is paramount to getting anywhere with the hacking. I see this becomes a bit of showstopper for your development work here. > That said, I don't object to having a separate MAINTAINERS section for > the pinctrl driver(s) as long as I still get CC'ed on changes. We have > wanted to add Mani as R for Actions overall, so that would probably mean > adding me as R to an Actions pinctrl section, to avoid syncing the paths > between two sections. No problem we keep it to one entry. > I had previously felt that it does not make sense > to list Mani as co-maintainer (M) for Actions overall since he can't tag > and submit from my repo. And for the record I have offered him to take > over which he didn't want to. I still hope to find some more time to > review and queue his SPS patches, a driver that I have designed and thus > understand and am much happier about the incremental additions there. OK nice! > A further side note is that I had reached out about setting up an > infradead mailing list linux-actions, but there was no response from > David or anyone. Having an L on the section(s) would avoid messing with > R and hand-maintained CC lists. Any help with that appreciated. We can talk to kernel.org about setting up a list, that probably works quicker. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 25, 2018 at 7:01 AM, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote: > FYI, I have ordered S700 based Cubieboard and will work on adding support for > that first. I still don't have access to S500 board yet since it is not > available on my region. Will find a way to get this asap. Awesome, then we can count on some actions action here. >> Also I had been investing efforts in explaining the upstreaming process >> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in >> CC and I have not seen any Reviewed-by or Acked-by from anyone at >> Actions on this and the preceding series. There are more chips than the >> one on Linaro's 96board, so I would prefer to assure that the design >> works for all. Thus I am very critical of you applying the patches >> without waiting for review by Actions. > > I don't think Actions would be interested in any upstreaming efforts. It > is our (comunity) responsibility to add support for that in order to > have our boards running mainline kernel and that's what we both have been > doing. Moreover I only saw once David Liau responded to your patchset and > there isn't much further. So how can you expect the subsystem maintainer's > to hold the patch series waiting for a so far silent SoC manufacturer's > response? They are certainly informed now! :D Actions semi folks, please familiarize yourself with the following: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt?h=devel https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/drivers/pinctrl/actions?h=devel If you have any concerns with this, now is a good time to share them. > I > did ask you to add me as Co-Maintainer but you didn't responded to that. > I know that I can't send any pull requests to Arnd, but we should sort > it out IMO. Also, if you are completely swamped, then I take take up the > maintainership role now inorder to keep the things moving. TBH I don't > want my patches to be floating for months without any reason. Doing some comainatinership can very well include doing pull requests as long as you agree on who does what. I think it may be a bit late for the next merge window right now, but if you simply queue up stuff in some git tree and ask Srothwell to include it in linux-next then Andreas can very well pull it to his tree from there and then to ARM SoC or you can queue patches as well. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 25, 2018 at 02:12:06PM +0200, Linus Walleij wrote: > On Fri, May 25, 2018 at 7:01 AM, Manivannan Sadhasivam > <manivannan.sadhasivam@linaro.org> wrote: > > > FYI, I have ordered S700 based Cubieboard and will work on adding support for > > that first. I still don't have access to S500 board yet since it is not > > available on my region. Will find a way to get this asap. > > Awesome, then we can count on some actions action here. > Oops... Small correction here, I have ordered S500 based board. > >> Also I had been investing efforts in explaining the upstreaming process > >> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in > >> CC and I have not seen any Reviewed-by or Acked-by from anyone at > >> Actions on this and the preceding series. There are more chips than the > >> one on Linaro's 96board, so I would prefer to assure that the design > >> works for all. Thus I am very critical of you applying the patches > >> without waiting for review by Actions. > > > > I don't think Actions would be interested in any upstreaming efforts. It > > is our (comunity) responsibility to add support for that in order to > > have our boards running mainline kernel and that's what we both have been > > doing. Moreover I only saw once David Liau responded to your patchset and > > there isn't much further. So how can you expect the subsystem maintainer's > > to hold the patch series waiting for a so far silent SoC manufacturer's > > response? > > They are certainly informed now! :D > > Actions semi folks, please familiarize yourself with the following: > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt?h=devel > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/drivers/pinctrl/actions?h=devel > > If you have any concerns with this, now is a good time to share them. > > > I > > did ask you to add me as Co-Maintainer but you didn't responded to that. > > I know that I can't send any pull requests to Arnd, but we should sort > > it out IMO. Also, if you are completely swamped, then I take take up the > > maintainership role now inorder to keep the things moving. TBH I don't > > want my patches to be floating for months without any reason. > > Doing some comainatinership can very well include doing pull > requests as long as you agree on who does what. > > I think it may be a bit late for the next merge window right now, > but if you simply queue up stuff in some git tree and ask > Srothwell to include it in linux-next then Andreas can very well > pull it to his tree from there and then to ARM SoC or you can > queue patches as well. > Cool. Will queue up all approved dts patches in a git tree and share it with andreas. Thanks, Mani > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/MAINTAINERS b/MAINTAINERS index 640dabc4c311..9e1a17c9b4a7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1125,10 +1125,12 @@ F: arch/arm/mach-actions/ F: arch/arm/boot/dts/owl-* F: arch/arm64/boot/dts/actions/ F: drivers/clocksource/owl-* +F: drivers/pinctrl/actions/* F: drivers/soc/actions/ F: include/dt-bindings/power/owl-* F: include/linux/soc/actions/ F: Documentation/devicetree/bindings/arm/actions.txt +F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt F: Documentation/devicetree/bindings/power/actions,owl-sps.txt F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
Add S900 pinctrl entries under ARCH_ACTIONS Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+)