Message ID | 20250203080902.1864382-1-raag.jadav@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Split devres APIs to device/devres.h and introduce devm_kmemdup_array() | expand |
On Mon, Feb 03, 2025 at 01:38:42PM +0530, Raag Jadav wrote: > This series > > 1. Splits device/devres.h for the users that are only interested in devres APIs. > Original work by Andy Shevchenko: > https://lore.kernel.org/r/20241203195340.855879-1-andriy.shevchenko@linux.intel.com > > 2. Introduces a more robust and cleaner devm_kmemdup_array() helper and uses it > across drivers. > > The idea behind embedding both work into a single series is to reduce conflicts > and dependencies while merging. > > v2: Use size_mul() for multiplication (Dmitry) > Update commit message (Dmitry) > > v3: Embed devres.h work by Andy > Add more users of devm_kmemdup_array() I understand the desire to cover as much as possible, but it becomes much harder to coordinate. My proposal stays the same, i.e. I may take the GPIO/pin control related (and already ACKed!) changes via Intel pin control tree and the rest may use that immutable tag as needed. What we need is an Ack for the first patch from Greg and perhaps I can take IIO, if Jonathan gives an Ack. > Update tags and rebase
On Mon, Feb 03, 2025 at 11:48:52AM +0200, Andy Shevchenko wrote: > On Mon, Feb 03, 2025 at 01:38:42PM +0530, Raag Jadav wrote: > > This series > > > > 1. Splits device/devres.h for the users that are only interested in devres APIs. > > Original work by Andy Shevchenko: > > https://lore.kernel.org/r/20241203195340.855879-1-andriy.shevchenko@linux.intel.com > > > > 2. Introduces a more robust and cleaner devm_kmemdup_array() helper and uses it > > across drivers. > > > > The idea behind embedding both work into a single series is to reduce conflicts > > and dependencies while merging. > > > > v2: Use size_mul() for multiplication (Dmitry) > > Update commit message (Dmitry) > > > > v3: Embed devres.h work by Andy > > > Add more users of devm_kmemdup_array() > > I understand the desire to cover as much as possible, but it becomes much > harder to coordinate. I have a few more patches which I'm delaying to reduce dependency. Raag
On Mon, Feb 03, 2025 at 12:34:03PM +0200, Raag Jadav wrote: > On Mon, Feb 03, 2025 at 11:48:52AM +0200, Andy Shevchenko wrote: > > On Mon, Feb 03, 2025 at 01:38:42PM +0530, Raag Jadav wrote: > > > This series > > > > > > 1. Splits device/devres.h for the users that are only interested in devres APIs. > > > Original work by Andy Shevchenko: > > > https://lore.kernel.org/r/20241203195340.855879-1-andriy.shevchenko@linux.intel.com > > > > > > 2. Introduces a more robust and cleaner devm_kmemdup_array() helper and uses it > > > across drivers. > > > > > > The idea behind embedding both work into a single series is to reduce conflicts > > > and dependencies while merging. > > > > > > v2: Use size_mul() for multiplication (Dmitry) > > > Update commit message (Dmitry) > > > > > > v3: Embed devres.h work by Andy > > > > > Add more users of devm_kmemdup_array() > > > > I understand the desire to cover as much as possible, but it becomes much > > harder to coordinate. > > I have a few more patches which I'm delaying to reduce dependency. So, let's focus on the IIO/pin control ones only for the starter? With the produced immutable tag you may convince the respective maintainers to pull that tag along with the patches to their subsystems. It will be much easier to coordinate and execute.