From: Daniel Scally <djrscally@gmail.com> To: Hans de Goede <hdegoede@redhat.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Wolfram Sang <wsa@kernel.org>, Lee Jones <lee.jones@linaro.org>, Maximilian Luz <luzmaximilian@gmail.com>, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, platform-driver-x86@vger.kernel.org, devel@acpica.org Cc: Len Brown <lenb@kernel.org>, Mika Westerberg <mika.westerberg@linux.intel.com>, Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Mark Gross <mgross@linux.intel.com>, Robert Moore <robert.moore@intel.com>, Erik Kaneda <erik.kaneda@intel.com>, laurent.pinchart@ideasonboard.com, kieran.bingham@ideasonboard.com Subject: Re: [PATCH v4 0/8] Introduce intel_skl_int3472 module Date: Wed, 26 May 2021 00:03:23 +0100 [thread overview] Message-ID: <f4664310-0975-335d-8dc3-95726f53ab67@gmail.com> (raw) In-Reply-To: <f2d8e74f-f33b-2489-1b90-b11bf7465d19@redhat.com> Hi Hans On 25/05/2021 14:10, Hans de Goede wrote: > Hi Daniel, > > On 5/20/21 4:09 PM, Daniel Scally wrote: >> Hello all >> >> Apologies for the long delay since the last version of this series; the time I >> had free to work on it became somewhat restrained. > No worries, thank you for all the work you are putting into this. My pleasure > I have not taken a close look at the code yet, but I see that Andy has and > the amount of remarks which he has on patch 7/8 which is the big one seems > to be limited, so I believe that we are getting close to this being ready > for merging. > > This touches a lot of subsystems, so we need to come up with a plan to > merge this. Here is my proposal for how to do this: > > 1/8 ACPI: scan: Extend acpi_walk_dep_device_list() > 2/8 ACPI: scan: Add function to fetch dependent of acpi device > 3/8 i2c: core: Add a format macro for I2C device names > 4/8 gpiolib: acpi: Export acpi_get_gpiod() > 5/8 clkdev: Make clkdev_drop() null aware > 6/8 gpiolib: acpi: Add acpi_gpio_get_io_resource() > 7/8 platform/x86: Add intel_skl_int3472 driver > 8/8 mfd: tps68470: Remove tps68470 MFD driver > > Rafael already indicated that he wants to merge 1/8 (and presumably also 2/8) > through his tree and that he will provide an immutable branch with those > for merging into the pdx86 tree. I'll send a v5 with the renames asap, might try and do the other changes and send the whole series, depends how much time I get to work on it over the next few days... > 4/8 and 6/8 are both gpiolib-acpi patches and seem to be ready for merging > now, perhaps the gpiolib-acpi maintainers can already merge these and also > provide an immutable branch ? Andy/Mika ? So, Andy, you'd prefer I re-order these so they're consecutive...did I understand that right? > 3/8 and 5/8 seem to be nice cleanups, but not really necessary. IMHO it > would be best to park these cleanups for later and for 3/8 add the following > where necessary for now: > > /* FIXME drop this once the I2C_DEV_NAME_FORMAT macro has been added to include/linux/i2c.h */ > #ifndef I2C_DEV_NAME_FORMAT > #define I2C_DEV_NAME_FORMAT "i2c-%s" > #endif > > This is not the prettiest but it reduces all the subsys cross-deps and things > like this have been done before for similar reasons. > > Likewise it would be good if you can add if (foo) as condition before any > clkdev_drop(foo) calls in this patch-set and then merge > 5/8 "clkdev: Make clkdev_drop() null aware" independently of this and then > once both are in Linux tree follow-up with a cleanup patch dropping the if (foo) > guards. This is fine by me if people are happy for it to go in like that; I'll just fix it up later. > So this would leave as deps for 7/8 just the 2 ACPI and 2 gpiolib-acpi patches > which I can hopefully pull-in via immutable branches and then we are good. > > AFAICT patch 8/8 can be merged independently once 7/8 hits for-next (IOW once > we are sure the next kernel will have 7/8). > > > > Or alternatively one of the involved subsys maintainers just merges the entire > set (once it is ready) and then provides an immutable branch with the entire set > on top of 5.13-rc1 (or 5.14-rc1). But that requires acks from all the other > subsys maintainers. Note I'm fine with either approach.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Scally <djrscally@gmail.com> To: Hans de Goede <hdegoede@redhat.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Wolfram Sang <wsa@kernel.org>, Lee Jones <lee.jones@linaro.org>, Maximilian Luz <luzmaximilian@gmail.com>, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, platform-driver-x86@vger.kernel.org, devel@acpica.org Cc: Len Brown <lenb@kernel.org>, Mika Westerberg <mika.westerberg@linux.intel.com>, Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Mark Gross <mgross@linux.intel.com>, Robert Moore <robert.moore@intel.com>, Erik Kaneda <erik.kaneda@intel.com>, laurent.pinchart@ideasonboard.com, kieran.bingham@ideasonboard.com Subject: Re: [PATCH v4 0/8] Introduce intel_skl_int3472 module Date: Wed, 26 May 2021 00:03:23 +0100 [thread overview] Message-ID: <f4664310-0975-335d-8dc3-95726f53ab67@gmail.com> (raw) In-Reply-To: <f2d8e74f-f33b-2489-1b90-b11bf7465d19@redhat.com> Hi Hans On 25/05/2021 14:10, Hans de Goede wrote: > Hi Daniel, > > On 5/20/21 4:09 PM, Daniel Scally wrote: >> Hello all >> >> Apologies for the long delay since the last version of this series; the time I >> had free to work on it became somewhat restrained. > No worries, thank you for all the work you are putting into this. My pleasure > I have not taken a close look at the code yet, but I see that Andy has and > the amount of remarks which he has on patch 7/8 which is the big one seems > to be limited, so I believe that we are getting close to this being ready > for merging. > > This touches a lot of subsystems, so we need to come up with a plan to > merge this. Here is my proposal for how to do this: > > 1/8 ACPI: scan: Extend acpi_walk_dep_device_list() > 2/8 ACPI: scan: Add function to fetch dependent of acpi device > 3/8 i2c: core: Add a format macro for I2C device names > 4/8 gpiolib: acpi: Export acpi_get_gpiod() > 5/8 clkdev: Make clkdev_drop() null aware > 6/8 gpiolib: acpi: Add acpi_gpio_get_io_resource() > 7/8 platform/x86: Add intel_skl_int3472 driver > 8/8 mfd: tps68470: Remove tps68470 MFD driver > > Rafael already indicated that he wants to merge 1/8 (and presumably also 2/8) > through his tree and that he will provide an immutable branch with those > for merging into the pdx86 tree. I'll send a v5 with the renames asap, might try and do the other changes and send the whole series, depends how much time I get to work on it over the next few days... > 4/8 and 6/8 are both gpiolib-acpi patches and seem to be ready for merging > now, perhaps the gpiolib-acpi maintainers can already merge these and also > provide an immutable branch ? Andy/Mika ? So, Andy, you'd prefer I re-order these so they're consecutive...did I understand that right? > 3/8 and 5/8 seem to be nice cleanups, but not really necessary. IMHO it > would be best to park these cleanups for later and for 3/8 add the following > where necessary for now: > > /* FIXME drop this once the I2C_DEV_NAME_FORMAT macro has been added to include/linux/i2c.h */ > #ifndef I2C_DEV_NAME_FORMAT > #define I2C_DEV_NAME_FORMAT "i2c-%s" > #endif > > This is not the prettiest but it reduces all the subsys cross-deps and things > like this have been done before for similar reasons. > > Likewise it would be good if you can add if (foo) as condition before any > clkdev_drop(foo) calls in this patch-set and then merge > 5/8 "clkdev: Make clkdev_drop() null aware" independently of this and then > once both are in Linux tree follow-up with a cleanup patch dropping the if (foo) > guards. This is fine by me if people are happy for it to go in like that; I'll just fix it up later. > So this would leave as deps for 7/8 just the 2 ACPI and 2 gpiolib-acpi patches > which I can hopefully pull-in via immutable branches and then we are good. > > AFAICT patch 8/8 can be merged independently once 7/8 hits for-next (IOW once > we are sure the next kernel will have 7/8). > > > > Or alternatively one of the involved subsys maintainers just merges the entire > set (once it is ready) and then provides an immutable branch with the entire set > on top of 5.13-rc1 (or 5.14-rc1). But that requires acks from all the other > subsys maintainers. Note I'm fine with either approach. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-25 23:03 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-20 14:09 [PATCH v4 0/8] Introduce intel_skl_int3472 module Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 1/8] ACPI: scan: Extend acpi_walk_dep_device_list() Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 17:15 ` Maximilian Luz 2021-05-20 17:15 ` Maximilian Luz 2021-05-20 18:22 ` Rafael J. Wysocki 2021-05-20 18:22 ` [Devel] " Rafael J. Wysocki 2021-05-20 18:22 ` Rafael J. Wysocki 2021-05-20 21:03 ` Hans de Goede 2021-05-20 21:03 ` Hans de Goede 2021-05-21 12:59 ` Andy Shevchenko 2021-05-21 12:59 ` Andy Shevchenko 2021-05-20 14:09 ` [PATCH v4 2/8] ACPI: scan: Add function to fetch dependent of acpi device Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 18:33 ` Rafael J. Wysocki 2021-05-20 18:33 ` [Devel] " Rafael J. Wysocki 2021-05-20 18:33 ` Rafael J. Wysocki 2021-05-20 18:55 ` Rafael J. Wysocki 2021-05-20 18:55 ` [Devel] " Rafael J. Wysocki 2021-05-20 18:55 ` Rafael J. Wysocki 2021-05-21 19:25 ` Daniel Scally 2021-05-21 19:25 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 3/8] i2c: core: Add a format macro for I2C device names Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 4/8] gpiolib: acpi: Export acpi_get_gpiod() Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 5/8] clkdev: Make clkdev_drop() null aware Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 6/8] gpiolib: acpi: Add acpi_gpio_get_io_resource() Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-21 12:05 ` Andy Shevchenko 2021-05-21 12:05 ` Andy Shevchenko 2021-05-25 22:30 ` Daniel Scally 2021-05-25 22:30 ` Daniel Scally 2021-05-20 14:09 ` [PATCH v4 7/8] platform/x86: Add intel_skl_int3472 driver Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-21 12:57 ` Andy Shevchenko 2021-05-21 12:57 ` Andy Shevchenko 2021-05-25 22:53 ` Daniel Scally 2021-05-25 22:53 ` Daniel Scally 2021-05-26 7:54 ` Andy Shevchenko 2021-05-26 7:54 ` Andy Shevchenko 2021-05-20 14:09 ` [PATCH v4 8/8] mfd: tps68470: Remove tps68470 MFD driver Daniel Scally 2021-05-20 14:09 ` Daniel Scally 2021-05-25 13:10 ` [PATCH v4 0/8] Introduce intel_skl_int3472 module Hans de Goede 2021-05-25 13:10 ` Hans de Goede 2021-05-25 13:12 ` Hans de Goede 2021-05-25 13:12 ` Hans de Goede 2021-05-25 13:23 ` Andy Shevchenko 2021-05-25 13:23 ` Andy Shevchenko 2021-05-25 23:03 ` Daniel Scally [this message] 2021-05-25 23:03 ` Daniel Scally 2021-05-26 7:55 ` Andy Shevchenko 2021-05-26 7:55 ` Andy Shevchenko 2021-05-26 12:36 ` Hans de Goede 2021-05-26 12:36 ` Hans de Goede
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=f4664310-0975-335d-8dc3-95726f53ab67@gmail.com \ --to=djrscally@gmail.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bgolaszewski@baylibre.com \ --cc=devel@acpica.org \ --cc=erik.kaneda@intel.com \ --cc=hdegoede@redhat.com \ --cc=kieran.bingham@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lee.jones@linaro.org \ --cc=lenb@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=luzmaximilian@gmail.com \ --cc=mgross@linux.intel.com \ --cc=mika.westerberg@linux.intel.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=rafael.j.wysocki@intel.com \ --cc=robert.moore@intel.com \ --cc=wsa@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.