Building this driver with "clang -O3" produces a link error
after the compiler partially unrolls the loop and 256ms
becomes a compile-time constant that triggers the check
in udelay():
ld.lld: error: undefined symbol: __bad_udelay
>>> referenced by applesmc.c
>>> hwmon/applesmc.o:(read_smc) in archive drivers/built-in.a
I can see no reason against using a sleeping function here,
as no part of the driver runs in atomic context, so instead use
usleep_range() with a wide range and use jiffies for the
end condition.
Signed-off-by: Arnd Bergmann <[email protected]>
---
drivers/hwmon/applesmc.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index ec93b8d673f5..316618409315 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -156,14 +156,19 @@ static struct workqueue_struct *applesmc_led_wq;
*/
static int wait_read(void)
{
+ unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
+
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- udelay(us);
+ usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
/* read: wait for smc to settle */
if (status & 0x01)
return 0;
+ /* timeout: give up */
+ if (time_after(jiffies, end))
+ break;
}
pr_warn("wait_read() fail: 0x%02x\n", status);
@@ -178,10 +183,11 @@ static int send_byte(u8 cmd, u16 port)
{
u8 status;
int us;
+ unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
outb(cmd, port);
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- udelay(us);
+ usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
/* write: wait for smc to settle */
if (status & 0x02)
@@ -190,7 +196,7 @@ static int send_byte(u8 cmd, u16 port)
if (status & 0x04)
return 0;
/* timeout: give up */
- if (us << 1 == APPLESMC_MAX_WAIT)
+ if (time_after(jiffies, end))
break;
/* busy: long wait and resend */
udelay(APPLESMC_RETRY_WAIT);
--
2.26.2
On Wed, May 27, 2020 at 03:51:57PM +0200, Arnd Bergmann wrote:
> Building this driver with "clang -O3" produces a link error
> after the compiler partially unrolls the loop and 256ms
> becomes a compile-time constant that triggers the check
> in udelay():
>
> ld.lld: error: undefined symbol: __bad_udelay
> >>> referenced by applesmc.c
> >>> hwmon/applesmc.o:(read_smc) in archive drivers/built-in.a
>
> I can see no reason against using a sleeping function here,
> as no part of the driver runs in atomic context, so instead use
> usleep_range() with a wide range and use jiffies for the
> end condition.
>
Me not either.
> Signed-off-by: Arnd Bergmann <[email protected]>
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/applesmc.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index ec93b8d673f5..316618409315 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -156,14 +156,19 @@ static struct workqueue_struct *applesmc_led_wq;
> */
> static int wait_read(void)
> {
> + unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
> u8 status;
> int us;
> +
> for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
> - udelay(us);
> + usleep_range(us, us * 16);
> status = inb(APPLESMC_CMD_PORT);
> /* read: wait for smc to settle */
> if (status & 0x01)
> return 0;
> + /* timeout: give up */
> + if (time_after(jiffies, end))
> + break;
> }
>
> pr_warn("wait_read() fail: 0x%02x\n", status);
> @@ -178,10 +183,11 @@ static int send_byte(u8 cmd, u16 port)
> {
> u8 status;
> int us;
> + unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
>
> outb(cmd, port);
> for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
> - udelay(us);
> + usleep_range(us, us * 16);
> status = inb(APPLESMC_CMD_PORT);
> /* write: wait for smc to settle */
> if (status & 0x02)
> @@ -190,7 +196,7 @@ static int send_byte(u8 cmd, u16 port)
> if (status & 0x04)
> return 0;
> /* timeout: give up */
> - if (us << 1 == APPLESMC_MAX_WAIT)
> + if (time_after(jiffies, end))
> break;
> /* busy: long wait and resend */
> udelay(APPLESMC_RETRY_WAIT);
On my late 2013 Macbook Pro, I have a couple of scripts that set the
fans to auto or full-speed:
fan-hi:
#!/bin/sh
sudo sh -c 'echo 1 > /sys/devices/platform/applesmc.768/fan1_manual
echo 1 > /sys/devices/platform/applesmc.768/fan2_manual
cat /sys/devices/platform/applesmc.768/fan1_max > /sys/devices/platform/applesmc.768/fan1_output
cat /sys/devices/platform/applesmc.768/fan2_max > /sys/devices/platform/applesmc.768/fan2_output'
fan-auto:
#!/bin/sh
sudo sh -c 'echo 0 > /sys/devices/platform/applesmc.768/fan1_manual
echo 0 > /sys/devices/platform/applesmc.768/fan2_manual'
Running ./fan-hi and then ./fan-auto on Linux v5.6 works and doesn't
cause any problems, but after updating to v5.9 I see this in dmesg:
[Nov 6 17:24] applesmc: send_byte(0x01, 0x0300) fail: 0x40
[ +0.000005] applesmc: FS! : write data fail
[ +0.191777] applesmc: send_byte(0x30, 0x0300) fail: 0x40
[ +0.000009] applesmc: F0Tg: write data fail
[ +7.097416] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[ +0.000006] applesmc: FS! : write data fail
and the fan controls don't work.
Googling turned up this [1] which looks like the same problem. They said
it began occurring between v5.7 and v5.8, so I looked and found this
commit.
After reverting commit fff2d0f701e6753591609739f8ab9be1c8e80ebb from
v5.9, I no longer see the errors in dmesg and the fan controls work
again.
Any ideas what the problem is?
Thanks,
Matt
[1] https://stackoverflow.com/questions/63505469/cant-write-data-to-applesmc-error-after-upgrade-to-arch-linux-kernel-5-8-1
On Fri, Nov 06, 2020 at 06:17:10PM -0500, Matt Turner wrote:
> On my late 2013 Macbook Pro, I have a couple of scripts that set the
> fans to auto or full-speed:
>
> fan-hi:
> #!/bin/sh
> sudo sh -c 'echo 1 > /sys/devices/platform/applesmc.768/fan1_manual
> echo 1 > /sys/devices/platform/applesmc.768/fan2_manual
> cat /sys/devices/platform/applesmc.768/fan1_max > /sys/devices/platform/applesmc.768/fan1_output
> cat /sys/devices/platform/applesmc.768/fan2_max > /sys/devices/platform/applesmc.768/fan2_output'
>
> fan-auto:
> #!/bin/sh
> sudo sh -c 'echo 0 > /sys/devices/platform/applesmc.768/fan1_manual
> echo 0 > /sys/devices/platform/applesmc.768/fan2_manual'
>
> Running ./fan-hi and then ./fan-auto on Linux v5.6 works and doesn't
> cause any problems, but after updating to v5.9 I see this in dmesg:
>
> [Nov 6 17:24] applesmc: send_byte(0x01, 0x0300) fail: 0x40
> [ +0.000005] applesmc: FS! : write data fail
> [ +0.191777] applesmc: send_byte(0x30, 0x0300) fail: 0x40
> [ +0.000009] applesmc: F0Tg: write data fail
> [ +7.097416] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ +0.000006] applesmc: FS! : write data fail
>
> and the fan controls don't work.
>
> Googling turned up this [1] which looks like the same problem. They said
> it began occurring between v5.7 and v5.8, so I looked and found this
> commit.
>
> After reverting commit fff2d0f701e6753591609739f8ab9be1c8e80ebb from
> v5.9, I no longer see the errors in dmesg and the fan controls work
> again.
>
> Any ideas what the problem is?
>
> Thanks,
> Matt
>
> [1] https://stackoverflow.com/questions/63505469/cant-write-data-to-applesmc-error-after-upgrade-to-arch-linux-kernel-5-8-1
>
There is another thread on this regression:
https://lore.kernel.org/lkml/20200930105442.3f642f6c@aktux/
Looks like Brad Campbell has a patch that has some success in fixing the
regression (although others are saying it breaks their setup...):
https://lore.kernel.org/lkml/[email protected]/
Might be worth giving it a shot and jumping in so you get CC'd on
further revisions.
Cheers,
Nathan