| Message ID | 20190425232028.9333-1-fancer.lancer@gmail.com |
|---|---|
| Headers | show |
| Series | i2c-mux-gpio: Split plat- and dt-specific code up | expand |
Hello folks, Any updates on this patchset status? I haven't got any comment on v2, but instead a notification about the status change was sent to me: > * linux-i2c: [v2,1/3] i2c-mux-gpio: Unpin a platform-based device initialization > - http://patchwork.ozlabs.org/patch/1091120/ > - for: Linux I2C development > was: New > now: Superseded > > * linux-i2c: [v2,2/3] i2c-mux-gpio: Unpin the platform-specific GPIOs request code > - http://patchwork.ozlabs.org/patch/1091122/ > - for: Linux I2C development > was: New > now: Superseded > > * linux-i2c: [v2,3/3] i2c-mux-gpio: Create of-based GPIOs request method > - http://patchwork.ozlabs.org/patch/1091121/ > - for: Linux I2C development > was: New > now: Superseded I may misunderstand something, but how come the v2 patchset switched to be superseded while it is the last patchset version I've sent? -Sergey On Fri, Apr 26, 2019 at 02:20:25AM +0300, Serge Semin wrote: > The main idea of this patchset was to add the full dt GPIOs specifier > support in i2c-mux-gpio driver. In particular we needed to have the > full GPIOs specifier being handled including the flags like GPIO_ACTIVE_HIGH, > GPIO_ACTIVE_LOW, GPIO_PUSH_PULL, GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE. > Due to using a legacy GPIO interface the former driver implementation > didn't provide this ability. > > On the way of adding the full dt-GPIO flags support a small set of > refactorings has been done in order to keep the platform_data-based > systems support, make the code more readable and the alterations - clearer. > In general the whole changes might be considered as the plat- and dt- > specific code split up. In the first patch we unpinned the platform-specific > method of GPIO-chip probing. The second patch introduces a new initial_state > value field into the "gpiomux" structure. The third one is responsible for > GPIO request loop isoltaing into a dedicated function. At this stage common > it is a common function for both dt- and plat- code paths. Finally last > patch introduces a full dt-based GPIOs request method, which uses > gpiod_get_from_of_node() method in order to parse the corresponding dt GPIO > specifiers with their falgs. The last patch does what we inteded this patchset > for in the first place - adds the full dt-GPIO specifiers support. > > Changelog v2 > - Remove fallback pattern when selecting the dt- or plat-based code paths. > (Cause the patch "i2c-mux-gpio: Return an error if no onfig data found" > removal.) > - Use a dedicated initial_state variable to keep the initial channels selector > state. (Causes the patch "i2c-mux-gpio: Save initial channel number to the > idle" removal.) > - Mention open-drain, open-source flags in the patchset descriptions. > > > Serge Semin (3): > i2c-mux-gpio: Unpin a platform-based device initialization > i2c-mux-gpio: Unpin the platform-specific GPIOs request code > i2c-mux-gpio: Create of-based GPIOs request method > > drivers/i2c/muxes/i2c-mux-gpio.c | 226 ++++++++++++++++++++----------- > 1 file changed, 146 insertions(+), 80 deletions(-) > > -- > 2.21.0 >
On 2019-05-07 11:02, Serge Semin wrote: > Hello folks, > > Any updates on this patchset status? I haven't got any comment on v2, but > instead a notification about the status change was sent to me: > >> * linux-i2c: [v2,1/3] i2c-mux-gpio: Unpin a platform-based device initialization >> - http://patchwork.ozlabs.org/patch/1091120/ >> - for: Linux I2C development >> was: New >> now: Superseded >> >> * linux-i2c: [v2,2/3] i2c-mux-gpio: Unpin the platform-specific GPIOs request code >> - http://patchwork.ozlabs.org/patch/1091122/ >> - for: Linux I2C development >> was: New >> now: Superseded >> >> * linux-i2c: [v2,3/3] i2c-mux-gpio: Create of-based GPIOs request method >> - http://patchwork.ozlabs.org/patch/1091121/ >> - for: Linux I2C development >> was: New >> now: Superseded > > I may misunderstand something, but how come the v2 patchset switched to be superseded > while it is the last patchset version I've sent? That was my mistake. Patchwork got confused when v2 was sent as a reply to something in the v1 tree, and marked all 8 patches as "v2". Then I in turn got confused by that, and changed status on the wrong set. Sorry! So, thanks for the heads up, it should be fixed now. As for comments on the patches, I'm personally buried in work and others may have the merge window to focus on... Cheers, Peter
Hello Peter On Tue, May 07, 2019 at 09:17:38AM +0000, Peter Rosin wrote: > On 2019-05-07 11:02, Serge Semin wrote: > > Hello folks, > > > > Any updates on this patchset status? I haven't got any comment on v2, but > > instead a notification about the status change was sent to me: > > > >> * linux-i2c: [v2,1/3] i2c-mux-gpio: Unpin a platform-based device initialization > >> - http://patchwork.ozlabs.org/patch/1091120/ > >> - for: Linux I2C development > >> was: New > >> now: Superseded > >> > >> * linux-i2c: [v2,2/3] i2c-mux-gpio: Unpin the platform-specific GPIOs request code > >> - http://patchwork.ozlabs.org/patch/1091122/ > >> - for: Linux I2C development > >> was: New > >> now: Superseded > >> > >> * linux-i2c: [v2,3/3] i2c-mux-gpio: Create of-based GPIOs request method > >> - http://patchwork.ozlabs.org/patch/1091121/ > >> - for: Linux I2C development > >> was: New > >> now: Superseded > > > > I may misunderstand something, but how come the v2 patchset switched to be superseded > > while it is the last patchset version I've sent? > > That was my mistake. Patchwork got confused when v2 was sent as a reply to > something in the v1 tree, and marked all 8 patches as "v2". Then I in turn > got confused by that, and changed status on the wrong set. Sorry! > > So, thanks for the heads up, it should be fixed now. > > As for comments on the patches, I'm personally buried in work and others > may have the merge window to focus on... > > Cheers, > Peter No worries. Glad everything is clear now. Thanks for the quick response. Regarding the patchset comments. Lets wait for the merge window being closed. Then if no comments will have been received in one-two weeks after that I'll ping this patchset mailing-list again .) Cheers, -Sergey