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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240227022919856ffa1d@mail.local>
Date: Tue, 27 Feb 2024 03:29:19 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: antoniu.miclaus@...log.com, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	jdelvare@...e.com, linux@...ck-us.net, linux-rtc@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-hwmon@...r.kernel.org,
	Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
	Zeynep Arslanbenzer <Zeynep.Arslanbenzer@...log.com>
Subject: Re: [PATCH v8 1/2] rtc:  max31335: Add support for additional chips

On 27/02/2024 14:03:09+1300, Chris Packham wrote:
> -	max31335->clkout.clk = devm_clk_get_enabled(dev, NULL);
> -	if (IS_ERR(max31335->clkout.clk))
> -		return dev_err_probe(dev, PTR_ERR(max31335->clkout.clk),
> -				     "cannot enable clkout\n");

This is so ugly and should have never passed. I went weak in front of
Antoniu's insistance but I'm very close from ripping out the whole
driver from the kernel now.

Seriously, read all the comments that have been made around the IRQ/clk
stuff and come back with a proper solution.

> +static int max31335_irq_init(struct device *dev, const char *devname)
> +{
> +	struct max31335_data *max31335 = dev_get_drvdata(dev);
> +	int ret;
> +
> +	switch (max31335->id) {
> +	case ID_MAX31328:
> +		break;
> +	case ID_MAX31331:
> +	case ID_MAX31334:
> +		if (max31335->clkout.clk) {
> +			/*
> +			 * interrupt muxing depends on clkout so enable clkout
> +			 * if configured before requesting interrupt
> +			 */
> +			ret = clk_prepare_enable(max31335->clkout.clk);

Do I get this right that this is about enabling its own output clock?
Why would you need to do that? Something else must be the consumer, not
the provider itself.

> +			if (ret)
> +				return dev_err_probe(dev, ret,
> +						     "cannot enable clkout\n");
> +		}
> +		break;
> +	default:
> +		if (max31335->clkin) {
> +			if (max31335->clkout.clk && max31335->irq > 0)
> +				return dev_err_probe(dev, -EOPNOTSUPP,
> +						     "irq not possible when both clkin and clkout are configured\n");

This is not true, the RTC is always a clock provider. What is not
possible is muxing the clock on the pin in a few configurations.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ