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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5043C005.8060907@metafoo.de>
Date:	Sun, 02 Sep 2012 22:22:29 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Thierry Reding <thierry.reding@...onic-design.de>
CC:	Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org,
	Antony Pavlov <antonynpavlov@...il.com>,
	Maarten ter Huurne <maarten@...ewalker.org>
Subject: Re: [PATCH 3/3] pwm: Add Ingenic JZ4740 support

On 09/02/2012 09:59 PM, Thierry Reding wrote:
>>> +	is_enabled = jz4740_timer_is_enabled(pwm->hwpwm);
>>> +	if (is_enabled)
>>> +		pwm_disable(pwm);
>>
>> I think this should be jz4740_pwm_disable
>>
>>> +
>>> +	jz4740_timer_set_count(pwm->hwpwm, 0);
>>> +	jz4740_timer_set_duty(pwm->hwpwm, duty);
>>> +	jz4740_timer_set_period(pwm->hwpwm, period);
>>> +
>>> +	ctrl = JZ_TIMER_CTRL_PRESCALER(prescaler) | JZ_TIMER_CTRL_SRC_EXT |
>>> +		JZ_TIMER_CTRL_PWM_ABBRUPT_SHUTDOWN;
>>> +
>>> +	jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
>>> +
>>> +	if (is_enabled)
>>> +		pwm_enable(pwm);
>>
>> and jz4740_pwm_enable here.
> 
> I wonder if this is actually required here. Can the timer really not be
> reprogrammed while enabled?
>

It can, but we've observed this to cause permanent glitches until the timer is
reprogrammed again.

>>> +{
>>> +	struct jz4740_pwm_chip *jz4740 = platform_get_drvdata(pdev);
>>> +	int ret;
>>> +
>>> +	ret = pwmchip_remove(&jz4740->chip);
>>> +	if (ret < 0)
>>> +		return ret;
>>
>> remove is not really allowed to fail, the return value is never really tested
>> and the device is removed nevertheless. But this seems to be a problem with the
>> PWM API. It should be possible to remove a PWM chip even if it is currently in
>> use and after a PWM chip has been removed all calls to a pwm_device of that
>> chip it should return an error. This will require reference counting for the
>> pwm_device struct though. E.g. by adding a 'struct device' to it.
> 
> I beg to differ. It shouldn't be possible to remove a PWM chip that
> provides requested PWM devices. All other drivers do the same here.

Part of the Linux device driver model is that that a device may appear or
disappear at any given time (if the kernel has been compiled with
CONFIG_HOTPLUG). So you can't prevent removal. The fact that the remove
callback function return an int is kind of misleading and should probably be
fixed at some point. The return value is never checked and the device will be
removed nevertheless. So the PWM subsystem must cope with the case where the
PWM chip is removed while some of its pwm_devices are still in use.

[...]
>>
>>> +};
>>> +module_platform_driver(jz4740_pwm_driver);
>>
>> MODULE_LICENSE(...), MODULE_AUTHOR(...), MODULE_DESCRIPTION(...), MODULE_ALIAS(...)
> 
> Those weren't present previously. I suppose they should be "GPL", you,
> "Ingenic JZ4740 PWM driver" and "platform:jz4740-pwm", respectively?

Yes, sounds good. The old code couldn't be build as a module, so these were not
necessary previously.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ