| Message ID | 20191008044153.12734-1-andrew@aj.id.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | pinctrl: Fixes for AST2600 support | expand |
On Tue, 8 Oct 2019 at 04:41, Andrew Jeffery <andrew@aj.id.au> wrote: > > Hello, > > This series resolves several issues found in testing by Johnny Huang from > ASPEED, who also contributed the patches to fix them. We'll have more patches > from him in the near future (which I'm pretty happy about). For the series: Reviewed-by: Joel Stanley <joel@jms.id.au> These patches have been in the OpenBMC tree for a while and look good. Cheers, Joel > > The major issue resolved is the way I grouped the eMMC pins. What I had was > ugly and I want to get rid of it before the binding is solidified with the 5.4 > release. > > The remaining fixes are minor issues that stem from lack of documentation or > understanding on my part, and at least one brain-fart. > > Please review! > > Andrew > > Andrew Jeffery (4): > dt-bindings: pinctrl: aspeed-g6: Rework SD3 function and groups > pinctrl: aspeed-g6: Sort pins for sanity > pinctrl: aspeed-g6: Fix I2C14 SDA description > pinctrl: aspeed-g6: Make SIG_DESC_CLEAR() behave intuitively > > Johnny Huang (3): > pinctrl: aspeed-g6: Fix I3C3/I3C4 pinmux configuration > pinctrl: aspeed-g6: Fix UART13 group pinmux > pinctrl: aspeed-g6: Rename SD3 to EMMC and rework pin groups > > .../pinctrl/aspeed,ast2600-pinctrl.yaml | 86 ++++++------ > drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 124 ++++++++---------- > drivers/pinctrl/aspeed/pinmux-aspeed.h | 3 +- > 3 files changed, 98 insertions(+), 115 deletions(-) > > -- > 2.20.1 >
On Tue, Oct 8, 2019 at 6:41 AM Andrew Jeffery <andrew@aj.id.au> wrote: > This series resolves several issues found in testing by Johnny Huang from > ASPEED, who also contributed the patches to fix them. We'll have more patches > from him in the near future (which I'm pretty happy about). > > The major issue resolved is the way I grouped the eMMC pins. What I had was > ugly and I want to get rid of it before the binding is solidified with the 5.4 > release. Should some of these go in with fixes? All of them? Or just some? I applied them to devel right now (for v5.5). > The remaining fixes are minor issues that stem from lack of documentation or > understanding on my part, and at least one brain-fart. Do they need to go in to v5.4 or not? I need a shortlist of anything that should go into v5.4 if anything. Yours, Linus Walleij
On Wed, 16 Oct 2019, at 21:49, Linus Walleij wrote: > On Tue, Oct 8, 2019 at 6:41 AM Andrew Jeffery <andrew@aj.id.au> wrote: > > > This series resolves several issues found in testing by Johnny Huang from > > ASPEED, who also contributed the patches to fix them. We'll have more patches > > from him in the near future (which I'm pretty happy about). > > > > The major issue resolved is the way I grouped the eMMC pins. What I had was > > ugly and I want to get rid of it before the binding is solidified with the 5.4 > > release. > > Should some of these go in with fixes? All of them? Or just some? > I applied them to devel right now (for v5.5). I was hoping to get them into the 5.4 fixes branch: I consider them all fixes - the rework of the eMMC pin groups and functions is a fix for the binding. The rest are fixes for the driver itself. My preference is that they get into a release sooner rather than later. It's there something that makes you think they shouldn't be merged as fixes for 5.4? > > > The remaining fixes are minor issues that stem from lack of documentation or > > understanding on my part, and at least one brain-fart. > > Do they need to go in to v5.4 or not? > > I need a shortlist of anything that should go into v5.4 if anything. IMO all of them should go into 5.4, as above. It's there something I can do in the future to communicate this better? Explicit shortlist in the cover letter? Fixes tags on the relevant patches? Keen to make things easier/more obvious if I can. Cheers, Andrew
On Wed, Oct 16, 2019 at 1:42 PM Andrew Jeffery <andrew@aj.id.au> wrote: > I was hoping to get them into the 5.4 fixes branch: I consider them all fixes OK I moved them all to fixes. > > I need a shortlist of anything that should go into v5.4 if anything. > > IMO all of them should go into 5.4, as above. OK > It's there something I can do in the future to communicate this better? Nah it is a complicated process, things need to be done manually at times, overly obsessing with process is counterproductive. Yours, Linus Walleij
On Thu, 17 Oct 2019, at 00:30, Linus Walleij wrote: > On Wed, Oct 16, 2019 at 1:42 PM Andrew Jeffery <andrew@aj.id.au> wrote: > > > I was hoping to get them into the 5.4 fixes branch: I consider them all fixes > > OK I moved them all to fixes. Thanks. > > > > I need a shortlist of anything that should go into v5.4 if anything. > > > > IMO all of them should go into 5.4, as above. > > OK > > > It's there something I can do in the future to communicate this better? > > Nah it is a complicated process, things need to be done manually > at times, overly obsessing with process is counterproductive. No worries, happy to carry on as is. Andrew