MAINTAINERS | 6 + drivers/mfd/cros_ec_dev.c | 9 + drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/cros_ec_wdt.c | 202 ++++++++++++++++++ .../linux/platform_data/cros_ec_commands.h | 78 +++---- 6 files changed, 264 insertions(+), 43 deletions(-) create mode 100644 drivers/watchdog/cros_ec_wdt.c
Chromeos devices are equipped with the embedded controller (EC) that can be used as a watchdog. The following patches updates the structures and definitions required to communicate with EC-based watchdog and implements the driver itself. The previous version of this patch was sent here: https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 Changelog V2->V3: * drop "-drv" from driver name * use format #define<space>NAME<tab>value Best regards, Lukasz Lukasz Majczak (3): platform/chrome: Update binary interface for EC-based watchdog watchdog: Add ChromeOS EC-based watchdog driver mfd: cros_ec: Register EC-based watchdog subdevice MAINTAINERS | 6 + drivers/mfd/cros_ec_dev.c | 9 + drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/cros_ec_wdt.c | 202 ++++++++++++++++++ .../linux/platform_data/cros_ec_commands.h | 78 +++---- 6 files changed, 264 insertions(+), 43 deletions(-) create mode 100644 drivers/watchdog/cros_ec_wdt.c -- 2.43.0.429.g432eaa2c6b-goog
On 1/19/24 00:43, Lukasz Majczak wrote: > Chromeos devices are equipped with the embedded controller (EC) > that can be used as a watchdog. The following patches > updates the structures and definitions required to > communicate with EC-based watchdog and implements the > driver itself. > > The previous version of this patch was sent here: > https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 > > Changelog > V2->V3: > * drop "-drv" from driver name > * use format #define<space>NAME<tab>value > I am a bit lost here. You dropped my Reviewed-by: tags, even though I specifically said that they applied with those changes made. Also, according to the above patch 1/3 was not changed at all. What else did you change that warrants dropping the tags ? Guenter
On Fri, Jan 19, 2024 at 1:50 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 1/19/24 00:43, Lukasz Majczak wrote: > > Chromeos devices are equipped with the embedded controller (EC) > > that can be used as a watchdog. The following patches > > updates the structures and definitions required to > > communicate with EC-based watchdog and implements the > > driver itself. > > > > The previous version of this patch was sent here: > > https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 > > > > Changelog > > V2->V3: > > * drop "-drv" from driver name > > * use format #define<space>NAME<tab>value > > > > I am a bit lost here. You dropped my Reviewed-by: tags, even though > I specifically said that they applied with those changes made. > Also, according to the above patch 1/3 was not changed at all. > > What else did you change that warrants dropping the tags ? > > Guenter > The "-drv" change was related to patch 2 and 3, and I have used "format #define<space>NAME<tab>value" only in patch 3 (as ec_commands.h is mixing those) Sorry for dropping your "Reviewed-by" tag :( I've assumed (wrong) that I cannot take it for granted sending V3. Alos in such a case if there are changes in patch 2 and 3 and 1 remains untouched shall I send only 2 and 3 in the next version ? Best regards, Lukasz
On 1/19/24 06:10, Łukasz Majczak wrote: > On Fri, Jan 19, 2024 at 1:50 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> On 1/19/24 00:43, Lukasz Majczak wrote: >>> Chromeos devices are equipped with the embedded controller (EC) >>> that can be used as a watchdog. The following patches >>> updates the structures and definitions required to >>> communicate with EC-based watchdog and implements the >>> driver itself. >>> >>> The previous version of this patch was sent here: >>> https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 >>> >>> Changelog >>> V2->V3: >>> * drop "-drv" from driver name >>> * use format #define<space>NAME<tab>value >>> >> >> I am a bit lost here. You dropped my Reviewed-by: tags, even though >> I specifically said that they applied with those changes made. >> Also, according to the above patch 1/3 was not changed at all. >> >> What else did you change that warrants dropping the tags ? >> >> Guenter >> > The "-drv" change was related to patch 2 and 3, and I have used > "format #define<space>NAME<tab>value" only in patch 3 (as > ec_commands.h is mixing those) > Sorry for dropping your "Reviewed-by" tag :( I've assumed (wrong) that > I cannot take it for granted sending V3. From Documentation/process/submitting-patches.rst: Both Tested-by and Reviewed-by tags, once received on mailing list from tester or reviewer, should be added by author to the applicable patches when sending next versions. However if the patch has changed substantially in following version, these tags might not be applicable anymore and thus should be removed. Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned in the patch changelog (after the '---' separator). > Alos in such a case if there are changes in patch 2 and 3 and 1 > remains untouched shall I send only 2 and 3 in the next version ? > Again, from Documentation/process/submitting-patches.rst: ... the patch (series) and its description should be self-contained. This benefits both the maintainers and reviewers. Some reviewers probably didn't even receive earlier versions of the patch. Note that the same document also says: Wait for a minimum of one week before resubmitting or pinging reviewers - possibly longer during busy times like merge windows. I could just send another series of Reviewed-by: tags, but quite frankly by now I am wary that you might drop those again, so I guess I'll wait a while to see if there is another version of the series. Guenter
Gunter, I'm sorry for the confusion, I've just forgotten to add "received-by" and there are no other changes besides mentioned in the cover letter changelog. Thank you for mentioning the process, now I understand why it is so important. I will send V4 for the sake of following the process. Best regards, Lukasz On Fri, Jan 19, 2024 at 3:43 PM Guenter Roeck <linux@roeck-us.net> wrote: > > On 1/19/24 06:10, Łukasz Majczak wrote: > > On Fri, Jan 19, 2024 at 1:50 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> > >> On 1/19/24 00:43, Lukasz Majczak wrote: > >>> Chromeos devices are equipped with the embedded controller (EC) > >>> that can be used as a watchdog. The following patches > >>> updates the structures and definitions required to > >>> communicate with EC-based watchdog and implements the > >>> driver itself. > >>> > >>> The previous version of this patch was sent here: > >>> https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 > >>> > >>> Changelog > >>> V2->V3: > >>> * drop "-drv" from driver name > >>> * use format #define<space>NAME<tab>value > >>> > >> > >> I am a bit lost here. You dropped my Reviewed-by: tags, even though > >> I specifically said that they applied with those changes made. > >> Also, according to the above patch 1/3 was not changed at all. > >> > >> What else did you change that warrants dropping the tags ? > >> > >> Guenter > >> > > The "-drv" change was related to patch 2 and 3, and I have used > > "format #define<space>NAME<tab>value" only in patch 3 (as > > ec_commands.h is mixing those) > > Sorry for dropping your "Reviewed-by" tag :( I've assumed (wrong) that > > I cannot take it for granted sending V3. > > From Documentation/process/submitting-patches.rst: > > Both Tested-by and Reviewed-by tags, once received on mailing list from tester > or reviewer, should be added by author to the applicable patches when sending > next versions. However if the patch has changed substantially in following > version, these tags might not be applicable anymore and thus should be removed. > Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned > in the patch changelog (after the '---' separator). > > > Alos in such a case if there are changes in patch 2 and 3 and 1 > > remains untouched shall I send only 2 and 3 in the next version ? > > > > Again, from Documentation/process/submitting-patches.rst: > > ... the patch (series) and its description should be self-contained. > This benefits both the maintainers and reviewers. Some reviewers > probably didn't even receive earlier versions of the patch. > > Note that the same document also says: > > Wait for a minimum of one week before resubmitting or pinging reviewers > - possibly longer during busy times like merge windows. > > I could just send another series of Reviewed-by: tags, but quite frankly > by now I am wary that you might drop those again, so I guess I'll wait > a while to see if there is another version of the series. > > Guenter >
Ohhh, I get it now. Gunter please send reviewed-by to V3 whenever you feel appropriate. Best regards, Lukasz On Fri, Jan 19, 2024 at 3:50 PM Łukasz Majczak <lma@chromium.org> wrote: > > Gunter, > > I'm sorry for the confusion, I've just forgotten to add "received-by" > and there are no other changes besides mentioned in the cover letter > changelog. > Thank you for mentioning the process, now I understand why it is so important. > > I will send V4 for the sake of following the process. > > Best regards, > Lukasz > > On Fri, Jan 19, 2024 at 3:43 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > On 1/19/24 06:10, Łukasz Majczak wrote: > > > On Fri, Jan 19, 2024 at 1:50 PM Guenter Roeck <linux@roeck-us.net> wrote: > > >> > > >> On 1/19/24 00:43, Lukasz Majczak wrote: > > >>> Chromeos devices are equipped with the embedded controller (EC) > > >>> that can be used as a watchdog. The following patches > > >>> updates the structures and definitions required to > > >>> communicate with EC-based watchdog and implements the > > >>> driver itself. > > >>> > > >>> The previous version of this patch was sent here: > > >>> https://patchwork.kernel.org/project/linux-watchdog/list/?series=817925 > > >>> > > >>> Changelog > > >>> V2->V3: > > >>> * drop "-drv" from driver name > > >>> * use format #define<space>NAME<tab>value > > >>> > > >> > > >> I am a bit lost here. You dropped my Reviewed-by: tags, even though > > >> I specifically said that they applied with those changes made. > > >> Also, according to the above patch 1/3 was not changed at all. > > >> > > >> What else did you change that warrants dropping the tags ? > > >> > > >> Guenter > > >> > > > The "-drv" change was related to patch 2 and 3, and I have used > > > "format #define<space>NAME<tab>value" only in patch 3 (as > > > ec_commands.h is mixing those) > > > Sorry for dropping your "Reviewed-by" tag :( I've assumed (wrong) that > > > I cannot take it for granted sending V3. > > > > From Documentation/process/submitting-patches.rst: > > > > Both Tested-by and Reviewed-by tags, once received on mailing list from tester > > or reviewer, should be added by author to the applicable patches when sending > > next versions. However if the patch has changed substantially in following > > version, these tags might not be applicable anymore and thus should be removed. > > Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned > > in the patch changelog (after the '---' separator). > > > > > Alos in such a case if there are changes in patch 2 and 3 and 1 > > > remains untouched shall I send only 2 and 3 in the next version ? > > > > > > > Again, from Documentation/process/submitting-patches.rst: > > > > ... the patch (series) and its description should be self-contained. > > This benefits both the maintainers and reviewers. Some reviewers > > probably didn't even receive earlier versions of the patch. > > > > Note that the same document also says: > > > > Wait for a minimum of one week before resubmitting or pinging reviewers > > - possibly longer during busy times like merge windows. > > > > I could just send another series of Reviewed-by: tags, but quite frankly > > by now I am wary that you might drop those again, so I guess I'll wait > > a while to see if there is another version of the series. > > > > Guenter > >
© 2016 - 2026 Red Hat, Inc.