busybox: Fix rtcwake to use /dev/rtc0 properly

rtcwake from busybox has failed in case the /dev/rtc is a symlink (which is default case for udev enabled systems) due to wrong pathname used for a sysfs wakeup attribute.

Signed-off-by Andy Shevchenko <[email protected]>

---
 ...bb-Try-dev-rtc0-first-followed-by-dev-rtc.patch | 45 ++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 package/busybox/0006-libbb-Try-dev-rtc0-first-followed-by-dev-rtc.patch

package/busybox/0006-libbb-Try-dev-rtc0-first-followed-by-dev-rtc.patch new file +45 -0

new file mode 100644
index 0000000000..0702c3c065
@@ -0,0 +1,45 @@
+From b59088ab14fb9c336414e2c9b27a9f5b7447ce5b Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <[email protected]>
+Date: Thu, 23 Nov 2017 19:33:08 +0200
+Subject: [PATCH v1] libbb: Try /dev/rtc0 first followed by /dev/rtc
+
+In case we run
+
+% rtcwake -s5 -mmem
+
+in udev environment we will get an error:
+
+rtcwake: /dev/rtc not enabled for wakeup events
+
+because /dev/rtc is a symlink to /dev/rtc0 in Buildroot and other Linux
+distributions (like Fedora) and make_wakeup() obviously fails.
+
+As a quick fix just reorder probe of device nodes to try /dev/rtc0
+first.
+
+The proper solution, of course much expensive by code footprint,
+is to resolve /dev/rtc to a proper device node and then
+to follow sysfs attributes.
+
+Signed-off-by: Andy Shevchenko <[email protected]>
+---
+ libbb/rtc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libbb/rtc.c b/libbb/rtc.c
+index c4117ba34..e087a8fd6 100644
+--- a/libbb/rtc.c
++++ b/libbb/rtc.c
+@@ -64,8 +64,8 @@ int FAST_FUNC rtc_xopen(const char **default_rtc, int flags)
+ {
+ 	int rtc;
+ 	const char *name =
+-		"/dev/rtc""\0"
+ 		"/dev/rtc0""\0"
++		"/dev/rtc""\0"
+ 		"/dev/misc/rtc""\0";
+ 
+ 	if (!*default_rtc)
+-- 
+2.15.0
+

Hi Andy,

Quoted 4 lines · Andy Shevchenko

rtcwake from busybox has failed in case the /dev/rtc is a symlink (which is default case for udev enabled systems) due to wrong pathname
used for a sysfs wakeup attribute.

In Buildroot, we don't accept "feature patches" for packages.

We try to limit
to patches that fix the build or complete breakage, sometimes also to make it
work together with other packages. I think this patch doesn't fall in that category.

For sure, you should first send the patch upstream.

Particularly in the case of
busybox, Denys often proposes improved patches. If it gets accepted upstream,
then we can consider including it in Buildroot as well.

Quoted 8 lines · Arnout Vandecappelle

Hi Andy,

Quoted 4 lines · Andy Shevchenko

rtcwake from busybox has failed in case the /dev/rtc is a symlink (which is default case for udev enabled systems) due to wrong pathname
used for a sysfs wakeup attribute.

Quoted 1 line

In Buildroot, we don't accept "feature patches" for packages.

To be honest it's not a feature patch at all. It fixes (okay, workarounds) obvious bug in rtcwake logic. Easy to reproduce. 100% reproducible

Quoted 2 lines

We try to limit
to patches that fix the build or complete breakage, sometimes also to

Quoted 3 lines

make it
work together with other packages. I think this patch doesn't fall in that category.

Whatever, your choice at the end.

Quoted 2 lines

For sure, you should first send the patch upstream.

Are you sure I didn't?

The policy of Busybox mailing list is to reject (I'm not subscriber and

after a such policy would not like to be one). Happy contribution!

Quoted 4 lines

Particularly in the case of
busybox, Denys often proposes improved patches. If it gets accepted upstream,
then we can consider including it in Buildroot as well.

Good luck!

I'm done with it. If Denys is caring about project he will take the series (there are more patches than just one) from his private mailbox (Cc was there as well).

Hi Andy,

Sorry, I should have started my mail with:

Thank you very much for your contributation. I'm afraid, however, we
will not
accept it as is in Buildroot.

Quoted 5 lines

Quoted 1 line

In Buildroot, we don't accept "feature patches" for packages.

To be honest it's not a feature patch at all. It fixes (okay, workarounds) obvious bug in rtcwake logic. Easy to reproduce. 100% reproducible

Yes, that's why I continued with:

Quoted 3 lines

Quoted 3 lines

We try to limit
to patches that fix the build or complete breakage, sometimes also to

              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For other bugs, we will happily include upstream patches. But patches
that are
not yet upstream are dangerous: how can we be sure that it doesn't break things?
In this particular case, you patch *will* actually break things for a who does
have a working /dev/rtc but it is something different than /dev/rtc0. We want
upstream to take the responsibility for that.

Quoted 3 lines

Quoted 1 line

For sure, you should first send the patch upstream.

Are you sure I didn't?

I checked the mailing list, it wasn't there. I checked google, and
found nothing.

Quoted 2 lines

The policy of Busybox mailing list is to reject (I'm not subscriber and

Buildroot mailing list has the same policy (well, it goes into a
moderation
queue but that is filled up with so much spam that it's unlikely it ever makes
it to the list).

If you have a solution to bar spam from mailing lists, please
share it!

Quoted 10 lines

after a such policy would not like to be one). Happy contribution!

Quoted 5 lines

Particularly in the case of
busybox, Denys often proposes improved patches. If it gets accepted
upstream,
then we can consider including it in Buildroot as well.

Good luck!

Quoted 4 lines

I'm done with it. If Denys is caring about project he will take the series (there are more patches than just one) from his private mailbox
(Cc was there as well).

If/when he does, feel free to resubmit with a reference to the
upstream commit.