linux-kernel - Re: [PATCH v2] MIPS: IP32: Add platform data hooks to use DS1685 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <551B7B19.30305@gentoo.org>
Date:	Wed, 01 Apr 2015 00:59:05 -0400
From:	Joshua Kinard <kumba@...too.org>
To:	Ralf Baechle <ralf@...ux-mips.org>
CC:	Alessandro Zummo <a.zummo@...ertech.it>,
	Linux/MIPS <linux-mips@...ux-mips.org>,
	rtc-linux@...glegroups.com, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] MIPS: IP32: Add platform data hooks to use DS1685
 driver

On 03/31/2015 06:56, Ralf Baechle wrote:
> On Thu, Feb 26, 2015 at 09:23:50PM -0500, Joshua Kinard wrote:
> 
>> This modifies the IP32 (SGI O2) platform and reset code to utilize the new
>> rtc-ds1685 driver.  The old mc146818rtc.h header is removed and ip32_defconfig
>> is updated as well.
> 
> In general - good cleanup.  But:
> 
>> index 511e9ff..ec9eb7f 100644
>> --- a/arch/mips/sgi-ip32/ip32-platform.c
>> +++ b/arch/mips/sgi-ip32/ip32-platform.c
> [...]
>>  MODULE_AUTHOR("Ralf Baechle <ralf@...ux-mips.org>");
>>  MODULE_LICENSE("GPL");
>> -MODULE_DESCRIPTION("8250 UART probe driver for SGI IP32 aka O2");
>> +MODULE_DESCRIPTION("IP32 platform setup for SGI IP32 aka O2");
> 
> This isn't even a kernel module so I've just nuked all these MODULE_*
> calls.

Works for me, thanks!

>> diff --git a/arch/mips/sgi-ip32/ip32-reset.c b/arch/mips/sgi-ip32/ip32-reset.c
>> index 44b3470..ef21706 100644
>> --- a/arch/mips/sgi-ip32/ip32-reset.c
>> +++ b/arch/mips/sgi-ip32/ip32-reset.c
> [...]
>> -static void ip32_machine_restart(char *cmd)
>> +static __noreturn void ip32_poweroff(void *data)
>>  {
>> -	crime->control = CRIME_CONTROL_HARD_RESET;
>> -	while (1);
>> -}
>> +	void (*poweroff_func)(struct platform_device *) =
>> +		symbol_get(ds1685_rtc_poweroff);
>> +
>> +#ifdef CONFIG_MODULES
>> +	/* If the first __symbol_get failed, our module wasn't loaded. */
>> +	if (!poweroff_func) {
>> +		request_module("rtc-ds1685");
>> +		poweroff_func = symbol_get(ds1685_rtc_poweroff);
>> +	}
>> +#endif
> 
> symbol_get() calls are high on my list of items that indicate a piece of
> code is probably ill-structured.

That was the only function I could find that would attempt to fetch the
ds1685_rtc_poweroff() function from kernel memory and return an indication of
success or failure that could be checked.  If there's a better way to do that,
I'll be happy to re-write that section.  I looked through the docs back then
and couldn't find another way that worked with and without modules.

> While RTCs often deal with power the RTC really only wants to deal with
> time and so power stuff should rather go elsewhere.  I suggest to take a
> look at drivers/power/reset/.  A small driver there could set pm_power_off
> approriately.  drivers/power/reset/restart-poweroff.c is a very compact
> example.

Except this code is in a file called "ip32-reset.c", and the original code
there did the exact same thing -- powered off the machine.  The
ds1685_rtc_poweroff() function is defined in the core DS1685 driver
(drivers/rtc/rtc-ds1685.c) that got added to linux-next a few weeks ago (no one
had any complaints about that).  This code just checks to see if the RTC driver
is loaded and then calls that function to power the machine down.

IP30 uses a similar setup as well, since both machines share the same RTC
chip/family.

>> @@ -190,15 +141,12 @@ static __init int ip32_reboot_setup(void)
>>  
>>  	_machine_restart = ip32_machine_restart;
>>  	_machine_halt = ip32_machine_halt;
>> -	pm_power_off = ip32_machine_power_off;
>> +	pm_power_off = ip32_machine_halt;
> 
> So halt and power_off no do the same?
> 

They always did.  This is the original ip32_machine_halt function:

static inline void ip32_machine_halt(void)
{
       ip32_machine_power_off();
}

I just got rid of the added level of misdirection and set both _machine_halt
and pm_power_off to call the same function (especially since there's no
sleeping these kinds of machines -- maybe hibernate, but that'll still properly
poweroff).  Seemed the logical thing to do.  In either case, it'll lead to the
RTC driver handling the poweroff routine, which seems to be the only way SGI
designed these machines to power off.  I'll wager the ARCS firmware internally
does the same thing.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@...too.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/