From: Miquel Raynal <miquel.raynal@bootlin.com> To: Saravana Kannan <saravanak@google.com> Cc: Maxim Kiselev <bigunclemax@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, Naresh Kamboju <naresh.kamboju@linaro.org>, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, brgl@bgdev.pl, colin.foster@in-advantage.com, cristian.marussi@arm.com, devicetree@vger.kernel.org, dianders@chromium.org, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert+renesas@glider.be, geert@linux-m68k.org, gregkh@linuxfoundation.org, heikki.krogerus@linux.intel.com, jpb@kernel.org, jstultz@google.com, kernel-team@android.com, kernel@pengutronix.de, lenb@kernel.org, linus.walleij@linaro.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-imx@nxp.com, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux@roeck-us.net, lkft@linaro.org, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, maz@kernel.org, rafael@kernel.org, robh+dt@kernel.org, s.hauer@pengutronix.de, sakari.ailus@linux.intel.com, shawnguo@kernel.org, tglx@linutronix.de, tony@atomide.com, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Subject: Re: [PATCH v2 00/11] fw_devlink improvements Date: Fri, 24 Feb 2023 15:46:59 +0100 [thread overview] Message-ID: <20230224154659.432a4d4c@xps-13> (raw) In-Reply-To: <CAGETcx-0VboaAeoa+_AqDtrDj6v6ZytFj6pU-FVyAu-pk-hG6A@mail.gmail.com> Hi Saravana, > > > > > So, can you please retest config 1 with all pr_debug and dev_dbg in > > > > > drivers/core/base.c changed to the _info variants? And then share the > > > > > kernel log from the beginning of boot? Maybe attach it to the email so > > > > > it doesn't get word wrapped by your email client. And please point me > > > > > to the .dts that corresponds to your board. Without that, I can't > > > > > debug much. > > > > > > > > Ok, I retested config 1 with all _debug logs changed to the _info. I > > > > added the kernel log and the dts file to the attachment of this email. > > > > > > Ah, so your device is not supported/present upstream? Even though it's > > > not upstream, I'll help fix this because it should fix what I believe > > > are unreported issues in upstream. > > > > > > Ok I know why configs 1 - 4 behaved the way they did and why my test > > > patch didn't help. > > > > > > After staring at mtd/nvmem code for a few hours I think mtd/nvmem > > > interaction is kind of a mess. > > > > nvmem is a recent subsystem but mtd carries a lot of legacy stuff we > > cannot really re-wire without breaking users, so nvmem on top of mtd > > of course inherit from the fragile designs in place. > > Thanks for the context. Yeah, I figured. That's why I explicitly > limited my comment to "interaction". Although, I'd love to see the MTD > parsers all be converted to proper drivers that probe. MTD is > essentially repeating the driver matching logic. I think it can be > cleaned up to move to proper drivers and still not break backward > compatibility. Not saying it'll be trivial, but it should be possible. > Ironically MTD uses mtd_class but has real drivers that work on the > device (compared to nvmem_bus below). > > > > mtd core creates "partition" platform > > > devices (including for nvmem-cells) that are probed by drivers in > > > drivers/nvmem. However, there's no driver for "nvmem-cells" partition > > > platform device. However, the nvmem core creates nvmem_device when > > > nvmem_register() is called by MTD or these partition platform devices > > > created by MTD. But these nvmem_devices are added to a nvmem_bus but > > > the bus has no means to even register a driver (it should really be a > > > nvmem_class and not nvmem_bus). > > > > Srinivas, do you think we could change this? > > Yeah, this part gets a bit tricky. It depends on whether the sysfs > files for nvmem devices is considered an ABI. Changing from bus to > class would change the sysfs path for nvmem devices from: > /sys/class/nvmem to /sys/bus/nvmem Ok, so this is a no :) > > > And the nvmem_device sometimes points > > > to the DT node of the MTD device or sometimes the partition platform > > > devices or maybe no DT node at all. > > > > I guess this comes from the fact that this is not strongly defined in > > mtd and depends on the situation (not mentioning 20 years of history > > there as well). "mtd" is a bit inconsistent on what it means. Older > > designs mixed: controllers, ECC engines when relevant and memories; > > while these three components are completely separated. Hence > > sometimes the mtd device ends up being the top level controller, > > sometimes it's just one partition... > > > > But I'm surprised not all of them point to a DT node. Could you show us > > an example? Because that might likely be unexpected (or perhaps I am > > missing something). > > Well, the logic that sets the DT node for nvmem_device is like so: > > if (config->of_node) > nvmem->dev.of_node = config->of_node; > else if (!config->no_of_node) > nvmem->dev.of_node = config->dev->of_node; > > So there's definitely a path (where both if's could be false) where > the DT node will not get set. I don't know if that path is possible > with the existing users of nvmem_register(), but it's definitely > possible. It's an actual path. I just checked more in details, this is the change from 2018 which uses the no_of_node flag: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API") It basically allows any mtd device to be accessible (read-only) through nvmem. So mtd partitions or such which are not described in the DT may just be accessed through nvmem (that is my current understanding). There was later a patch in 2021 which prevented this flag to be automatically set, so that if partitions (well, mtd devices in general) were described in the DT, they would provide a valid of_node in order to be used as cell providers (again, my understanding): 658c4448bbbf ("mtd: core: add nvmem-cells compatible to parse mtd as nvmem cells") But I guess the major problem comes from the nvmem-cell compatible. I am wondering if it would make sense to kind of transpose the meaning of this compatible into a property. But, well, backward compatibility would still be a problem I guess... > > > So it's a mess of multiple devices pointing to the same DT node with > > > no clear way to identify which ones will point to a DT node and which > > > ones will probe and which ones won't. In the future, we shouldn't > > > allow adding new compatible strings for partitions for which we don't > > > plan on adding nvmem drivers. > > > > > > Can you give the patch at the end of the email a shot? It should fix > > > the issue with this series and without this series. It just avoids > > > this whole mess by not creating useless platform device for > > > nvmem-cells compatible DT nodes. > > > > Thanks a lot for your help. > > No problem. I want fw_devlink to work for everyone. > Thanks, Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com> To: Saravana Kannan <saravanak@google.com> Cc: Maxim Kiselev <bigunclemax@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, Naresh Kamboju <naresh.kamboju@linaro.org>, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, brgl@bgdev.pl, colin.foster@in-advantage.com, cristian.marussi@arm.com, devicetree@vger.kernel.org, dianders@chromium.org, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert+renesas@glider.be, geert@linux-m68k.org, gregkh@linuxfoundation.org, heikki.krogerus@linux.intel.com, jpb@kernel.org, jstultz@google.com, kernel-team@android.com, kernel@pengutronix.de, lenb@kernel.org, linus.walleij@linaro.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-imx@nxp.com, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux@roeck-us.net, lkft@linaro.org, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, maz@kernel.org, rafael@kernel.org, robh+dt@kernel.org, s.hauer@pengutronix.de, sakari.ailus@linux.intel.com, shawnguo@kernel.org, tglx@linutronix.de, tony@atomide.com, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Subject: Re: [PATCH v2 00/11] fw_devlink improvements Date: Fri, 24 Feb 2023 15:46:59 +0100 [thread overview] Message-ID: <20230224154659.432a4d4c@xps-13> (raw) In-Reply-To: <CAGETcx-0VboaAeoa+_AqDtrDj6v6ZytFj6pU-FVyAu-pk-hG6A@mail.gmail.com> Hi Saravana, > > > > > So, can you please retest config 1 with all pr_debug and dev_dbg in > > > > > drivers/core/base.c changed to the _info variants? And then share the > > > > > kernel log from the beginning of boot? Maybe attach it to the email so > > > > > it doesn't get word wrapped by your email client. And please point me > > > > > to the .dts that corresponds to your board. Without that, I can't > > > > > debug much. > > > > > > > > Ok, I retested config 1 with all _debug logs changed to the _info. I > > > > added the kernel log and the dts file to the attachment of this email. > > > > > > Ah, so your device is not supported/present upstream? Even though it's > > > not upstream, I'll help fix this because it should fix what I believe > > > are unreported issues in upstream. > > > > > > Ok I know why configs 1 - 4 behaved the way they did and why my test > > > patch didn't help. > > > > > > After staring at mtd/nvmem code for a few hours I think mtd/nvmem > > > interaction is kind of a mess. > > > > nvmem is a recent subsystem but mtd carries a lot of legacy stuff we > > cannot really re-wire without breaking users, so nvmem on top of mtd > > of course inherit from the fragile designs in place. > > Thanks for the context. Yeah, I figured. That's why I explicitly > limited my comment to "interaction". Although, I'd love to see the MTD > parsers all be converted to proper drivers that probe. MTD is > essentially repeating the driver matching logic. I think it can be > cleaned up to move to proper drivers and still not break backward > compatibility. Not saying it'll be trivial, but it should be possible. > Ironically MTD uses mtd_class but has real drivers that work on the > device (compared to nvmem_bus below). > > > > mtd core creates "partition" platform > > > devices (including for nvmem-cells) that are probed by drivers in > > > drivers/nvmem. However, there's no driver for "nvmem-cells" partition > > > platform device. However, the nvmem core creates nvmem_device when > > > nvmem_register() is called by MTD or these partition platform devices > > > created by MTD. But these nvmem_devices are added to a nvmem_bus but > > > the bus has no means to even register a driver (it should really be a > > > nvmem_class and not nvmem_bus). > > > > Srinivas, do you think we could change this? > > Yeah, this part gets a bit tricky. It depends on whether the sysfs > files for nvmem devices is considered an ABI. Changing from bus to > class would change the sysfs path for nvmem devices from: > /sys/class/nvmem to /sys/bus/nvmem Ok, so this is a no :) > > > And the nvmem_device sometimes points > > > to the DT node of the MTD device or sometimes the partition platform > > > devices or maybe no DT node at all. > > > > I guess this comes from the fact that this is not strongly defined in > > mtd and depends on the situation (not mentioning 20 years of history > > there as well). "mtd" is a bit inconsistent on what it means. Older > > designs mixed: controllers, ECC engines when relevant and memories; > > while these three components are completely separated. Hence > > sometimes the mtd device ends up being the top level controller, > > sometimes it's just one partition... > > > > But I'm surprised not all of them point to a DT node. Could you show us > > an example? Because that might likely be unexpected (or perhaps I am > > missing something). > > Well, the logic that sets the DT node for nvmem_device is like so: > > if (config->of_node) > nvmem->dev.of_node = config->of_node; > else if (!config->no_of_node) > nvmem->dev.of_node = config->dev->of_node; > > So there's definitely a path (where both if's could be false) where > the DT node will not get set. I don't know if that path is possible > with the existing users of nvmem_register(), but it's definitely > possible. It's an actual path. I just checked more in details, this is the change from 2018 which uses the no_of_node flag: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API") It basically allows any mtd device to be accessible (read-only) through nvmem. So mtd partitions or such which are not described in the DT may just be accessed through nvmem (that is my current understanding). There was later a patch in 2021 which prevented this flag to be automatically set, so that if partitions (well, mtd devices in general) were described in the DT, they would provide a valid of_node in order to be used as cell providers (again, my understanding): 658c4448bbbf ("mtd: core: add nvmem-cells compatible to parse mtd as nvmem cells") But I guess the major problem comes from the nvmem-cell compatible. I am wondering if it would make sense to kind of transpose the meaning of this compatible into a property. But, well, backward compatibility would still be a problem I guess... > > > So it's a mess of multiple devices pointing to the same DT node with > > > no clear way to identify which ones will point to a DT node and which > > > ones will probe and which ones won't. In the future, we shouldn't > > > allow adding new compatible strings for partitions for which we don't > > > plan on adding nvmem drivers. > > > > > > Can you give the patch at the end of the email a shot? It should fix > > > the issue with this series and without this series. It just avoids > > > this whole mess by not creating useless platform device for > > > nvmem-cells compatible DT nodes. > > > > Thanks a lot for your help. > > No problem. I want fw_devlink to work for everyone. > Thanks, Miquèl _______________________________________________ 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-02-24 14:47 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 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 [this message] 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=20230224154659.432a4d4c@xps-13 \ --to=miquel.raynal@bootlin.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=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=saravanak@google.com \ --cc=shawnguo@kernel.org \ --cc=srinivas.kandagatla@linaro.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.