From: Saravana Kannan <saravanak@google.com> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Len Brown <lenb@kernel.org>, Daniel Scally <djrscally@gmail.com>, Heikki Krogerus <heikki.krogerus@linux.intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Tony Lindgren <tony@atomide.com>, Linux Kernel Functional Testing <lkft@linaro.org>, Naresh Kamboju <naresh.kamboju@linaro.org>, Abel Vesa <abel.vesa@linaro.org>, Alexander Stein <alexander.stein@ew.tq-group.com>, Geert Uytterhoeven <geert@linux-m68k.org>, John Stultz <jstultz@google.com>, Doug Anderson <dianders@chromium.org>, Guenter Roeck <linux@roeck-us.net>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Maxim Kiselev <bigunclemax@gmail.com>, Maxim Kochetkov <fido_max@inbox.ru>, Miquel Raynal <miquel.raynal@bootlin.com>, Luca Weiss <luca.weiss@fairphone.com>, Colin Foster <colin.foster@in-advantage.com>, Martin Kepplinger <martin.kepplinger@puri.sm>, Jean-Philippe Brucker <jpb@kernel.org>, kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v2 01/11] driver core: fw_devlink: Don't purge child fwnode's consumer links Date: Fri, 27 Jan 2023 23:33:28 -0800 [thread overview] Message-ID: <CAGETcx_g8yKQQQVtNt+6cB8hS7OY9=dqm4tDhm1ZJZqG5nzSLg@mail.gmail.com> (raw) In-Reply-To: <Y9OXs9+uYi31dYJD@smile.fi.intel.com> On Fri, Jan 27, 2023 at 1:22 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Jan 26, 2023 at 04:11:28PM -0800, Saravana Kannan wrote: > > When a device X is bound successfully to a driver, if it has a child > > firmware node Y that doesn't have a struct device created by then, we > > delete fwnode links where the child firmware node Y is the supplier. We > > did this to avoid blocking the consumers of the child firmware node Y > > from deferring probe indefinitely. > > > > While that a step in the right direction, it's better to make the > > consumers of the child firmware node Y to be consumers of the device X > > because device X is probably implementing whatever functionality is > > represented by child firmware node Y. By doing this, we capture the > > device dependencies more accurately and ensure better > > probe/suspend/resume ordering. > > ... > > > static unsigned int defer_sync_state_count = 1; > > static DEFINE_MUTEX(fwnode_link_lock); > > static bool fw_devlink_is_permissive(void); > > +static void __fw_devlink_link_to_consumers(struct device *dev); > > static bool fw_devlink_drv_reg_done; > > static bool fw_devlink_best_effort; > > I'm wondering if may avoid adding more forward declarations... > > Perhaps it's a sign that devlink code should be split to its own > module? I've thought about that before, but I'm not there yet. Maybe once my remaining refactors and TODOs are done, it'd be a good time to revisit this question. But I don't think it should be done for the reason of forward declaration as we'd just end up moving these into base.h and we can do that even today. > > ... > > > -int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > > +static int __fwnode_link_add(struct fwnode_handle *con, > > + struct fwnode_handle *sup) > > I believe we tolerate a bit longer lines, so you may still have it on a single > line. That'd make it >80 cols. I'm going to leave it as is. > > ... > > > +int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > > +{ > > > + int ret = 0; > > Redundant assignment. Thanks. Will fix in v3. > > > + mutex_lock(&fwnode_link_lock); > > + ret = __fwnode_link_add(con, sup); > > + mutex_unlock(&fwnode_link_lock); > > return ret; > > } > > ... > > > if (dev->fwnode && dev->fwnode->dev == dev) { > > You may have above something like > > > fwnode = dev_fwnode(dev); I'll leave it as-is for now. I see dev->fwnode vs dev_fwnode() don't always give the same results. I need to re-examine other places I use dev->fwnode in fw_devlink code before I start using that function. But in general it seems like a good idea. I'll add this to my TODOs. > if (fwnode && fwnode->dev == dev) { > > > struct fwnode_handle *child; > > fwnode_links_purge_suppliers(dev->fwnode); > > + mutex_lock(&fwnode_link_lock); > > fwnode_for_each_available_child_node(dev->fwnode, child) > > - fw_devlink_purge_absent_suppliers(child); > > + __fw_devlink_pickup_dangling_consumers(child, > > + dev->fwnode); > > __fw_devlink_pickup_dangling_consumers(child, fwnode); I like the dev->fwnode->dev == dev check. It makes it super clear that I'm checking "The device's fwnode points back to the device". If I just use fwnode->dev == dev, then one will have to go back and read what fwnode is set to, etc. Also, when reading all these function calls it's easier to see that I'm working on the dev's fwnode (where dev is the device that was just bound to a driver) instead of some other fwnode. So I find it more readable as is and the compiler would optimize it anyway. If you feel strongly about this, I can change to use fwnode instead of dev->fwnode. Thanks, Saravana
WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <saravanak@google.com> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Len Brown <lenb@kernel.org>, Daniel Scally <djrscally@gmail.com>, Heikki Krogerus <heikki.krogerus@linux.intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Tony Lindgren <tony@atomide.com>, Linux Kernel Functional Testing <lkft@linaro.org>, Naresh Kamboju <naresh.kamboju@linaro.org>, Abel Vesa <abel.vesa@linaro.org>, Alexander Stein <alexander.stein@ew.tq-group.com>, Geert Uytterhoeven <geert@linux-m68k.org>, John Stultz <jstultz@google.com>, Doug Anderson <dianders@chromium.org>, Guenter Roeck <linux@roeck-us.net>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Maxim Kiselev <bigunclemax@gmail.com>, Maxim Kochetkov <fido_max@inbox.ru>, Miquel Raynal <miquel.raynal@bootlin.com>, Luca Weiss <luca.weiss@fairphone.com>, Colin Foster <colin.foster@in-advantage.com>, Martin Kepplinger <martin.kepplinger@puri.sm>, Jean-Philippe Brucker <jpb@kernel.org>, kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v2 01/11] driver core: fw_devlink: Don't purge child fwnode's consumer links Date: Fri, 27 Jan 2023 23:33:28 -0800 [thread overview] Message-ID: <CAGETcx_g8yKQQQVtNt+6cB8hS7OY9=dqm4tDhm1ZJZqG5nzSLg@mail.gmail.com> (raw) In-Reply-To: <Y9OXs9+uYi31dYJD@smile.fi.intel.com> On Fri, Jan 27, 2023 at 1:22 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Jan 26, 2023 at 04:11:28PM -0800, Saravana Kannan wrote: > > When a device X is bound successfully to a driver, if it has a child > > firmware node Y that doesn't have a struct device created by then, we > > delete fwnode links where the child firmware node Y is the supplier. We > > did this to avoid blocking the consumers of the child firmware node Y > > from deferring probe indefinitely. > > > > While that a step in the right direction, it's better to make the > > consumers of the child firmware node Y to be consumers of the device X > > because device X is probably implementing whatever functionality is > > represented by child firmware node Y. By doing this, we capture the > > device dependencies more accurately and ensure better > > probe/suspend/resume ordering. > > ... > > > static unsigned int defer_sync_state_count = 1; > > static DEFINE_MUTEX(fwnode_link_lock); > > static bool fw_devlink_is_permissive(void); > > +static void __fw_devlink_link_to_consumers(struct device *dev); > > static bool fw_devlink_drv_reg_done; > > static bool fw_devlink_best_effort; > > I'm wondering if may avoid adding more forward declarations... > > Perhaps it's a sign that devlink code should be split to its own > module? I've thought about that before, but I'm not there yet. Maybe once my remaining refactors and TODOs are done, it'd be a good time to revisit this question. But I don't think it should be done for the reason of forward declaration as we'd just end up moving these into base.h and we can do that even today. > > ... > > > -int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > > +static int __fwnode_link_add(struct fwnode_handle *con, > > + struct fwnode_handle *sup) > > I believe we tolerate a bit longer lines, so you may still have it on a single > line. That'd make it >80 cols. I'm going to leave it as is. > > ... > > > +int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > > +{ > > > + int ret = 0; > > Redundant assignment. Thanks. Will fix in v3. > > > + mutex_lock(&fwnode_link_lock); > > + ret = __fwnode_link_add(con, sup); > > + mutex_unlock(&fwnode_link_lock); > > return ret; > > } > > ... > > > if (dev->fwnode && dev->fwnode->dev == dev) { > > You may have above something like > > > fwnode = dev_fwnode(dev); I'll leave it as-is for now. I see dev->fwnode vs dev_fwnode() don't always give the same results. I need to re-examine other places I use dev->fwnode in fw_devlink code before I start using that function. But in general it seems like a good idea. I'll add this to my TODOs. > if (fwnode && fwnode->dev == dev) { > > > struct fwnode_handle *child; > > fwnode_links_purge_suppliers(dev->fwnode); > > + mutex_lock(&fwnode_link_lock); > > fwnode_for_each_available_child_node(dev->fwnode, child) > > - fw_devlink_purge_absent_suppliers(child); > > + __fw_devlink_pickup_dangling_consumers(child, > > + dev->fwnode); > > __fw_devlink_pickup_dangling_consumers(child, fwnode); I like the dev->fwnode->dev == dev check. It makes it super clear that I'm checking "The device's fwnode points back to the device". If I just use fwnode->dev == dev, then one will have to go back and read what fwnode is set to, etc. Also, when reading all these function calls it's easier to see that I'm working on the dev's fwnode (where dev is the device that was just bound to a driver) instead of some other fwnode. So I find it more readable as is and the compiler would optimize it anyway. If you feel strongly about this, I can change to use fwnode instead of dev->fwnode. Thanks, Saravana _______________________________________________ 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:[~2023-01-28 7:34 UTC|newest] Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-27 0:11 [PATCH v2 00/11] fw_devlink improvements Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 01/11] driver core: fw_devlink: Don't purge child fwnode's consumer links Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:21 ` Andy Shevchenko 2023-01-27 9:21 ` Andy Shevchenko 2023-01-28 7:33 ` Saravana Kannan [this message] 2023-01-28 7:33 ` Saravana Kannan 2023-01-30 12:04 ` Andy Shevchenko 2023-01-30 12:04 ` Andy Shevchenko 2023-01-27 0:11 ` [PATCH v2 02/11] driver core: fw_devlink: Improve check for fwnode with no device/driver Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 03/11] soc: renesas: Move away from using OF_POPULATED for fw_devlink Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 8:11 ` Geert Uytterhoeven 2023-01-27 8:11 ` Geert Uytterhoeven 2023-01-28 7:18 ` Saravana Kannan 2023-01-28 7:18 ` Saravana Kannan 2023-01-30 8:42 ` Geert Uytterhoeven 2023-01-30 8:42 ` Geert Uytterhoeven 2023-01-30 20:00 ` Saravana Kannan 2023-01-30 20:00 ` Saravana Kannan 2023-01-31 8:14 ` Geert Uytterhoeven 2023-01-31 8:14 ` Geert Uytterhoeven 2023-02-04 22:30 ` Saravana Kannan 2023-02-04 22:30 ` Saravana Kannan 2023-01-27 9:25 ` Andy Shevchenko 2023-01-27 9:25 ` Andy Shevchenko 2023-01-27 9:30 ` Geert Uytterhoeven 2023-01-27 9:30 ` Geert Uytterhoeven 2023-01-27 9:44 ` Andy Shevchenko 2023-01-27 9:44 ` Andy Shevchenko 2023-01-27 0:11 ` [PATCH v2 04/11] gpiolib: Clear the gpio_device's fwnode initialized flag before adding Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:27 ` Andy Shevchenko 2023-01-27 9:27 ` Andy Shevchenko 2023-01-28 7:33 ` Saravana Kannan 2023-01-28 7:33 ` Saravana Kannan 2023-01-30 12:05 ` Andy Shevchenko 2023-01-30 12:05 ` Andy Shevchenko 2023-01-30 14:31 ` Sudeep Holla 2023-01-30 14:31 ` Sudeep Holla 2023-01-30 15:14 ` Andy Shevchenko 2023-01-30 15:14 ` Andy Shevchenko 2023-01-31 4:01 ` Saravana Kannan 2023-01-31 4:01 ` Saravana Kannan 2023-01-31 10:13 ` Sudeep Holla 2023-01-31 10:13 ` Sudeep Holla 2023-02-04 22:32 ` Saravana Kannan 2023-02-04 22:32 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 05/11] driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:29 ` Andy Shevchenko 2023-01-27 9:29 ` Andy Shevchenko 2023-01-27 9:30 ` Andy Shevchenko 2023-01-27 9:30 ` Andy Shevchenko 2023-01-27 9:55 ` Geert Uytterhoeven 2023-01-27 9:55 ` Geert Uytterhoeven 2023-01-28 7:34 ` Saravana Kannan 2023-01-28 7:34 ` Saravana Kannan 2023-01-30 12:08 ` Andy Shevchenko 2023-01-30 12:08 ` Andy Shevchenko 2023-01-27 0:11 ` [PATCH v2 06/11] driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:33 ` Andy Shevchenko 2023-01-27 9:33 ` Andy Shevchenko 2023-01-28 7:34 ` Saravana Kannan 2023-01-28 7:34 ` Saravana Kannan 2023-01-30 12:09 ` Andy Shevchenko 2023-01-30 12:09 ` Andy Shevchenko 2023-01-27 0:11 ` [PATCH v2 07/11] driver core: fw_devlink: Consolidate device link flag computation Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 08/11] driver core: fw_devlink: Make cycle detection more robust Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:43 ` Andy Shevchenko 2023-01-27 9:43 ` Andy Shevchenko 2023-01-27 9:52 ` Geert Uytterhoeven 2023-01-27 9:52 ` Geert Uytterhoeven 2023-01-27 10:10 ` Andy Shevchenko 2023-01-27 10:10 ` Andy Shevchenko 2023-01-27 10:29 ` Geert Uytterhoeven 2023-01-27 10:29 ` Geert Uytterhoeven 2023-01-28 7:34 ` Saravana Kannan 2023-01-28 7:34 ` Saravana Kannan 2023-01-30 12:15 ` Andy Shevchenko 2023-01-30 12:15 ` Andy Shevchenko 2023-01-30 14:36 ` Geert Uytterhoeven 2023-01-30 14:36 ` Geert Uytterhoeven 2023-01-30 15:16 ` Andy Shevchenko 2023-01-30 15:16 ` Andy Shevchenko 2023-01-27 0:11 ` [PATCH v2 09/11] of: property: Simplify of_link_to_phandle() Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-30 14:39 ` Sakari Ailus 2023-01-30 14:39 ` Sakari Ailus 2023-01-31 3:51 ` Saravana Kannan 2023-01-31 3:51 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 10/11] irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:51 ` Andy Shevchenko 2023-01-27 9:51 ` Andy Shevchenko 2023-01-28 7:34 ` Saravana Kannan 2023-01-28 7:34 ` Saravana Kannan 2023-01-27 0:11 ` [PATCH v2 11/11] firmware: arm_scmi: Set fwnode for the scmi_device Saravana Kannan 2023-01-27 0:11 ` Saravana Kannan 2023-01-27 9:52 ` Andy Shevchenko 2023-01-27 9:52 ` Andy Shevchenko 2023-01-27 10:48 ` Sudeep Holla 2023-01-27 10:48 ` Sudeep Holla 2023-01-27 20:30 ` [PATCH v2 00/11] fw_devlink improvements Colin Foster 2023-01-27 20:30 ` Colin Foster 2023-01-27 21:35 ` Saravana Kannan 2023-01-27 21:35 ` Saravana Kannan 2023-01-30 8:55 ` Naresh Kamboju 2023-01-30 8:55 ` Naresh Kamboju 2023-01-30 10:49 ` Marc Zyngier 2023-01-30 10:49 ` Marc Zyngier 2023-01-30 23:03 ` Saravana Kannan 2023-01-30 23:03 ` Saravana Kannan 2023-01-31 10:18 ` Sudeep Holla 2023-01-31 10:18 ` Sudeep Holla 2023-02-02 17:36 ` Maxim Kiselev 2023-02-02 17:36 ` Maxim Kiselev 2023-02-03 6:07 ` Saravana Kannan 2023-02-03 6:07 ` Saravana Kannan 2023-02-03 9:39 ` Maxim Kiselev 2023-02-03 9:39 ` Maxim Kiselev 2023-02-06 1:32 ` Saravana Kannan 2023-02-06 1:32 ` Saravana Kannan 2023-02-06 2:17 ` Saravana Kannan 2023-02-06 2:17 ` Saravana Kannan 2023-02-06 9:39 ` Miquel Raynal 2023-02-06 9:39 ` Miquel Raynal 2023-02-06 20:08 ` Saravana Kannan 2023-02-06 20:08 ` Saravana Kannan 2023-02-24 14:46 ` Miquel Raynal 2023-02-24 14:46 ` Miquel Raynal 2023-02-06 15:18 ` Rob Herring 2023-02-06 15:18 ` Rob Herring 2023-02-06 19:59 ` Saravana Kannan 2023-02-06 19:59 ` Saravana Kannan 2023-01-30 10:48 ` Miquel Raynal 2023-01-30 10:48 ` Miquel Raynal 2023-01-30 12:08 ` Maxim Kiselev 2023-01-30 12:08 ` Maxim Kiselev 2023-01-31 1:20 ` Saravana Kannan 2023-01-31 1:20 ` Saravana Kannan
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='CAGETcx_g8yKQQQVtNt+6cB8hS7OY9=dqm4tDhm1ZJZqG5nzSLg@mail.gmail.com' \ --to=saravanak@google.com \ --cc=abel.vesa@linaro.org \ --cc=alexander.stein@ew.tq-group.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bigunclemax@gmail.com \ --cc=brgl@bgdev.pl \ --cc=colin.foster@in-advantage.com \ --cc=cristian.marussi@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=djrscally@gmail.com \ --cc=dmitry.baryshkov@linaro.org \ --cc=festevam@gmail.com \ --cc=fido_max@inbox.ru \ --cc=frowand.list@gmail.com \ --cc=geert+renesas@glider.be \ --cc=geert@linux-m68k.org \ --cc=gregkh@linuxfoundation.org \ --cc=heikki.krogerus@linux.intel.com \ --cc=jpb@kernel.org \ --cc=jstultz@google.com \ --cc=kernel-team@android.com \ --cc=kernel@pengutronix.de \ --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-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=lkft@linaro.org \ --cc=luca.weiss@fairphone.com \ --cc=magnus.damm@gmail.com \ --cc=martin.kepplinger@puri.sm \ --cc=maz@kernel.org \ --cc=miquel.raynal@bootlin.com \ --cc=naresh.kamboju@linaro.org \ --cc=rafael@kernel.org \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=sakari.ailus@linux.intel.com \ --cc=shawnguo@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=tglx@linutronix.de \ --cc=tony@atomide.com \ /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.