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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 08 Aug 2014 14:38:13 +0200
From:	Javier Martinez Canillas <>
To:	Bartlomiej Zolnierkiewicz <>
CC:	Krzysztof Kozlowski <>,
	Samuel Ortiz <>,
	Lee Jones <>,
	Doug Anderson <>,
	Kyungmin Park <>,,,
	Kukjin Kim <>
Subject: Re: [PATCH] mfd: max77686: fix support for devices without irq specified

On 08/08/2014 02:24 PM, Bartlomiej Zolnierkiewicz wrote:
> It seems that Daniel Drake has already fixed ODROID dtsi with:
>   [PATCH 1/2] ARM: dts: Enable PMIC interrupts on ODROID
> and
>   [PATCH 2/2] ARM: dts: ODROID i2c improvements
> Both patches are needed to fix boot on ODROID.  They also fix RTC driver
> registration:
> MFD driver error message with only patch #1 applied:
> [    0.164488] max77686 0-0009: failed to add RTC irq chip: -6
> RTC driver messages with both patches #1 and #2 applied:
> [    1.731461] max77686-rtc max77686-rtc: max77686_rtc_probe
> [    1.833303] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0


> Kukjin, could you please apply Daniel's fixes?  They are critical for ODROID
> boards.
> Javier, I think that it still would be useful to apply my patch for max77686
> as it makes new kernels work with older dtbs and leaves the possibility to
> use PMIC on boards without IRQ connected.  If you agree I will post v2 of
> the patch (with suspend/resume handlers fixed and bindings documentation
> updated).

Well it really depends on whether it is possible or not to have a design where a
IRQ line is not connected to the PMIC. If such a design makes sense then your
patch should be applied since the driver should not fail to probe in that case.

But then the DT binding doc should be changed and the "interrupt" property moved
from required to optional in order to reflect that it's not a requirement.

If the motivation is just to support old DTB then I tend to disagree since those
DTBs were not following the documented binding. Drivers should be robust enough
to not crash of course but if a required property is not defined in a DTB but
failing to probe is the right thing to do IMHO.

Best regards,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists